ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
On 12/08/2010 15:32, John R Levine wrote:
> On my tiny mail system, most but not quite all of the bounces can be
> handled as rejections at SMTP time. The ones I can't are generally
> deliveries to scripts where the script decides whether it can accept
> the mail. When those say nope, can't deliver that, when is it worth
> generating a bounce?
We have had several cases where our customers have been blacklisted by
their ISP for sending 'spam', when, in fact, they have just been sending
NDNs to all the spam they receive.
Operationally speaking, once you've accepted responsibility for a
message, you lose a lot of handling options, one of them being to
blindly send NDNs for stuff like invalid recipients without first
checking to see if the message is spam.
This is why it's important to validate recipient addresses at the
administrative boundary, and if you cannot do that, you need to perform a
spam/virus check before generating any sort of response.
+1.
We observed ~60% in overhead reduction simply by following the SMTP
Section 3.3 suggestion for delay MAIL FROM verification:
3.3 Mail Transactions
.....
Despite the apparent scope of this requirement, there are
circumstances in which the acceptability of the reverse-path may
not be determined until one or more forward-paths (in RCPT
commands) can be examined. In those cases, the server MAY
reasonably accept the reverse-path (with a 250 reply) and then
report problems after the forward-paths are received and
examined. Normally, failures produce 550 or 553 replies.
This became important when adding SPF or any other MAIL FROM:
verification. The 60% rejection at RCPT TO corresponded to a 60%
savings in MAIL FROM SPF lookup reduction.
--
Sincerely
Hector Santos
http://www.santronics.com