We’ve been interested in the ability of Gmail to use POP3 to connect to a mailbox and pull messages over into the Gmail account. Configuration is quite simple and it seemed like a sensible option where a user might otherwise be forwarding mail that contained a lot of spam.
Whilst we flag spam we don’t tend to discard the lower level stuff, preferring to leave it down to our users to act on the headers we provide. That doesn’t work out so well if a user is forwarding all email to a Gmail account. Gmail see a lot of spam arriving and tend to rate limit the sending (us in this case) mail server. So an approach where the mail goes into a mailbox and Gmail collects it appealed as a possible workaround to forwarding.
During initial tests we noticed Gmail was flagging our test mails as having SPF failures. Upon some investigation it appears Gmail performs and SPF check on each mail it retrieves via POP3, SPF is really supposed to be at SMTP time, but Gmail doesn’t have that luxury when collecting mail in this fashion and perhaps doesn’t feel it can trust the headers the receiving mail server may have put in place.
The problem with this (technically incorrect) extra SPF check comes with SMTPAUTH. If an authenticated sender sends mail via our mail server to an inbox that Gmail is picking up from the recieved header line will (correctly) include the sender’s IP address (i.e. the IP of their local workstation’s Internet connection). Our mail server knows they are authenticated and so doesn’t fail an SPF check in this case. Gmail of course doesn’t know that so fails the SPF check - that workstation is not a designated sender it thinks (rightly so). That’s annoying.
Our solution? We’ve had to use a few tricks. Firstly we flag mailboxes that are going to be used by Gmail like this. We then have an additional router that runs where the sender’s domain is one we manage and the mailbox is flagged. If that’s the case the transport associated with this router looks for our SPF checks. If the message failed then we don’t do anything extra to it (actually we remove and add the received header, but the net result is nothing). If it didn’t fail the SPF checks (and that includes everything except an explicit fail) then we remove the received header and generate a new one purporting to be from our mail server. Gmail then sees this and passes it’s own SPF checks.
Bit complicated and round the houses, but seems to work. Not 100% foolproof. If a domain we manage doesn’t have SPF records then a spoofed (if you like) incoming mail wont’t fail the SPF check, but will have it’s received header rewritten. However chances are that will still fail at the Gmail end because of the lack of SPF records, so no huge worry. We maintain a copy of the original received header in the message to aid tracing, so no information is lost.