On Tue, 9 Mar 2010, Kai Schaetzl wrote:
Second: you are completely misguided in your wish to reject mail after
SMTP data stage.
You may certainly argue for YOUR preference (and I emphasise *preference*)
for the most 'efficient' way to run an SMTP server, but there is nothing
sufficiently 'wrong' with rejecting mail after DATA that you can use the
term 'misguided'. All this term implies is your attitude....
Apart from this, you make some nice arguments, but again, you seem to
have a bias that weighs them too heavily.
It does not make any sense to process a complete message and then
reject it.
If this were true, no one would have added 'header' and 'body' checks to
the postfix configuration.... and no one would have been jumping through
hoops to find ways to integrate SA into the front end of MTA's....
Indeed, it makes far LESS sense to have a system accept mail but send it
to a spam folder. That practice leaves the sender with the mistaken
impression that their mail was sucessfully delivered. And argue as you
will, there is simply no way to get a broad user base to adopt the habit
of reviewing a spam folder. I mean the whole point of filtering is that
the user no longer has to sift through a pile of junk, right?
Processing a message takes CPU power and precious SMTP time. Doing that
at SMTP stage means you cannot take in as much mail as you could. It
also means that the sending MTA cannot send as much mail as it could.
Think about that statement twice. It IS correct, but it is an argument FOR
processing mail at SMTP time. A legitimate outbound SMTP sever is *never*
as busy as an incoming mail server. So a leigitimate server will not
suffer *any* penalty from my system introducing a 5-6 second delay into
the SMTP transaction. But a spammer's zombie is trying to pump out mail as
fast as it can. The spambot will be slowed down. That is a GOOD thing.
Yes? :)
There are other reasons not to do this, for instance legal ones.
Again, you are quoting arguments that favor SMTP reject. It is better to
reject a mail, so that legitimate senders know it, rather than have them
believe it was delivered when it was sent into a spam folder, perhaps
suffer consequences and then sue the recipient. Sure, OUR butts will be
covered by our user agreements, but only if we have jumped through hoops
so that the user cannot claim they did not "know" about their spam
folder. But in the real world, even if we don't get sued, we get a lot of
people complaining that they didn't know about the optional spam folder
on our system that the user turned ON themselves! Now we use a spam
folder for 'borderline' spams that score 5-10. The rest get rejected at
SMTP time. But still I get these occasional complaints.... It's just the
way users are.... LOL
The idea is not to "punish" the other side because it sends spam.
If they send spam, I'm happy to see them "punished". If they send
legitimate mail, they should not be "punished" for the actions of spammers
by having to GUESS whether their mail made it through.
The idea behind a rejection at SMTP stage is twofold: avoid unnecessary
processing and avoid unncessary traffic. None of that is achieved if you
take a whole message, scan it and reject it at SMTP stage.
Well, firstly, ALL of that is achieved *regardless* of these arguments
because the helo/rbl checks are done BEFORE the DATA stage. The only
'loss' of time is on mail that you were going to have to fully process
anyway because it made it past those checks. No loss to me. A few seconds
delay on the SMTP connectino that saves a legitimate sender worry without
incurring the 'cost' of backscatter, and actually might slow spammers down
a bit..... Maybe I personally don't gain any time. But maybe by the end of
the day the spammer doesn't get to send quite as many e-mails, and someone
out there enjoys less traffic on their server!
- Charles
