ietf-smtp
[Top] [All Lists]

Re: Do the must 'bounce' rules need to be relaxed for virus.

2004-03-25 07:01:37

from: wayne <wayne(_at_)midwestcs(_dot_)com> 
<x4isgtzl1w(_dot_)fsf(_at_)footbone(_dot_)midwestcs(_dot_)com>
In <59A5A8E4-7D2F-11D8-BA10-000393DB5366(_at_)cs(_dot_)utk(_dot_)edu> Keith 
Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> writes: 


for instance, I don't think it would be acceptable to silently drop
messages on the basis of an SPF record, because the problem could
actually be a configuration error rather than malice or deceit.

The intent of SPF is that you *wouldn't* silently drop email on a
failure, but rather issue an SMTP 5xx rejection (or 4xx on DNS
failure).

The problem comes when the 5xx spawns a message that follows a forged
return path, or notifies the virus writer that his virus has been
recoginized and rejected. Why add a victim or give clue to a villian? 


The intent of SPF is that, if the check passes, you can safely send
bounces to the envelope-from.  SPF is also designed to be light-weight
enough to be run in the MTA in most cases, and flexible enough so that
you can do a certain amount of per-user validation if you want.


The intent of the spammers and virus writers is to USE 'blind adherence'
to the current RFCs to increase the damages done by their messages. 

The point isn't "Can SPF ensure that no virus could successfully forge a
'valid' return path?" 

The point is that it IS VITAL to dump some messages. Should the RFCs
'permit' such dumping or 'forbid' the dumping that MUST be done to keep
the internet mail running. 

If the RFCs continue to forbid, then more message systems will be operated
'outside the RFCs'. 


I really don't want to see the must bounce rule relaxed.  

There are many things I don't really want to see. Some, I must see, even
though I would rather not do so. 

There are
already too many times that spam-filters silently discard legitimate
email, it would be nice if more of that email could be safely bounced.

It WOULD be nice. unfortunately spam/virus generated e-mail often can NOT
be safely bounced. 

Reality rules. 

Is it ABSOLUTELY essential that ALL messages be either delivered to the
supposed 'addressee' or 'bounced' to the supposed originator, EVEN WHEN so
delivering or bouncing will victimize said 'addressee' or 'originator'???? 

I don't think so. If it were ABSOLUTELY essential, then the first time
someone started dumping the virus messages, rather than bouncing them, the
whole structure of e-mail would have collapsed. It hasn't. The bounces
sent have caused much more damage than the bounces dumped. 

I agree that dropping messages must be done with extreme caution, but I
think that it IS essential that some kind of official ruling to the
effect: 

'we acknowledge that this is happening and we want to let systems managers
know that it IS permitted under RFCxxxx. We caution that such dumping
should ONLY be done under the following conditions: 1) the 'sender' is
forged. [one SHOULD never bounce to a forged address.] 

2) the 'recipient' will be victimized by receiption of the message. [one
SHOULD not deliver any message that has been generated en mass by a virus
or that is clearly spam. 

Note: The party responsible for dropping the messages MAY take steps to
track down and notify those parties that could reasonably be expected to
do something to STOP the continued origination of such messages.]' 


-- 
bz

please pardon my infinite ignorance, the set-of-things-I-do-not-know is an
infinite set.

bz+ietf(_at_)chem(_dot_)lsu(_dot_)edu


-- 
bz

please pardon my infinite ignorance, the set-of-things-I-do-not-know is an
infinite set.

bz+ietf(_at_)chem(_dot_)lsu(_dot_)edu


<Prev in Thread] Current Thread [Next in Thread>