Subject: [spfbis] Authentication-Result (Issue 10?)

From: Hector Santos <[email-masked]>
Date: Thu, 23 Aug 2012 01:18:28 -0400

Just notice that Auth-Res was added (which I agree with) but not as an 
exclusive replacement for Received-SPF at this stage.  Wouldn't that 
make this a SPF protocol change?

Specifically, in 2.5.4, it has an OR

    If the checking software chooses not to reject the mail during the
    SMTP transaction, then it SHOULD add a Received-SPF or
    Authentication-Results header field (see Section 7) to communicate
    this result to downstream message processors.

For 4408BIS implementators who choose Auth-Res, would this not open an 
possible interop or compatibility issue with any 3rd party mail 
filtering applet still focused on Received-SPF?  I don't have any 
control over 3rd party filters.

If were to do this tomorrow, we would to add Receiver-SPF AND 
Authentication-Result, a new one or append to the existing 
Authentication-Result that may come from some other mail 
authentication protocol check.

Anyway, I think this and related sections should convey this as 
migration feature because I don't think it will cater to all existing 
systems that already have bots (theirs or 3rd party) that rely on 
Receiver-SPF.  I suspect most will add both since they may not be able 
to technically afford breaking existing operations with just Auth-Res 
version for SPF.

I'm not sure if this also violates "Don't Break SPF" concerns.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Thu, 23 Aug 2012 07:40:41 -0700

At 22:18 22-08-2012, Hector Santos wrote:
>migration feature because I don't think it will cater to all 
>existing systems that already have bots (theirs or 3rd party) that 
>rely on Receiver-SPF.  I suspect most will add both since they may 
>not be able to technically afford breaking existing operations with 
>just Auth-Res version for SPF.

I am quoting the above for context.  I copied this message to Douglas 
Otis to notify him that this issue is being discussed.

The Responsible Area Director once asked what was the problem with 
keeping the Received-SPF: header.  The argument was about long-term 
simplification.  John Levine mentioned that if you were allowed to 
generate both headers, they could disagree.  Douglas Otis provided 
arguments in favor of retaining the Received-SPF: header ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html ).

Murray Kucherawy suggested an alternative in a message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02175.html 
Could the working group please work out something from there?

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: S Moonesamy <[email-masked]>
Date: Sat, 25 Aug 2012 01:13:59 -0700

Dear SPFBIS WG,

The text below 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.)"

The following text is from Section 2.5.4 of draft-ietf-spfbis-4408bis-06:

   "If the checking software chooses not to reject the mail during the
    SMTP transaction, then it SHOULD add a Received-SPF or
    Authentication-Results header field (see Section 7) to communicate
    this result to downstream message processors.  While this is true for
    all SPF results, it is of particular importance for "fail" results
    since the message is explicitly not authorized by the domain owner."

I consider the above as a significant change to Section 2.5.4.

And from Section 7 of draft-ietf-spfbis-4408bis-06:

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

I consider the above as a significant change to Section 7.

I'll skip Section 7.1 for now.  From Section 7.2:

   'As mentioned in Section 7, the Authentication-Results header field is
    designed to communicate lists of tests a border MTA did and their
    results.  The specified elements of the field provide less
    information than the SPF-Received field:

    Authentication-Results: myhost.example.org; spf=pass
      smtp.mailfrom=example.net

    Received-SPF: pass (myhost.example.org: domain of
     [email-masked] designates 192.0.2.1 as permitted sender)
        receiver=mybox.example.org; client-ip=192.0.2.1;
        envelope-from="[email-masked]"; helo=foo.example.com;

    It is, however, possible to add CFWS in the "reason" part of an
    Authentication-Results header field and provide the equivalent
    information.  Receivers SHOULD include the same information they
    would have provided if they had used the Received-SPF field.

    The reason SHOULD include a key-value-list with keys provinding
    information normally included in a Received-SPF header field that is
    not already part of the Authentication-Results header field.  That
    is, at least "client-ip", "helo", and, if the "MAIL FROM" identity
    was checked, "envelope-from".  Authentication-Results header fields
    can contain results for more than one authentication, so one field
    can provide results for both an "MAIL FROM" check and an "HELO"
    check.

    reasonspec       = <reason per [RFC5451]>

    A suitably enhanced Authentication-Results header field might look
    like (for a "MAIL FROM" check in this example):

    Authentication-Results: myhost.example.org; spf=pass
      reason="client-ip=192.0.2.1; smtp.helo=foo.example.com"
      smtp.mailfrom=[email-masked]'

I consider the above as a significant change.  I am concerned that it 
may lead to the document updating RFC 5451.  That would be outside 
the scope of what this working group is chartered to do.

In a message at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg02275.html WG 
participants were given some leeway to work things out.  Please note 
that even though I have not seen any more arguments from Douglas Otis 
I will take the arguments which he submitted on April 25, 2012 into 
consideration ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html 
).  I will have a discussion next week with Andrew Sullivan to 
determine what to do if the different views cannot be reconciled.  My 
default will be no change.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 25 Aug 2012 15:35:31 -0700

On Sat, Aug 25, 2012 at 1:13 AM, S Moonesamy <[email-masked]> wrote:
> participants were given some leeway to work things out.  Please note that
> even though I have not seen any more arguments from Douglas Otis I will take
> the arguments which he submitted on April 25, 2012 into consideration (
> http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html ).  I will
> have a discussion next week with Andrew Sullivan to determine what to do if
> the different views cannot be reconciled.  My default will be no change.

I agree that there are substantive changes in this area since RFC4408,
and I'm aware at how increasingly allergic to change we are.  However,
our charter does explicitly permit us to accommodate the "addition of
any enhancements that have already gained widespread support".  I
don't believe anyone disputes the claim that RFC5451 is in substantial
use, including for SPF, so I submit that this is an appropriate topic.

I also think that what the -06 draft currently says goes beyond what's
necessary, at least in terms of its normative language if not in
general.  It should be sufficient to point out the two available
options for post-MTA communication, explain why we're documenting two
of them, and leave it there.

In the message you cited, you referenced a proposal I made that I
think needs more discussion.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2012 05:13:12 -0000

>of them, and leave it there.

Agreed.  The stuff about how to hide extra information in A-R comments
really doesn't belong in a standards track document.

If someone thinks that it would be a good idea if A-R headers included
more details about SPF results, do a separate draft to update RFC 5451.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Aug 2012 01:20:02 -0400

On Saturday, August 25, 2012 03:35:31 PM Murray S. Kucherawy wrote:
> > even though I have not seen any more arguments from Douglas Otis I will
> > take the arguments which he submitted on April 25, 2012 into
> > consideration (
> > http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html ).  I
> > will have a discussion next week with Andrew Sullivan to determine what
> > to do if the different views cannot be reconciled.  My default will be no
> > change.

Suggestions on changes please.

I considered addition of A-R to 4408bis appropriate under the terms of the 
widespread support aspect of the charter.  The question is how best to 
characterize it.

Received-SPF is a trace header that carries, in addition to SPF results 
additional information to assist readers in understanding what it's trying to 
communicate and reconstruct decision logic after the fact for diagnostic 
purposes.

A-R as is widely used today communicates less information as it is, by design, 
focused on communicating the results of multiple types of authentication 
without emphasis on additional detail or forensics.

In the current draft I tried to make a recommendation about how to provide the 
same information typically provided in Received-SPF in an A-R header field so 
that it would be suitable as a replacement because it seemed to me that the 
discussion had been about aiming towards transition and an eventual 
replacement.

Perhaps that was in error and it would be better to position A-R as 'no 
frills' results only used and Received-SPF as a more verbose vehicle in cases 
where it's desired.  This isn't really right either though since it's quite 
possible to add all the same information to A-R.

Thoughts?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 26 Aug 2012 01:53:50 -0400

> more details about SPF results, do a separate draft to update RFC 5451.

If you want A-R to be a replacement for SPF-Received than it need the extra 
information.  If extending 5451 is the right way to handle it, then I think we 
should just remove it from 4408bis and wait for 5451 bis.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 26 Aug 2012 03:00:49 -0400

> should just remove it from 4408bis and wait for 5451 bis.

I should note as the OP of this thread, that regardless if was 
correct, flexible or not,  my concern was 4408bis should present it as 
a migration, not just as an exclusive replacement since this is going 
to break existing 3rd party mail bots keying in on Received-SPF and is 
ignorant of A-R.

Unless its specifically designed for a specific local system only or 
vendor solution, I sincerely doubt any mail-bot developers is going to 
eliminate support for Received-SPF anything soon.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Sun, 26 Aug 2012 01:20:07 -0700

Hello,

This is a very rough summary of the Authentication-Results and 
Received-SPF: headers discussion.

Hector Santos mentioned presenting this as a migration, not just as 
an exclusive replacement [1].  John Levine suggested having more 
(Authentication-Results:) details about SPF results in a separate 
draft [2].  One of the arguments mentioned by Douglas Otis  is that 
it would never be in a users interest to adopt result formats aimed 
at disabling third-party competitors by omitting essential 
information [3].  Murray Kucherawy commented that it should be 
sufficient to point out the two available options for post-MTA 
communication, explain why we're documenting two of them, and leave 
it there [4].

As an individual comment, this working group had to determine a 
resolution to two experiment.  That happened because consensus did 
not clearly support one over the other.  The working group will be 
conducting a similar experiment if it is WG consensus to support both options.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02365.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg02357.html
3. http://www.ietf.org/mail-archive/web/spfbis/current/msg01466.html
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg02350.html

---

From: "John Levine" <[email-masked]>
Date: 26 Aug 2012 18:55:57 -0000

Remember that the point of a standard is to tell people how to write
their software so that it interoperates.  The suggestion to hide stuff
in the A-R header doesn't do that, since we're not updating 5451, and
as far as 5451 is concerned, these headers are equivalent:

   Authentication-Results: myhost.example.org; spf=pass
     reason="client-ip=192.0.2.1; smtp.helo=foo.example.com"
     smtp.mailfrom=[email-masked]

   Authentication-Results: myhost.example.org; spf=pass
     reason="your mail is boring"
     smtp.mailfrom=[email-masked]

I'd suggest chopping everything about A-R out of 7 and 7.2 other than
saying that you can use it, with a reference to 5451 and an example
that doesn't go beyond what 5451 defines.

Also keep in mind that whether A-R is an adequate substitute for
Received-SPF is a local policy issue.  If I don't happen to use the
info that A-R doesn't record, A-R is fine.

Once again, I'm not opposed to updating 5451 to record more
mechanically parsable info about SPF results, but there's a way to do
that, and this isn't it.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 26 Aug 2012 13:16:34 -0700

On Sun, Aug 26, 2012 at 11:55 AM, John Levine <[email-masked]> wrote:
> [...]

+1 to this entire message.

Received-SPF needs a full definition because this will become its
official definition, so we're good there.  (Which reminds me: IANA
Considerations needs to update the permanent header field registry to
say this document is the new formal definition of that field if it
doesn't already.)

A-R is defined elsewhere, and we only need to reference it and explain
that it's the "new" way to do things, and leave it to the receiver to
decide which one is appropriate for its own use.

If you'd like specific replacement text as a proposal, I'm happy to help.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Aug 2012 11:53:14 +0200

> decide which one is appropriate for its own use.

RFC 5451 is rather succinct in its explanation of the layout of SPF
results.  Comparing A-R to Received-SPF might not be obvious.  Is that
worth additional text, possibly in its own subsection?  Here's my try:

  7.3  Relationship between Received-SPF and Authentication-Results

  Per identity results are conveyed using one or two stanzas
  (resinfo) in one or two Authentication-Results header fields.
  There is no identity tag in those stanzas, as its value can be
  inferred by the presence of the smtp.mailfrom or smtp.helo tags,
  which imply the corresponding identities.  If the result is the
  same for both identities, one stanza is enough to convey both tags.

  In case both kinds of trace header fields are added at the same
  hop, they MUST be compatible, in the sense that the result for any
  given identity, and the value of helo/smtp.helo MUST NOT differ,
  and the value of envelope-from/smtp.mailfrom MUST either be equal
  or have an equal domain if the value of smtp.mailfrom consists of
  the domain portion only.  Fields can complement one another, though.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Aug 2012 06:42:10 -0700

>   the domain portion only.  Fields can complement one another, though.

Is the normative stuff necessary, or does that discussion belong in
Security Considerations?  What interoperability breaks if the MUSTard
you have there is removed?  Presumably consumers of this information
aren't looking for both fields.

Another important distinction is that RFC4408 contained no protections
against spoofed Received-SPF attacks, while RFC5451 did.

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 27 Aug 2012 16:57:12 +0200

> aren't looking for both fields.

The MUSTard serves just to convince consumers that they can look for
the field they prefer, no need to compare them.  Perhaps, without it,
someone can think that uncertain cases like, say, temperror vs
neutral, could be rendered by setting different results in those
fields, possibly assuming that each field correspond to some class of
consumers.

> against spoofed Received-SPF attacks, while RFC5451 did.

Right.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 27 Aug 2012 09:22:26 -0700

On Mon, Aug 27, 2012 at 7:57 AM, Alessandro Vesely <[email-masked]> wrote:
> the field they prefer, no need to compare them.

Is that an interoperability concern?

> Perhaps, without it,

The only case where I can imagine an ADMD using both of them would be
knowledge that there are agents inside that use one and agents inside
that use the other.  I can't imagine a single agent that uses both and
would be confounded by the existence of both fields with differing
information.  I think that renders the MUSTard unnecessary.

Instead, if you have different agents, some of which want Received-SPF
and some want Authentication-Results, then you essentially have two
disjoint communication channels from the verifying agent to those
internal agents.  What's the benefit of demanding that they include
the same message?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Aug 2012 10:51:28 +0200

> Is that an interoperability concern?

If it is, it's about the communication to downstream message
processors.  Is that the sense that Hector means when he says
MTA-to-MDA protocol?

>> Perhaps, without it, someone can think that uncertain cases like,
>> say, temperror vs neutral, could be rendered by setting different
>> results in those fields, possibly assuming that each field
>> correspond to some class of consumers.
> 
> that use the other.

Yes.

> I can't imagine a single agent that uses both and would be
> confounded by the existence of both fields with differing 
> information.

I don't want to imagine that.  However, if it becomes customary that
in certain cases those fields differ, agents that examine both in
order to detect such cases seem plausible.

> I think that renders the MUSTard unnecessary.

Hm...

> internal agents.  What's the benefit of demanding that they include

Cleanliness of mind.  If you have an undertone that you wish your
agent captures, you should extend the relevant field appropriately and
fill the new value when you find it.  If that's a clever idea, it may
get standardized, eventually.

Differentiating agent's behavior by target field will cause confusion
to agents beyond control, such as an IMAP client add-on.  Home brewed
code based on such kludges will be difficult to share and evolve.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 Aug 2012 06:52:02 -0700

> processors.  Is that the sense that Hector means when he says

I'm going by RFC5598 definitions.  I believe he means originator to
receiver, as different from relay-to-relay.  MDA is a delivery agent,
i.e., the thing that actually writes to inboxes.  I think it's false
to claim that the MDA is doing anything SPF-related at all, so if he
means that then I disagree.  SPF is therefore an out-of-band message
between the originating MTA and the receiving MTA, which is what I
mean when I say it's MTA-to-MTA.

What that means to me is that we should spend very little energy
talking about the communication between the receiver's MTA and agents
internal to the ADMD such as the MDA or MUA.  That's what Section 7 is
about.

> order to detect such cases seem plausible.

That presumes the consumers of these fields will notice that they
could get "better" information by looking at the other field and
adapt.  I don't think that's likely.

> get standardized, eventually.

That path seems highly unlikely to me.

> code based on such kludges will be difficult to share and evolve.

I'm happy to discourage home brewed code based on kludges.

-MSK

---

From: John Leslie <[email-masked]>
Date: Tue, 28 Aug 2012 10:35:18 -0400

Murray S. Kucherawy <[email-masked]> wrote:
>...
> SPF is therefore an out-of-band message between the originating MTA
> and the receiving MTA,

   Yes. (Can we say that clearly, please?)

> which is what I mean when I say it's MTA-to-MTA.

   Unfortunately, that's not what the average reader takes MTA-to-MTA
to mean.

> internal to the ADMD such as the MDA or MUA.  That's what Section 7 is

   Until we clearly define SPF to belong at the receiving MTA, reading
policy of the sender, it's hard to rule it out of scope...

--
John Leslie <[email-masked]>

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 28 Aug 2012 19:41:39 +0200

On Tue 28/Aug/2012 15:52:02 +0200 Murray S. Kucherawy wrote:
>>> [I]f you have different agents, some of which want
>>> Received-SPF and some want Authentication-Results, then you
>>> essentially have two disjoint communication channels from the
>>> verifying agent to those internal agents.  What's the benefit
>>> of demanding that they include the same message?
>>
>> Cleanliness of mind.  If you have an undertone that you wish
>> your agent captures, you should extend the relevant field
>> appropriately and fill the new value when you find it.  If that's
>> a clever idea, it may get standardized, eventually.
> 

Both Received-SPF and the spf's resinfo of Authentication-Results are
extensible.  However unlikely may be the need for additional info,
that's the right track for conveying it.

> I'm happy to discourage home brewed code based on kludges.

If you know of a sauce better than MUSTard to keep that on the right
track, I'd be happy with it.

---

From: Hector Santos <[email-masked]>
Date: Tue, 28 Aug 2012 13:46:38 -0400

An SMTP code can have multiple roles, MTA, MDA and MSA and not to go 
overboard and for the sake of simplicity a good way to see it is:

    MTA - generic transporter, router, sender/receiver, client/server,
          etc. In general and traditionally, little to no overhead and
          all "intelligent processing" was done post acceptance - Store
          and forward.

    MDA - receiver with no authorization requirement (no open relay)
          and only for local user or locally hosted domains.

    MSA - receiver with authorization requirement.

In older established systems, where the MTA did not have dynamic state 
machine processing, shims, hooks, i.e. ACLs, milters, WCX scripts for 
us, etc, the MDA was generally a gateway, mail importer/exporter, 
transformer, even uucp/slip processor, etc.  This is where the email 
to user account existence check was done and this is where the bounce 
was also created (hence accept+bounce problems).

But in modern systems, the MTA with user checking (delivery and user 
account checking), and state machine hook processing, it now behaves 
more like an MDA when there is no authentication for relaying.  If 
there was authentication established, the user/sender account was 
checked etc, then its mode is behaving more like an MSA.

Of course, there are still large scale systems that still keep these 
roles separated yet, increasingly to improve TCO, they are scaling up 
with lesser machines, more multi-cores machine and upgrading and 
updating the software so that a MTA can play more than one role.

With RFC5598, the one noted objection I had with it during the 
development  was its locked down on using SIEVE and at the time, and 
maybe still today, it only allowed for post SMTP processing.  It could 
not be used as a inline SMTP state machine scripting tool to make 
dynamic decisions on the fly and this is where reality does include 
such modes with all the different SMTP software. It didn't support DNS 
lookups for example, to do the sort of SPF and/or other dynamic SMTP 
online checking.

I believe RFC4408 has SPF as a SMTP level processor.  If the target is 
a remote address, then we have a relay authentication requirement and 
SPF is not required. This would be the behavior of a MSA or MTA with 
relay authentication established.  Hence, IMV, SPF is more of a MTA to 
MDA protocol because

      A) No authentication is required to deliver mail,
      b) No User Login is required,
      c) Only mail for local user or locally hosted domain is allowed.

Thats the behavior of a MDA.

--
HLS

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

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Wed, 29 Aug 2012 13:51:46 -0700

Hello,

Here are my individual comments.

This is a RFC 2119 recommendation in Section 7 of RFC 4408 for SMTP 
receivers to record the result of SPF processing in the message 
header.  There is a SHOULD in the second sentence of that 
paragraph.  The two normative sentence could have been folded into 
one sentence to tighten the specification.  The second paragraph 
mentions that the header field should be prepended but it must appear 
before all other Received-SPF fields in the message.  The Security 
Considerations section (see 10.5) does not provided a thorough 
analysis of the security issues [1].

The comment and key-value-pair is optional in the ABNF.  There is 
normative text which makes the comment a RFC 2119 
recommendation.  There is another RFC 2119 recommendation for
SPF clients to give enough information so that the SPF results can be verified.

I took a quick look to find out which header fields are generated:

Google:

Received-SPF: pass (example.net: domain of prvs=518e12a64=[email-masked]
   designates 165.155.105.213 as permitted sender) client-ip=165.155.105.213;
Authentication-Results: example.net; spf=pass (google.com: domain of
  prvs=518e12a85=[email-masked] designates 165.155.105.213 as permitted
  sender) smtp.mail=prvs=518e12a64=[email-masked]

Hotmail:

Authentication-Results: example.net; sender-id=none (sender IP is
  176.98.199.110) header.from=[email-masked]; dkim=none
  header.d=example.com; x-hmca=none

Yahoo:

Received-SPF: none (domain of example.com does not designate permitted sender
   hosts)
Authentication-Results:example.net  from=example.com; domainkeys=fail (bad
   syntax);  from=example.com; dkim=permerror (invalid domain)

MDaemon:

Authentication-Results: example.net spf=hardfail
  smtp.mail=[email-masked]; sender-id=hardfail
  header.from=[email-masked]; x-ip-ptr=pass
  dns.ptr=metamail.metapack.com (ip=193.129.71.18); x-ip-helo=pass
  smtp.helo=metamail.metapack.com (ip=193.129.71.18); x-ip-mail=hardfail
  smtp.mail=[email-masked]  (does not match
  193.129.71.18)
Received-SPF: fail (example.net: domain of 
[email-masked]
   does not designate 193.129.71.18 as permitted sender)

spfmilter and Exim add Received-SPF headers.

My reading of the above header fields is that they diverge from the 
specification.  There is a message about Issue #10 at 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00901.html 
I'll suggest a straw man proposal:

  (a) Add text to say that the result can be recorded in a
      Received-SPF: header field

  (b) Specify the Received-SPF: header field using the
      least common denominator (see examples above)

  (c) Add text as a security consideration pointing to RFC 5451

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg02386.html

---

From: Hector Santos <[email-masked]>
Date: Wed, 29 Aug 2012 22:46:29 -0400

1) 1st paragraph in section 7 should be consistent with 2.5.4 where 
there is a receiver rejection functionality describe in RFC2119 lingo 
and hence Recordings COULD NOT be possible as described in section 7.

2)  The text in 2.5.4 and the 2nd paragraph 7.0 describe A-R as a 
exclusive replacement without any insight on compatibility issues. 
IMV, it should provide semantics for using Received-SPF first, A-R 
second as an migration feature.  This of course will highly dependence 
on the implementation. It if uses in house canned software with no 3rd 
party support, then it has the luxury to use A-R only.   But if the 
implementation can be used for systems with 3rd party support, it 
should continued to offer Received-SPF

S Moonesamy wrote:
> receivers to record the result of SPF processing in the message header.  
> There is a SHOULD in the second sentence of that paragraph.  The two 
> normative sentence could have been folded into one sentence to tighten 
> the specification.

>  The second paragraph mentions that the header field 
> should be prepended but it must appear before all other Received-SPF 
> fields in the message.  The Security Considerations section (see 10.5) 
> does not provided a thorough analysis of the security issues [1].
> 
> normative text which makes the comment a RFC 2119 recommendation.  There 
> is another RFC 2119 recommendation for
> http://www.ietf.org/mail-archive/web/spfbis/current/msg00901.html I'll 
> suggest a straw man proposal:
> 

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 Aug 2012 00:16:42 -0400

> SPF clients to give enough information so that the SPF results can be

It's my recollection that msk had already volunteered to provide a proposed 
revision to this section, so I think further work on deciding it needs to be 
revised has limited utility.

> Received-SPF: pass (example.net: domain of
> prvs=518e12a64=[email-masked] designates 165.155.105.213 as
> permitted sender) client-ip=165.155.105.213; Authentication-Results:
> example.net; spf=pass (google.com: domain of
> prvs=518e12a85=[email-masked] designates 165.155.105.213 as
> permitted sender) smtp.mail=prvs=518e12a64=[email-masked]
> 
> Hotmail:
> 
> Received-SPF: none (domain of example.com does not designate permitted
> sender hosts)
 
This is great data.

>   (c) Add text as a security consideration pointing to RFC 5451

The decision to use Received-SPF or RFC 5451 A-R header fields has nothing to 
do with security, so I find this recommendation difficult to understand.  Please 
clarify.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Wed, 29 Aug 2012 22:45:29 -0700

Hi Scott,
>do with security, so I find this recommendation difficult to 

There are security considerations no matter which header field is 
used.  There are issues such as header positioning and forged header 
fields.  Murray Kucherawy pointed out that RFC4408 contained no 
protections against spoofed Received-SPF attacks.

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Thu, 30 Aug 2012 03:50:47 -0400

S Moonesamy wrote:
> There are security considerations no matter which header field is used.  
> There are issues such as header positioning and forged header fields.  
> Murray Kucherawy pointed out that RFC4408 contained no protections 
> against spoofed Received-SPF attacks.

Don't follow this claim security claim.

The only threat entry point I can see is some insertion between the 
MDA and MUA outside the ADMD network and thats pretty much means at 
the 3rd party MUA - offline, not online.

The Receiver-SPF header is for local network consumption where the 
trust is located.  It is not for offline MUA trust.   Its the same 
thing applies for A-R or another other similar header.  DKIM-Signature 
as well.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 06:35:14 -0700

On Wed, Aug 29, 2012 at 10:45 PM, S Moonesamy <[email-masked]> wrote:
> Murray Kucherawy pointed out that RFC4408 contained no protections against
> spoofed Received-SPF attacks.

Right, the Security Considerations of RFC5451 pretty much all apply to
Received-SPF as well.  It would probably be wise to indicate this at
least (i.e., refer to it and save ourselves repeating much of it).

I would add to SM's summary that sid-milter (now abandonware)
generated only Authentication-Results.

I still owe a proposal for new text for Section 7, but I've been
swamped with day job stuff.  Will try again to take a run at it today.

-MSK