Re: SPFv3 proposal: rawfail result

On Wed, 9 Feb 2011, Michael Deutschmann wrote:

> On Tue, 8 Feb 2011, Stuart D. Gathman wrote:
> > Then maybe we should make it one.  It is a simpler and easier alternative to
> > deploying SRS (although more trouble for the final receiver).
> 
> It would work better to promulgate Sham SRS, which would avoid the
> scalability problem of your hack.

As a less clueless than average email sender, I would much prefer 
having the email simply rejected by SPF fail to Sham SRS.  The DSN
from the forwarder would contain the new email, and I would simply resend to
that.  Sham SRS gives no notice of delivery problems (unless the forward
is the final hop).  I realize the average email user never actually reads DSNs,
so this is not a general solution.

What if there was a standard SMTP code for SPF fail?  Then a non-SRS forwarder
could easily send an end-user friendly DSN to facilitate resending
to the new email?

> But this is a distraction from the question I originally pondered, which
> is -- given a site that has whitelisted all its friendly incoming
> forwards, yet is using a whitelisting heuristic that the forwarding
> entities have not promised not to break, can it reject on an ordinary fail
> when the whitelist engine says "not a trusted forward"?

I say "yes".  But I also realize that this is a judgement that
others may disagree with (not a black and white issue).  Keep in mind
that rejecting on SPF fail after alias forwarding is not such a horrible thing.
If the forwarder MTA is standards compliant, the user is notified of the new
address, and can resend.  At least the email doesn't go in the bit bucket.

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