Subject: Re: [spfbis] In support of retaining Received-SPF Header Field

From: Stuart Gathman <[email-masked]>
Date: Tue, 08 May 2012 12:38:09 -0400

Long ago, Nostradamus foresaw that on 04/25/2012 09:31 PM, Douglas Otis
would write:
> It would never be in a users interest to adopt result formats aimed at
> disabling third-party competitors by omitting essential information.
I think what Douglas is trying to say is that Authentication-Results has
less information than Received-SPF, and therefore Received-SPF should be
retained. 

+1  retain Received-SPF

I have implemented both headers in production over the past week, and
the information in A-R is only a brief summary of the information in
Received-SPF.  So there is little redundancy in having both in a
message.  The additional information in Received-SPF is very valuable
for the reasons Doug mentioned at length, and also for diagnosing
problems.  (This is for the existing RFC 5451.  I haven't checked the
proposed extensions.)  We should not deprecate Received-SPF until all
its information has been standardized in the A-R header. 

Here is a live example of both headers:

Received-SPF: Pass (mail.bmsi.com: domain of accion.netcommunity1.com
designates 205.139.105.170 as permitted sender)
client-ip=205.139.105.170;
envelope-from="[email-masked]";
helo=d2pdcsmmta02v0.blackbaud.com; receiver=mail.bmsi.com;
mechanism="ip4:205.139.104.0/22"; identity=mailfrom

Authentication-Results: mail.bmsi.com; iprev=pass
policy.iprev=205.139.105.170 (d2pdcsmmta02v0.blackbaud.com); spf=pass
(sender SPF authorized) smtp.helo=d2pdcsmmta02v0.blackbaud.com
smtp.mailfrom=[email-masked]

The missing field in this example is "mechanism" (including iprev method
makes up for missing client ip).
Additionally, HELO SPF result is often included in Received-SPF (and
x-bestguess result as an extension in my case).

---

From: Hector Santos <[email-masked]>
Date: Wed, 09 May 2012 23:35:34 -0400

+1

-- 
HLS