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 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.