* * * * *
Unintended consequences
While in the process of solving a secure certificate issue with one of our
customers I ended up having to debug an email issue for the same customer
before continuing with the resolution of the primary issue (just have to love
those “one-step forward, two-steps backwards and a sidestep” issues).
Anyway, the email issue involves SPF (Sender Policy Framework) [1] and it's a
situation that frankly, never crossed my mind.
conman.org has an SPF (Sender Policy Framework) record that basically states:
“only hosts listed as MX (Mail eXchange) hosts for conman.org and IP
(Internet Protocol) addresses XXX.XXX.XXX.XXX through XXX.XXX.XXX.XXX are
allowed to send mail from conman.org and no others.” No problem there, until
email is forwareded!
I sent a test message from
[email protected] to root@XXXXXXXXXXXX, which is
then forwarded to an account (that all root@<the various servers at The
Company> get forwarded to) that ultimately ends up in my work mailbox. Now,
all email for The Company goes through a spam firewall, which, among other
things, checks for SPF. So, the mail message I sent went
[email protected] →
root@[customer] → rootmail@[The Company root catch-all account], but when it
hit the spam firewall at rootmail@[The Company root catch-all account] the
mail was still from
[email protected], but it was coming from the customer's
server, which isn't listed in my SPF record (see above), so it was blocked
from being delivered.
Lovely.
Draconian SPF records break in the face of email forwarding. Email forwarding
is a standard feature of email. SPF is pretty pointless without draconian
records (well, non-draconian records means one can mark an email as
suspicious but without support for such tagging why even bother?).
So why bother using SPF then?
Sigh.
[1]
http://www.openspf.org/
Email author at
[email protected]