ietf-asrg
[Top] [All Lists]

RE: [Asrg] "worm spam" and SPF

2004-11-27 17:14:22

After consideration and reconsideration I've come to the conclusion that
delayed rejection to hide the user list is much like security through
obfuscation -- it is too easily defeated. Consequently, I've found it better
to reject messages "on the wire" and keeping them from getting past the
first MTA. Delays, so that you can send a bounce (often to a bogus address)
is at best a waste of resources.

-- Bruce

-----Original Message-----
From: asrg-bounces(_at_)ietf(_dot_)org 
[mailto:asrg-bounces(_at_)ietf(_dot_)org] On Behalf Of
Daniel Feenberg
Sent: Saturday, November 27, 2004 3:19 PM
To: Bill Cole
Cc: asrg(_at_)ietf(_dot_)org
Subject: Re: [Asrg] "worm spam" and SPF



On Fri, 26 Nov 2004, Bill Cole wrote:

At 5:00 AM +0200 11/27/04, Gadi Evron wrote:
As everyone probably knows, there is a pretty large outbreak going
on right now. According to our mail filters at
http://aves.f-prot.com,
10.56% of all filtered E-mail contains W32/Sober(_dot_)J(_at_)mm(_dot_)  
In addition,
there is a significant number of bounces as well.

We've reached 1.5 GB an hour of this s**t since Tuesday. Only our AV
calls it Sober(_dot_)I(_at_)mm(_dot_)

I agree, bounces are the very evil of the net itself.


No, they are not. They are a critically important part of the
robustness of email. Broad acceptance of the idea that bounces are
evil will be the last nail in the coffin of email.


Rejection during SMTP processing is a good substitute for delayed DSN
messages. It is not necessary to drop any messages on the floor, which
would, I agree, be a terrific loss. I am aware that this is easier with
some MTAs than others, but the technical reasons for delaying notification
untill after message acceptance are not sufficiently strong to justify the
practice into the future.

For example, it has been argued that there is a security advantage in not
having the user list available to the "outside" MTA, or that there is a
reliability advantage in have the secondary MX at a remote location
without access to the user list, or that anti-spam or anti-virus
processing is so CPU intensive that it needs to be queued for delayed
execution. All of these are cogent, but none are sufficiently powerfull to
justify sending DSNs to possibly forged From addresses.

It is true that some MTAs make it extremely difficult to reject invalid
users, or spam or virus messages during SMTP processing, but in the
fullness of time they will be fixed or left behind, and MTAs will be
capable of making accept/reject decisions in real time while the
connecting server waits for the final "." in the data step of the SMTP
dialog.

Daniel Feenberg



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg