----- Original Message ----- From: "Douglas Otis" <dotis@mail-abuse.org> To: "Todd Vierling" <tv@duh.org> Cc: "Geo." <geoincidents@nls.net>; <nanog@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.