Re: SPF and bouncing

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]>