North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: SMTP store and forward requires DSN for integrity (wasRe:Clueless anti-virus )
- From: Micheal Patterson
- Date: Fri Dec 09 14:34:21 2005
----- Original Message -----
From: "Douglas Otis" <email@example.com>
To: "Todd Vierling" <firstname.lastname@example.org>
Cc: "Geo." <email@example.com>; <firstname.lastname@example.org>
Sent: Friday, December 09, 2005 11:03 AM
Subject: RE: SMTP store and forward requires DSN for integrity
(wasRe:Clueless anti-virus )
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?
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
> 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
Have you not even read the rest of the prior thread?
It doesn't matter what the notifications look like. There is no reason
my SMTP server should be subject to more than TEN THOUSAND of these
things every day, which I must receive all the way through the DATA phase
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
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.
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.
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