Subject: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Jan 2012 14:46:30 -0800

I've started this individual submission to correct the SPF entry in the Authentication-Results result name table from "hardfail" to "fail", to match what RFC4408 (and presumably RFC4408bis) says.  This corrects an approved erratum against RFC5451.

I suggested this as a first-tier work item for spfbis but there was resistance to doing so for the sake of keeping its charter lean; since it's really a lightweight effort, I decided to move ahead with it on my own.

Please give it a once over and a thumbs-up if I haven't missed anything.

Thanks,
-MSK

Subject: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt
From: "[email-masked]" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 3 Jan 2012 14:43:51 -0800
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Authentication-Results Registration Update for SPF Results
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-kucherawy-authres-spf-erratum-00.txt
	Pages           : 5
	Date            : 2012-01-03

   This memo updates the registry of authentication method results in
   Authentication-Results: message header fields, correcting a
   discontinuity between the original registry creation and the SPF
   specification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kucherawy-authres-spf-erratum-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-kucherawy-authres-spf-erratum-00.txt

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Jan 2012 22:24:40 -0500

On Tuesday, January 03, 2012 02:46:30 PM Murray S. Kucherawy wrote:
> I've started this individual submission to correct the SPF entry in the
> Authentication-Results result name table from "hardfail" to "fail", to
> match what RFC4408 (and presumably RFC4408bis) says.  This corrects an
> approved erratum against RFC5451.
> 
> I suggested this as a first-tier work item for spfbis but there was
> resistance to doing so for the sake of keeping its charter lean; since it's
> really a lightweight effort, I decided to move ahead with it on my own.
> 

I think what's there is correct and a good change to make.  If you want to 
take a step further and look and making Authentication Results a potential 
replacement for Received-SPF (up to you if you want to tackle this, it's your 
individual submission) there are additional changes needed.

The most critical missing piece is a way to to distinguish between a Mail From 
and HELO result.  Receivers commonly treat these differently and and Received-
SPF provides this.  I would recommend adding two new entries to the Email 
Authentication Method Name Registry:

spf-mfrom
spf-helo

The values in the table would (minimally) be the same as the existing SPF 
entry (alternately it might be sufficient to define the current SPF entry as for 
Mail From - since that is by far the most common - and just add one new entry 
for spf-helo).

Additionally, Received-SPF defines a key value list structure for comments 
about addiitonal information so that they can be machine parsed.  I think this 
is an important part of the header field we should preserve.  I think this will 
need to be more than an IANA registry change, however.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Jan 2012 19:31:35 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, January 03, 2012 7:25 PM
> To: [email-masked]
> Subject: Re: [spfbis] FW: I-D Action: draft-kucherawy-authres-spf-erratum-00.txt
> 
> The most critical missing piece is a way to to distinguish between a
> Mail From and HELO result.  Receivers commonly treat these differently
> and and Received- SPF provides this.  I would recommend adding two new
> entries to the Email Authentication Method Name Registry:
> 
> spf-mfrom
> spf-helo
> 
> The values in the table would (minimally) be the same as the existing
> SPF entry (alternately it might be sufficient to define the current SPF
> entry as for Mail From - since that is by far the most common - and
> just add one new entry for spf-helo).

I think this is already supported.  The very last entry in Section 6.2 of RFC5451 shows that you would do something like:

Authentication-Results: hostname; spf=pass smtp.mailfrom=whatever

...or:

Authentication-Results: hostname; spf=pass smtp.helo=whatever

...to indicate which evaluation was done.

> Additionally, Received-SPF defines a key value list structure for
> comments about addiitonal information so that they can be machine
> parsed.  I think this is an important part of the header field we
> should preserve.  I think this will need to be more than an IANA
> registry change, however.

Check the ABNF in Section 2.2.  The "reasonspec" appears to do just this.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Jan 2012 23:40:43 -0500

On Tuesday, January 03, 2012 07:31:35 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Scott Kitterman Sent: Tuesday, January 03, 2012 7:25 PM
> > To: [email-masked]
> > Subject: Re: [spfbis] FW: I-D Action:
> > draft-kucherawy-authres-spf-erratum-00.txt
> > 
> I think this is already supported.  The very last entry in Section 6.2 of
> RFC5451 shows that you would do something like:
> 
OK.  Perhaps I was misreading 5451 on that one.  If I'm reading you right, 
you're suggesting a ptype of smtp, property of mailfrom or helo, and a pvalue 
of whatever, yielding a single propspec of smtp.mailfrom=whatever.

> Check the ABNF in Section 2.2.  The "reasonspec" appears to do just this.

I think it's close, but Received-SPF provides a list of "reasons" that 
implementations can standardize on (keys):

   key              = "client-ip" / "envelope-from" / "helo" /
                      "problem" / "receiver" / "identity" /
                       mechanism / "x-" name / name

This is important for machine parsing and interoperability.  

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 3 Jan 2012 20:51:30 -0800

> Sent: Tuesday, January 03, 2012 8:41 PM
> To: [email-masked]
> OK.  Perhaps I was misreading 5451 on that one.  If I'm reading you
> right, you're suggesting a ptype of smtp, property of mailfrom or helo,
> and a pvalue of whatever, yielding a single propspec of
> smtp.mailfrom=whatever.

Yes.  In fact I think those were added specifically because SPF wanted them.

> This is important for machine parsing and interoperability.

I think this would best be done in SPFbis itself, as an "Updates RFC5451" type of thing.  That is, enumerate these, and say people SHOULD use a reasonspec with one of them as the value when reporting SPF results using Authentication-Results.  Then we could deprecate Received-SPF, or at least recommend use of the newer header field.

We should drop "x-" from that list though, in deference to draft-ietf-appsawg-xdash.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Jan 2012 23:56:54 -0500

On Tuesday, January 03, 2012 08:51:30 PM Murray S. Kucherawy wrote:
> > Of Scott Kitterman Sent: Tuesday, January 03, 2012 8:41 PM
> > To: [email-masked]

It probably is.  I was misreading the RFC (and some API documentation for the 
Python module for building Authentication Results headers.

> I think this would best be done in SPFbis itself, as an "Updates RFC5451"
> type of thing.  That is, enumerate these, and say people SHOULD use a
> reasonspec with one of them as the value when reporting SPF results using
> Authentication-Results.  Then we could deprecate Received-SPF, or at least
> recommend use of the newer header field.
> 

At the time 4408 was written, x- was the standard method.

I agree this can be done in 4408bis if it's in scope for the working group to 
do so.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 04 Jan 2012 21:45:50 +0100

On 04.01.2012 05:51, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Scott Kitterman
>

I'm not clear on how this is to be done.  I wouldn't like the following:

  Authentication-Results: some-server.example;
    spf=neutral smtp.mailfrom=whatever reasonspec=x-bestguess=pass;

The generic unquoted /name/ in the key rule doesn't suit required IANA
registrations.  SPF extensions will also have to register their properties
and pvalues, if they are not to be considered different methods.

What are the use cases for seldom used Received-SPF keys?  Perhaps, we could
limit A-R to concisely report the results.  How about the following?

  Authentication-Results: some-server.example;
    spf=neutral smtp.mailfrom=whatever (this line could be omitted);
    spf-bestguess=pass smtp.mailfrom=whatever;

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Jan 2012 12:49:25 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Wednesday, January 04, 2012 12:46 PM
> To: [email-masked]

That wouldn't match the ABNF.  If you want to show that SPF itself was neutral but best-guess SPF passed, you should register a method called "bestguess-spf" and then report a separate result for it.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jan 2012 15:51:09 -0500

On Wednesday, January 04, 2012 09:45:50 PM Alessandro Vesely wrote:
> > Authentication-Results.  Then we could deprecate Received-SPF, or at
> > least recommend use of the newer header field.
> 

If (and it's not clear we do yet) we want Authentication Results to supplant 
Recieved-SPF then I think it has to support the same information passing that 
Recieved-SPF support (to the extent the features are being used - perhaps not 
all of them are), so I think while the list could be constrained, I think it 
would be constrained to something pretty close to what's in RFC 4408 for 
Received-SPF.  Some like receiver and IP address are very frequently used.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jan 2012 15:52:42 -0500

On Wednesday, January 04, 2012 12:49:25 PM Murray S. Kucherawy wrote:
> > Of Alessandro Vesely Sent: Wednesday, January 04, 2012 12:46 PM
> > To: [email-masked]
> > I'm not clear on how this is to be done.  I wouldn't like the
> > 
> > following:
> That wouldn't match the ABNF.  If you want to show that SPF itself was
> neutral but best-guess SPF passed, you should register a method called
> "bestguess-spf" and then report a separate result for it.

+1.

A best guess rule result isn't an SPF result and should not be reported as 
one.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Jan 2012 13:00:08 -0800

> Sent: Wednesday, January 04, 2012 12:51 PM
> To: [email-masked]
> If (and it's not clear we do yet) we want Authentication Results to
> supplant Recieved-SPF then I think it has to support the same
> information passing that Recieved-SPF support (to the extent the
> features are being used - perhaps not all of them are), so I think
> while the list could be constrained, I think it would be constrained to
> something pretty close to what's in RFC 4408 for Received-SPF.  Some
> like receiver and IP address are very frequently used.

I think the Updates/SHOULD approach I mentioned yesterday includes all of that.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 04 Jan 2012 16:05:42 -0500

On Wednesday, January 04, 2012 01:00:08 PM Murray S. Kucherawy wrote:
> > Of Scott Kitterman Sent: Wednesday, January 04, 2012 12:51 PM
> > To: [email-masked]

I agree, as long as we put the right stuff on the list and don't overly 
contrain ourselves too early.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 05 Jan 2012 13:55:01 +0100

On 04.01.2012 21:49, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>

Thanks for the clarification.  Thus the following should work

Since we're at it, do you think such method can be registered by your
presently in subject draft?

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 05 Jan 2012 14:21:30 +0100

> Received-SPF.  Some like receiver and IP address are very frequently used.

Indeed, including the IP address was the subject of Section 2 of this appeal:
http://www.sonic.net/~dougotis/id/draft-otis-auth-header-sec-issues-00.html
(See also http://mipassoc.org/pipermail/mail-vet-discuss/2008q4/000511.html)

IMHO, they are two different header fields, with different aims, and the
cycles required to make them equal could be better spent in useful tasks.

---

From: Dotzero <[email-masked]>
Date: Thu, 5 Jan 2012 09:21:27 -0500

On Wed, Jan 4, 2012 at 3:52 PM, Scott Kitterman <[email-masked]> wrote:
<snippage>
> A best guess rule result isn't an SPF result and should not be reported as

+1

---

From: Hector Santos <[email-masked]>
Date: Thu, 05 Jan 2012 09:36:16 -0500

Dotzero wrote:
> On Wed, Jan 4, 2012 at 3:52 PM, Scott Kitterman wrote:
>

+1

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 05 Jan 2012 06:40:23 -0800

+1

Protocol standards do not include heuristics.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 5 Jan 2012 09:11:40 -0800

> Sent: Thursday, January 05, 2012 4:55 AM
> To: [email-masked]

No, piggybacking on an erratum is not appropriate.

The spfbis working group can take this on when it recharters.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Jan 2012 10:18:17 -0700

> The spfbis working group can take this on when it recharters.

Agreed.

Peter

-- 
Peter Saint-Andre
http://stpeter.im/