SoylentNews is people
SoylentNews
from the mail-only-accepted-from-ourselves dept.
On his blog, Peter N. M. Hansteen sometimes writes about the problems with getting certain mail service providers to up their game. This time his post provides the details on how a particularly large service not only fails at SMTP sender verification but also at many other tasks necessary for professional mail hosting.
Whenever I encounter incredibly stupid and functionally destructive configuration errors like this I tend to believe they're down to simple incompetence and not malice.
But this one has me wondering. If you essentially require incoming mail to include the contents of spf.outlook.com (currently no less than 81 subnets) as valid senders for the domain, you are essentially saying that only outlook.com customers are allowed to communicate.
If that restriction is a result of a deliberate choice rather than a simple configuration error, the problem moves out of the technical sphere and could conceivably become a legal matter, depending on what outlook.com have specified in their contracts that they are selling to their customers.
One takeaway is that spam-fighting decisions from decades past have left us with technologies that have led to the centralization of mail on fewer and fewer providers. As such it is increasingly difficult for even skilled professionals to operate their own mail hosting smoothly.
Source : A Life Lesson in Mishandling SMTP Sender Verification
(Score: 5, Informative) by TheRaven on Monday February 19 2018, @09:46AM (3 children)
You've been able to do that with S/MIME for ages. Here's the problem: Who signs the domain certificate? If you use the current list of a few hundred CAs, then it's wide open to abuse for a number of reasons. First, various CAs are not nearly as trustworthy as they are trusted. Second, now the domain cert that they sign for you is a signing cert and so you need to handle it very carefully - if that's compromised then anyone can sign email for any address in that domain. For large companies, insider threat is a big issue (think how valuable a big company's email cert signing cert would be to scammers if people actually checked and trusted S/MIME certs). If you don't use the existing CAs, now you need some centralised authority that will issue the signing certs, and that gives a single point of failure. Once DNSSEC is widely deployed (any decade now), it may be possible to use that to distribute the public key of the signing cert for a domain, but that doesn't really help with the requirement to maintain the security of the cert.
sudo mod me up
(Score: 2) by ledow on Monday February 19 2018, @02:20PM (2 children)
All your issues have been pretty well handled for everything from DKIM to code-signing itself.
Are you suggesting that they are even on the scale that I can send a million messages claiming to be from just about any domain I like and some of them will get through because of the myriad technical hurdles necessary to stop that happening at the moment.
The code-certs stored in, say, Exchange are pretty well locked down to the average user. You aren't going to be able to do that without having control of the Exchange server anyway. And to sign into the Exchange server you need valid AD credentials which limit you to what messages you can send anyway.
Are you suggesting that Exchange servers, and their ilk, are corporate liabilities from "insiders" too?
It's the mail server that needs the key. Security of an authentication to the mail server is another matter entirely. But at the moment, mailservers can claim to be "from" anyone, which they wouldn't be able to do if they don't have, say, "microsoft.com''s signing key.
S/MIME just piggybacks on existing SMTP... which is already broken in ways more than S/MIME can fix by layering over the top.
(Score: 2) by sjames on Monday February 19 2018, @03:04PM
So what's your proposal that doesn't just move the problem around without solving it or make the problem worse? Think carefully before replying, but please do reply.
(Score: 2) by TheRaven on Monday February 19 2018, @05:14PM
No they haven't. DKIM is purely server side. The server signs a key and publishes it in DNS so that no one will trust a key that doesn't come from that server. Assuming that you're using DNSSEC, this is pretty robust (if you aren't, then you have no chain of trust for the public key). The key is relatively easy to keep secure, because you need it on precisely one machine: the mail server (DKIM lets you have multiple keys, so you can have a per-server key if you use multiple MXs). These problems become a lot more complex if you need to use that key to sign a client cert for everyone in your organisation, because now you need everyone to submit a (potentially malicious file containing a) CSR, which you then sign.
Code signing is also different for two reasons. First, there is a single source of authority. If you sign a Windows device driver, Microsoft issues your signing cert. If you sign an iOS app, Apple issues the signing cert. There is not equivalent source of authority for email. Second, unless the org is run by idiots, the signing cert is not installed on dev machines and is kept on a separate machine that is solely used for distribution. Even then, some orgs have had their signing certs compromised.
The rest of your post is too incoherent for me to understand what you're proposing.
sudo mod me up