Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Clueless anti-virus products/vendors (was Re: Sober)

  • From: Edward B. Dreger
  • Date: Wed Dec 07 19:07:12 2005

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.




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.