Subject: [spfbis] Received-SPF in the real world

From: Arthur Thisell <[email-masked]>
Date: Wed, 5 Sep 2012 04:00:29 -0700 (PDT)

Has anyone collected information on how Received-SPF is actually being used?  

Things like the mechanism production rule was most important back when SPF used to support unknown mechanisms.  I'm not sure I've ever seen it used in practice.  Could it just be removed as being unused?

Yahoo creates a Received-SPF header field that doesn't follow RFC 4408 at all and I can't make sense of it.  E.g.:

Received-SPF:   	 	 pass (domain of ietf.org designates 64.170.98.30 as permitted sender) 
    dCBhbGwgdGhlIGluZGl2aWR1YWwgbWVzc2FnZSBhdHRhY2htZW50cyB5b3Ug 
    d2lsbCBuZWVkIHRvIHVwZGF0ZSB5b3VyIGRpZ2VzdCBvcHRpb25zIGluIHlv 
    dXIgbGlzdCBzdWJzY3JpcHRpb24uIFRvIGRvIHNvLCBnbyB0byBodHRwczov  
    L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwZmJpcyBDbGljayB0 
    aGUgJ1Vuc3Vic2NyaWJlIG9yIGVkaXQgb3B0aW9ucycgYnV0dAEwAQEBAQN0 
    ZXh0L3BsYWluAwMxAgN0ZXh0L3BsYWluAwMxAgNtdWx0aXBhcnQvZGlnZXN0 
    AwM3AgNtZXNzYWdlL3JmYzgyMgMDMwIDbWVzc2FnZS9yZmM4MjIDAzQCA3Rl 
    eHQvcGxhaW4DAzE-

I'm not even sure how you could collect a good cross section of Received-SPF examples.  Looking at individual implementations might be a good start,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Sep 2012 06:51:10 -0700

> Has anyone collected information on how Received-SPF is actually being used?

I have the same question.  Does any production software actually
consume the things Received-SPF supports that Authentication-Results
does not?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Sep 2012 10:04:13 -0400

> consume the things Received-SPF supports that Authentication-Results

I don't think that's a question that can be answered.  I do believe that while 
A-R support for spamassassin is in it's development trunk, it has not been 
released yet spamassassin will either consume Received-SPF from trusted relays 
or do it's own SPF check based on information from the Received header field.

Scott K

---

From: Stuart D Gathman <[email-masked]>
Date: Wed, 05 Sep 2012 14:21:29 -0400

> consume the things Received-SPF supports that Authentication-Results
My python milter production software on a dozen MTAs consumes 
Received-SPF.  It is very important for a main MTA getting mail 
forwarded from an MX (the MX has to check SPF, of course).  All the 
fields are used, plus a few x-* fields I added (like x-bestguess). The 
mechanism field in particular is *very* useful in diagnostic messages 
for 5xx SMTP responses and DSNs - although that mainly comes up with 
PermError and Pass.  The mechanism is usually "-all" for Fail.

Ironically, ietf.org has provided an example of the utility of 
problem/mechanism.  Here are the results from the email quoted above:

Authentication-Results: mail.bmsi.com; iprev=pass policy.iprev=2001:1890:126c::1:1e (mail.ietf.org); spf=permerror (SPF Permanent Error: Invalid IP6 address: ip6:2001:1890:126c:::0/56) smtp.helo=mail.ietf.org smtp.mailfrom=[email-masked]; dkim=pass (Good signature.) header.d=ietf.org
Received-SPF: PermError (mail.bmsi.com: permanent error in processing domain of ietf.org: Invalid IP6 address) client-ip=2001:1890:126c::1:1e; envelope-from="[email-masked]"; helo=mail.ietf.org; receiver=mail.bmsi.com; problem="ip6:2001:1890:126c:::0/56"; x-helo-spf=pass; identity=mailfrom

ietf.org has published an invalid SPF record!  Too many colons in an IP6 
mechanism.

That said, I seem to recall authres providing for user defined fields 
also - so I plan on using those when transitioning.

BTW, speaking of diagnostics, what has come up many times is wishing 
that  mechanism provided a "stack trace" - i.e. what mechanism at each 
include level.  This can usually be resolved by rerunning the query 
manually with IP, MFROM, HELO however.

---

From: SM <[email-masked]>
Date: Wed, 05 Sep 2012 12:08:13 -0700

Hi Stuart,
At 11:21 05-09-2012, Stuart D Gathman wrote:
>ietf.org has published an invalid SPF record!  Too many colons in an 
>IP6 mechanism.

The problem was fixed a few minutes ago.

Regards,
-sm

---

From: "Wayne Doust" <[email-masked]>
Date: Thu, 6 Sep 2012 13:06:16 +1000

While not a standard commercial implementation, I use Received-SPF for
scoring purposes, particularly for whitelisted addresses by bypass SPF
blocking.

I imagine that this is most useful in second-line defence (eg: hold
SoftFails for later release).

Regards,

Wayne Doust

---

From: Hector Santos <[email-masked]>
Date: Thu, 06 Sep 2012 04:04:09 -0400

Received-SPF is meant to for local consumption only. It can not be 
trusted outside the internal processing.  IMO, keep in mind most 
people (end users) don't care about headers, only what the MUA 
displays and unless you request it (click a few things, if possible) 
you can't even see the headers.

That said, we have several server-side only (p-code) scripting rules 
that reads the Received-SPF, more importantly  we do not have 
information on 3rd party developers scripts, but we can't rule out 
their existence.  Generally, if one make a presumption that someone 
isn't used and then you pull it, that is generally when you find out 
otherwise.

-- 
HLS

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