GMail fails SPF checks on POP3 fetched messages

Posted on 26 October 2014 by Pier Carlo Chiodi

It seems that, under certain conditions, GMail reports failed SPF checks for messages fetched via POP3 from other mail servers.

I noticed this behaviour on messages received, for example, by mail servers where an internal relay is used, like the following message sent from PayPal (which uses an hard-fail policy):

Delivered-To: MYSELF@gmail.com
...
Received-SPF: fail (google.com: domain of xxxyyyzzz@emea.e.paypal.com does not
        designate A.B.C.D as permitted sender) client-ip=A.B.C.D;
Received: by 10.64.225.172 with POP3 ...
X-Gmail-Fetch-Info: MYSELF@MYDOMAIN.TLD 3 pop3.MYDOMAIN.TLD
        995 MYSELF@MYDOMAIN.TLD
Return-Path: <xxxyyyzzz@emea.e.paypal.com>
Delivered-To: MYSELF@MYDOMAIN.TLD
Received: from server1.MYPROVIDER.TLD (A.B.C.D)
        by server2.MYPROVIDER.TLD with SMTP; ...
Received: from outbound.emea.e.paypal.com (96.47.30.179)
        by mx1.MYPROVIDER.TLD with SMTP; ...
Return-Path: <xxxyyyzzz@emea.e.paypal.com>
...
From: "PayPal" <paypal@e.paypal.it>
To: MYSELF@MYDOMAIN.TLD

This is the SPF record for emea.e.paypal.com:

;; QUESTION SECTION:
;emea.e.paypal.com.        IN   TXT
 
;; ANSWER SECTION:
emea.e.paypal.com.   3600  IN   TXT  "v=spf1 a:outbound.emea.e.paypal.com -all"

It authorizes every IP address resolved by the outbound.emea.e.paypal.com A record.

In the example, MyProvider receives the message from 96.47.30.179, which is one of the many IP addresses resolved by and authorized by outbound.emea.e.paypal.com:

;; QUESTION SECTION:
;outbound.emea.e.paypal.com.       IN   A
 
;; ANSWER SECTION:
outbound.emea.e.paypal.com.  300   IN	A   96.47.30.224
...
outbound.emea.e.paypal.com.  300   IN	A   96.47.30.179

After receiving the message, MyProvider uses an internal relay and adds a new header:

Received: from server1.MYPROVIDER.TLD (A.B.C.D)
        by server2.MYPROVIDER.TLD with SMTP; ...

Unfortunately, when GMail fetches the message from MyProvider, it runs the SPF check against the IP address of the last Received header (A.B.C.D), that is the IP address of MyProvider internal relay, and not the one authorized by PayPal for outbound email, resulting in a SPF fail.

Also when messages are not internally relayed by the receiving provider, so when they present only one Received header, GMail fails the SPF check with the error “best guess record for domain of transitioning postmaster@MYOTHERDOMAIN.TLD does not designate as permitted sender“.

From the Common receiver mistakes FAQ of OpenSPF.org…

SPF is designed to work at the border of your network…

… to accept or reject messages as soon as they try to enter, and not after processing, relaying or forwarding have been performed. Moreover it’s intended to be use for SMTP sessions, and not on POP3/fetch.

Email good reputation is hard to achieve; lots of efforts are spent on methods like SPF, DKIM, DMARC to help senders to reach users’ InBox folders and to increase users’ confidence about their content. Surely GMail folks had more than good intentions when they decided to use this policy but, IMHO, a wrong use of these techniques may lead to the opposite results of those intended.

Bio
Latest Posts

Pier Carlo Chiodi

Italian, born in 1980, I started working in the IT/telecommunications industry in the late '90s; I'm now a system and network engineer with a deep knowledge of the global Internet and its core architectures, and a strong focus on network automation.

Latest posts by Pier Carlo Chiodi (see all)

Good MANRS for IXPs route servers made easier - 11 December 2020
Route server feature-rich and automatic configuration - 13 February 2017
Large BGP Communities playground - 15 September 2016

Pierky's Blog

mostly a system and network engineer's repository