Re: SPF and bouncing

On Sun, 8 Apr 2012, alan wrote:
> then the block is on ip and thus dosn't reference mailfrom as the issue
> obviously

So you mean per-IP blacklisting trumps per-sender-address whitelisting?

Does that apply if the per-IP blacklisting is from a DNSBL and not a
manual entry?

Sender whitelisting is most commonly used to patch over the occasional
DNSBL false positive/collateral damage, without standing down the
defenses entirely.  A sender whitelist that did not trump the IP-based
reputation would be useless for that purpose.


Coming back to SPF, regardless of what SPFv1 Pass means, it would be good
to have a differentition in SPFv3 between a "unbounceable pass" and a
"bounceable pass".

The distinction would not be used for spam filtering.  Setting up a
conspiracy-compliant spam filter that doesn't blackhole is costly, but it 
is a flat cost.  Exempting "bounceable pass" messages doesn't save you
anything.

Also, even if the spammer has no right to complain of you bouncing back at
him, he can still be a jerk when you try to deliver that bounce....  Some
spammers might find it hiliarous to teergrube you, or endlessly 4xx.

Where it would help with is quota issues.  The more bytes of unbounceable
mail a backup MX is allowed to queue, the bigger the worst-case quota
overrun on the primary.  So a conspiracy-compliant MX will start 4xxing
incoming mail long before it comes near to running out of disk.

The MX could add a separate, larger reserve of queue space just for
bounceable mail -- knowing that if the primary stays down for a month, it
*can* try to shed the load.  In the usual case where the primary does
come back eventually, then it can ETRN and the waiting mail can be on it's
way immediately.  That's the sender's incentive to publish bounceable
pass.

But a goldlisting sender can't accept bounces without weakening its
defense considerably, so it would *prefer* to get 4xxed than to face
blackholing on the slim chance the message is flushed off the bounceable
queue and cannot be returned due to the goldlisting.

It would be even better to add a third SPF declaration: bouncing is ok if
and only if bounces can be reliably identified.  An obvious way to do this
is to require both that the bounce be close enough to RFC 3464 & 6522 so
as to reliably extract the "Original-Recipient" field, that the bounce
actually contain one (it's optional by RFC 3464) and that SPF would have
Passed the message had that address been the MAIL FROM.

It requires content filtering for airtightness, but is practical since <>
is rare (and will stay that way if the filter is used), and it is
reasonable to demand only one RCPT per transaction.  A message can have
many recipients but only one sender -- hence a bounce can only have one
recipient.

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