
Client IP address disclosure in smtp.gmail.com - rbanffy
https://www.leeholmes.com/blog/2020/04/02/client-ip-address-disclosure-in-smtp-gmail-com/
======
mike_d
This is "Working as Intended" (and Google told him exactly that).

Gmail and other providers have to split the balance between privacy and
security. If you use the web interface and they authenticate your device
directly, Google hides your IP and takes responsibility as the "source" of the
email. If you're using SMTP it is possible you could be relaying mail for
others (even possibly as an open relay) and they will disclose the IP of your
client or mail server.

------
throwaway483284
_Disclosure Timeline

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_

Sorry but this is just embarrassing. He wasted so much of his time and time of
others while doing 15 sec of googling[1] would solve this.

[0] [https://www.quora.com/Does-sending-email-from-Gmail-
expose-y...](https://www.quora.com/Does-sending-email-from-Gmail-expose-your-
IP-address-to-the-sender)

------
throwanem
I've just reproduced the described behavior via a test message from Gmail.

On the other hand, I've _also_ just reproduced it via test messages from every
other one of my email accounts, across multiple providers as well as the
various instances I run for my own use. The only one that _didn 't_ repro was
Office 365.

~~~
resfirestar
With O365, your IP should generally be in the X-Originating-IP header.

~~~
throwanem
Oh, look at that, so it is.

~~~
yipeedipee
We use a mail flow rule to remove the header when it goes through o365
outgoing.

------
_wldu
Isn't that how SMTP has worked for decades?

~~~
ratsmack
Yes, and it is extremely handy for debugging email issues and for identifying
spammers.

------
gumby
In other news iOS tells every web site you visit Your IP address! And no
matter where you drive people have access to a unique vehicle ID assigned to
your vehicle by the state!

------
resfirestar
This is how SMTP is supposed to work. As a side note, messages sent with
Outlook or webmail using O365 (or Exchange) don't go from your client to the
O365 server over SMTP, but your IP address is still shown in the
X-Originating-IP header.

------
tedunangst
I'm half surprised I didn't get a "your computer has an IP!" popup visiting
this page.

------
55555
This is what is supposed to happen. I guess I agree though that we could get
rid of it as normal users dont know this is how email normally works. It's
useful though...

------
9wzYQbTYsAIc
Anyone know how privacy-focused providers fare with this?

~~~
dannyw
Unsurprisingly, Protonmail strips the IP address.

~~~
mike_d
Protonmail does not support SMTP at all, so I'm not sure what you think they
would be stripping.

Both Protonmail and Gmail hide the IP if you're using the web interface.

~~~
NonEUCitizen
ProtonMail does support SMTP via a bridge:

[https://protonmail.com/bridge/](https://protonmail.com/bridge/)

tho not clear if dannyw tested with ProtonMail IMAP/SMTP Bridge or with
ProtonMail web.

------
Carpetsmoker
If host A is using gmail to spam me, then I can block host A, but if gmail
would remove this I can only block all of gmail (or the gmail account, but a
new account will be created 2 seconds later, whereas creating new IPs is much
harder).

I'm all for privacy and prevention of leaking data such as IP addresses, but
there are other concerns, as well, which I often see "privacy advocates"
forget about. Maybe there is a better way to solve this problem than including
the IP address – I would be all for it – but this post doesn't mention any of
this.

Unfortunately, 100% privacy is often open to abuse from malicious actors, and
a balance needs to be struck.

BTW: you can make a similar argument about the stamps the post office puts on
your letters, which often includes the location and may be "private
information".

~~~
gruez
How is this argument relevant when you can still spam anonymously by using the
web version?

~~~
Carpetsmoker
Sending spam on the gmail web UI is considerably harder than a few lines of
shell script needed to spam over SMTP. And arguably, the web UI should really
add the same Received headers.

------
jamesaepp
Can someone break down what this means for me? I'm assuming an example of say
Thunderbird as the MUA connects to gmail's servers with SMTP over TLS or using
STARTTLS and happens to include this header of the client's public OR (not
xor) private IP address as per specification(s).

What's unclear for me it whether this is then stripped by gmail's MSA/MTA
before being routed towards the destination. From how I'm reading the article
in the OP, it seems to imply that the recipient of the message would know the
sender's IP address. If this is the case then I'd say that's of some concern,
but it seems people are saying this is NOT the case. Can someone please expand
on the exact test setup?

~~~
dfox
Any random MTA including gmail's that receives your message over SMTP prepends
Received header to your message that contains where the message was received
from and that somewhat obviously includes the IP address where the message
came from. It works as intended and if you at all care about privacy
implications of that (whatever that might be) you simply should not use
email/SMTP.

~~~
jamesaepp
I'm not looking for an argument, I've never noticed this behavior before. Why
is this done? People are saying this is some kind of way to combat
spamming/spoofing/malicious email but I don't see how that's the case. If the
source address of the packets matches a blacklist then you can correlate
against that. While not impossible to forge an IP address, it's certainly more
trivial to edit the SMTP header (I'm not saying that would avoid detection,
mind you).

What benefit do we gain from including the origin's IP address throughout the
entire header history?

~~~
d1zzy
This was done way before Google existed, way before they offered a GMail
server or an SMTP interface to their servers. It is done to combat spam, if I
get an email that was relayed through their servers I can see which IP
connected to their servers to send it. Then every time the email is sent
between servers the source IP is again added. It allows to track the real
source of an email, remember that email inherently has no authentication,
there's no way to really say the From address is authentic. But having a
record of all the IP addresses used when transferring the email I can
determine that pretty easily.

~~~
jamesaepp
While yes, email has no implicit authentication and forging an email is
trivial, pulling that attack off is super difficult due to modern SPF and DKIM
mechanisms. I'm not super familiar with DKIM but I'll use SPF in my example
below.

Let's say I'm running an email server for myself for example.com and I receive
an email from 192.0.2.1 and it claims to be from bob@gmail.com. Okay, great.
First I consult with my database of blacklists to make sure that 192.0.2.1
isn't blacklisted. If it is, into the trash it goes.

The blacklist reports the address is clear, I move to the next step - SPF. I
do a DNS lookup for the txt records under gmail.com and find the one for SPF.
But lo and behold, the SPF record does _not_ include 192.0.2.1 as a valid
address to submit mail on behalf of gmail.com - this email is likely forged. I
drop the mail and submit a report to my favorite blacklist provider(s).

Now, could the DNS have been forged? Yes. With modern DNSSEC, is that likely?
I don't think so. Could the packet's source address been forged? Yes, that's
pretty easy if you're the ISP or state-sponsored. But if the source address
has been forged, there's no way the IP address in the SMTP headers are going
to do you any good - the attack is too sophisticated at that point.

If a receiver of mail fails to properly validate the source of the email, that
onus is on them as far as I'm concerned, especially so if DNSSEC, SPF, DKIM,
etc have all been implemented. While open relays aren't extinct, they sure are
easy to detect and most best practices I've read on email say to reject them
when detected.

I still don't see how having this trail of user IP addresses is useful.
There's nothing implicitly in the message that can be trusted - that's what
PKI is for.

~~~
tptacek
I don't know what you mean by "modern DNSSEC", but virtually none of the most
important names on the Internet are (or likely ever will be) signed, so
whatever your obstacles to forging an email might be, DNSSEC won't be among
them.

~~~
jamesaepp
>Virtually none of the important names are signed.

Source?

>...Or likely ever will be

Source?

~~~
likpok
[https://dnssec-name-and-shame.com/](https://dnssec-name-and-shame.com/)

This shows the top 25 websites and that none of them have DNSSEC.

As for whether people will in the future, it’s impossible to say for sure. But
chrome doesn’t support dnssec, which shows how seriously google takes it.

~~~
jamesaepp
Thanks for the link, that's quite interesting. While web browsers can
implement their own DNS resolver, that's completely irrelevant when we're
talking about an MTA. The server(s) the MTA(s) are running on have their own
underlying resolvers which can be DNSSEC-compatible, or better yet, if you're
using a public resolver like quad9, they validate the DNSSEC for you.

Edit: Not that I'm saying you should _trust_ quad9 full-stop, but it is a nice
feature. Anyone could run their own private resolver but most choose not to
because of the very same privacy concerns we're talking about in these
headers, namely - making your traffic easier to profile.

~~~
tptacek
It doesn't matter that your MTA could, in theory, do fully recursive
signature-validating resolutions, because none of the domains you'll be
looking at are signed.

~~~
jamesaepp
Yes, I'm satisfied with the evidence presented that the "major" vendors aren't
signing their zones, but I do think we're far off-topic at this point as to
whether or not the client IP address has value in the message headers.

Thanks for the discussion!

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

Or, use a VPN rather than hamstring the ability to validate email or fight
spam.

------
icedchai
This is how SMTP works.

------
zeroimpl
Tip: run your own mail server and configure it to hide your source IP

------
jscholes
April Fool's was yesterday...

