Re: SPF and bouncing

At 20:36 03/04/2012  Tuesday, Michael Deutschmann wrote:
>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.)

i would argue 
you cannot have any difference in acceptance policy between your own mx's (including any hidden internal hops)
if you do you have a bigger issue than backscatter.
All rejection decisions MUST be made on the edge.
thus any mail accepted by any of your MX's will therefore obviously reach the user or their spamfolder
(blackholing should simply never be done)
(having further deeper analysis of the content on an internal/downstream host for scoring/filtering is fine, but if you are rejecting it must be at the first MX contacted)

the only bounces your hosts should ever generate are ones to your users in response to 5xx rejects from remote servers they attempted to send to.

this simple rule ensures you can never be a source of backscatter as you never bounce any mail.

if using a 3rd party to provide backup mx they must have identical policy (which most cannot) so you MUST
A never use a 3rd party that dosn't have a synched copy of your live addresses
B pick one with a policy you can live with and ensure that all mail from them is whitelisted (except for scoring/filtering to spamfolder) they should never see a 5xx
C live with the fact that if you have a difference in policy between MX's spammers will simply ALL only deliver to the most relaxed MX, (they get paid per 2xx, not by how many reach the user) so if you don't 5xx initially they have won(monitarilly)

so having a backup mx with a 3rd party means your own policy becomes pointless/futile

alternately (and what I recommend to all our customers) if your own MX's arn't reliable enough then ditch them entirely
setup your MX's to point ONLY at reliable 3rd party, ensure their policy is setup as you wish, let them deliver to you ONLY (access lists firewall rules whatever) but only accept SMTP from their servers and never 5xx 
points A and B above still are applicable in this scenario

(info: we do provide spamfiltering/reliable MX's for customers but do not allow them to accept smtp directly if we do, we also insist their outbound stream is directed via us also (for us to ensusure they cant send with non-existant return path etc.) also we insist they 5xx unknown users at their edge (some exchange servers don't by default so we show them howto) and we use smtp callforward to sync our address-lists live with theirs, any 5xx response from them other than user unknown is an immediate investigation and firing if they are bouncing/rejecting due to content as we will not allow them to make us send backscatter, and we will not allow them to send out backscatter directly or via us. we also will not allow them to send anything phishy or spammy or forged, obviously.
we're quite proud of the fact that we allow them to set per domain defaults and per address exceptions (stricter or looser) on all areas of filtering/scoring/rejecting policy so that hopefully we provide a more robust and customisable solution than they could ever have in-house, but do encourage them to do further content filtering in-house if and only if it results in a spamfoldering not a blackhole or bounce)

>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]>
>
>
>-------------------------------------------
>Sender Policy Framework: http://www.openspf.net [http://www.openspf.net]
>Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]
>
>Archives: https://www.listbox.com/member/archive/735/=now
>RSS Feed: https://www.listbox.com/member/archive/rss/735/13124949-0b42f103
>Modify Your Subscription: https://www.listbox.com/member/?&
>Unsubscribe Now: https://www.listbox.com/unsubscribe/?&&post_id=20120403153709:616DEB34-7DC4-11E1-959A-EFE378D6CBD4
>Powered by Listbox: http://www.listbox.com