Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451

From: S Moonesamy <[email-masked]>
Date: Mon, 12 Mar 2012 11:19:09 -0700

At 14:10 07-02-2012, spfbis issue tracker wrote:
>#10: RFC 4408 rplace Received-SPF with RFC5451
>
>  Message from Murray Kucherawy on 6 Feb 2012:
>
>  We should consider striking Section 7 and replacing it with a reference to
>  RFC5451 with some reasonable but brief associated text.
>
>  http://www.ietf.org/mail-archive/web/spfbis/current/msg00330.html

[snip]

>Ticket URL: <http://trac.tools.ietf.org/wg/spfbis/trac/ticket/10>

Please comment on Issue #10.  As a reminder, please keep the subject line.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 14:57:22 -0400

On Monday, March 12, 2012 11:19:09 AM S Moonesamy wrote:
> >  We should consider striking Section 7 and replacing it with a
> >  reference to RFC5451 with some reasonable but brief associated text.

At the time RFC 4408 was written, there was no general framework for reporting 
authentication results, so the Received-SPF trace header was developed.  It is 
still widely used.  Now that Authentication-Results exists and is gaining 
deployment, I agree that it should eventually replace Received-SPF.

I have reviewed the Authentication-Results header definition and implemented it 
as an optional alternative to Received-SPF.  I also helped create a Python 
module for creating and parsing Authentication-Results headers 
(http://pypi.python.org/pypi/authres ).  Based on that work, I believe that 
Authentication-Results is technically suitable to replace Received-SPF.

I do not, however, think we can do it now.  Received-SPF is a feature in 
widespread use and so it's too soon (charter or no charter I think it's 
premature).  I would, however, support including information about both in 
4408bis with an indication that Received-SPF is deprecated and support may be 
dropped in the future when the specification is revisited.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 19:15:03 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Monday, March 12, 2012 11:57 AM
> To: [email-masked]
> Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
> 
> I do not, however, think we can do it now.  Received-SPF is a feature
> in widespread use and so it's too soon (charter or no charter I think
> it's premature).  I would, however, support including information about
> both in 4408bis with an indication that Received-SPF is deprecated and
> support may be dropped in the future when the specification is
> revisited.

At the risk of harkening back to the type 99 debate, I have two points in response to this:

1) I'm concerned about endorsing two mechanisms.  This may be the right way forward, but I'm not sure yet.  And if it is, I want to be very careful not to create another type 99 problem.

2) It's clear there are SPF verifiers that add Received-SPF, but it's not clear that anything other than humans actually consumes it.  There are however implementations of RFC5451 (at least one) that do parse them inbound in order to conform to the "remove your own on inbound" requirement that specification imposes, and I imagine there have to be more for that reason.  If we conclude there's no machine processing of Received-SPF inbound, then I suspect it's safe, and within charter, to switch.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 15:31:02 -0400

On Monday, March 12, 2012 07:15:03 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Scott Kitterman Sent: Monday, March 12, 2012 11:57 AM
> > To: [email-masked]
> 1) I'm concerned about endorsing two mechanisms.  This may be the right way
> forward, but I'm not sure yet.  And if it is, I want to be very careful not
> to create another type 99 problem.
> 
> 2) It's clear there are SPF verifiers that add Received-SPF, but it's not
> clear that anything other than humans actually consumes it.  There are
> however implementations of RFC5451 (at least one) that do parse them
> inbound in order to conform to the "remove your own on inbound" requirement
> that specification imposes, and I imagine there have to be more for that
> reason.  If we conclude there's no machine processing of Received-SPF
> inbound, then I suspect it's safe, and within charter, to switch.

There are such.  Spamassassin will consume Received-SPF.  Recent versions will 
consume Auth-Results too.  I'm also aware of a number of private 
implementations that do the remove your own on inbound processing.

As an example of why I think it's too soon to switch, I only recently finished 
implementing Auth-Res support for the Python based SPF policy-server for 
Postfix that I develop/maintain.  This is new enough that, AFAIK, it has yet to 
appear in any Linux distribution release.

Because there is no automatice multi-ADMD interoperability requirement for 
either of these trace headers (to the extent they are processed, they only 
matter within an ADMD), there isn't an issue with getting stuck in a non-
deployment don't loop like we have with Type SPF.  

In any case, given that the feature is widely used, I'm not sure how you can 
find it in the charter to be OK to remove?

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 19:36:05 +0000

> Sent: Monday, March 12, 2012 12:31 PM
> To: [email-masked]
> In any case, given that the feature is widely used, I'm not sure how
> you can find it in the charter to be OK to remove?

I did say "If we conclude...".  If we don't, then it isn't.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 15:40:48 -0400

On Monday, March 12, 2012 07:36:05 PM Murray S. Kucherawy wrote:
> > Of Scott Kitterman Sent: Monday, March 12, 2012 12:31 PM
> > To: [email-masked]

I don't think that if it's machine processed or not is particularly germane to 
the charter requirements, but since it is used via machine processing, I think 
the argument is moot.  I guess I'll save it for if we get there.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Mon, 12 Mar 2012 16:41:32 -0400

>>  I would, however, support including information about
> 1) I'm concerned about endorsing two mechanisms.  This may be the right
way forward,
> but I'm not sure yet.

Isn't that what Scott's "deprecated" suggestion says?  Deprecating
"Received-SPF" means saying that it's in current use, but new
implementations are advised not to generate it (basically, SHOULD NOT).
 For something that has enough usage that we can't remove it (yes, the
charter goes against that), noting that it's on the way out and new
implementations shouldn't generate it seems to be the right way to go.

Barry, participatorilly

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Mar 2012 20:46:54 +0000

As long as that's made clear, sure.  I'm just trying to avoid having two mechanisms in use like we did with the RRTypes.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Monday, March 12, 2012 1:42 PM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451

> 1) I'm concerned about endorsing two mechanisms.  This may be the right way forward,
> but I'm not sure yet.

Isn't that what Scott's "deprecated" suggestion says?  Deprecating "Received-SPF" means saying that it's in current use, but new implementations are advised not to generate it (basically, SHOULD NOT).  For something that has enough usage that we can't remove it (yes, the charter goes against that), noting that it's on the way out and new implementations shouldn't generate it seems to be the right way to go.

Barry, participatorilly

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Mar 2012 16:52:39 -0400

I think the transition issue is very different.  For this one it's make sure 
you're generating the same thing at the border that you're consuming 
internally for each ADMD, not "Let's switch over everyone on the internet".

Scott K

On Monday, March 12, 2012 08:46:54 PM Murray S. Kucherawy wrote:
> As long as that's made clear, sure.  I'm just trying to avoid having two
> mechanisms in use like we did with the RRTypes.
> 
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Barry Leiba Sent:
> Monday, March 12, 2012 1:42 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> > At the risk of harkening back to the type 99 debate, I have two points
> > in response to this: 1) I'm concerned about endorsing two mechanisms. 
> > This may be the right way forward, but I'm not sure yet.
>

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 13 Mar 2012 13:17:57 +0100

On 12/Mar/12 21:41, Barry Leiba wrote:
>>> I would, however, support including information about both in
>>> 4408bis with an indication that Received-SPF is deprecated and 
>> 1) I'm concerned about endorsing two mechanisms.  This may be the
>> right way forward, but I'm not sure yet.
> 
> implementations are advised not to generate it (basically, SHOULD
> NOT).  For something that has enough usage that we can't remove it
> (yes, the charter goes against that), noting that it's on the way out
> and new implementations shouldn't generate it seems to be the right
> way to go.

Hm... a SHOULD NOT seems quite stronger than needed here.  There are
implementations that use both, and it is not much disturbing (except
for bandwidth/storage, that is.)  I'd let it at MAY, noting that the
evolution is toward the more homogeneous A-R, but allowing plenty of
time to migrate.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 13 Mar 2012 11:10:55 -0400

Scott Kitterman <[email-masked]> wrote:

>Alessandro Vesely <[email-masked]> wrote:
>

I think the term deprecated is a sufficiently standard software development term to make the point that needs making.  Since automatic processing generally takes place within an ADMD, switching isn't something that has global interoperability impacts. I don't think any kind of 2119 MUSTard is appropriate here.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 14 Mar 2012 11:52:58 -0700

This is a summary of the comments on Issue #10.  As usual, if I 
misinterpreted or misunderstood your comments, please let me know.

Issue #10 was opened based on the message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00330.html

Scott Kitterman believes that Authentication-Results is technically 
suitable to replace Received-SPF but he does not think that it can be 
done now [1].  Murray Kucherawy mentioned that it clear there are SPF 
verifiers that add Received-SPF, but it's not clear that anything 
other than humans actually consumes it.  He mentioned that there are 
however implementations of RFC5451 (at least one) that do parse them 
inbound in order to conform to the "remove your own on inbound" 
requirement that specification imposes [2].  He concluded that it is 
safe and within the charter to switch.  Scott Kitterman pointed out 
that there is an implementation that consumes the Received-SPF header 
and mentioned that the feature is widely used [3].

Barry Leiba, as a participant, pointed out that deprecating 
"Received-SPF" means saying that it's in current use, but new 
implementations are advised not to generate it (basically, SHOULD 
NOT).  For something that has enough usage that we can't remove it 
(yes, the charter goes against that), noting that it's on the way out 
and new implementations shouldn't generate it seems to be the right 
way to go [4].  Alessandro Vesely suggested a MAY, noting that the 
evolution is toward the more homogeneous A-R, but allowing plenty of 
time to migrate [5].

Scott Kitterman mentioned that since automatic processing generally 
takes place within an ADMD, switching isn't something that has global 
interoperability impacts [6].

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00861.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00862.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg00863.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00872.html
5. http://www.ietf.org/mail-archive/web/spfbis/current/msg00879.html
6. http://www.ietf.org/mail-archive/web/spfbis/current/msg00880.html

---

From: Stuart Gathman <[email-masked]>
Date: Tue, 20 Mar 2012 11:38:32 -0400

Long ago, Nostradamus foresaw that on 03/12/2012 03:15 PM, Murray S.
Kucherawy would write:
> 2) It's clear there are SPF verifiers that add Received-SPF, but it's
> not clear that anything other than humans actually consumes it. There
> are however implementations of RFC5451 (at least one) that do parse
> them inbound in order to conform
My MTAs parse Received-SPF from trusted forwarders, and accrue
reputation to the domain:spf-result therein.  Sure, I will eventually
handle A-R also, but it isn't done yet.  It is too soon to drop
Received-SPF.  Unlike type99, there is no penalty to having both headers
- other than a few bytes per message.  So mentioning the new header is
good.  But don't drop the old one.  Yet.

---

From: Paul Midgen <[email-masked]>
Date: Thu, 22 Mar 2012 20:03:29 +0000

After reading through all this, and being a new implementer of SPF that already implements RFC5451, if given the choice I will not stamp Received-SPF.

I'd prefer not to because (believe it or not, every byte counts) this reduces mail storage cost. RFC5451 already provides the opportunity to remove a bunch of other x- headers Hotmail inflicted on itself, so I don't see the point in adding redundancy.

Since I'm not removing Received-SPF from an existing implementation, this seems in-line with current sentiment.

-p

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
Sent: Wednesday, March 14, 2012 11:53 AM
To: [email-masked]
Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451

This is a summary of the comments on Issue #10.  As usual, if I misinterpreted or misunderstood your comments, please let me know.

Issue #10 was opened based on the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg00330.html

Scott Kitterman believes that Authentication-Results is technically suitable to replace Received-SPF but he does not think that it can be done now [1].  Murray Kucherawy mentioned that it clear there are SPF verifiers that add Received-SPF, but it's not clear that anything other than humans actually consumes it.  He mentioned that there are however implementations of RFC5451 (at least one) that do parse them inbound in order to conform to the "remove your own on inbound" 
requirement that specification imposes [2].  He concluded that it is safe and within the charter to switch.  Scott Kitterman pointed out that there is an implementation that consumes the Received-SPF header and mentioned that the feature is widely used [3].

Barry Leiba, as a participant, pointed out that deprecating "Received-SPF" means saying that it's in current use, but new implementations are advised not to generate it (basically, SHOULD NOT).  For something that has enough usage that we can't remove it (yes, the charter goes against that), noting that it's on the way out and new implementations shouldn't generate it seems to be the right way to go [4].  Alessandro Vesely suggested a MAY, noting that the evolution is toward the more homogeneous A-R, but allowing plenty of time to migrate [5].

Scott Kitterman mentioned that since automatic processing generally takes place within an ADMD, switching isn't something that has global interoperability impacts [6].

Regards,
S. Moonesamy

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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 22 Mar 2012 17:01:19 -0400

On Thursday, March 22, 2012 08:03:29 PM Paul Midgen wrote:
> After reading through all this, and being a new implementer of SPF that
> already implements RFC5451, if given the choice I will not stamp
> Received-SPF.
> 
> I'd prefer not to because (believe it or not, every byte counts) this
> reduces mail storage cost. RFC5451 already provides the opportunity to
> remove a bunch of other x- headers Hotmail inflicted on itself, so I don't
> see the point in adding redundancy.
> 

Agreed.  By definition, no one is depending on your implementation providing 
Received-SPF and which you provide is primarily a matter for how you chose to 
do things within your overall ADMD.  There are people that relay out of 
Hotmail to other providers for final delivery that might prefer to see both, 
but it's not like they are getting anything now.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 23 Mar 2012 09:07:08 +0100

On 22/Mar/12 22:01, Scott Kitterman wrote:
> do things within your overall ADMD.

+1, it makes sense to encourage new implementations to use A-R (only).

> There are people that relay out of Hotmail to other providers for
> final delivery that might prefer to see both, but it's not like
> they are getting anything now.

Hm... some implementations rename that to Original-Received-SPF.  The
old header field was not designed for forwarding.  (Actually, SPF
itself was not designed for forwarding, but this mumbling belongs to
the other thread...)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 23 Mar 2012 17:33:53 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Friday, March 23, 2012 1:07 AM
> To: [email-masked]
> > final delivery that might prefer to see both, but it's not like they
> > are getting anything now.
> 

Why would they do that?  As I recall, Received-SPF includes an indication of who added it, so this shouldn't strictly be necessary.

Worth documenting in any case.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 24 Mar 2012 16:49:42 +0100

On 23.03.2012 18:33, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of Alessandro Vesely
>
>> Hm... some implementations rename that to Original-Received-SPF.
> 
> Why would they do that?

To ease checking, IIRC.  I'm unable to find that discussion right now, I'll
confirm (or retract) this point next week.

> As I recall, Received-SPF includes an indication of who added it, so this
> shouldn't strictly be necessary.

Correct.  However, the "receiver" field is not mandatory, and there is no
discussion about removing spoofed fields.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 24 Mar 2012 12:00:59 -0400

> discussion about removing spoofed fields.

The implementations I've seen use a combination of Received: and Received-SPF: 
to determine which ones were added by a trusted MTA.  There's an assumption 
that anything added before the first trusted MTA will be ignored, so there's no 
need to remove them (they are untrustworthy, but not necessarily spoofed).

This is not completely reliable, but better than trying to extract the correct 
source IP address out of a Received: field and apply SPF against that after the 
SMTP transaction is finished (which I have also seen).

Scott K