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

Fri Dec 9 18:26:42 UTC 2005

----- Original Message ----- 
From: "Geo." <geoincidents at nls.net>
To: <nanog at merit.edu>
Sent: Friday, December 09, 2005 9:57 AM
Subject: RE: SMTP store and forward requires DSN for integrity (was 
Re:Clueless anti-virus )

>
>>>While AV scanning may be done during the session, it would also require
> additional steps to also contain _all_ upstream activity within the same
> session as well, when attempting to achieve an apparent point-to-point
> operation.  If SMTP were point-to-point, this would be evolving into the
> IM model where the message queue or storage would always be at the
> sender.  Such mode of operation will increase the average transaction
> time needed for email.<<
>
> You know, the problem we are trying to solve is virus notification 
> blowback,
> etc. So instead of changing the system why not work with it.
>
> If everyone would just standardize on at least the first part of every 
> virus
> notification being the same thing, say:
>
> XXX  VIRUS NOTIFICATION: blah blah blah
>
> where XXX is some error number, we could all easily control virus
> notifications at the receiving end, allowing or blocking, as the 
> recipients
> choice. A simple standard message format and all the problems and 
> complaints
> go away.
>
> George Roettger
> Netlink Services

Standardizing the DSN is an exercise in futility. Mainly because it still 
requires the message to pass through your outbound pipe and into my inbound 
pipe, hit my server port where my server starts processing that traffic. 
What has been accomplished here? Providing me a mechanism to block the 
notification if it's for a virus? For systems that are sending out 
notifications with forged addresses, this becomes UBE and provisions are 
already in place in the mta via access or in worst cases, the border 
firewall or even the border router for dealing with the originating network 
itself.

If a system is incapable of determining the validity of the sender address, 
then that address should not be getting a DSN from any system regarding a 
virus, trojan or other malware.  One can say, well *this* system is going 
into place or *that* system is in place at these locations, but it's simply 
not good enough. It's not standardized. There is currently no 100% tried and 
true method of dealing with this that is *standard* through out the net. So, 
the next best thing is to simply not send the DSN for viri / trojan 
infection at all.

What was the quote from Wargames? Oh yes, "The only winning move is not to 
play".

Mike P.