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

Fri Dec 9 19:21:20 UTC 2005

----- Original Message ----- 
From: "Douglas Otis" <dotis at mail-abuse.org>
To: "Todd Vierling" <tv at duh.org>
Cc: "Geo." <geoincidents at nls.net>; <nanog at merit.edu>
Sent: Friday, December 09, 2005 11:03 AM
Subject: RE: SMTP store and forward requires DSN for integrity 
(wasRe:Clueless anti-virus )

>
> On Fri, 2005-12-09 at 11:16 -0500, Todd Vierling wrote:
>> On Fri, 9 Dec 2005, Geo. wrote:
>>
>> > 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.
>>
>> Have you not even read the rest of the prior thread?
>>
>> It doesn't matter what the notifications look like.  There is no reason 
>> that
>> my SMTP server should be subject to more than TEN THOUSAND of these 
>> damned
>> things every day, which I must receive all the way through the DATA phase 
>> in
>> order to block.  That's the problem:  just like other forms of UBE,
>> virus-worm warnings (to forged addresses) *do not scale*.
>>
>> I don't care what kind of duck the UBE looks like.  Content is 
>> irrelevant.
>> It still looks, walks, and quacks like a UBE duck.
>
> There is a solution you can implement now that gets rid of these tens of
> thousands of virus and abuse laden DSNs you see every day before the
> data phase.  It could be seen as less than altruistic to bounce content
> of suspected malware, so perhaps one should not expect standardization
> of DSN content either.  There are many languages to deal with as well.

It's only a solution if it's available for all accepted MTA's that currently 
exist.  According to MIPA, the only currently available BATV "equipped" 
mta's are Exim and NetQmail. I'll admit that I'm not up to par on the BATV 
project but damn, if you can't find information on it through a google 
search, or you find very limited information on it, then how can you say 
that it's ready for implementation now? Also, regardless of it's status, why 
should I have to redo my entire mail system to deploy BATV because others 
can't play nice on the net?

> With BATV, the slogan could be a quote from Socrates "Know thyself."
> With BATV, you should stop blaming others for _your_ inability to deal
> with a DSN problem.  Calling DSNs UBE is not a solution, although
> traffic from AV applications seems to be approaching that definition.
> If it has a null return-path, that is all you should need.

> -Doug

When DSN's become autogenerated by systems that are not MTA's then those 
messages should no longer be considered DSNs should they.

My "inability" to deal with a DSN problem? Please allow me to assure you 
that I have various methods of dealing with bogus DSN's within my network 
infrastructure. Regardless of that, why should I have to accept traffic not 
destined for my network? That is, afterall, what is happening when a DSN is 
sent to a forged originating address is it not?  Truth of the matter is that 
I don't have to accept it at all. Your belief that I have the inability to 
deal with the problem is a misconception on your part. One has various 
methods in place already to deal with the problem at a very basic level. One 
can merely filter traffic at their upstream provider, place restrictions on 
their local MTA, firewall appliance or router. Those of us that see that 
DSN's are becoming UBE are trying to get the issue resolved before it comes 
to that. It will either happen or filters will go live. It's just that 
simple.

Mike P.