Re: SPFv3 proposal: rawfail result

On Thu, 3 Feb 2011, Stuart D. Gathman wrote:
> So to paraphrase the semantics of "rawfail": even if a receiver does
> not track their forwarders (a large legacy ESP, for example), rawfail
> asks them to reject a message anyway.

Exactly.

Although I object to the namecalling -- unless and until a "TENBOX"
standard emerges, it is unfair to call the ESPs in question "legacy".
Today, forwarder whitelisting requires ad hoc approaches and is generally
only available when the end user and the mailserver admin are the same
person.

> > And again, the key advantage of "/all" is not that many senders will use
> > it.  It's to ensure that recipients don't accidentally assign rawfail
> > semantics to "-all", a problem that has ruined SPFv1 by deterring senders
> > from publishing it.
>
> That is a bogus argument.  No matter what you do, there will be receivers
> that don't actually read the standard.  "Rawfail" will not help with that.

But it would improve things, as even in this very forum there is not
universal agreement that SPFv1 "-all" is not a raw fail.

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.

> No one should avoid publishing "-all" because there are clueless receivers.

But they do.  That annoys me, but we cannot force them to stop lying
(saying "?all" when the truth is "-all"). All we can do is reduce the
temptation by cutting down the number of "clueless receivers".

> I do see potential usefulness in requesting that forwarded messages get
> rejected.  It could help ensure a direct transfer between sender and receiver,

"/all" is insufficent for that purpose, as it will not block SRS
forwarders, or pull-based arrangements.

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