Subject: [spfbis] Proposed Section 7 update

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 10:39:19 -0700

7. Recording The Result

For operators that choose to record SPF results in the header of the
message for processing by internal filters or MUAs, two methods are
presented.  Section 7.1 defines the Received-SPF field, which is the
results field originally defined for SPF use.  Section 7.2 discusses
Authentication-Results [RFC5451] which was specified more recently and
is designed for use by SPF and numerous other authentication
protocols.

Both are in common use, and hence both are included here.  However, it
is important to note that they serve slightly different purposes:
Received-SPF is intended to include enough forensic information to
enable reconstruction of the SPF evaluation of the message, while
Authentication-Results is designed only to relay the result itself and
related output details of likely use to end users (e.g., what property
of the message was actually authenticated and what it contained),
leaving forensic work to the purview of system logs and the Received
field contents.  Also, Received-SPF relies on compliance of agents
within the receiving ADMD to adhere to the header field ordering rules
of [RFC5321] and [RFC5322], while Authentication-Results includes some
provisions to protect against non-compliant implementations.

An operator could choose to use both to serve different downstream
agents.  In such cases, care needs to be taken to ensure both fields
are conveying the same details, or unexpected results can occur.

7.1.  The Received-SPF Header Field

<unchanged from what's there now>

7.2.  The Authentication-Results Header Field

[RFC5451] defined the Authentication-Results header field and included
provisions for reporting SPF results to downstream agents.  As noted
above, however, it lacks the capability to include certain forensic
details.

If an operator wishes to use this field, the missing forensic details
could be included either in the "reasonspec" or in header field
comments, which can then be extracted and used by downstream agents.
For example:

<Scott's example of A-R use here>

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 31 Aug 2012 14:18:31 -0400

On Friday, August 31, 2012 10:39:19 AM Murray S. Kucherawy wrote:

I think, before discussing the specific text, we should resolve what to do 
about the fundamental idea of adding a header field.  Your proposed text 
starts:

>     7. Recording The Result
> 
>     For operators that choose to record SPF results ...

RFC 4408 starts:

>    It is RECOMMENDED that SMTP receivers record the result of SPF
>    processing in the message header.

Was this change intentional and if so, what was the rationale?  I don't recall 
any discussion that adding a header field was a bad idea.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 11:19:08 -0700

Hi Murray,
>are conveying the same details, or unexpected results can occur.

Thanks.  The text is well-written.  I don't think that the working 
group will get away with "relies on compliance within receiving ADMD" 
to address security considerations about the Received-SPF: header field.

John Levine commented on possible issues if an operator chooses to 
use both headers.  You covered that in the second sentence of the 
third paragraph.  I am not comfortable with that as it looks like 
DISCUSS material.  I'll advise the working group against that to be 
on the safe side.

><unchanged from what's there now>

The following text can be used to argue about the forensic information:

   "The following key-value pairs are designed for later machine parsing.
    SPF verifiers SHOULD give enough information so that the SPF results
    can be verified."

Parallels will be drawn between the two header fields.

><Scott's example of A-R use here>

I previously mentioned that Section 7.2 looks like an update to RFC 
5451.  if you feel strongly about the above, I'll suggest folding the 
text into Section 7.

I would like to look at stable text (one that the WG can agree on) to 
have a better view of the implications.  Otherwise, I will be looking 
at one alternative instead of considering all the alternatives.  The 
text is a good starting point.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 11:35:36 -0700

> any discussion that adding a header field was a bad idea.

I don't think it's a bad idea, but it is still an operator choice.  On
the basis that SPF is a protocol primarily between MTAs, not adding a
field at all doesn't violate that interoperability so the RECOMMENDED
isn't really meaningful.

However, in the interests of staying consistent with RFC4408, I'd be
fine restoring that sentence.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 11:40:50 -0700

On Fri, Aug 31, 2012 at 11:19 AM, S Moonesamy <[email-masked]> wrote:
> Thanks.  The text is well-written.  I don't think that the working group
> will get away with "relies on compliance within receiving ADMD" to address
> security considerations about the Received-SPF: header field.

Why?

> John Levine commented on possible issues if an operator chooses to use both
> headers.  You covered that in the second sentence of the third paragraph.  I
> am not comfortable with that as it looks like DISCUSS material.  I'll advise
> the working group against that to be on the safe side.

In that we can't remove Received-SPF since it's in use, but A-R is
increasing in use, it seems that we are in a position where providing
both options is entirely appropriate.  Since there's been pressure
even at the IESG level to be forward-compatible, I think we're going
to get less resistance than you're predicting.

> I previously mentioned that Section 7.2 looks like an update to RFC 5451.
> if you feel strongly about the above, I'll suggest folding the text into
> Section 7.

It's not an update in the normative sense.  It suggests possible use.
It doesn't rise to the level of an applicability statement.  I think
it's fine.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 31 Aug 2012 14:40:55 -0400

On Friday, August 31, 2012 11:35:36 AM Murray S. Kucherawy wrote:
> > Was this change intentional and if so, what was the rationale?  I don't
> > recall any discussion that adding a header field was a bad idea.
> 

Thanks.  I think it's better to stay consistent without a strong reason to 
change.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 31 Aug 2012 14:51:30 -0400

> <Scott's example of A-R use here>

I think (with the RECOMMENDED change already discussed upstream) this is 
pretty good.  Can we squeeze the suggestion to use the SPF-Received key-value-
list to add details to A-R into here?  I don't think it needs to be more than 
'here's a reasonable way to do it', but I'd like to at least suggest something 
if people want to go down this path (and it helps support the example, which 
does exactly that).

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 11:55:45 -0700

> if people want to go down this path (and it helps support the example, which

You could do that in a sentence or two right before including your
example.  Just don't use any normative language to say you SHOULD or
MUST do it this way and I think it's fine.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 11:55:44 -0700

>Why?

If the argument wasn't convincing for Authentication-Results:, it 
won't be convincing here.

>to get less resistance than you're predicting.

Maybe.

 From an IETF perspective, we have not explored all the 
possibilities.  Let me try and list for constraints:

   (a) address security concerns

   (b) taking into account what's in use

   (c) the charter

The Received-SPF: header field is about (a) while 
Authentication-Results: header field is about (c).  I'll leave others 
to chime in on this to get a better idea.

>It doesn't rise to the level of an applicability statement.  I think

Ok.  I mentioned it to avoid any surprises.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 12:21:53 -0700

On Fri, Aug 31, 2012 at 11:55 AM, S Moonesamy <[email-masked]> wrote:
> If the argument wasn't convincing for Authentication-Results:, it won't be
> convincing here.

I think the fact that Received-SPF is already in use means we can't
remove it.  The best we can do is call out that it's at the mercy of
the "no reordering" rule and implementations' adherence to it.

> Maybe.
>
> From an IETF perspective, we have not explored all the possibilities.  Let
> me try and list for constraints:
>
> The Received-SPF: header field is about (a) while Authentication-Results:
> header field is about (c).  I'll leave others to chime in on this to get a
> better idea.

I think the proposed text (intentionally) addresses all three of those concerns.

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 12:32:52 -0700

Hi Murray,
>the "no reordering" rule and implementations' adherence to it.

We have one wish where we can beg the IESG for mercy. :-)  My 
preference is not to use it for this issue.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 31 Aug 2012 17:12:11 -0400

> the "no reordering" rule and implementations' adherence to it.

Absolutely.  Additionally, there's no evidence so far that removing it is even 
a good idea.

> I think the proposed text (intentionally) addresses all three of those

I agree.

I think the current bidding on the text is something like this then:

7. Recording The Result

It is RECOMMENDED that SMTP receivers record the result of SPF processing in 
the message header for processing by internal filters or MUAs.  Two methods are
presented.  Section 7.1 defines the Received-SPF field, which is the results 
field originally defined for SPF use.  Section 7.2 discusses Authentication-
Results [RFC5451] which was specified more recently and is designed for use by 
SPF and numerous other authentication protocols.

If an operator wishes to use this field, the missing forensic details
could be included either in the "reasonspec" or in header field
comments, which can then be extracted and used by downstream agents.  Using 
the SPF-Received key-value-list (see Section 7.1) would provide a structured 
method to convey this information.  For example:

How's that?  The only changes from Murray's original text are to put the 
RECOMMENDED back at the beginning and make reference to the key-value-list in 
the A-R section.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 15:07:10 -0700

> RECOMMENDED back at the beginning and make reference to the key-value-list in

In retrospect, I think it would be good to explain (in no more than a
sentence or so) why it's RECOMMENDED.  Otherwise I'm (obviously) happy
with the text I proposed.  :-)

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 31 Aug 2012 18:31:16 -0400

On Friday, August 31, 2012 03:07:10 PM Murray S. Kucherawy wrote:
> > RECOMMENDED back at the beginning and make reference to the key-value-list
> > in the A-R section.
> 

In order to avoid the uncertainty associated with internal MTA SPF assessments 
(see [MTA Relays]) in follow on processing and to assist in trouble shooting 
...

How's that?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 15:52:04 -0700

> (see [MTA Relays]) in follow on processing and to assist in trouble shooting

I'm thinking:

To provide downstream agents, such as MUAs, with the information they
may need in terms of evaluating or representing the apparent safety of
the message content, it is RECOMMENDED...

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 31 Aug 2012 19:18:00 -0400

>the message content, it is RECOMMENDED...

Works for me.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Fri, 31 Aug 2012 20:59:37 -0400

It would be wonderful to get more WG participant input, especially 
from current SPF vendors, implementators  in this exchange. Too 
limited input IMV may does not adequately represent the SPF community 
which I hope the WGCs take serious.  I personally have some "MUA" 
related issues with the text below, in addition to the some MUA 
inconsistencies in applicability here vs there.

Scott Kitterman wrote:
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 01 Sep 2012 00:50:13 -0400

"I have some issues" isn't actionable.  Please provide actionable comments, 
preferably with proposed text.

Scott K

On Friday, August 31, 2012 08:59:37 PM Hector Santos wrote:
> >> On Fri, Aug 31, 2012 at 3:31 PM, Scott Kitterman <[email-masked]>
> >> 
> >> wrote:
> >>>> In retrospect, I think it would be good to explain (in no more than
> >> 
> >> a
> >> 
> >>>> sentence or so) why it's RECOMMENDED.  Otherwise I'm (obviously)
> >> 
> >> happy
> >> 
> >>> In order to avoid the uncertainty associated with internal MTA SPF
> >> 
> >> assessments
> >> 
> >>> (see [MTA Relays]) in follow on processing and to assist in trouble
> >> 
> >> shooting
> >> 
> >>> ...
> >>> 
> >>> How's that?
> >> 
> >> I'm thinking:
> >>