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

From: Alessandro Vesely <[email-masked]>
Date: Tue, 03 Apr 2012 17:20:08 +0200

On 24/Mar/12 16:49, Alessandro Vesely wrote:
> 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.

I remembered wrong, it is Old-Received-SPF, not Original.  I found
this one-year-old post by the developer of Courier:

  The goal here is to certify that any "Received-SPF:" headers in the
  mail were inserted by this host, and not somewhere else. Multiple
  Received-SPF: headers are allowed. If any existing headers do not
  get renamed, it would not be possible to reliably determine which
  ones are authentic.
       http://sourceforge.net/mailarchive/message.php?msg_id=27291203

That solution is more effective than looking for the "receiver" tag
--the equivalent of authserv-id-- since it is not mandatory for
Received-SPF to have one.  That renaming only occurs if SPF checking
is locally enabled.  Still, problems exist with backup MXes.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Apr 2012 12:51:41 -0400

On Tuesday, April 03, 2012 05:20:08 PM Alessandro Vesely wrote:
> > To ease checking, IIRC.  I'm unable to find that discussion right now,
> > I'll confirm (or retract) this point next week.
> 

As far as I know, this approach is unique to Courier.  Spamassassin, for 
example, looks at the interleaved Received: headers and it's list of trusted 
hosts to determine which Received-SPF headers can be used.  

Adding Old-Received-SPF would be a new requirement and I don't think it has 
wide spread adoption.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 03 Apr 2012 19:27:51 +0200

> Adding Old-Received-SPF would be a new requirement and I don't think it has 

I would leave this field's spec as it is, except mentioning RFC 5451
and thus recommending that at least one of those fields be used, and
possibly that in case both are used they should/must agree at least on
the result and on the mandated key-value pairs.

However, if Murray finds out where in the experiment doc it is worth
to mention this renaming approach, I'd agree.  Received-SPF can be
considered a precursor of Authentication-Results, although I don't
know if any of its traits did actually influence any of RFC 5451's ideas.

---

From: Hector Santos <[email-masked]>
Date: Tue, 03 Apr 2012 20:49:38 -0400

> know if any of its traits did actually influence any of RFC 5451's ideas.

There has been this "elephant in the room" regarding DKIM.  I would 
like to set the record straight  my position on the matter, if not 
already stated before.

I believe in Murray's effort to integrate, consolidate the various 
related email augmented protocols and specifically, SPF and DKIM.  My 
only concerns is any mindset or efforts to replace SPF  and/or SIDF by 
watering it down with DKIM.  IMV, there causes conflicts, but I think 
there is a compromising solution when it is accepted and recognize SPF 
has a very fundamental strong deterministic hardfail policy for 
rejection that MUST NOT confused with domain intentions and doubt.

DKIM had a strong deterministic framework with SSP (nor ADSP) but it 
was watered down when the unfortunately injection provision was 
written in section 10 in RFC5016:

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

        INFORMATIVE NOTE: the main thrust of this requirement is that
        practices should only be published for that which the publisher
        has control, and should not meddle in what is ultimately the
        local policy of the receiver.

This is my main concern with the SPFBIS efforts - strong local 
receiver policy honoring of SPF hardfail domain policies can be at 
risk with the introduction of AUTH-RES and new similar relaxing 
semantics are rejected suggesting local SPF receivers should not 
"impugn" on the existence of DKIM information in the message.

IMV, Auth-Res is important because it provides a means to couple SPF 
and DKIM results for mail filtering "evaluators" however, SPFBIS MUST 
also recognize that a SPF domain hardfail violation may not be 
regarded using a Received-SPF or a AUTH-RES.

So IMO, Auth-Res should/could be introduced as a way to regard 
indeterminate SPF results to assist evaluators of the aggregated 
AUTH-RES results.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Apr 2012 21:59:58 -0400

On Tuesday, April 03, 2012 08:49:38 PM Hector Santos wrote:
> Alessandro Vesely wrote:
> >> Adding Old-Received-SPF would be a new requirement and I don't think
> >> it has wide spread adoption.
> > 

I think that (your last paragraph) is what's proposed.  I think use of auth-
res for SPFbis is just a natural evolution and unrelated to any larger 
architectural considerations.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 4 Apr 2012 03:55:23 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Tuesday, April 03, 2012 7:00 PM
> To: [email-masked]
> Subject: Re: [spfbis] #10: RFC 4408 replace Received-SPF with RFC5451
> 
> I think that (your last paragraph) is what's proposed.  I think use of
> auth- res for SPFbis is just a natural evolution and unrelated to any
> larger architectural considerations.

I think Scott's last sentence is also right.

(Or, to cite APPSAWG for those that were there, "Everything that was just said is true.")

-MSK