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: Micheal Patterson
  • Date: Fri Dec 09 13:32:46 2005




----- Original Message ----- From: "Geo." <[email protected]>
To: <[email protected]>
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.