From owner-nanog@merit.edu Sat Dec 10 06:58:38 2005 Date: Sat, 10 Dec 2005 12:57:34 +0000 (GMT) From: "Stephen J. Wilcox" <steve@telecomplete.co.uk> Subject: Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

On Sat, 10 Dec 2005, Matthew Sullivan wrote:

...

Please remember people..

RFC 2821 states explicitly that once the receiving server has issued a 250 Ok to the end-of-data command, the receiving server has accepted responsibility for either delivering the message or notifying the sender that it has been unable to deliver. RFC2821 also says that a message MUST NOT be dropped for trivial reasons such as lack of storage space for the message. To that end is a detected virus/trajan/malware/phishing scam etc... a trivial reason to drop the message?

Personally I believe that not trivial means not unless the entire server crashes and disks fry etc... To that end I am a firm believer that malware messages SHOULD BE rejected at the end of the data command

rfc2821 was written prior to this problem

Systems which 'silently discard' virus-infected messages for "policy" reasons are not in violation of RFC 2821, nor even the obseleted 821. "Delivery" of a message does NOT require that the message hit a person's "in box". Trivial proof: mail to an 'autoresponder'. 'Delivery' of any message is handled in accordance with 'policy' established at the receiving site. If policy dictates that that message be routed to the bit-bucket, rather than to the user's mailbox, that message *IS* considered 'delivered', within the context of RFC 2821.

we should also take the rfc in context and differentiate between email sent between individuals for which the responsibility applies, and email generated by systems (spam, virus bounces) in which we the providers carry some responsibility to drop them (okay, it would be better if they didnt exist in the first place, but thats not reality) if they can be identified in the best interests of the user

to not do this is like saying we have a responsibility to ensure end to end delivery of packets in a DoS attack just because the rules governing routing and ip stacks dont explicitly cover the use of sinks and filters.

Steve