Re: SPF and bouncing

may i suggest we take this offlist as I'm sure the debate about bouncing is really of no interest to
(and definitely not really relevant to SPF at all)

alan @ the domain in from:
rather than the tagged address here

At 05:21 07/04/2012  Saturday, Michael Deutschmann wrote:
>On Fri, 6 Apr 2012, G.W. Haywood wrote:
>> On Tue, 3 Apr 2012, Michael Deutschmann wrote:
>> > "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?"
>>
>> One simple answer.  No.
>
>How about this variation:
>
>"Is it okay, on the modern internet, to assume that legitimate bounce
>messages between bailiwicks will not occur?"

yes they will, between sending machines and 3rd parties that are allowed to send via them
like anyone offering unauthenticated outbound relay from their IP's etc. 

>That is, to declare that deadletters other people experience when they try
>to bounce something you *actually sent* are their own fault for not
>saluting the Conspiracy Against Bouncing.

If I actually sent it I accept the bounce (as its RCPT address exists so why in hell would I refuse a valid bounce??)
(I have never said in all of this that refusing mail due to <> in mailfrom is legitimate for anyone)
(in fact i welcome even likely backscatter so its possible to report the source and have them blacklisted for running the sloppy system that generates the abuse)
(obvious caveat if mail is from <> and to multiple recipients its not an NDR and is then treatable with suspicion)

>I'm suprised how vehement people are behind the No regarding the first
>question, but that may just be Postel's Law talking. ("Be conservative in
>what you send, liberal in what you accept.") Postel would also say No to
>the second one.

it is simply I do not run an abusive receiver, I know others do so do not refuse external bounces as my users being informed of delivery failures is paramount, i give users a simple 'report as backscatter' link in any <> they receive from external and preserve a copy for analasis so their hitting this for mail that is a legitimate bounce, results in them getting the larting not the sender.

>And on reflection, it's the second question that is most important.  Some
>anti-spam strategies become far weaker if asked to treat a bounce message
>for failed delivery to <x@y> just as well as a normal message from <x@y>.

a delivery failure to x@y is hard to deduce (due to NDR text not being in any standard format, possibly determinable by enumerating all the major formats, but not an exact science)

>Most dramatically, this applies to goldlisting, where any envelope sender
>not on the whitelist is rejected.  If <> is not whitelisted, no bounce ever
>gets through.  If <> is, anyone from any IP can circumvent the goldlist.

not really if you goldlist without using batv then yer kinda likely stuck,
we do not allow users to block for <> alone ever, but we do allow them to block all from known backscatter source-ips (ie using their deliverability/non-deliverability as leverage to cleanup)
or <> from known backscatter sources (ie just avoiding the likely backscatter but not rejecting all mail)
(batv users dont ever get allowed to block <> as long as the batv RCPT is correct)

>(One idea is to use SPF-checked HELO and/or rDNS to at least get a domain
>that can be coarsely checked against the whitelist.  But that can easily
>fail, especially if the sending IP is a smarthost for many domains.)

90% of legitimate mail (here) is thusly sent from a smarthost
if you really wanted to try and guess if <> is possibly from a whitelisted/goldlisted address' system.

you would need to check the helo +/- rdns against the domains in the MXs of the domains you have whitelisted
(or better the IPs against the IPs you have already received whitelisted mail from)

Ie every legit mail from whitelisted address would cause the sending IP to be added to an allowed to send from <> in future list.
(again goldlisting/whitelisting by address i find never works as from address is trivially forged and few will have SPF/DKIM to aid forgery detection)
(blocking <> again I believe is both irresponsible and stupid and a disservice to your users)

users here that want to whitelist/goldlist or similar are advised to do so by more than one detail ie envelope-from:x@y AND SPF-pass or envelope-from:x@y AND helo *.domain.tld etc. 
yes rules are usually 2 or 3 times longer but they are more likely to avoid the actual phishes and forgeries
(usually only addresses like mine above that are used legitimately only by one sender (this mailing-list-srv))

obviously they also need to look at their own server side rejection logs and ammend their rules when their contacts start reporting issues (moved their domain from smarthost at providerX to providerY for example) 
as if the user wants Draconian filters they have to be willing to maintain them, we will educate and provide the tools but we don't have access to change their settings (as far as they are told) so the administration burden is entirely theirs)