Emails sent via SMTP AUTH reveal the sender's IP

[peter-h]

I asked a colleague who does a lot of IT stuff to check if my DKIM and SPF are OK. Gmail is now bouncing any incoming email unless it has either SPF or DKIM.

He pointed out that my email headers are leaking my home (or office) IP. This is astonishing... but apparently it is correct per the protocol.

The SMTP AUTH service I use has a control panel config to suppress this header



but I wasn't aware of this until now.

The headers still leak the machine name but that doesn't normally matter.

[Monkeh]

Yes, this is completely normal and has been the case for, oh, 40 years.

Neither your external nor internal IPs are secrets.

[peter-h]

So it seems, but locating somebody via their IP wasn't so easy 40 years ago I'd think most people don't expect their emails to geolocate them.

[Monkeh]

In my experience, geolocation by IP is.. not concerningly precise. You'd get on the right side of my county, at least, with one of my IPs..

[peter-h]

Sure, but an IP can reveal all kinds of peripheral stuff e.g. a business you happen to work at, etc. An entire IP history is available nowadays, including hosted domains which were on it for just 5 mins.

[SiliconWizard]

Yep. This is absolutely not secure.
SMTP is "outrageously" basic by today's standards.
And while locating someone by IP is imprecise with IPv4, wait for IPv6 to become more widely used, and things will change quite a bit.

[Monkeh]

Sure, but an IP can reveal all kinds of peripheral stuff e.g. a business you happen to work at, etc. An entire IP history is available nowadays, including hosted domains which were on it for just 5 mins.

If keeping peripheral information like that secret is important, you shouldn't make contact with any external service from that IP.

And while locating someone by IP is imprecise with IPv4, wait for IPv6 to become more widely used, and things will change quite a bit.

My v6 block doesn't geolocate any better. Because, for very good reasons, ISPs don't go around registering physical addresses of customers against data which isn't merely not private, but absolutely must be disclosed to all and sundry.

[golden_labels]

The reason for those headers being present is debugging. A full path trace helps MTA and MDA admins understand, what is happening in the case of problems. Whether nowadays including the path beyond the initiating MTA is useful is debatable. Majority of the end users became too ignorant to be of any help, so MTA operators are the last useful link. If they need more details on the actual sender, they can log the relevant information locally. Email, similar to other internet technologies, was also developed in an environment valuing coöperation, competence, and mutual respect. Confronted with a world, which treats even communication as a liability to be minimized in the balance sheets, some features start making little sense. This is one of them.

As for the risks: to nearly all people revealing an IP address is of no risk.⁽¹⁾

From security standpoint: IP addresses are public, necessarily exchanged in open form, and collectable or even associable with an individual through effort much smaller than people expect. If not already catalogued enough, in the 20s scanning the entire IPv4 range for a selected vulnerability is completed within minutes using resources available to a script kiddie. Which makes “leaking” that information not completely irrelevant. I want to be clear on that! But much, much, much less important than people would believe.

Privacy is a bigger problem. But leaking that through email headers is also of minor importance, compared to extreme level of surveillance through other means. My personal preference is to have those stripped. But only because I believe in the privacy by default approach. Not due to any particular, major threat.

Geolocation works very well. It can narrow down the address to at least a single district or a town. The thing is: you need to buy that information. Public databases became quite useless after IP address leasing and anycasting became commonplace.

⁽¹⁾ The few exceptions include vulnerable groups and people engaged for illegal activity.  And people, who made the above claim on the internet. Because there is always some dumb kid believing they “prove the point” by causing nuisance.

[madires]

Yep, it's valuable debugging info vs. privacy. Many MTAs have options to strip parts of the email header. For exim one can set 'headers_remove = Received' for an email router to strip the Received lines.

[peter-h]

It is quite good for "stalking" - today's favourite civil liberties term The messaging sites go out of their way to strip off EXIF from images, due to this.

[SiliconWizard]

I do consider this a privacy concern indeed and overall, again, SMTP is very, very poor in terms of both privacy and security, it's mind-boggling that we're still using it.

Now as a "privacy concern", you'll get all kinds of opinions. The opinion that it doesn't matter unless you have "something to hide" seems pretty popular. "Si vous n'affez rien à cacher... il ne faut pas affoir peur!"

[peter-h]

But what else can one use?

Google owns the universe and demands SPF or DKIM, will probably demand DKIM at some point, and while you can run your own SMTP server and implement DKIM on that, it is likely to get blacklisted because even though it is on a fixed IP, that "fixed IP" will be out of an ISP IP block which is downranked in trust level.

Email is email

[tszaboo]

Just wait until you find out that the return address on a letter or package is on the outside of the package.

[madires]

Google owns the universe and demands SPF or DKIM, will probably demand DKIM at some point, and while you can run your own SMTP server and implement DKIM on that, it is likely to get blacklisted because even though it is on a fixed IP, that "fixed IP" will be out of an ISP IP block which is downranked in trust level.

While the big players claim they do it to fight SPAM, they also distribute a lot of SPAM. For example, for 10 days or so someone runs a SPAM campaign using Google groups. I reported a few SPAM emails, but no reaction from Google or any change. So I added a filter rule to SpamAssassin and my MTAs reject that SPAM.

[SiliconWizard]

Google owns the universe and demands SPF or DKIM, will probably demand DKIM at some point, and while you can run your own SMTP server and implement DKIM on that, it is likely to get blacklisted because even though it is on a fixed IP, that "fixed IP" will be out of an ISP IP block which is downranked in trust level.

While the big players claim they do it to fight SPAM, they also distribute a lot of SPAM. For example, for 10 days or so someone runs a SPAM campaign using Google groups. I reported a few SPAM emails, but no reaction from Google or any change. So I added a filter rule to SpamAssassin and my MTAs reject that SPAM.

I've seen that a lot as well.

[Halcyon]

Google owns the universe and demands SPF or DKIM, will probably demand DKIM at some point, and while you can run your own SMTP server and implement DKIM on that, it is likely to get blacklisted because even though it is on a fixed IP, that "fixed IP" will be out of an ISP IP block which is downranked in trust level.

It's not exactly a matter of picking one, SPF and DKIM have very different purposes.

SPF authenticates the sender. DKIM cryptographically signs each message.

Setting up both on your domain is best practice (along with a strong DMARC policy). MTA-STS is also advisable to prevent TLS downgrade attacks.

I'd say all of the major email service providers, not just Google and Microsoft, are encouraging better email security through these methods. And organisations are getting stricter on what emails will pass through to end-user mailboxes. For example, I've set up a rule in our organisation that if your email fails DMARC, if gets rejected. Not just quarantined or delivered to spam, but you'll get a NDR telling you to fix your email set up, and the email is entirely gone from our end.

[peter-h]

I looked at DMARC and AFAICT one passes it by having a valid DKIM.

None of this stuff will ever be perfect because anybody can set up valid DKIM on a server they control. All the recipient can really do is run a whitelist of trusted domains. Then DKIM is 100% reliable. But then you cannot receive emails from new customers, which is dumb.

[madires]

Yup, valid SPF or valid DKIM, or both valid. They help to detect address spoofing and reduce backscattering of NDRs. But they don't prevent someone from setting up a new domain with everything enabled and sending tons of SPAM. Also, DKIM has some drawbacks, e.g. when some MTA changes headers which are signed.

[Halcyon]

I looked at DMARC and AFAICT one passes it by having a valid DKIM.

None of this stuff will ever be perfect because anybody can set up valid DKIM on a server they control. All the recipient can really do is run a whitelist of trusted domains. Then DKIM is 100% reliable. But then you cannot receive emails from new customers, which is dumb.

DMARC will determine both SPF and DKIM pass/fail.

[peter-h]

Right, but is the bottom line that one day DKIM itself will not be enough?

The bottom line is that there is no way to be sure an email is not spam

[golden_labels]

SPF and DKIM are not protecting against spam. They authenticate the sender MTA, preventing spoofing. That’s a security issue, not a mere inconvenience. Deploying SPF or DKIM for a botnet is also a relatively high cost, so coincidently they limit the amount of spam by making address-based circumvention harder (note the emphasis). But they can’t stop spam. In particular in the extended meaning of word “spam,” which most people use.

The problem of spam can’t be resolved by purely technological means either. It’s a societal issue. Similar to other blind alleys of history, the arrival of computers spawned a wave of narrow minds believing their new toys are a panaceum and the final solution to all trouble of mankind. But they’re not and that kind of problems fail to be resolved by technology. Worse: even from purely technical perspective it’s unsuitable for the task. It’s like building and hiding in a fortress… with “the enemy” being on the inside. Spam doesn’t exist, because a bunch of idiots have nothing better to do, but to send it. Where there is demand, there is supply. Spam continues, because recipients actually use it. Senders merely make a reasonable decision and adjust to the demand, filling voids in the market.

[peter-h]

You can't stop spam but DKIM enables a recipient to implement a whitelist of trusted senders, which is a good thing. How many actually do that, I have no idea. I used a filtering outfit for many years (Messagelabs, until they disintegrated, and then some German outfit called Hornet Security which went mad, organisationally, crazy reseller who deleted our account) and it was possible to set up a whitelist but based on the domain, not simply based on DKIM.

These outfits also offered SMTP AUTH but I don't know if they offered the IP header suppression. Probably not...