[87150] in North American Network Operators' Group
Re: Clueless anti-virus products/vendors (was Re: Sober)
daemon@ATHENA.MIT.EDU (Todd Vierling)
Tue Dec 6 17:17:13 2005
Date: Tue, 6 Dec 2005 17:15:54 -0500 (EST)
From: Todd Vierling <tv@duh.org>
To: Douglas Otis <dotis@mail-abuse.org>
Cc: "Steven M. Bellovin" <smb@cs.columbia.edu>,
"Church, Chuck" <cchurch@netcogov.com>, nanog@merit.edu
In-Reply-To: <564F10DA-C8A2-49DC-AF59-88DBD5374984@mail-abuse.org>
Errors-To: owner-nanog@merit.edu
On Tue, 6 Dec 2005, Douglas Otis wrote:
> > > A less than elegant solution as an alternative to deleting the message, is
> > > to hold the data phase pending the scan.
> >
> > Contrary to your vision of this option, it is not only elegant; it happens
> > to be the *correct* thing to do.
>
> Holding at the data phase does usually avoid the need for a DSN, but this
> technique may require some added (less than elegant) operations depending upon
> where the scan engine exists within the email stream.
Not my problem. I don't need or want, and should not be hammered with,
virus "warnings" sent to forged addresses -- ever. They are unsolicited (I
didn't request it, and definitely don't want it), bulk (automated upon
receipt of viruses by the offending server), e-mail... thus UBE.
It's up to the server operator to choose how to handle virus protection in
the mail system, without generating any mail whatsoever to forged or
unknown-if-it-is-forged senders.
> It would seem that when a DSN is required, as a
> general practice, the DSN should not include message content.
> This should at least thwart this vector being used to spread
> malware and spam. Preventing the spread of a virus seems key.
I, frankly, don't care about the issue of whether or not a "warning" message
includes the virus that triggered it; you've missed the point.
I care about the fact that these "warnings" are UBE, at levels that have
been peaking above those of direct spam from what I can see.
Generated virus "warnings" must not go to a known forged sender, or to a
sender for which the forgery status is unknown. If you cannot *guarantee*
that the address in MAIL FROM:<> is correct, and cannot reject at SMTP time,
your only options are to quarantine, discard, or allow delivery. Do not
send a DSN; do not pass Go; do not collect US$200.
> There is always BATV to clean-up spoofed bounce-addresses in the meantime.
And other methods (DK, SPF, SID, choose your poison). However, if the
server cannot verify that the MAIL FROM:<> is not forged with reasonable
certainty, the server should not send a DSN, period. Otherwise, it's a
direct contributor to the UBE problem.
--
-- Todd Vierling <tv@duh.org> <tv@pobox.com> <todd@vierling.name>
