Subject: [spfbis] auth-results and spf

From: Brandon Long <[email-masked]>
Date: Tue, 9 Feb 2016 13:44:04 -0800

Not sure the best list to send this to... but anyone know why the IP isn't
a formal field in the spf method for the Authentication-Results header (RFC
7601)?

For "iprev", there is policy.iprev, but there isn't one for spf.  We put it
in the comment now, but it would seem like an obvious requirement for what
was evaluated.

Brandon

---

From: Franck Martin <[email-masked]>
Date: Tue, 9 Feb 2016 16:09:49 -0800

Well, for instance with DMARC we do not add again the SPF and DKIM
identifiers used to get the DMARC results. So I guess this is the same, you
have policy.iprev to indicate the connecting IP, this is what I use in
Authentication-Results.

If you were just doing the Received-SPF header, then it has client-ip,
because this header needs to be able to stand on its own.

So I feel there is no need to add a client ip key within the SPF construct
in the Authentication-Results header, just make sure to have policy.iprev
in this header.

Also in the SPF portion of the Authenticated-Results, I make sure to have
the value for the rfc5321.mailfrom and rfc5321.helo there, because the SPF
pass depends on one or the other if your SPF local policy is only based on
the RFC7208.MAILFROM. Technically, there are 2 SPF results, one for
RFC7208.HELO and one for RFC7208.MAILFROM. Your local policy decide on
which one will do what... Many people ignore RFC7208.HELO.

On Tue, Feb 9, 2016 at 1:44 PM, Brandon Long <[email-masked]> wrote:

> For "iprev", there is policy.iprev, but there isn't one for spf.  We put
> it in the comment now, but it would seem like an obvious requirement for
> what was evaluated.
>
> Brandon
>
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
>
>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 09 Feb 2016 20:27:31 -0500

>in the comment now, but it would seem like an obvious requirement for

If I recall correctly, this goes back to the original discussions on [email-masked] and what became RFC 5451.  You can check the list archive for details, but I believe it wasn't included on the theory that IP address is an input, not an output of the SPF check.

This was hotly debated at the time and this is how it came out.  It's one of the reasons that A-R isn't a complete replacement for Received-SPF.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2016 02:24:14 -0000

>If I recall correctly, this goes back to the original discussions on
>[email-masked] and what became RFC 5451.  You can check the list archive
>for details, but I believe it wasn't included on the theory that IP address is an input,
>not an output of the SPF check.

Also, you should be able to see the IP address in the Received: header
under the A-R header.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Feb 2016 20:37:50 -0800

On Tue, Feb 9, 2016 at 5:27 PM, Scott Kitterman <[email-masked]> wrote:

> [email-masked] and what became RFC 5451.  You can check
> the list archive for details, but I believe it wasn't included on the
> theory that IP address is an input, not an output of the SPF check.
>
> This was hotly debated at the time and this is how it came out.  It's one
> of the reasons that A-R isn't a complete replacement for Received-SPF.
>
>
Yeah, that was mostly it.  A-R was meant to provide (a) the outputs of
authentication methods, and (b) what thing was actually authenticated,
i.e., what part of the visible message you think is "safe" as a result.
For most methods I can think of, it's the domain name in the From: field or
the MAIL FROM parameter, so there was no need to report the IP address as
well; what would a typical user do with that?

Someone was pushing to add it so that SPF could be re-evaluated by the MUA,
but there wasn't much in the way of support for that (and, in fact, it
resulted in what is now Appendix C of RFC7601).

-MSK