[87163] in North American Network Operators' Group
Re: Clueless anti-virus products/vendors (was Re: Sober)
daemon@ATHENA.MIT.EDU (Edward B. Dreger)
Wed Dec 7 19:06:30 2005
Date: Thu, 8 Dec 2005 00:06:01 +0000 (GMT)
From: "Edward B. Dreger" <eddy+public+spam@noc.everquick.net>
To: nanog@merit.edu
In-Reply-To: <64B32EC3-BB76-4C19-91A0-F9BD4A9141D2@mail-abuse.org>
Errors-To: owner-nanog@merit.edu
DO> Date: Wed, 7 Dec 2005 14:15:00 -0800
DO> From: Douglas Otis
DO> > Perhaps DSNs should be sent to the original recipient, not the purported
DO> > sender. RFC-compliant? No. Ridiculous? Less so than pestering a
DO> > random third party. Let the intended recipient communicate OOB or
DO> > manually if needed.
DO>
DO> Being refused by the intended recipient would be the cause for the DSN.
Fine. But where to send it? Certainly not to a random address.
DO> > DO> furthermore a DSN could be desired even for cases where an
DO> > authorization
DO> >
DO> > When auth fails, one knows *right then* c/o an SMTP reject. No bounce
DO> > is necessary.
DO>
DO> This assumes all messages are rejected within the SMTP session.
Perhaps we're examining different "authorization" cases. Maybe my
mindset of "SMTP auth" is too narrow for your intended scope.
DO> > DO> scheme fails. Why create corner cases?
DO> >
DO> > The corner case is that a virus _might_ actually have a realistic "From"
DO> > address. :-)
DO>
DO> You mean bounce-address? A From address often has nothing to do with where
DO> a message originated.
DO>
DO> SPF has _nothing_ to do with the From address.
Errrr, "return-path". Freudian slip dealing with some site local
experiments... "from" is not as accurate as "return-path", but it's far
from (no pun intended) useless.
DO> Once again, not _all_ messages are rejected within the SMTP session. False
Of course not.
DO> positives are not 0%. To ensure the integrity of email delivery, not
DO> including message content and using a null bounce-address should be the
DO> recommended practice at the initial recipient. If you do not want to see
DO> DSNs with spoofed bounce-addresses, employ BATV at _your_ end should be the
DO> recommended practice. You would not need to insist that anything special be
DO> done at millions of other locations.
Oh well. I guess I've pretty much given up on pre-body filtering... so
I suppose it would be too idyllic to expect anything different with
DSNs.
Hmmmm. BATV-triggered bounces. Virus triggers forged bounce which in
turn triggers "your DSN was misguided" bounce. Perhaps the bandwidth
growth of the '90s will continue. ;-)
Eddy
--
Everquick Internet - http://www.everquick.net/
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
________________________________________________________________________
DO NOT send mail to the following addresses:
davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net
Sending mail to spambait addresses is a great way to get blocked.
Ditto for broken OOO autoresponders and foolish AV software backscatter.
