ietf-smtp
[Top] [All Lists]

Fw: Re: SPEWS: S1861 removal request

2004-03-25 06:51:28

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


<Prev in Thread] Current Thread [Next in Thread>
  • Fw: Re: SPEWS: S1861 removal request, bz <=