headers
Stuart D. Gathman | 3 Feb 2011 19:12

Re: SPFv3 proposal: rawfail result

On Sun, 30 Jan 2011, Michael Deutschmann wrote:

> On Sun, 30 Jan 2011, Stuart D. Gathman wrote:
> > The forwarding you are concerned about is something only the
> > recipient can know about or initiate.  Why would a sender want a message
> > rejected if the recipient happened to forward it to another mailbox?
> 
> But not a senseless one.  A (non-VERP) sender who publishes "/all" is not
> trying to break forwarding; he would be *accepting* the breakage of
> forwarding in return for a much higher efficacy in supressing forgeries.

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.

> 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.
No one should avoid publishing "-all" because there are clueless receivers.
It is only by missing important email that they will get off their duff
and figure out what they screwed up (likely one of the common mistakes
listed on openspf.org).  Furthermore, the sender does get the reject, and
knows to take action.  (Receivers that throw SPF fails or any other reject
into the bit bucket are a hopeless case.)

I do see potential usefulness in requesting that forwarded messages get
(Continue reading)

Permalink | Reply | 16 comments |
headers
Michael Deutschmann | 4 Feb 2011 03:28

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.
(Continue reading)

Permalink | Reply | 15 comments |
headers
Stuart D Gathman | 4 Feb 2011 04:33

Re: SPFv3 proposal: rawfail result

On 02/03/2011 09:28 PM, Michael Deutschmann wrote:
> On Thu, 3 Feb 2011, Stuart D. Gathman wrote:
>> 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.
SRS documents the forward - your domain is not in the return-path (apart
from being encoded in the localpart).  Pull-based is still direct.
Permalink | Reply | 0 comments |
headers
Alessandro Vesely | 4 Feb 2011 10:41
Picon
Favicon

Re: SPFv3 proposal: rawfail result

On 04/Feb/11 03:28, Michael Deutschmann wrote:
> On Thu, 3 Feb 2011, Stuart D. Gathman wrote:
>> No matter what you do, there will be receivers that don't actually
>> read the standard.

The standard says

   A "Fail" result is an explicit statement that the client is not
   authorized to use the domain in the given identity.  The checking
   software can choose to mark the mail based on this or to reject the
   mail outright.

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

IME, services that mailout from web pages and forwarders have learned
to set an empty mailfrom in case nobody is interested in knowing about
possible failures, or an SPF-compatible address otherwise.

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

How about clueless forwarders?

> But they do.  That annoys me, but we cannot force them to stop lying
> (saying "?all" when the truth is "-all").
(Continue reading)

Permalink | Reply | 11 comments |
headers
Michael Deutschmann | 4 Feb 2011 12:43

Re: SPFv3 proposal: rawfail result

On Fri, 4 Feb 2011, Alessandro Vesely wrote:
> IMHO there is enough confusion already with neutral and softfail.  If
> we want to provide for more, and still not block, why don't we just
> allow to set the "mark" value numerically, specifying the score that
> should be added or subtracted?  E.g.

The distinction between rawfail and fail is not quantitative -- this is
why I call it "rawfail" and not "hardfail".

Fail still means 100.00% confidence of rejection *if the validator is sure
the message is not a forward*.

Rawfail makes the *qualitative* change of telling the validator not to
worry about the risk of forwarding false positives.

If 5 outcomes (pass,neutral,softfail,fail,rawfail) is really too much,
then I nominate softfail for removal in SPFv3 to make room for rawfail.

---- Michael Deutschmann <michael <at> talamasca.ocis.net>
Permalink | Reply | 9 comments |
headers
Stuart D. Gathman | 4 Feb 2011 16:45

Re: SPFv3 proposal: rawfail result

On Fri, 4 Feb 2011, Alessandro Vesely wrote:

> >> No one should avoid publishing "-all" because there are clueless receivers.
> 
> How about clueless forwarders?

Receivers choose their (legitimate) forwarders, so a clueless forwarder
is still a clueless receiver.  (A receiver with a clue would certainly
*not* want email "forwarded" by random MTAs that they did not request to
do so.)  If a receiver is forced to deal with a badly configured forwarder,
then a simple whitelist accomodates that without causing problems with SPF.

--

-- 
	      Stuart D. Gathman <stuart <at> bmsi.com>
    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.
Permalink | Reply | 0 comments |
headers
Stuart D. Gathman | 4 Feb 2011 17:11

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 <stuart <at> bmsi.com>
    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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alessandro Vesely | 4 Feb 2011 19:56
Picon
Favicon

Wording of the IP parameter, was SPFv3 proposal: rawfail result

On 04/Feb/11 17:11, Stuart D. Gathman wrote:
> 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.

Yes, please.  The spec mentions that checking "can be performed
elsewhere in the mail processing chain", but then it says (twice)

   <ip>   - the IP address of the SMTP client that is emitting the
            mail, either IPv4 or IPv6.

Formally, the client that /is emitting/ the mail is the previous hop,
isn't it?  IMHO, that deserves an errata.

Perhaps the correct wording could be based on a formal definition of
border, along the lines of http://www.openspf.org/Community/Glossary
Permalink | Reply | 0 comments |
headers
Alessandro Vesely | 4 Feb 2011 20:09
Picon
Favicon

Re: SPFv3 proposal: rawfail result

On 04/Feb/11 12:43, Michael Deutschmann wrote:
> On Fri, 4 Feb 2011, Alessandro Vesely wrote:
>> IMHO there is enough confusion already with neutral and softfail.  If
>> we want to provide for more, and still not block, why don't we just
>> allow to set the "mark" value numerically, specifying the score that
>> should be added or subtracted?  E.g.
> 
> The distinction between rawfail and fail is not quantitative -- this is
> why I call it "rawfail" and not "hardfail".
> 
> Fail still means 100.00% confidence of rejection *if the validator is sure
> the message is not a forward*.

To me, it seems nearly impossible to formally define that difference
within the definition of the check_host function, in the face of
forgeries.
Permalink | Reply | 8 comments |
headers
Michael Deutschmann | 5 Feb 2011 10:39

Re: SPFv3 proposal: rawfail result

On Fri, 4 Feb 2011, Alessandro Vesely wrote:
> To me, it seems nearly impossible to formally define that difference
> within the definition of the check_host function, in the face of
> forgeries.

Actually, "check_host" doesn't need to worry about it.  It would be
called upon only to *return* "fail" or "rawfail" according to the SPF
records, not to *interpret* them.

Still, I see what you're talking about, but would counter that it is even
harder to write a single reference behavior-set that makes use of the
distinction between "unknown" and "pass", let alone "softfail".

What I'd do is define a second function "is_internal_forward", that
returns a ternary result : True, False, or Unknown.  The definition would
have to be supplied by the local site, but it would have to satisfy the
following requirements.

 * MUST return True in all cases where a backup MX is handing off a
message towards the primary
 * MAY return Unknown in any other case
 * SHOULD NOT return True when the message is not a forward.
 * SHOULD NOT return False when the message is a forward.

(I use SHOULD because today forwarder whitelisting is done in an ad-hoc
way that could be utterly broken by a forwarder changing the IP or
hostname of its handoff mailserver without notice.

If we used MUSTs, then reject-on-ordinary-fail would not be available to
sites that have merely enumerated their incoming non-rewriting forwards,
(Continue reading)

Permalink | Reply | 7 comments |

Gmane