Re: SPF and bouncing

On Thu, 5 Apr 2012, alan wrote:
> you reject based on, spammyness, sender reputation, local policy,
> content, spf-fail dkim-fail whatever ONLY

Faced with an unbounceable incoming message about to cross the perimeter,
you try *really, really hard* to find a good reason to reject it.  But you
often won't succeed, because a large proportion of *desired* mail has no
SPF information.  (I see 72.9% year-to-date)

And of course that assumes it is reasonable to bounce SPF pass mail --
which if you'll remember, was what I questioned in my original post.

> this is not recent thinking, this is more a reaction (backlash)

Not in my experience.  Before spam boomed in the turn of the millenium, it
was quite common for businesses to MX backup for each other, without
sharing valid address lists.  That's a big backscatter magnet these days.

What changed was that some of those sloppy MXes started using "sender
verify with callout" (itself an abusive practice, but that's another
story) to protect themselves from deadletters piling up when they
accepted a spam with a completely made up envelope sender.  That also
blocked the spammers from reaching users behind those MXes who actually
existed, so the spammers responded by using real addresses from their
"Millions CDs".

> simply whitelist the domain from RCPT-reject, if from:(in data) differs
> from whitelisted address then reject after data IF you would have
> otherwise rejected at RCPT

Looking at the RFC822 From: is a big can of worms.  You have to let the
connection go to DATA, and work out how you'll deal with multi-RCPT mails.

---- Michael Deutschmann <[email protected]>