Mail Security

Periodically we get "security researchers" telling us that our mail setup is prone to spoofing.

They suggest that we deploy some of the more modern technologies to minimise this issue, specifically SPF, DKIM and DMARC.

As far as I can work out, none of these can actually help with the way we work. I've attempted to dump my understanding of what the different technologies do here, and would encourage anyone who believes that I am wrong to contact me at robin.watts@artifex.com with suggested updates.

SPF

The Sender Policy Framework header allows a domain owner (i.e. us) to give a simple set of rules that define whether a given email was sent from a genuine sender (things like "it was sent from a particular server"), and what to do if it doesn't match the rules ("bad", "neutral", "good").

Historically, while most people have sent their emails via a central mailserver (smtp.gmail.com), some people don't, and instead use their ISPs own mailservers.

A quick poll suggests that most people can move over to the central mailserver. The exception to this appears to be one engineer who uses an old enough mail client that it can't talk to smtp.gmail.com. Accordingly, we've added his ISP's mailserver to the list.

We also have to add zendesk and constantcontact.

Until I'm sure that everyone is using a named mailserver, the best we can do is to give a "neutral" response for all messages. That's what we do.

v=spf1 include:_spf-internal.plus.net include:_spf-internal2.plus.net include:spf.constantcontact.com include:mail.zendesk.com include:_spf.google.com ?all
Various "security researchers" that have reported problems here have complained that we don't have an SPF rule at all (we do), and that the one we do have doesn't pass validation (it does). It's not a strong enough rule to prevent spoofing, but it's a valid rule. If any researcher can tell me a stronger rule to use that doesn't break our usage, I'll be pleasantly surprised.

DKIM

The Domain Keys Identified Mail system is a cryptographically based system whereby messages are signed. As I understand it, it basically provides a way for systems to know that nothing has altered an email since it was sent from the original mailserver.

My limited understanding of this suggests that it's something that is done at the mailserver level. As such either we'd need to share a cryptographic key around EVERY one of the mailservers that we use, or again, we'd need to move to a single mailserver.

DMARC

The Domain-based Message Authentication, Reporting & Conformance system, as far as I can see, allows for rules that say "Use SPF and/or DKIM. Filter n% of messages. If they fail, quarantine/bin/send them anyway. Send failure reports to whoever@whereever.com."

i.e. it's a way for domain owners to actually get feedback about which emails are being rejected, rather than a new way to validate them.

Upshot

The upshot of all this to me is that:

  • SPF is useless to us unless we can either a) move everyone to using a central email server, or b) list all the mailservers we use in the record.
  • DKIM is useless to us unless we move everyone to using a central email server. If we do move everyone to using a central email server, it's not clear to me what we actually gain for it.
  • DMARC is useless unless we want to monitor how either of the other two are working out.
-- Robin Watts - 2020-09-04

Comments


Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2020-09-21 - RobinWatts
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 2014 Artifex Software Inc