Re: SPF and bouncing

again simply
bounce or anti-bounce policy is an ecosystemwide choice to remove the avenue for abuse
(like removing open relays were)

spf is an anti-forgery policy for senders
(it has always been up to receivers to do as they please with the results)

to shoehorn other side issues into spf in any form (especially issues that are NOTHING to do with sender policy)
Is simply patently a dumb idea.

suppressing bounces to one sender opposed to another is DUMB
(spf is only supposed to suppress bounces by allowing you to reject immediately forged mail)

If you ignored the spf and accepted the mail, then later bounce it should not be used to suppress bounces to that domain when non-spf users do not get the same treatment, 
you either obey the spf (and the domain dosn't receive bounces from you, just the forger), or IF you accept then deliver. if delivery generates a bounce(say mailbox full) then deliver it too.

tighten your acceptance policy ONLY as this is where the spammers get paid, anything else isnt fixing the problem or lessening the abuse its just masking it from your users (blackholing spam) or masking it from the legitimate senders and abused (blackholing bounces) both are part of the problem not an aid to the solution.

At 01:26 21/04/2012  Saturday, Michael Deutschmann wrote:
>On Wed, 11 Apr 2012, alan wrote:
>> if a goldlister that you describe exists
>> A their sending system would have to insist the also cannot mail
>> addresses other than those in their 'gold-list'
>
>Of course.  Or it can do the converse, automatically adding outgoing
>recipient addresses to a dynamic whitelist.  Which is, in turn, the line
>of thinking that led me to this issue.
>
>If the end-user is offered a flexible spam control panel and such a
>dynamic whitelist, he will be tempted to set his spam defenses extremely
>high, as the whitelist will save him from the false positives that would
>otherwise make him back off.  The result is a gradual slide towards an
>effective goldlisting policy.
>
>> B thus their sending system can easily enumerate that <> from the ip's
>> that are MXs for such goldlist address' and ips that have previously sent
>> from a goldlist address, or are in a goldlist addess's SPF are obviously
>> unlikely to be anything but legitimate bounces (this allowed to <> list
>> could be automatically enumerated and added to every time a new goldlist
>> address is added and refreshed every time one is emailed (as mxs and spfs
>> change)
>Yuck.  Among other problems this can't work with the exists mechanism.
>
>> C bounces can all be allowed to goto data phase (as no legit <> can be
>> to multiple recipients) and thus searched for lines like x@y mailbox full
>> etc (where address in message body is a goldlist address, or ip in
>> returned headers is a goldlist MX, to catch the occasional edge case
>> multi-stage inbound relays sending from alien IP
>Something like this is the way to go, but as-is it doesn't scale.  You
>have to check every line of the putative bounce against every address in
>the whitelist.  (A dynamic whitelist could get rather big.)
>
>What's needed is a way to analyze the message and derive the original
>recipient.  This would be trivial if everyone implemented RFC 3464, but
>many do not.  (Including Exim, the MTA I use.  Its author was never a
>fan of MIME.)
>
>> subverting spf to say anything about reception/reply/bounce policy will
>> not clean any of these or lessen the damage they do
>
>SPFv3 should say something about bouncing because without SPF the
>conspiracy implies a bounce policy that some senders find convenient --
>that they should never ever happen.  SPF pass removes the conspiracy's
>rationale of protecting innocents, since any backscatter of SPF-pass mail
>is (at least equally) the fault of the putative sender.
>
>In an SPFv3, instead of just "+", I'd like the choice of saying:
>
> * Pass, so you are free to act like it's 1990.
> * Pass, but I explicitly do not release you from the demands of the
>conspiracy.  Mail acceptance is still absolutely binding.  I'd rather be
>4xxed than have to deal with a post-transactional rejection.
> * Pass, but please note that only bounces following a minimum
>specification (that any RFC 6522 compliant bounce with an RFC 3464
>component would be guaranteed to pass) and arriving from a server which
>would have had an SPF pass if the original recipient was used in place of
>MAIL FROM, can be expected to be delivered.
>
>After the publication of this hypothetical SPFv3, I could set my SPFv1
>record to "?a -all".  Then any disregard of my chosen bounce policy would
>be willful -- if they don't grok SPFv3, then they see Neutral and are
>risking the wrath of the conspiracy should they not assume the worst.
>
>---- 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=20120420202632:A40159AE-8B48-11E1-8A80-A2406E639DDA
>Powered by Listbox: http://www.listbox.com