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?

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:


Determine the MX hosts (Mail eXchangers) for the domain 
Telnet to port 25 on one of them
Type in "ehlo yourhostname.domain.com"
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).
