huey.callison@gmail.com wrote:

"Stop spam"??!? What's the point of that?!

--
Requiescas in pace o email

Ex turpi causa non oritur actio

http://members.cox.net/larrysheldon/

Add Homonym snerts-r-us.org> wrote:

How is that either 'a good compromise' or 'fair'? The anti-spam
movement has been telling senders that they need to do confirmed
opt-in on all of their mailings, or risk being blocked. Now, we're
blocking the confirmations? How are they supposed to do confirmed
opt-in if they just get blocked anyway? Mental telepathy?

The act of blocking confirmation emails penalizes the good guys while
doing nothing to the bad guys, since they don't send confirmation
emails. How does that help stop spam?

--
Huey

In article ,
Jem Berkes users.pc9.org> wrote:

"Dead" may be considered the equivalent of 4xx, so won't result in
unsubscription.

I'd recommend a couple of months to be on the safe side; some lists
don't mail every day (or week or perhaps month).

Others' experiences have found that even 5 years will leave you plenty
of spam to list.

Seth

In article <45e34939$0$3158$ae4e5890@news.nationwide.net>,
Larry M. Smith FahQ2.com> wrote:

What is your definition of spam?

I use "unsolicited bulk email".

Backscatter is unsolicited; I didn't ask 100 machines in Russia I never
heard of to send me anything.

Backscatter is bulk; I've received thousands of backscatters.

Backscatter is email; it has all the appropriate headers, came via
Port 25, etc.

So where does your definition differ?

Seth

Please publish your list here too. (Or a URL if it's too big.)

--
These are my opinions, not necessarily my employer's. I hate spam.

NFN Smith sacbeemail.com> wrote in news:jz3Dh.2698$3W4.1719
@newsfe21.lga:

Oh yeah, this can happen.

The whole issue came up because a lot of mailing lists were hitting my
spamtrap. These addresses (the whole domain) had been dead for at least a
year, but I thought maybe not explicitly bouncing with 5xx.

So I set up the MX to bounce everything with 5xx no such user, been doing
this for days to give any legitimate mailing lists a chance.

Some have stopped mailing, most have not. They will get blacklisted.

On Mon, 26 Feb 2007 14:22:16 GMT Larry M. Smith fahq2.com> wrote:

| The point I'm trying to make is that backscatter not quite the same
| problem as spam. It is still a problem, but needs to be addressed with
| better precision than just the one-size fits all anti-spam mallet.

Convince me. Regardless of what you or I call it, it is a sufficient
problem that I justify SMTP de-peering for. That means if you deploy a
mail server that sends backscatter, you can expect that I will refuse to
take any email from that server. I happen to call it "spam". So it seems
you do not. Do you even have a term that covers all of these things?

| What we need is practical solutions to deal with backscatter, and
| looking at backscatter as spam will not get us there. Not all
| backscatter is related to spammers forging sender's envelopes.

Whether it is labeled "spam" or not, I have my solution. Do you have a
convincing reason I should change to a different solution (hint: it must
not cost me any more than the one I have in place now).

On Mon, 26 Feb 2007 14:02:14 GMT Larry M. Smith fahq2.com> wrote:
| Shmuel (Seymour J.) Metz wrote:
| (snip)
|>> The RFCs dictate what, when, and how NDNs will be sent.
|>
|> No. RFC 2821 allows you to reject e-mail during the SMTP session; it's
|> disingenuous to blame the decision to send backscatter on RFC 2821.
|
| Doesn't matter, when a failure happens the last server left holding the
| message is required to send the NDN.

Please, remove ip 195.225.128.41 of the black list.

======================================= MODERATOR'S COMMENT:

news.admin.net-abuse.blocklisting IS NOT a blocklist removal request
queue.

Hi all,

Facts are:
Spammers try to discredit blacklists, by getting innocent people listed.

Problem for Spammers:
Not only they can learn how blacklists work, blacklists can also learn how
Spammers are sabotaging blacklist :-)

We know found a very effective way to prevent inadvert blockings.

Policies only describes what *can* be listed under which circumstances.
That means doing something which is a listing criteria *might* result in a
listing, but a spammer can no longer be sure that it really happens :-)

Reason: All trapservers will only nominate for listings now.

Nominated IP's will be checked against secret internal routines, which will
prevent inadvert listings.

This new routines will not be published.
Spammers will not be able to figure out what exactley we are doing here :-)
It is just too complex ...

The only thing you will be know for sure, that things which do not match
listing criterias, will also *never* get listed in the future.