35

I would like to ask what happens when an email is sent from Gmail, Yahoo or Hotmail public web email services?

I don't understand email protocols in details, but as far as I know email traffic is unencrypted and the messages are passed along many mail servers (in plain text) before reaching their destination server. However, this was questioned recently by other people, and their view was that if one of the big providers is used, the email messages are encrypted and there is no need to worry about security.

Do you know if they are right about this and are emails moderately secure?

Improve this question
1
  • 1
    Can you clarify that you mean their public mail services, not their staff e-mail system?
    – user185
    Commented Aug 23, 2011 at 16:44

4 Answers 4

Reset to default
53

An SMTP session between two mail servers may be encrypted, but only if both ends support it and if both ends choose to use it. So if you're sending mail from Gmail to example.net, then Google could only encrypt if example.net was ready and willing. For this reason, you cannot trust email to be even moderately secure at the transport layer. (The only safe end-to-end method is to encrypt your email using S/MIME or PGP, but the people you're exchanging email with need to be on board too... just like the mail servers).

As to whether the big three are performing opportunistic STARTTLS, I haven't seen any evidence of it, but I spend less time reading my mail server logs than I used to. And if they are, they're still only half of every SMTP connection they make, and cannot guarantee the use of encryption.

Update:

I just banner tested MX hosts for gmail.com, yahoo.com, and hotmail.com. Only gmail advertises STARTTLS, which is to say, only gmail would be willing to encrypt the SMTP session if the other party wanted to.

I tested gmail outbound by sending mail to a server I own and watching the wire; Google does indeed take advantage of STARTTLS if it is offered and encrypts the SMTP transaction when a gmail user is sending mail. Props to Google.

So as far as "sending" email encryption goes: Google 1, Yahoo 0, Microsoft 0.

As per the comments below, if you want to test these yourself, it's very simple:

  1. Determine the MX hosts (Mail eXchangers) for the domain
  2. Telnet to port 25 on one of them
  3. Type in "ehlo yourhostname.domain.com"
  4. If you don't see "250-STARTTLS" as one of the responses, they don't support opportunistic encryption.

Like this:

$ host -t mx yahoo.com
yahoo.com mail is handled by 1 mta5.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta7.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta6.am0.yahoodns.net.
$ telnet mta5.am0.yahoodns.net 25
Trying 66.196.118.35...
Connected to mta5.am0.yahoodns.net.
Escape character is '^]'.
220 mta1315.mail.bf1.yahoo.com ESMTP YSmtpProxy service ready
ehlo myhost.linode.com
250-mta1315.mail.bf1.yahoo.com
250-8BITMIME
250-SIZE 41943040
250 PIPELINING
quit
221 mta1315.mail.bf1.yahoo.com
Connection closed by foreign host.
$

As a side note, Yahoo will close the connection if you don't ehlo right away. I had to cut & paste my ehlo because typing it in took too long.

MORE UPDATE:

As of January 2014, Yahoo is now encrypting - I just tested (as above) and verified. However, both The Register and Computerworld are reporting that the intracacies of SSL setup (such as Perfect Forward Secrecy) leave a lot to be desired as implemented by Yahoo.

EVEN MORER UPDATE:

Google is now including SMTP encryption data in their Transparency Report Safer Email section. They're sharing their data about who else is willing to encrypt, and you can look at the top numbers as well as query individual domains.

Addendum:

@SlashNetwork points out that it is possible to configure a mail server to require that TLS be negotiated before exchanging mail. This is true, but to quote the Postfix documentation:

You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, by setting "smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP server. This option is off by default and should only seldom be used.

Now, the world is full of implementations that violate the RFCs, but this sort of thing - e.g., something that may break routine required functionality like accepting bounces and mail for the postmaster - is probably more likely to have negative consequences.

A better solution which mail gateways often allow is the imposition of TLS requirements on a per-domain policy basis. For example, it is usually possible to say "Require TLS with a valid Certificate signed by Entrust when talking to example.com". This is usually implemented between organizations that are part of the same parent company but have different infrastructure (think: acquisitions) or organizations with a business relationship (think: ACME, Inc., and their outsourced support call center company). This has the advantage of ensuring that specific subsets of mail that you care about get encrypted, but doesn't break the open (accept from anyone by default) architecture of SMTP email.

Addendum++

Google has announced the gmail will percolate information about the security if the mail path out to the reader. So these behind-the-scenes encryption steps will be brought to the notice of the user a little bit more.

(Probably still doesn't care about the certificate provenance; just an indicator of encryption of bits).

Improve this answer
9
11

There are three points in the chain you need to consider: Transport between mail servers (e.g. between Google and example.org), transport between mail servers and clients, and the mail servers themselves.

Traffic between mail servers may or may not be encrypted; you shouldn't rely on it, and AFAIK, there is no way to enforce it from the client.

Traffic between clients and mail servers may or may not be encrypted; if you connect over SSL (either via a web interface or SMTP), your end of the chain is secure, but you can't say anything about the recipient. Conversely, if you're the recipient, you can fetch mail securely, but if the sender (or anyone in the CC/BCC) doesn't do the same, then there's your leak.

And finally, there's the mail servers themselves. If someone hacks into them, or social-engineers their way in, and the mail server stores content unencrypted, then again you're out of luck.

TL;DR: Unless you control the entire chain (both clients, and all mail servers involved), which is practically never the case, the only way to send emails with reliable security is to encrypt and decrypt locally, using something like PGP.

Improve this answer
10

There's two different questions here:

  1. Does the email system allow emails to be sent to it over an encrypted channel and send email along an encrypted channel when the recipient's mail server supports it.
  2. Does the email system encrypt the contents of a mailbox when displaying it to the owner.

gownfawr addresses (1) well.

Gmail does encrypt via default for (2) so when viewing your mail, by default it is done via HTTPS, so a snooper will not be able to observe gmail sending the mail to your browser. I believe the others have not yet followed suite. (Full disclosure, I work for Google).

Gmail is set to use the 'Always use https' setting by default, ...

"Make Your Webmail More Secure" has instructions for avoiding plain-text reads of a mailbox for a number of large webmail providers, but I cannot vouch for it being up-to-date.

Improve this answer
6
  • 1
    +1 good separation of the two aspects. Pretty certain the answer to 1 is "Not by default, but all 3 will do this if required and both ends support it, and (where relevant) keys have been exchanged"
    – Rory Alsop ♦
    Commented Aug 22, 2011 at 23:01
  • Thank you for the answer! About the ecnryption - I was asking for the messages when they are sent by the mail server, not for the user interface which is used by end-users to check their inbox. It was valuable for me to understand that only 2 mail servers are involved.
    – luben
    Commented Aug 23, 2011 at 7:23
  • 2
    Actually, it is common for more than 2 servers to be involved. I just reviewed 56 messages in my inbox: 7% had one "hop" (two servers), 18% had two hops, 57% had three hops, 2% had four hops, 4% had 5 hops, and 12% had 6 hops. One hop may represent client-to-SMTP-server, but the rest will be server-to-server. (The 6's are all Yahoo mail, which bounces around inside Yahoo using NNFMP before going out; I don't know but suspect that NNFMP doesn't support encryption).
    – gowenfawr
    Commented Aug 23, 2011 at 12:39
  • @gowenfawr, thanks for explaining. The lack of encryption within Yahoo is less worrying than outside since there are fewer potential observers inside Yahoo's firewall.
    – Mike Samuel
    Commented Aug 23, 2011 at 16:22
  • 1
    Other potential reasons for multiple mail hops include divisional mail routing (e.g., big companies, one domain, many sites and organizations), anti-SPAM services (e.g., Cloudmark, Postini), anti-SPAM and anti-Virus gateways (Barracuda). To see where your mail has been, look at the headers; there will be multiple "Received:" headers. Each time a mail server accepts a mail message, it adds its own "Received" header, so each one represents a hop, and you can see what servers (name and/or IP and sometimes software) touched your email. Some will also note if they used SSL for that hop.
    – gowenfawr
    Commented Aug 23, 2011 at 21:49
2

You can test for yourself by using the websites mentioned at Test STARTTLS configuration of SMTP server. Be sure to test both receiving and sending.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .