Subject: [spfbis] Section 7 of draft-ietf-spfbis-4408bis-05

From: SM <[email-masked]>
Date: Sun, 19 Aug 2012 09:35:59 -0700

Hello,

The following text is from Section 7 of RFC 4408:

   'It is RECOMMENDED that SMTP receivers record the result of SPF
    processing in the message header.  If an SMTP receiver chooses to do
    so, it SHOULD use the "Received-SPF" header field defined here for
    each identity that was checked.  This information is intended for the
    recipient.  (Information intended for the sender is described in
    Section 6.2, Explanation.)'

And the text below is from draft-ietf-spfbis-4408bis-05:

   'It is RECOMMENDED that SMTP receivers record the result of SPF
    processing in the message header.  There are two methods for doing
    this: the Received-SPF header field defined here and the more generic
    Authentication-Results header field defined in [RFC5451].  Because
    these fields are generally used within a receiving ADMD, it is a
    local policy choice which to include.  In general, the more broadly
    applicable Authentication-Results header field ought to be used, but
    it SHOULD be used in such a way that it conveys the same information
    that the verifier would have provided in a Received-SPF header field
    if that had been used.

    If an SMTP receiver chooses to do so, it SHOULD use one of these
    header fields for each identity that was checked.  This information
    is intended for the recipient.  (Information intended for the sender
    is described in Section 6.2, Explanation.)'

My reading of the old text is that SMTP receivers record the result 
of SPF processing for the recipient.  The new text proposes two 
methods of conveying the information to the recipient.  This is the 
kind of text which causes debates.  If which header to add is a 
matter of local policy, the receiver also have the ability to follow 
the specification; RFC 5451 in this case.  I suggest adding 
(non-normative) guidance if anyone would like to have the 
Authentication-Results: header.  Anything more than that ends up as 
not picking one option and trying to satisfy everyone.

I have read the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html   I 
have also read the other messages about the topic.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 19 Aug 2012 13:18:49 -0400

> have also read the other messages about the topic.

The suggestion in the current text about how to create an Authentication-
Results header field that is a suitable replacement for Received-SPF goes 
beyond the minimal requirements of RFC 5451, so, in my opinion, merely using 
the mandatory elements of the field from RFC 5451 is not sufficient.

Are you objecting to "In general, the more broadly applicable Authentication-
Results header field ought to be used "?  

I think that giving guidance on how to use A-R in this context is important 
and appropriate (Use of A-R is, I believe, in scope as a widely used 
extension, but until now there's no standardized guidance on use as a 
replacement for SPF-Received).  In IETF terms, I believe this is an 
applicability statement

I think I'm not following your concern.  Perhaps if you proposed specific text 
I would understand it better.

Scott K

---

From: SM <[email-masked]>
Date: Sun, 19 Aug 2012 10:38:17 -0700

Hi Scott,
>Results header field ought to be used "?

My comment, which is not an objection, is about picking one 
option.  The consequences of having two options is documented in RFC 6686.

>replacement for SPF-Received).  In IETF terms, I believe this is an

I am ok with providing guidance.  Having a SHOULD is not 
guidance.  It is a recommendation (see RFC 2119).  I don't see how 
4408bis can be an applicability statement about RFC 5451.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 19 Aug 2012 13:52:08 -0400

On Sunday, August 19, 2012 10:38:17 AM SM wrote:
> >Are you objecting to "In general, the more broadly applicable
> >Authentication- Results header field ought to be used "?
> 

There are two options.  We can't remove Received-SPF as it is in use.  RFC 
5451 exists.  Use of A-R as specified in RFC 5451 contains less information 
than Received-SPF does, so it's not a fully suitable replacement.

So there isn't, at this time, a basis for picking.

I also don't think there's a reason to pick.  As long as one is picked and 
used within an ADMD, it doesn't matter which it is.

AIUI, an applicability statement is about how to combine two technologies to 
meet a certain goal.  I think that's exactly what the current text does 
between A-R and SPF.  4408bis is not formally an applicability statement, but 
it accomplishes the same goal in this case.

Also the only SHOULD we have is that the result SHOULD be recorded.  There's 
no 2119 preference for either and I think that is appropriate.

Scott K

---

From: SM <[email-masked]>
Date: Sun, 19 Aug 2012 11:51:38 -0700

>used within an ADMD, it doesn't matter which it is.

I'll comment without taking any position on "in use".  I do not have 
an opinion for or against the Authentication-Results: header.  There 
are days when it is good to have an IESG.  It can point out the 
uncomfortable choices that a working group does not want to make.

As the MTA operator, I get to decide whether to use Received-SPF: or 
Authentication-Results: as it is mentioned that it is a policy 
matter.  I can pick either.

Assuming I sell an add-on for MUAs, if the recipient asks whether the 
software supports SPF, I say yes as the Received-SPF: header can be 
parsed.  The MTA the recipient uses adds an Authentication-Results: 
header.  The recipient does not get the SPF result because of 
that.  This is the type of operational issue that occurs when there 
isn't any standardized method to convey information.

Regards,
-sm

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 19 Aug 2012 16:09:32 -0400

> isn't any standardized method to convey information.

Currently, the field this is handled by supporting both.  

As an example, my pypolicyd-spf policy server for postfix will cause postfix to 
add Received-SPF: by default.  It can optionally be configured to add A-R.  
I've also provided documentation on how to provide both if desired.  
Spamassassin will gladly consume either (I didn't check what it does if there 
are two from the same MTA).

SMTP Auth provides multiple mechanisms and if the client and server have none 
in common, no authorization is possible.  I think that's fine and this is no 
different.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 19 Aug 2012 21:15:58 -0700

On Sun, Aug 19, 2012 at 9:35 AM, SM <[email-masked]> wrote:
> My reading of the old text is that SMTP receivers record the result of SPF
> processing for the recipient.  The new text proposes two methods of
> conveying the information to the recipient.  This is the kind of text which
> causes debates.  If which header to add is a matter of local policy, the
> receiver also have the ability to follow the specification; RFC 5451 in this
> case.  I suggest adding (non-normative) guidance if anyone would like to
> have the Authentication-Results: header.  Anything more than that ends up as

I imagine this can be resolved by pointing out the reason support for
two schemes is included, namely that one is historic but still in some
use while the other is an established proposed standard used by
several other mechanisms.  It is in effect a migration path.
Essentially, a receiving ADMD can use either one, but there's more
momentum behind one of them to have more wide adoption in the long
term, and implementers should be aware of that.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Aug 2012 14:24:14 -0700

> term, and implementers should be aware of that.

A further thought:

Use of A-R or Received-SPF is not a part of the SPF protocol itself.
Where SPF is a protocol between the SMTP client and server, this stuff
is a protocol between the SPF verifier and internal filters and MUAs.
Put another way: If an SPF verifier doesn't add either of these, do we
claim it's non-compliant?

We might instead drop all the normative stuff from Section 7 and just
say: If the verifier wishes to communicate SPF results to internal
agents like filters or MUAs, it can use either of these two
mechanisms; the reason we present two mechanisms instead of one is
because one (Received-SPF) was in RFC4408 and in popular use among SPF
implementations, while the other (A-R) is the more general proposed
standard gaining wider adoption.  We'd probably make the IESG happier
to converge on one, but I suspect they'd let this slide under the
guise of an implicit migration path.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Mon, 20 Aug 2012 15:32:59 -0700

>claim it's non-compliant?

If I had to describe this I would say that we would like to have 
interoperability between the SPF publisher and the "mail 
receiver".  If the "mail receiver" would like to interoperate with a 
MUA (it can be another filtering option) that's another part.  If you 
want everything as a whole, you cannot have local policy in between 
the SPF publisher and the MUA.

>guise of an implicit migration path.

If there isn't any interoperability issues, it less of a problem.  I 
suggest keeping matters simple unless someone has a good reason for X 
or Y.  The above is one alternative.  If anyone has other alternative 
to suggest, I would like to hear it.

Regards,
S. Moonesamy
SPFBIS WG co-chair