SPF and bouncing

Recently I've been pondering one simple question:

 "Is it okay, on the modern internet, to send a bounce message outside
  of one's own bailiwick, when the original message had an SPF Pass
  result?"

Without an SPF pass, the consensus is clear -- bouncing is unacceptable
because it risks backscatter.  (So all mail accepted by an MX must be
delivered all the way forwards, explicitly ignoring any local policy
preference to the contrary.)

Until recently, my answer to the question was "Yes.  Although it hasn't
come up in practice yet, so the ground may not be firm...", as
backscatter is impossible with an SPF Pass based on a sane SPF record.
(If the SPF record is insane, it's the backscatter victim's own fault.)
However, lately I'm starting to doubt it.

The problem is this: The original sender may be not only publishing his
own SPF policy, but using SPF lookups in combination with a whitelist to
decide whether to accept mail.  Now, if the reputation of the bouncing
site is not good enough for that sender to accept mail from someone not
whitelisted, then they won't accept the bounce either, since bounces are
sent from <>.

So, the answer then is "No.  Unlike the non-SPF case, you won't make
anyone angry.  But there's still a substantial risk of double-bounce,
which you can avoid by remaining as cautious as if there were no SPF."

On the other hand, there are lots of special cases where an SPF pass
message could be bounced.  If no sender-address whitelists are used, or
they only serve to stand down content filters, a bounce is unlikely to
fail.  And VERP allows legitimate bounces to be recognized, at a cost of
complicating whitelisting at the other site.

There is a small incentive for a site to permit bouncing.  A backup MX
serving multiple domains might reserve a portion of it's queue space
only for bounceable messages.  Then, if a mailbomb occurs against a
mailbox with a primary that is down, the server can continue to accept
only Pass mail in hopes that the server will come back up, knowing that
it *can* flush the queue buildup without operator attention if it has
to.  Unknown/Softfail/None mail would simply be deferred until the
messages presently sitting in the queue can be unloaded forwards.

So, it might be reasonable to add a modifier (to SPFv1), or a new
qualifier (in SPFv3), that indicates "Pass, and I'll accept bounces in
potential return of faster delivery."

(Note that my Substitute Whitelist Key proposal from 2008 would have
resolved this problem, as it would allow both for VERP/whitelist
co-existance and for the failed-sender of a bounce to be indicated to
the SMTP server in the MAIL command.)

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