Re: [Asrg] "worm spam" and SPF

At 6:18 PM -0500 11/27/04, Daniel Feenberg wrote:
> 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.
It isn't a matter of specific MTA's, but of the complexity of 
internal mail systems behind an external MX. If an external MX is is 
an entry point for a mail system where you cannot do final delivery 
synchronously with message acceptance, there will be cases where a 
later DSN, silent quarantine, or silent dropping are the only options.
> 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.
I disagree, but only slightly. There is no excuse for sending DSN's 
to addresses that you can reasonably expect to be forged, i.e. 
because you determine the mail to be viral or spam and therefore 
refuse to deliver it. If you refuse to deliver a message because you 
have determined that the real sender (a spammer or a piece of 
malware) is not to be trusted and that the mail is itself 
untrustworthy, it makes no sense at all to generate a DSN for the 
message.
> 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.
This is not an MTA issue at its heart. the core problem is that a lot 
of mail systems, particularly larger ones that are not structured as 
simply as most ISP systems, cannot even in principle do all mail 
delivery synchronously with exterior gateway SMTP acceptance. If 
there is a finite period where the message has been accepted but has 
not been finally delivered to whatever point the user eventually 
picks up their mail from, there will be some cases where the user 
existed and their mailbox was capable of accepting a message when it 
was accepted but where at least one of those will not be true when 
final delivery is tried. Mail systems have been built this way for 
decades because email usually and Internet email in particular have 
been designed for store-and-forward operations, not synchronous 
end-to-end delivery. Redefining that imposes major re-architecture 
requirements on a lot of large (mostly corporate) mail systems.


--
Bill Cole
bill(_at_)scconsult(_dot_)com


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