Google, Microsoft, Yahoo Join Forces To Create New Encrypted Email Protocol 123
An anonymous reader writes: A group of independent security researchers and major Silicon Valley tech giants have submitted a proposal for a new email protocol called SMTP STS (Strict Transport Security). In theory, this new extension looks like the HSTS (HTTP Strict Transport Security) extension to HTTPS. Much like HSTS, SMTP STS brings message confidentiality and server authenticity to the process of starting an encrypted email communications channel. HSTS works alongside HTTPS to avoid SSL/TLS downgrades and MitM attacks. to avoid SSL/TLS downgrades and MitM attacks. The biggest names on the contributors list include Microsoft, Google, Yahoo, LinkedIn, and Comcast. Last year, Oracle also submitted a similar proposal called DEEP (Deployable Enhanced Email Privacy).
Storage (Score:2, Insightful)
If the messages are not stored encrypted, what's the point? Private email sitting on Google/Yahoo servers is a much larger attack surface than email in transit.
Re:Storage (Score:5, Insightful)
The storage of content and transmission of content are separate concerns. A standard protocol to cover transmission of messages should not be concerned with the storage of it.
Re: Storage (Score:5, Insightful)
Encryption of messages is not prevented by this technology, it's two completely different uses.
- SMTP STS is used for validating the server channel to prevent spoofed servers. It doesn't care about the message content.
- Encrypted messages already exists and encrypts the message body, but that will require that both sender and receiver have exchanged some information. However these messages don't care about the channel used.
For best result you need both.
But I also see problems here:
- the SMTP STS requires certificates provided by a Certificate Authority (CA), and lately it has been revealed that not every CA is especially good at handling this.
- It will also require a good implementation of revocation of certificates.
- The management of the certificates may be costly, both the certificate and the management of it.
Overall it will drive cost, and that may be what kills this idea.
Re: (Score:3)
Re: Storage (Score:4, Insightful)
The transport doesn't support *any* concept of storage. It doesn't have to, that's why it's called transport.
Now you could say you should be using S/MIME or similar as it's more comprehensive end-to-end and secure transport is inadequate, but this is strictly a transport standard.
It's also a standard that can do something to mitigate risk to those who do not avail themselves of S/MIME.
Re: Storage (Score:4, Insightful)
That's the thing.. it's a solved problem,, has been a solved problem for over a decade. If only the big cloud players (MS, Google, Yahoo) got off their behiends and implemented encrypted e-mail that's relatively easy for people to use, that would be a *great* step in the problems being addressed here. Instead, they have to start re-inventing the whole transport protocol, while leaving the goldmine of data storage in the same sad 1980's shape.
Re: (Score:3)
Exactly.
Also, more to the point, I think this is more about *authentication* than it is about encryption.
But since strong encryption requires authentication for proper implementation, you get 2 birds for the price of one.
Re: (Score:1)
Well in any case, I certainly don't trust Google, Microsoft and Yahoo to handle security and privacy.
Re:Storage (Score:5, Insightful)
Yeah, I was going to say: If Google actually did do their job correctly they wouldn't be able to monetize GMail.
Data Links should not be vulnerable. (Score:1)
http://www.slate.com/blogs/fut... [slate.com]
http://arstechnica.com/tech-po... [arstechnica.com]
Re: (Score:2)
The problem with storing messages encrypted with a key that only you know is either:
* Every time you read a message, you have to enter the key. This makes reading mail painful on a desktop and almost useless on mobile.
* Or, a long-term key is stored so you can read the messages, in which case anyone who grabs any of your devices (either physically or with malware) can now decrypt all of your messages. This is still slightly safer than what we have now, but would not slow down government agencies or crimin
Re: (Score:3)
Not really, Google servers are very secure. Unless you are a major government, there is probably nothing you can do there.
In transit, there are many vulnerable intermediates : WiFi and Ethernet can be sniffed, routers and DNS can be hijacked, ISPs can be compromised, etc...
Re: Storage (Score:2)
This is important... (Score:4, Interesting)
Re: (Score:3)
I haven't changed my gmail password in 10 years. I have turned on two factor authentication.
Re: (Score:2)
[...] a horrible shame if the address you use to suck up SPAM / Business Marketing Materials [...]
I don't get spam on this account.
"Transport" != "end-to-end" (Score:5, Informative)
Re: (Score:3, Funny)
Re:"Transport" != "end-to-end" (Score:5, Informative)
This. We need one-click client-side e-mail encryption, usable by everyone. Like PGP but without the key management complications and the scary mojibake added to the e-mail body.
Re: (Score:3)
Like in Thunderbird: "Encrypt this message" when you compose it.
You need to have a mail certificate, but that's no big deal except that you will have to pay for it.
Re: (Score:2)
but that's no big deal except that you will have to pay for it.
lulwat?
Re: (Score:2)
Well, like $15 to $20 for a year or so... Depending on which CA you use.
Re: (Score:2)
Symantec Encryption Desktop is pretty close. You can hit a key, type your key's passphrase, have the mail decrypted in the window. Kpgp is similar on Linux, although you do have to cut and paste with it. I can't see how it can get easier than that.
Re: (Score:3)
You're right, but the problem is that the "key management complications" are very hard to get rid of.
The problem with end-to-end encryption is that normal people can't be trusted to manage encryption keys. But then there are only two options: either you manage the keys, or someone else manages them for you. If someone else manages them for you, then whoever is managing the key also has access to your email. If your email provider is managing your keys for you, then your end-to-end encryption scheme is n
Re: (Score:3)
If you don't have key management complications you have certificate trust complications.
You could do public key directories (is there still a PGP directory?), but then you have trust questions about keys retrieved from a directory, which leads you back to key management issues.
Re: (Score:2)
I agree, but this is still really worth doing. It's a reaction to government and ISP surveillance. It prevents data collection on backbones and via router taps.
Re: (Score:2)
...but this is still really worth doing...
Agreed.
Finally (Score:4, Interesting)
Don't blame email! (Score:5, Insightful)
I get really tired of this, because it's completely backward and wrong. Email is fine, and it does exactly what it was intended to do. Route messages from source to destination. People like you want email to be something different, but always arbitrary because there is no solution which works to encrypt out of the box which can not be tampered with. You want secure, that's fine but don't make an insecure protocol for mail routing the answer.
Use email for email. Attach encrypted files using what ever format you want, and you have control of the encryption. Stop demanding that generic "email" does it all for you, because if you trust any of the companies listed in TFA to give you bullet proof security, you are a tool.
Re:Don't blame email! (Score:5, Interesting)
The current e-mail protocols were designed at a time when everybody on the internet was expected to play nice. It could use an upgrade for today's significantly more hostile environment. There's really no reason we shouldn't have an upgraded protocol with more security and better authentication built in.
Nothing against the brilliant minds that created some of these early protocols, but they simply couldn't foresee some of the modern security and privacy issues the current internet has to deal with. We've also learned a thing or two about encryption and secure protocols in the last few decades, and upgraded protocols accordingly, right? I think it's a good time to try to introduce an upgraded e-mail standard. Whether it takes hold or not is a question, but with some of the big names apparently behind it, I don't see why not.
BTW, if you're going to reject out of hand a proposal for a new standard because of the names of the companies involved, then you're not thinking things through clearly. This would be an open standard, meaning it's possible for security specialists to vet and declare the protocol safe and secure, just like we do with TLS and other modern protocols. It seems like it would be rather tricky to hide secret backdoors in an open standard.
Re: (Score:2, Interesting)
Analogy time, sorry I could not think up a car analogy..
The current public transit systems were designed at a time when everyone on the system was expected to play nice. All over the world these systems are now dangerous, so must need to be redesigned. You left your wallet sitting on the shelf and someone stole it, it must be the system's fault. You were nekked and someone took photo's of you, must be the system's fault. They blackmailed you with the photo's, has to be the system's fault too. You were
Re:Don't blame email! (Score:4)
By your argument, we shouldn't be using our current e-mail protocols for anything requiring security of any sort, and I absolutely agree, but that's not the reality of the world we live in. Everyone has need of a secure messaging protocol on occasion, not just commercial institutions. What happens when you reset your password to nearly any web site that requires a secure login? Yep, you get sent a reset code or link by e-mail, right in the clear, which is used to authenticate that you're the owner of that account. What open, universal, secure messaging alternative do we have for this sort of thing? There's clearly a need for it.
If we now understand how to do a better job of securing e-mail and why doing so is a good thing, is there a reason not to? I'm afraid I just don't really understand your apparent opposition to a more secure e-mail protocol. Did you fervently oppose HTTPS as well, accusing people of "blaming HTTP" for trying to do things with it that it was never designed to do? This seems rather analogous to me.
Re: (Score:2)
Facts and logic, use them! If my argument is wrong demonstrate where I am wrong and provide a better argument. I don't care about feelings, I care about facts and logic (which often run counter feelings). The world you claim to be frightening is the same world that existed when SMTP was first established. The only difference is that people like you demand that security for you is more important than freedom for everyone else.
You don't like SMTP don't use it! Go make your own protocol and have a great t
Re:Don't blame email! (Score:5, Insightful)
You don't like SMTP don't use it! Go make your own protocol
/facepalm. That's what we're discussing here.
Re: (Score:2)
Facts and logic, use them! If my argument is wrong demonstrate where I am wrong and provide a better argument. I don't care about feelings, I care about facts and logic (which often run counter feelings). The world you claim to be frightening is the same world that existed when SMTP was first established. The only difference is that people like you demand that security for you is more important than freedom for everyone else.
You don't like SMTP don't use it! Go make your own protocol and have a great time sitting by yourself on your internet island!
Responding to the bolded part.
Right. Are you seriously claiming that the internet of 1982 is the same as today, and that the threat model is the same?
Facts and logic, indeed.
Re: (Score:2)
I think the snail mail analogy is by far more appropriate. So for snail mail a simple envelope, nothing more secures it because there are real penalties for interfering with it https://www.law.cornell.edu/us... [cornell.edu]. So for electronic mail, simply enact the same laws and provide a simply concretion envelope. The mail identities it source and it's intended recipient and if you get it by mistake simply forward it on to authorities for redirection or inform the sender and delete it. Open it when you are not the in
Re: (Score:3)
Same thing would apply for HTTPS, wouldn't it?
"HTTP is fine, and it does exactly what it was intended to do. People like you want web servers to be something different, but always arbitrary because there is no solution which works to encrypt out of the box which can not be tampered with. You want secure, that's fine but don't make an insecure protocol for web serving the answer. Stop demanding that generic "web browsing" does it all for you, because if you trust any of the companies listed in TFA to give y
Wrong (Score:2)
Re: (Score:2)
Read again. You were talking about an encrypted SMTP protocol, my comparison was HTTPS (i.e. an encrypted HTTP protocol). Since my point flew over your head, let me state it directly:
Encrypted versions of protocols are a good thing. This is evidenced by HTTPS. It's not perfect, but without it the web may never have had a chance to become as useful as it is. It would have been a burden on users. Without a standard, different encryption schemes may all need to be supported, users may need to manage cert
Re: (Score:1)
Re: (Score:2)
An encrypted email protocol is what this entire conversation is about.
Re: (Score:2)
Use one of the thousands of encryption system and encrypt your email. Cripes this has been possible for well over 2 decades now.
Re: (Score:3)
How do you send email to random people encrypted?
Your solutions work for internal email, but not external. The idea is to make all email secure.
PGP, since 1991. key servers. If people cared (Score:5, Informative)
> How do you send email to random people encrypted?
> Your solutions work for internal email, but not external.
This problem was solved in 1991, in terms of the technical implementation and protocol. The "problem" is that few people care about receiving encrypted email, so they don't publish a key to use for sending them email. Maybe if email clients made it super-easy more people would do it.
Here's a brief description of how PGP/GPG works. Wherever I publish my email address, I also publish my public key, which I generated. To send me an email, you can either use my address and my public key, or you can let your email client retrieve the key for you, from a key server. Since the email is encrypted with my public key, it can only be decrypted by my private key.
Personally, I publish my public key on the "Contact Us" page of my web site and on the public key servers.
The protocol works fine. The problems are that email clients don't make it super-easy for you to generate and publish a key, or to send PGP email using the recipient's key. That's a UI problem, not a protocol problem.
Re: (Score:2)
Personally, I publish my public key on the "Contact Us" page of my web site and on the public key servers.
Sounds good. For extra safety, I'll also publish "your" private key on the public keyservers. Should be fine, I'm sure everyone will check your web site before sending email to you.
I love PGP, and for 15+ years every email I sent was PGP-signed. But I doubt if a single person ever checked the signatures. PGP's key management is useless; the web-of-trust doesn't scale and is easily compromised. CAs can also be compromised but are at least scalable,
Re: (Score:2)
Re: (Score:3)
What I'm saying is "PGP is not useful for the masses because PGP's key management is useless".
If you look on the public keyservers and you see three keys for an address, you have no way of knowing which (if any) belong to the person without lots of research and guessing. People forget their passwords for online accounts all the time; if all email were encrypted, then forgetting the password for your key means you lose all past email forever and don't have a good path to say "stop using that old key, use th
MITM means that pki encryption depends on signatur (Score:2)
Encryption with public keys basically requires signatures as a precondition. Without validation, you could be encrypting the message with the bad guy's key.
Re: (Score:3, Insightful)
This problem was solved in 1991, in terms of the technical implementation and protocol.
You are confusing the technical solution with the practical end-user solution.
The "problem" is that few people care about receiving encrypted email, so they don't publish a key to use for sending them email. Maybe if email clients made it super-easy more people would do it.
That will never, EVER happen. If people have to "publish" a key manually, then you can just forget it.
Personally, I publish my public key on the "Contact Us" page of my web site and on the public key servers.
See above. You completely and totally miss the point. If I have to track down a web site, or Google+ page, or Facebook page, and manually copy or use a key from there, you might as well toss the whole idea in the bin.
If it isn't automatic, then it doesn't exist for 95%+ of computer users.
Not wrong, but you have to find the email address (Score:2)
> You completely and totally miss the point. If I have to track down a web site, or Google+ page, or Facebook page, and manually copy or use a key from there, you might as well toss the whole idea in the bin.
I said that, twice. Twice I said if mail clients don't basically do it automatically, people won't do it manually. So I'm not sure how you can say I miss that point.
What I find interesting about that is that everyone WILL find and Sally's email address, sally.krendircksoen9283@hotmail.com. Yet almos
Re: (Score:2)
I said that, twice. Twice I said if mail clients don't basically do it automatically, people won't do it manually. So I'm not sure how you can say I miss that point.
Well, then I must have misread you. I apologize.
What I find interesting about that is that everyone WILL find and Sally's email address, sally.krendircksoen9283@hotmail.com. Yet almost -nobody-, not even the most privacy preaching, Rand Paul voting Slashtotters, will click on the key link right next to the email address.
That is what I said, so clearly I was completely misreading your post.
Sorry about that.
Ps an example UI solution is keys via DNSSEC (Score:2)
The way I see it, it's much like IP protocol and specifically IP addresses- the protocol, the technology, works well, but IP addresses needed a user-friendly layer on top. Enter DNS. You can google.com and your client software automatically looks up the matching IP and uses it. There's a standard to do the exact same thing with PGP keys.
PGP keys can be served via DNS, so when you email support@clonebox.net it automatically looks up my key and encrypts your email. Just as you, the human user, never see th
Re: (Score:2)
That sounds like a perfectly reasonable solution. But to do it will require that all the major companies do it. It has to be built into Chrome, Edge, Safari, etc.
It also has to be built into Yahoo Mail, GMail, Outlook Mail, etc.
But yes, I support that solution.
Re: (Score:2)
How do you send a web page to random visitors encrypted?
A: You don't.
B: You both use software utilizing an agreed-upon (and shitty) cert system that automates key exchange.
C: You transmit keys securely (NOT ON THE INTERNET) before hand (for random visitors, see option A).
Re: (Score:3)
You seem to not understand encryption.
Freely publish a public key. Step 2; there is no step 2 as anyone can now send me encrypted mail that I can decrypt using my private key.
Re: (Score:2)
Freely publish a public key. Step 2; there is no step 2 as anyone can now send me encrypted mail that I can decrypt using my private key.
I know (and love) several people who do tinfoil hat shit like carrying their cell phones turned off in foil bags or refusing to even own a cell phone.
I've tried everything possible to get them to use PGP, including installing the once-free-to-use version that integrated well with Outlook Express on their computers. One's a PhD in history, the other has a BS in mechanical engineering, so neither is stupid and one is very technically adept but neither one can put the effort into actually using PGP.
And they
Re: (Score:2)
No, you seem to not understand. You have described option B. PGP and the like are broken because of the concept of trust.
You can't just publish a public key and call it done. Someone wishing to send you something needs to know that the key does, in fact, belong to you. PGP dreams of a a web of trust. It hasn't happened, and likely never will, as we've seen the "trust"model fail spectacularly in every implementation.
Even if you trust the algorithms used in your public-key crypto (a terrible decision, in
Re: (Score:2)
You seem to not understand encryption.
I understand it perfectly well.
Freely publish a public key.
How do I know what you "publish" is really from *you*?
How do I know what is posted on some web site is not injected with man-in-the-middle attacks replacing the key with someone else's?
And where do I find such a "freely published key?" Random poking around?
Step 2; there is no step 2 as anyone can now send me encrypted mail that I can decrypt using my private key.
As Apple has so clearly shown, if it isn't default and automatic, people won't use it. Apple now sets all phones to be encrypted by default. Without that option, people wouldn't use it.
Unless the key exchange is completel
Re: (Score:2)
You don't because you can't. Public key Encryption requires the exchange of encryption keys, the only other kind of crypto is the kind that requires that a secure encryption key be swapped. Neither method is conducive to blindly sending email to a random person.
To do what you want you need a closed system with strict exchange profiles, a large keyring that's replicated to every device and you absolutely can't let any Jack and Jill run servers. It needs to be highly centralized to work. In every regard this
Re: (Score:3)
Maybe people will finally be able to email secure information easily.
Which has nothing to do with SMTP STS.
SMTP STS does not provide message integrity, privacy from any SMTP servers along the path, data security, nor authentication.
That said, SMTP STS seems like it's a good addition to the existing transport security.
The post title is, IMO, misleading. This isn't really a new email protocol, it's an extension to the existing protocol. Your email is not encrypted; your traffic is encrypted, and potentially only for part of its transit. While it is attempting to provide some l
It's about time (Score:2)
Re:It's about time (Score:4, Insightful)
GPG and/or S/MIME would address your concern, but this proposal would not.
This is basically using TLS more properly in SMTP, which in and of itself is good, but far from adequate.
Here is the tricky thing about TLS: it works well in theory for user-service interactions (e.g. I care I'm talking to 'onlinebanking.bigbank.com'), but not as well for messaging (I'm not conversing with a server, whose identity is hidden away in the headers, I'm conversing with whatever is in the 'From/To/CC/BCC' fields, and those are the folks I care about authenticating)
Will it come complete with... (Score:2, Insightful)
Solved problem? (Score:2)
What does this give over the existing protocols, other than using TLS? It looks like once the E-mail is received by the client side, it is stored decrypted, so it only solved a part of the problem.
What is so wrong with getting people to use a standard like S/MIME or OpenPGP, which truly secure messages, regardless if it is in-flight, sitting on a hard disk, or sitting on a spool file on a relay? The advantage of OpenPGP is that it functions independently of the messaging protocol, so security is assured,
Re:Solved problem? (Score:4, Insightful)
It could be considered a protocol to negotiate use of TLS more securely.
S/MIME and OpenPGP would be more thorough solution to the problem.
Re: (Score:2)
If it does this, this is useful. I know with Exchange, I ended up setting up TLS connectors manually between sites that were in constant communication with each other. This way, anything going from foo.com to bar.com and back would be encrypted. Having this new standard will make life easier, because making connectors between sites would not be as important.
I just wish someone can address endpoint encryption. TLS has been constantly updated, while S/MIME and OpenPGP are pretty much untouched since their
Re: (Score:2)
It also requires peer key exchange, which introduces burden. With burden comes 'simplified' services that do the key exchange for you, then you get back to where we are now (or at least if a shared conduit exists). There are only a very limited number of people who are willing to go to such lengths to guarantee secrecy (from everyone). You -could- use publicly signed key exchanges like Verisign, but but cost would generally kill mass adoption.
This isn't a new problem and you can always read more about it in
Re: (Score:2)
What does this give over the existing protocols, other than using TLS?
SMTP has a problem where the optional "I want a TLS connection" bit can be stripped out. Some ISP's (name Verizon) are known to do this. So if a non-SMTP protocol is used in the first place, the ISP can't strip out the optional bits.
What is so wrong with getting people to use a standard like S/MIME
From earlier Slashdot posts I remember people sharing experiences of having their entire team using S/MIME, but then when Android came out, it didn't support S/MIME, so everyone turned it off and nobody noticed. The idea behind S/MIME is that if I receive an email from castionso
Re: (Score:2)
The idea behind S/MIME is that if I receive an email from castionsosa and it has a little badge next to it, I can be assured that it's from castionsosa, and if the badge isn't there I'm supposed to be suspicious. Guess what, no humans notice when the badge isn't there; so S/MIME isn't solving the problem it was meant to solve.
That's not entirely accurate.
What an S/MIME signature is supposed to solve is to provide evidence that:
a) the message was from that sender (or someone with his private key), assuming you trust the cert CA and his public cert didn't just change
b) the message has not been altered in transit
If someone along the path the email travels (for example, the spam filter or virus filter) modifies the message (ex. strips out the attachment or adds a "sent via iSomething" phrase at the end, or maliciously alters the mes
Re: (Score:2)
The point is that this will identify the sending server, and that may allow you to block all servers not identifying themselves, spoofing another server or using revoked certificates.
TLS is just encrypting the channel between servers to prevent sniffers to see the clear text data and possible passwords used to authenticate SMTP sessions.
S/MIME or OpenPGP "only" protects the message itself and provides a way to validate the sender of the message. You may of course configure your server to validate all messag
Re: (Score:2)
Compared to existing TLS, it ensures the hop between your providers systems and the destination MX is also done over TLS.
As far as I am aware, S/MIME and OpenPGP do not do PFS (perfect forward secrecy). Doing so would be difficult because they would need some way to exchange the ephemeral key, and there is no direct handshake.
This means someone can intercept your S/MIME/CMS/PGP/GPG/etc encrypted message and deploy brute force attacks on it if they can intercept it in transit. The addition of SMTP STS will g
Re: (Score:2)
I think the problem this is trying to solve is that mail relays transmit information to both TLS and plain-text SMTP without any verification. I mean, most MTAs will deliver to SMTP servers that have invalid, self-signed and expired certificates. But yes, I don't see how this changes anything unless all MTAs implement it....and we could just do that by turning on strict for TLS (and watch 50%+ of your e-mails no longer get through)
Correction (Score:2, Informative)
I like that mods actually took their time to edit a description for once, but there's a mistake.
"The new protocol also works with HTTPS" should be "works like HSTS".
The original text from the recent submissions page was technically accurate.
But yeah, since Microsoft, Yahoo and Google joined forces, this almost guarantees the standard will be approved. Once you get the three major email providers to agree on something, it's almost as done.
some good things about insecure (Score:2)
It forces people to think a bit more carefully about the things they say/write (and read) over email, and makes people communicate a bit more formally in that medium. When someone starts relying (or incorrectly believing) that email contents are totally secure and private, you get in trouble and start writing/saying things you really shouldn't.
Re: (Score:2)
big problem is that email is now the replacement for the fax machine for many legal purposes
Editorial mistake... (Score:3)
The new protocol also works with HTTPS to avoid SSL/TLS downgrades and MitM attacks.
The article says:
HSTS works alongside HTTPS to avoid SSL/TLS downgrades and MitM attacks.
HSTS != SMTP STS, though they are similar.
Re: (Score:2)
S/MIME is your answer.
corps create appearance of security not reality (Score:2)
big tech corps are interested in creating appearance of secure and private communication to all, that it also usable without effort on our part. but this is impossible to achieve.
if we want to be secure and private, we have to do it ourselves and spend some time and effort to get a solution that will suit us. for most email we probably don't need that, but when we need it, we have to spend resources to achieve it.
don't expect, or trust, big tech corps to provide it.
Why isn't AOL participating? (Score:2)
Re:How about we create a new standard WITHOUT TABL (Score:4, Insightful)
I feel bad for you.
e-mail marketing is barely 1 step above straight spam.
If I had it my way, e-mail would be text only or implement some form of markdown [wikipedia.org]
If you want to have fancy formatting, throw up a web page and go nuts, then send a non-shortened link by e-mail if you absolutely must.
Re: (Score:2)
Markdown would allow for simple formatting like what you describe.
Can I setup my own e-mail server? (Score:2)
Will this standard allow me to setup my own e-mail server and Google/Microsoft not silently drop all my messages? Because that's the biggest problem with e-mail right now. I wrote a post on it a while ago:
http://penguindreams.org/blog/how-google-and-microsoft-made-email-unreliable/
Re: (Score:2)
It is more a deficiency of the underlying protocol than anything else. Spam and malware delivered by spam has become so pervasive that lots of people have given up on the thing. It wasn't that long ago that you could find open relays (perhaps there still are some out there), which permit anyone to send an email as anyone else.
And then there is the malware that hitches a ride on top of the automation interfaces that Microsoft has so generously provided. So once you get infected, your own machine starts se
Re: (Score:2)
When I did contract IT, I would always set up smart hosts, preferably Postini (now rolled into Google apps) or Securence (US Internet) but, in a pinch, I would use their ISP's mail server.
If they absolutely had to run their own mail server I would tell them that they required:
- Business class Internet connection
- Static IP
- Reverse DNS to match the forward DNS
If they didn't want to opt for any of those... well, I would still set up their mail server but made it clear that some e-mail was going to be rejecte
Re: (Score:2)
That link implies that email was reliable at some point. It has never been reliable, has only ever been best-effort, and when it fails it requires wizardry and chicken entrails to determine the problem. I was in charge of email for my organization from 1993-2010, and it was the most thankless job imaginable (except, maybe, for printer admin).
I don't have much experience with hotmail/outlook.com, but gmail has been far less likely to stop spam without blocking valid email than anything I could deploy at my
RFC's are submitted by individuals, not companies (Score:1)
Why do they hate America?!? (Score:2)
Wait..... (Score:3)
So now I'll have to decrypt my spam in order to read it? I feel safer already!