On Thu, 2009-01-15 at 18:54 -0500, Rich Kulawiec wrote:
Moreover, trying to guess what someone else's mail system will do is
pointless, and trying to correct it if you think it's wrong is futile.
All you can do is *your part*, which is to reject with an appropriate
error message and move on.
What a conforming MTA will do with a 5xx reject from your MTA is well
defined. From RFC 5321 Section 6.1:
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message.
The MTA has accepted the message, and the next-hop MTA has rejected it,
so the message is suffering delivery failure. Therefore the MTA is
obliged ("MUST") to send a notification message.
Therefore, if you always 5xx messages which are known to contain
malicious content, some fraction of those rejections will result in
notification messages which are likely to contain that malicious
content. If the vast majority of malicious content comes from bots or
similar, then the fraction may be small. However, the MTA which
generates the "bounce" is not at fault, it is doing what it is obliged
to do.
(And as a practical matter, if it's not a real mail server talking to
you, then it's not going to generate a bounce. If it *is* a real mail
server talking to you, and it's trying to deliver malware, then it's
probably already so badly hosed that nothing you could possibly do or
not do will make it any worse.)
An MTA has no obligation to inspect the content of messages which it is
passing through. You might suggest that it does have that obligation,
but there is none. Indeed, inspection of the content of messages by
every MTA might be regarded as a violation of privacy. An MTA is not
"badly hosed" that is simply doing its job of transferring messages
based on the data in the message "envelope" (any more than a postal
worker in a sorting office is at fault for sorting messages which happen
to contain illegal images).
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg