Re: SPF and bouncing

On Fri, 6 Apr 2012, alan wrote:
> either way no possible way to determine this (except spf fail) all
> passes and neutrals are still possibly forged

SPF-neutral is indeed unbounceable.  But if an SPF-pass mail is forged,
it's the sender domain's own fault.  They signed off and should have known
better.

If they want to disclaim responsibility for a portion of the mailstream
putatively from themselves, yet want to plead with people to accept it
anyway, that's what SPF-neutral is for.

Configuring a smarthost to prevent end-users from using identities that
they do not own (but that the same smarthost is indeed responsible for),
is a far easier problem than arranging bounce-free handling of incoming
mail.

> (few and far between, 3 users on my systems whitelist batv using
> senders, and a .many-zeros1 percent of mail)
So it doesn't scale to *automated* whitelisting and greylisting.

Note that if the user actually tells you, "I want to whitelist
<[email protected]>, and I *know* they are using the BATV family of
VERP", then you can add example.net to a local list of domains for which
you can demangle the VERP before consulting the whitelist and greylist.

But to do that without specific hints from the end-users, I'd want some
kind of signal, such as a modifier in the VERPing domain's own SPF record,
that tells me how to derive a whitelist key from the envelope sender.

For BATV the algorithm would appear to be discarding a prefix up to and
including the first two '=' characters from the localpart, but non-BATV
domains might use '=' in other ways.  BATV isn't even an RFC, so the
standing orders are that localparts must be assumed opaque.

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