Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Mail Security | ||||||||
Line: 12 to 12 | ||||||||
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"). | ||||||||
Changed: | ||||||||
< < | We don't have a central mailserver, instead, everyone sends their emails using their ISPs own mailservers. | |||||||
> > | 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. | |||||||
Changed: | ||||||||
< < | We could try and list all the mailservers we use normally to the DNS entry, but that's potentially a huge and ever changing list. | |||||||
> > | 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. | |||||||
Changed: | ||||||||
< < | Or we could move over to using a central mailserver, which everyone would need to change over to using. Possibly we have access to such a central mailserver as part of our deal to have google handle our domain. | |||||||
> > | We also have to add zendesk and constantcontact. | |||||||
Changed: | ||||||||
< < | In the absence of everyone using such a central mailserver, the best we can do is to give a "neutral" response for all messages. That's what we do.
| |||||||
> > | 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.
| |||||||
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 |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > |
Mail SecurityPeriodically 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.SPFThe 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"). We don't have a central mailserver, instead, everyone sends their emails using their ISPs own mailservers. We could try and list all the mailservers we use normally to the DNS entry, but that's potentially a huge and ever changing list. Or we could move over to using a central mailserver, which everyone would need to change over to using. Possibly we have access to such a central mailserver as part of our deal to have google handle our domain. In the absence of everyone using such a central mailserver, the best we can do is to give a "neutral" response for all messages. That's what we do.
DKIMThe Domain Keys Identified Mail![]() 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. DMARCThe Domain-based Message Authentication, Reporting & Conformance![]() 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. UpshotThe upshot of all this to me is that:
![]() Comments |