Summary

When email users of several email services send mail using mechanisms other than that service’s web interface (i.e.: their phone or laptop’s email program), services commonly include the user’s IP address in message headers. This information disclosure lets recipients of these messages perform some privacy-invasive actions, such as:

• Approximate geographical location of the sender
• Correlation of separate email addresses, but sent by the the same sender
• Broadband and / or cellphone provider

Users looking to send email in a manner that keeps this information private from message recipients should use either the web interface or an alternative mail provider. Impacted:

• Gmail
• Google Suite
• Apple (@mac.com, @me.com)
• Most ISP email providers

Not impacted:

• Yahoo, AOL
• Outlook.com / hotmail.com (M365 consumer)
• Office 365
• Protonmail

Edited 4/13/2020 - A previous version of this post singled out Gmail. While this is the most popular email provider impacted by this flaw in common configurations, they are not the only one.

Edited 1/4/2023 - A previous version of this post included Office 365 and Outlook.com (consumer) in uncommon configurations. These have now been removed: the M365 team has addressed these privacy issues.

Impact

While the RFC requires that email programs identify themselves to SMTP servers, consumer mail is a relatively new thing as far as internet time goes. It is a change in threat model compared to the work-centric mainframe systems that were at the core when the RFCs were written. Today, people use consumer email systems in privacy sensitive situations that they didn’t before - whistleblowing, at-risk communities, avoiding domestic abuse, and more. People that are uncomfortable with a mail recipient knowing their approximate geographical location should avoid using email applications to send email via the impacted email services, or use a privacy-preserving consumer email service.

Discussion

Non-web email clients generally use the Simple Mail Transfer Protocol (SMTP) to connect and send mail via their mail service provider. Examples of these non-web email clients are the mail applications built into phones (Android, iOS) or desktop / laptop operating systems (Apple Mail, Windows Mail). When these applications connect to their mail server’s SMTP server to send an outgoing mail, part of the protocol requires a “HELO” or “EHLO” message. RFC 821 describes this exchange as:

      At the time the transmission channel is opened there is an
      exchange to ensure that the hosts are communicating with the hosts
      they think they are.

      The following two commands are used in transmission channel
      opening and closing:

         HELO <SP> <domain> <CRLF>

         QUIT <CRLF>

      In the HELO command the host sending the command identifies
      itself; the command may be interpreted as saying "Hello, I am
      <domain>".

      -------------------------------------------------------------

                     Example of Connection Opening

         R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready
         S: HELO USC-ISIF.ARPA
         R: 250 BBN-UNIX.ARPA

                               Example 5

      -------------------------------------------------------------

Most mail clients include the user’s public IP address and host name as part of this exchange, with Apple Mail even including the computer name and IP address on the internal network used to send the mail. One could argue that mail clients should not send this information as part of the exchange, but some SMTP servers validate that the actual IP address of the sender matches the content of the SMTP exchange as a form of spoofing protection. As mail servers transport the message from its original SMTP server to the destination email server, much of this conversation is retained as part of the message’s mail header content. Microsoft has a good resource on how to see and interpret these mail headers here: https://support.office.com/en-us/article/view-internet-message-headers-in-outlook-cd039382-dc6e-4264-ac74-c048563d212c, but an example looks like this: As you can see in the “Received: from” headers above, some SMTP severs redact the sender’s client IP out of the rest of the exchange, replacing it instead with the address of the SMTP server. Two examples of email services that perform this client IP redaction are Outlook.com (as above) and AOL.com. However, as noted above, there are some scenarios in which Outlook.com does include this information. The SMTP servers of some services do not perform this redaction, which provides the following data to recipients of the message:

Recommendation

Users looking to send email in a manner that keeps this information private from message recipients should use either the service’s web interface or an alternative mail provider.

Disclosure Timeline

Google

• March 9, 2020 – Reported to Google security
• March 10-19, 2020 – Assisted with steps to reproduce
• March 20, 2020 – Resolved by Google as “Won’t Fix (Intended Behavior)”
• March 20-31, 2020 – Worked to confirm that there were no future plans to fix
• April 2, 2020 – Got confirmation that the team was aware of the issue and has no plans to fix

Microsoft

• March 9, 2020 - Reported to Microsoft security
• March 19, 2020 - Got confirmation that redaction was intentional for Consumer Outlook. This blog post and responses to it uncovered scenarios where this redaction wasn’t applying, and this is still under investigation.
• Late 2021 - M365 completed roll-out of redaction in all scenarios, including SMTP-only clients and Office 365.

Apple

• April 3, 2020 - Reported to Apple security