SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )
Robert Bonomi
bonomi at mail.r-bonomi.com
Sat Dec 10 14:52:25 UTC 2005
> From owner-nanog at merit.edu Sat Dec 10 06:58:38 2005
> Date: Sat, 10 Dec 2005 12:57:34 +0000 (GMT)
> From: "Stephen J. Wilcox" <steve at 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
>
More information about the NANOG
mailing list