On Wed, 12 Mar 2003, Vernon Schryver wrote:
Based on my tests less then half of mail servers will accept 500 error
after data command (those are mostly the ones that support limits on size
of emails - SIZE ESMTP extension I believe).
I'd like to believe that you've only hit bad patch of SMTP clients.
Since I was testing mail servers that connected to my mail server,
possibly the data was contaminated by spammers who just dont take no (500)
for an answer.
My review of solutions shows that most would require additions to SMTP
such that email server can not make a decision after RCPT and TO command
and only can do it either after all headers are received or after main
body of email is received. What I really would like is ability for
receiving mail server to get data or parts of it (particular header,
mime structure of the email, particular mime object) out of band before
making final decision on accepting or rejecting entire email.
...
Again, why do that when the protocol already includes sufficient
provisions for examining headers or data before making a final decision?
After you receive entire email though... Why wase so much bandwidth when
75% of spam can be rejected based on just incorrect headers and most
solutions require using special headers for additional information on
authentication as well allowing to distiguish between standard mail and
authenticated email.
But that you can't easily bounce email and filter
during DATA transmission is very unfortunate and puts many email filters
in the position of returning unwanted email (to FROM command, which is
often invalid and thus wasting servers resources) instead of bouncing it
at the transmission.
I don't understand that. If your SMTP server says 5yz to the STMP
client and incorrectly assumes that client is not junk, then it won't
know that no bouce was generated. That no bounce is generated in this
case is no more the responsibility of the rejecting SMTP server than
any other bug that causes the other machine to fail to generate a
bounce when it should.
I'm way confused by what you wrote. What I meant is that there is a difference
between how blacklists work (when SMTP servers responds with 500 just based on
your ip) and how spam filters work (which scans the email, trys to
classify it as spam and it is - its either discards it or bounced back to
the sender or sent to special spam folder). I'd rather have filtering do
like blacklists and either return an error (instead of discarding or
trying to send email back) or accept it (either to spam folder or to
normal folder).
What SMTP lacks is a way to say in response to the DATA command "reject
for the 1st recipeint, accept for the 2nd, and temp-fail for the 3rd."
To the DATA command ou can only say accept, reject, or temp-fail for
all recipients togehter.
I agree - this is also really really needed.
What else I'd find usefull is automated way to say that it requires
certain type of authentication for email to be accepted (and not just that
it requires authentication as is possible now).
--
William Leibzon
Elan Communications Inc.
william(_at_)elan(_dot_)net
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg