Bounce handling

On Wed, 2004-12-08 at 11:20, David Woodhouse wrote:
> On Wed, 2004-12-08 at 18:47 +0000, John Levine wrote:
> > I do agree that bounces vs. rejects are an increasing problem, and
> > I'm having trouble figuring out if there's any way I can do bounces
> > reasonably for the fraction of the mail here for which I can't tell
> > if it's deliverable at SMTP time.
> 
> The only real answer I've found is to make sure that during _normal_
> operation, there isn't actually any mail in that category ("can't tell
> if it's deliverable at SMTP time"). 
> 
> I do recipient verification callouts (with caching, of course) for the
> domains for which I am MX backup (and in some cases, also for mail I'm
> forwarding). Obviously it's pointless being an MX backup unless you
> actually accept the mail while the primary is down; but that's not
> normal operation.

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.  

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. : (

-Doug