Re: Bounce handling

On Wed, 2004-12-08 at 13:58 -0800, Douglas Otis wrote:
> The spammer often ignores MX priorities specifically to discover SMTP
> servers that accept mail for a particular domain without respect to
> valid users.  There is still an advantage using BATV even in the case
> where there is a bounce generated in this scenario.  The receiving MTA,
> if using BATV, should be able to reject a bounce when the MAILFROM is
> NULL. This is the reason for BATV.  

Yes. That's precisely why I'm _slightly_ less concerned about avoiding
bounces nowadays, since SES and BATV allow the 'victim' of bogus bounces
to reject them. SES just takes it a little further than BATV, by
offering simple ways for the (potential) recipient to verify the source
address too.

> It seems the proper etiquette for a bounce would be to ensure a NULL
> MAILFROM when issuing a bounce.  This behavior should include virus
> detection, vacation notices, and other message related events
>  generated as a result of a message being rejected and returned. 
> Unfortunately, the setting of MAILFROM for a bounce is optional. :(

For a bounce as defined by RFC2821 it's _not_ optional to use an empty
reverse-path; it's mandatory. For vacation messages it is optional -- in
fact I was utterly dismayed to see that RFC3834 said that an
autoresponse 'MAY' have an empty reverse-path, rather than 'MUST' or at
least 'SHOULD'.

I consider autoreplies (and especially bounces) with non-empty reverse-
path to be an attempted denial of service attack, because of the mail
loop they threaten. I tend to report them to the upstream network
provider of the offender as such, in the strongest possible language.
Especially if they're "responses" to viruses which are known to fake
their sender.

-- 
dwmw2