Charles Gregory wrote:
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
This is one of the stupidest arguments in this thread
NOBODY is "legally required" to accept e-mail. That is a crock of baloney.
A mailserver operator MAY have a contract to "accept all e-mail" with a
specific entity, but if the server admin rejects spam then ALL they are
POSSIBLY in violation of is simple breech of contract - and they can
merely argue that spam is NOT by definition "e-mail" since it lacks any
usable information, it is an abuse of the e-mail system. Thus that
would have to be a server contract that specifically defined receiving
spam - quite an odd contract at that.
It is NOT "illegal" to break a contract. It it were then the prisons
would be stuffed with people who defaulted on their credit cards. It
is a civil matter handled by civil proceedings.
Ted
