Mike Cardwell wrote:
On 11/02/2010 17:08, Bernd Petrovitsch wrote:
Let me explain this in simple terms.
Normal behaviour:
Spam filtering causes a 5xx rejection. You get an NDR. You either
contact the user some other way or not at all.
Spam filtering rejects valid non-spam because it mis-identified it as
"spam".
Yes. It's called a "false positive".
Behaviour on my system:
Spam filtering causes a 5xx rejection. You get an NDR. You either
contact the user some other way or not at all. But ... the recipient can
Spam filtering rejects valid non-spam because it mis-identified it as
"spam". Now *I* have to do something to work around *Your* buggy/screwed
spamcheck.
No different to a normal situation where the features I've described
aren't in place.
You just have to hope that I´m really, really that interested to my mail
through. If it's an answer per PM to e.g. typical ML mails (like this
here), you would loose.
No different to a normal situation where the features I've described
aren't in place.
still access the email if it's something they were expecting, *and* if
the sender still wants to contact the recipient they now have an *extra*
option to make their life easier - they can click a URL and fill in a
captcha.
So ... my system provides 2 extra little features which makes some
senders and some recipients lives more easy.
No, you are pushing effort from your side out to others. If you want to
do something for the (valid) sender, fix the FP rate by changing
whatever it needs so that my on-spam mail gets through.
Ridiculous claim. In a normal situation the effort relies on the sender
to get their mail through after a false positive occurs, or it wont get
through at all.
With the 2 features I described, the sender is provided with an extra
simple option to get the mail through, and the recipient has also been
provided with an option to get the mail through.
Neither sender nor recipient would benefit from me removing those
features from my system.
Of course anyone can do as they think it´s best. But that doesn´t imply
that other think the same.
I want you to describe a scenario where the sender or recipient are
actually worse off because of the particular two features I've
described. You've failed to even attempt that so far.
I know this system works well because I've been using it for a long time.
I'm going to make 2 points here since you all hijacked my thread for
this discussion, I feel I have the right to. ;-)
First of all with regards to accepting then processing mail, that's
bogus. It's imperative to issue an error 5xx to the sending server
before the server closes TCP connection, if your going to reject the
mail. Otherwise if you accept the message, your telling the spammer
that they have a valid e-mail address, even if such a recipient address
does not exist on your system, and your then encouraging them to spam.
The claim that amavisd* variants accept then process mail
is nonsense, nobody who runs a large mailserver with amavisd could
possibly have their server configured in this manner without it melting
down, so please no more of this ridiculous talk.
Secondly with regards to this reject-but-save system that Mike is
expounding on - it is an instance of a system that only works because
a few people (or one person) is doing it. It is totally worthless as
anything that can be scaled to multiple sites for a very simple reason.
Right now one of the constants in the e-mail universe is that an error
5xx means you failed to deliver your mail.
If many people deploy "reject-but-save-a-copy" then this breaks that
assumption and the spammers response is extremely predictable - they
will simply assume that EVERY error 5xx carries with it a chance for
a successful delivery - so they will then program their spambots to
continually retry no matter what the error.
Right now if their spambot gets an error 5xx it schedules the victim
address for removal - because the spambot only has a limited amount of
time it can do things on whatever host system it has hijacked, and it
can't spend time sending to addresses that are rejected when there are
so many more out there that will accept the spam.
If you remove that assumption by having a lot of sites deploy this
hack of Mike's, then the spambots will simply continually send to
millions of nonexistent e-mail addresses on your server - because
of the chance that your running the Mike Hack and those nonexistent
addresses your telling the spambot that are nonexistent are really
existing.
The spammers don't care that their spam is delivered to a junk mail
folder. If the user isn't automatically deleting their junkmail unread
(in which case there's no point in the Mike Hack in the first place)
then they ARE having to periodically read at least the subject lines
of messages in the Junk Mail folder. In short, the Mike Hack only has
value if the users are periodically opening up and reading the subject
lines of messages in the Junk Mail folder.
And the spammers thought is that their spam is so attractive that
all the user has to do is read the subject line and they will open
it. They aren't thinking "my spam got delivered to someone's junk
mail folder, boo hoo" They are thinking "Zowie, my mail got delivered
to someone's folder - it's just going to be a few more weeks and I'll
be rich, yipee yipee!!" Spammers are the most optimistic people you
will ever meet. Only an optimist would think that the sewage they send
out is something that people want to read.
Mike I'm not sure why you think this hack of yours is so clever. It's
just a cheap hack. I can think of a dozen more for filtering spam,
some I've read other people expounding on over the years as the
greatest thing since sliced bread, all of which work - and all of
which are totally unscalable.
If you want to write a clever spam filter than write one that everyone
can use. Otherwise the more you defend this, the more you look like
an inexperienced mail admin who knows just enough to be dangerous.
Ted
