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 (wasRe:Clueless anti-virus )

  • From: Douglas Otis
  • Date: Fri Dec 09 12:05:30 2005

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.

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.