Tuesday, March 21, 2006
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 and it's a situation that frankly, never crossed my mind.
conman.org
has an SPF record that basically states: “only hosts
listed as MX hosts for
conman.org
and IP
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 sean@conman.org
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
sean@conman.org
→ 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 sean@conman.org
, 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.