Re: SPFv3 proposal: rawfail result

On Thu, 3 Feb 2011, Michael Deutschmann wrote:

> The root problem is that the original designers of SPFv1 arrogantly
> assumed that SRS deployment would quickly outpace receiverside SPFv1
> deployment, hence there would be no need to make the distinction.

If it is not clear in the spec that you SHOULD NOT reject on -all
when not actually evaluated on an MX for the original RCPT TO domain, then we
should make that clear.

This *does* make -all not very useful to a receiver when the incoming border
MTAs are not clearly defined (since alias forwarders are the MXs for the
original RCPT TO domain). 

I do not support adding "rawfail" simply to clarify the meaning of "fail".
I am open to adding "rawfail" for its own sake, as a request to reject
mail rather than deliver via alias forwarding.

Some of the arguments used to support always rejecting on SPF fail apply to
rawfail: the reject DSN contains the real address, and a savvy sender can 
simply resend, possibly updating his address book.  So rawfail could be
a useful option for a Sender Policy.  (In addition to the already mentioned
feature of requesting direct delivery.)

-- 
	      Stuart D. Gathman <[email protected]>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.