Re: SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

[Robert Bonomi <bonomi () mail r-bonomi com>]

> 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