Next-gen secure email using internet's own DNS – your help needed A group of researchers from the US government and dot-com operator VeriSign are working on a new system for secure email: using domain names. Highlighting the problems and security holes associated with current mail systems, the team from the National Institute of Standards and Technology (NIST), a subset of the US Department …
As far as getting around state actors hijacking whole top levels was going to inquire about using Namecoin but after minimal research and seeing they are basically unusable right now due a to severe security vulnerability that pretty much answers itself (plus being limited to one top level domain). Too mickey mouse to be useful.
Yes spam is a huge horrible beast.
However... its a crime I'm willing to live with. If this works well, you won't be able to send email without a certificate. I don't want "all your base are belong to us" Verisign to be in control of everything. I don't want the government to be be in control of all communication. If there's no end-to-end encryption, it isn't secure. There may be some benefit to having inter-ISP mail verified, but if ISP's aren't willing to annoy their customers they know to be infected (or spamming) then what chance is there for this? How will it improve things? It just looks like another attempt to set up a toll-gate for the internet.
I walk down the street, people could stop me and talk to me. Yes its usually annoying pollsters, but I'm not willing to swap that for a situation where people can't talk to each other without a government or corporate license.
But X.509 will save us all. Never mind those dodgy Turkish (even American) registers.
There are many things wrong with X.509, but the existing public X.509 PKI structure is not one of them. That is, the existing X.509 PKI structure is horribly broken, but it's not the fault of X.509.
X.509 is a disaster, but it's a disaster that it's possible to live with.
The existing PKI is a disaster that, in its current form, cannot be fixed.
Two separate sets of problems.
This won't kill spam anyway.
- Spammers can register valid throw-away domains
- Spammers can continue to use services like hotmail, gmail etc
Spammers understand E-mail very well. Throw in any technical hoops you like, they simply comply with the standards. (e.g. sending host needs to have matching forward and reverse DNS? Check). In fact the more hoops you put like this, the more likely you are to lose mail from people you want to communciate with, but who are less technically competent than the spammers.
The fundamental problem with E-mail (and paper/postal junk mail for that matter) is simply that we are happy to receive E-mails and letters from strangers.
> they [spammers] comply with the standards
Not my experience at all. The only incoming filtering I run on my SMTP box is greylisting -- basically blocking non-RFC-compliant senders -- and it works very well, with zero false positives.
Anything that can be done to increase the cost of sending spam is effective. Incidentally, I can't remember ever seeing spam that had matching forward and reverse DNS. Mostly they come from pwned home PCs with dynamic IPs.
-A.
This trash is in place already (in a broad sense) but when Hotmail insists people DKIM and SPF their mail, Hotmail themselves are 'too big' to bother doing it's own outgoing email. Probably processor overhead or sheer arrogance, take your pick, but either way until the big players practice what they preach none of these ideas will ever take off.
You have to remember, as far as their marketing dept. goes, a spam email is an email and they can then boast they handle x trillion emails a day, even though to the real world 99.9 % are spam.
DKIM and SPF along with correct DNS records would stop this if every company we so far as to actually implement this. We get lots calls from partners/customers complaining that our server blocks their email only to find they have setup SPF but never included one of their systems or users have started using an SMTP relay service as their ISP blocks it or even their IT provider wont help.
Then this new service still won't stop all of it. Today we had a fake email come in to finance from the CEO arranging a payment be setup and these guys went all out. They registered a domain the same as ours but swapped a "g" for a "q" and setup websites, email servers, DNS with A,MX,PTR and SPF records and even some HTTPS services with legitimate certificates. Even our CEO thought maybe he did send the email. It was only by an export to notepad we noticed the q replacing the g showing the extend these guys went to.
I am sure we would all be happy if everyone adopted correct DNS setup with MX, A, PTR and SPF records and set a hard fail on them thus confining spam to targeted attacks that cost money/time like the above.
i dont do the email for them nor run their website, so not my fault...ive been trying to get them to move to hosted exchange from the crap that theyre on for ages, but to no avail. anyway, last week heres what happened
an email was purportedly sent by "Jim" a director of the company to a minion "Brian" (except it was spoofed).
the email said "brian, its Jim, please tell adam in finance to pay this company with these bank account details just shy of £20k by the end of play today". brian then emails adam this, and adam pays the (fake) company.
they probably got the details of who was who from the website (they are now changing their website...). quite an elegant attack though.
weve figured out a way to stop this, and you probably already know this, and you probably dont like exhcange, but i'll tell you anyway just incase it helps someone. if they move to exchange, and set up spf correctly, there is an exchange setting "Blacklist email on SPF Neutral (for specific domains)". juts bung your own domain into the list.
then, as long as every single server you use to send email is in the spf record, noone can spoof you like this. obviously, things like fax's that email,their website's contact us form mailserver etc need to be included.
if anyone has a better suggestion let me know please.
This post has been deleted by its author
If their email system were correctly configured to check the source of all incoming email, such a spoof would never happen.
Yes, SPF does guard against this, but not if you're using a bulk email service which uses "primed IP ranges" with your domain where it is not easy to guarantee what IP range the bulk email provider are using. The provider will say that you can guard against this using SPF syntax, but I don't believe it protects against the situation where the spoofer uses the bulk provider themselves.
It would be better not to use the same domain for both important emails and bulk emails in the first place, but there may be reasons why this is not possible. It is my experience also that some cloud email providers use a variety of IP addresses to send out emails which totally defeats the ability to use "grey listing" techniques any more.
Problem with that is that if an email is forwarded (which it may be for totally legitimate reasons) then SPF will fail as the check is performed on the last IP before the receiving MTA.
That's why you pair SPF with DKIM, as that (properly configured) survives forwarding.
If you use them both as part of DMARC then you also get full reporting on whether or not you listed all your sending IP's correctly, or missed off the payroll server/that SaaS vendor you just brought on etc.
DMARC also gives you (not the ISP) control over what happens to email that looks like it came from you but fails authentication - you specify in the p=tag whether they should do nothing, send it to spam or reject it.
Have a look at DMARC.org for the details - it's free, it's effective, there's no need to use a CA.
This post has been deleted by its author
I think you must have confused Spamhaus with some other PBL. I have pleanty of reasons to complain about stupid and downright libellous blacklisting of my own (fixed) IP address, but unlike some others Spamhaus de-lists swiftly on simple application (provided that you are actually clean). I am philosophically against the very idea of IP-based blacklisting (the correct reaction to spam is to report it to the upstream provider), but if I had to recommend a list, it would be Spamhaus's.
-A.
(the correct reaction to spam is to report it to the upstream provider)
The fact that reports to abuse@mail.upstream.provider is ignored 90% of the time doesn't help with that. The remaining 10 % comprised such helpful responses as "forwarding the full message with headers is not enough, please send it as an attachment to that adress which rejects emails with attachments" doesn't help either.
This post has been deleted by its author
I started using a desktop mailserver after the ISP lost a contract proposal email that cost me a bloody fortune. So with my own, I'd know -more-or-less-instantly- whether the mail got through or the reason it didn't. Plus, ISPs at the time seemed a little too keen to make you use their server...if I feel herded, I usually bugger off in the opposite direction.
There were a couple of clashes with other RBLs; but my problems were primarily caused by Spamhaus. To the extent that I just gave up and got some hosting with a mailserver built in...so no culture shock when changing ISPs and I could still -with more effort than the desktop version- get my hands on mailserver logs if necessary.
They could have called it PEM, or PGP, or even S/MIME.
(And, seriously, S/MIME in the new proposal? S/MIME's outstanding feature is that it's so unappealing almost no one uses it.)
The problem with "secure" email isn't that we don't know how to do it; it's that most people can't be bothered.
Incidentally: I know quite a bit about X.509, but I'll be damned if I can make any sense out of this sentence from the article: "And they would have to only accept certificates using the X.509 protocol (something that is currently far from universal)." X.509 is not a "protocol", and it's pretty much the only way anyone represents digital certificates. I have no idea what the author's trying to say here.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
