North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
> From [email protected] Sat Dec 10 06:58:38 2005 > Date: Sat, 10 Dec 2005 12:57:34 +0000 (GMT) > From: "Stephen J. Wilcox" <[email protected]> > 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 > |