Show HN: Test your E-Mail for IP Leaks
emailipleaktest.com
emailipleaktest.com
I'm getting a false "Your email has been received and it doesn't leak your IP", due to the fact that the web site is only available using IPv4 while I'm connecting to my SMTP server over IPv6. As long as the website only captures IPv4 addresses it really might need to display an inconclusive result in the presence of IPv6 received headers.
Oh, and when the web site do become IPv6 reachable you probably will want to make an explicit attempt to also catch a potential IPv4 address, in the case situation above is the reverse.
I'm guessing Gmail app would. edit: tested, doesn't leak!
Then I tested using an account on a personal email server that I set up recently using iRedmail on a VPS -- it leaked! It showed both my external ISP IP addres and my internal IP address on wifi!
Header: X-Originating-IP: [my-ip-address]Can anyone provide additional input into whether and when the Gmail web interface may be (and when not) inserting this header? Perhaps it's just in the Google Apps context?
I assume there's some kind of a rationale for them doing this...but I don't quite know what it is.
After all, anytime I visit a web site I "leak" my IP address. Is that also a problem?
If you browse news.ycombinator.com without ever registering, a site admin viewing access logs doesn't really have any frame of reference for the IP address. It's just a random visitor. They could also see your browser and OS, but that is not even remotely unique or descriptive about you as a person.
On the other hand, if you sign up with a personal e-mail address, a site admin could realize that some "5.5.5.5" IP making unusual requests is also "john.smith@gmail.com", and infer further things about you based on that.
The same goes for if your emails are leaking your IP address unbeknownst to you. So, for example, someone you are emailing will be able to quickly know your country, region, and potentially your city; you may or may not desire that. If you attend a university or are working at a company's premises, they will know what university or what company. If you sent the email from a coffee shop, they will know the shop's company's name and a rough location, and could infer the precise location based on that.
For a personal email like "jim@mit.edu", this isn't a concern, but if you perhaps have an email you use when you want to remain anonymous or semi-anonymous on the internet, often you won't want that kind of information disclosed.
And from a security perspective: if you are hosting some kind of a server from that IP address, it could be scanned or attacked. And whether you are hosting anything or not, the email recipient could try to launch a DDoS attack against you (typically in the form of pure bandwidth saturation).
Well, there is this: https://panopticlick.eff.org/
In the event that a site does, though, even if they acquire a completely unique fingerprint for you as a site user, they still don't find anything interesting about you yourself. If you visit the same site with the same IP and never register, they won't be able to put that fingerprint to much use.
Now, if that fingerprint were shared with or collected by other providers in some way (perhaps by a common ad network), much more nefarious things can be done in that regard.
Some site admins may not, but ad-exchanges certainly have.
It means I can select Show Original in Gmail and see your X-Originating-IP header. Then I can run your IP against, for example, MaxMind† and see if you are (1) at home, (2) at your office, (3) visiting your in-laws in Santa Fe, or (4) somewhere else.
Of course, there's a slight asymmetry: Gmail does not supply the X-Originating-IP header. So you can't, in turn, look me up on MaxMind. But, if you are my Gmail correspondent, you probably don't know about the header, anyway.
I'm looking for an apartment in SF, and I stumble across a few places that seem too good to be true. Pretty sure they're spam, but out of curiosity, I go ahead and email. (Plus the way to make life difficult for spammers is to give them a lot of false positives, playing along for as long as possible, wasting their time, but unfortunately yours too.) The response I get back is clearly a scam—the "pay $200 deposit to schedule a tour" kind of scam. I get a few more emails, pressing me to pay the "deposit." Out of curiosity, I check the email headers. The sender is using Yahoo, and the IP address is being leaked. I do a geo IP lookup, and it turns out the IP is from Ghana.
Naturally, I enter the IP in my browser, and guess what shows up? An authentication dialog for the "EchoLife Home Gateway." Sure enough, entering "admin" for both username and password works fine (first try too), and here I am, connected to some scammer's router, halfway across the globe.
What's more, the router connects to the ISP using PPPoE, so the username for the account is visible in the PPPoE config. And the password is hidden under a password field, but it's being loaded by some sketchy javascript (you know how router software is). Pretty trivial to check out the DOM and find a plaintext password. Next time I'm in Ghana, I get free DSL! Did I mention that the username for the PPPoE account was clearly an actual name? A bit of google-fu and I know quite a bit about the guy who tried to scam me. Turns out it's no secret he's a scammer—in his early days it looked like he'd been using his actual name to run scams, so there were a ton of postings on scam reporting sites.
I stopped there because, as fun as it was, this was just an exercise of intellectual curiosity, I never had the intention of breaking stuff. As much as a scammer might deserve it, vigilantism isn't really the way to do it. I just reported the email to Yahoo/Google and moved on. I doubt there was much anyone could do to stop the guy from scamming anyway. But there's a lot you can do with an open router if you want to harm someone, and that's an understatement. All it would take is something as simple as setting up a VPN connection (I don't think the router I was dealing with actually supported VPN, but I'm sure you could do something malicious, like port forwarding to netbios)
The moral of this should be pretty clear; if you're a scammer don't leak your IP. Also don't use default passwords for routers. Clearly that was the bigger issue here, but how many average people do you think use default passwords? At least if their IP is hidden, there's an extra layer of obscurity. Not a great one, but better than nothing.
'Leaking your IP' - should probably see a doctor about that.
On a related note, I run an exim server and it adds
Received: from my_unix_username by my.server.hostname with local (Exim 4.80)
to the headers when I send mail directly from the server with mutt. Is there any reason to hide it? Or not to remove it?Ha! Another site that thinks the x-forwarded-for header is real when it contains only stuff that triggers SQL injections.
Edit:
> The email you've sent has leaked your ip! The IP on your email was 83.161.210.237
No shit, that's the mailserver's IP. Who says it was actually sent from that IP? The headers it cites are merely listing "received from $mailserver ($reversedns [$ip])", not my client's IP address.
Immediately lost my "Trust".
Added to that, knowing how persuasive and creepily mad London politics is about evading privacy is (even more than the US), this being a blatant double agent maneuver, wouldn't even surprise me. Maybe some now suspect journalist, who thinks, he needs to hide traces would jump into the trap. So this would reduce the IP's to those people, who feel like they need to hide something. Everybody else already knows that this info can be easily found out by sending an email to yourself. It's obvious that gmail doesn't need your IP, they have your social profile and all you web-habits recorded actively (services) and passively (adsense)
In the other case that this is legitimate company not serving as a shell company, not trying to collect IP's or E-Mail addresses. I'm sorry for spreading paranoia, to those who are sensible about it.
They may know a couple of things about privacy, reputation and trust. I believe they need all three to operate their business, so I would be surprised if they were doing anything fishy when they're disclosing their name.
Little "dig"ging showed who your provider is, and Google gives me no results on this feature. Also read related docs too, nothing. Wonder why.
No idea why they don't advertise this feature. They wrote that they only tell about it to people that are actually having a problem about it. I guess it might be easier for them or for other email-ops to handle abuse/spam issues when this header is available?
It doesn't. What's the purpose then? Is it for people that don't know how to interpret email headers and instead want a simple yes/no answer?
Do we need to include this information in our email headers? Is it not enough to include the IP address of the mail server? Perhaps there is a need to do this?
I was just listening to Douglas Crockford[0] in a podcast where he talks about CR/LF and how we can't decide on whether A is correct or B is correct so we do both A and B which fits neither A's position or B's position so we pick something so neither side feels like they lost. The argument is that this middle-ground is worse than either side of the proposition.
Perhaps I am wrong. However, it is still good to know why we include this information in our emails. Is it simply a case of "we have this information, why not just include it?" or is it something to check against transaction logs? Perhaps a "distributed" way to add audit records of who logged on to the mail server? There had to be some reason why they included it, right?
[0] http://hanselminutes.com/396/bugs-considered-harmful-with-do...
The following Postfix configuration addresses this for me:
$ grep header_checks /etc/postfix/main.cf
header_checks = pcre:/etc/postfix/db/header_checks.pcre
$ cat /etc/postfix/db/header_checks.pcre
/^Received: .*\(Authenticated sender:.*/ IGNORE
/^Received: by my\.mailserver\.net .*from userid [0-9]+\)/ IGNOREAll SMTP headers can be spoofed with ease. Often a custom header like "X-Real-IP" will be used to send along the client's true IP; a spammer wishing to bypass filters could simply pass a phony X-Real-IP header with whatever they want, so checking against this is futile.
Or is this really only marketing?