User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3 When a mail is viewed in plaintext format, seamonkey will generate DNS requests for every url from the mail text. These DNS queries can be used to find out which spam mails are really viewed. Please can someone try to reproduce this? I would be shocked if seamonkey gives data to spammers that easily! Reproducible: Always Steps to Reproduce: 1. Trace your DNS request, e.g. tcpdump -i eth0 -nn -vv port 53 2. Send yourself mail: # nc -vn mailserver 25 (UNKNOWN) mailserver 25 (smtp) open 220 mailserver ESMTP Exim EHLO localhost 250 OK MAIL FROM: email@example.com 250 OK RCPT TO: firstname.lastname@example.org 250 Accepted DATA 354 Enter message, ending with "." on a line by itself Subject: Test Test content: (http://me-at-myhost-net.verifyaddr.org) . 250 OK id=1LofXY-000120-TW QUIT Actual Results: 15:13:43.506648 IP 192.168.0.1.39340 > 192.168.0.254.53: 32756+ A? me-at-myhost-net.verifyaddr.org. (50) 15:13:43.535984 IP 192.168.0.254.53 > 192.168.0.1.39340: 32756 NXDomain 0/1/0 (113) Could it be, that such a mechanism is already used in the wild? It seems that I receive more spam mails while I'm online then in the remaining time of the day, but I've never done a statistical test on this hypothesis (so it could be that just more spam-bots are online while I'm online).
When SeaMonkey creates a DNS request, it asks your local nameserver (usually that from your provider). If the provider doesn't know it, it goes to another level until somewhere the IP to that address is found. So a spammer only would know that someone read the mail, when he has its own DNS nameserver running, gave your spam mail a unique domain name and no other nameserver in the chain knows that domain already. In my opinion a very unlikely and not realistic way to get data about spammails.
halfdog, Does this happen with Thunderbird too ? Bruno, Yet, why is DNS used while viewing a plain-text message ? Would there be a preference to disable this behavior ?
Version: unspecified → Trunk
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: MailNews: General → Security
Ever confirmed: true
Product: SeaMonkey → MailNews Core
QA Contact: mail → security
I can confirm this for recent trunk, both for SeaMonkey and Thunderbird. Using tcdump against my local dns server at 192.168.1.1:53 (tcpdump -vvi eth0 host 192.168.1.1 and port 53) when looking at a plaintext message containing the potential url http://what.about.sub.domains.in.urls/I.wonder results in 18:22:56.493287 IP (tos 0x0, ttl 64, id 32190, offset 0, flags [DF], proto UDP (17), length 75) aupertir.local.40923 > 192.168.1.1.domain: [bad udp cksum e0c2!] 3223+ A? what.about.sub.domains.in.com. (47) which asks DNS for an IP address (A record) for the domain name what.about.sub.domains.in.urls. Thus spammers and other interested parties can set up their own DNS server and track reading of their spam mails. Given that they can enumerate their spam mails, they can easily track down the corresponding (range of) email addresses. SeaMonkey 1.1.16 etc. are *not* affected.
Erm, cut & paste error. :-( ... results in 18:36:59.719321 IP (tos 0x0, ttl 64, id 45140, offset 0, flags [DF], proto UDP (17), length 76) aupertir.local.47246 > 192.168.1.1.domain: [bad udp cksum df1e!] 8911+ A? what.about.sub.domains.in.urls. (48)
Summary: Seamonkey sends DNS queries when viewing mail, could be used to verify existence of mail accounts → Seamonkey/Thunderbird send DNS queries when viewing mail, could be used to verify existence of mail accounts
Seems to be fallout from bug 453403. Setting network.dns.disablePrefetch to true does stop the DNS querying, but turning this off globally is not helpful for SeaMonkey - reading mail should just not force a DNS query, even if using a <browser> element for display...
Does adding: <meta http-equiv="x-dns-prefetch-control" content="off"> to the HTML mailnews generates in plain-text mode help?
(In reply to comment #6) > Does adding: > > <meta http-equiv="x-dns-prefetch-control" content="off"> > > to the HTML mailnews generates in plain-text mode help? Yes (at nsMimeHtmlEmitter.cpp#433). But this doesn't even help against HTML mails with <meta http-equiv="x-dns-prefetch-control" content="on"> in their body(!)... The idea of DNS prefetching is generally undesirable for mail, imo, since mail is far more privacy-critical than mere browsing. BTW: I noticed another oddity: Given dns prefetching is on and a plaintext mail with http://what1.about.sub.domains.in.urls/I.wonder http://what2.about.sub.domains.in.urls/I.wonder http://what3.about.sub-domains-in-urls.com/I.wonder http://what4.about.sub.domains.in.urls/I.wonder.html http://what5.about.sub-domains-in-urls.com/I.wonder.html I only get dns hits for what1-3, but not for what4-5...
> But this doesn't even help against HTML mails with <meta > http-equiv="x-dns-prefetch-control" content="on"> in their body(!)... If it's just HTML mail, that doesn't matter (because it's loading images and such anyway), no? If it's the "simple html" mode where we block remote image loads, then we should be stripping that out... For plaintext it's not an issue. > The idea of DNS prefetching is generally undesirable for mail, imo I agree; the question is whether we need a change to core Gecko to handle this somehow (with resulting performance costs all around, almost certainly) or whether the existing infrastructure we have can suffice. If the former, then we need a core bug with some blocking1.9.1 flags on it.
(In reply to comment #8) > If it's just HTML mail, that doesn't matter (because it's loading images and > such anyway), no? I can turn off loading remote content via mailnews.message_display.disable_remote_image - but this has no influence on dns prefetching. I currently can't turn off dns prefetching for mail alone. > If it's the "simple html" mode where we block remote image > loads, then we should be stripping that out... Yes, dns prefetching occurs for both original HTML and simple HTML. > For plaintext it's not an issue. True, given the <meta>. (And, at least, the network.dns.disablePrefetch has priority over the <meta>.)
> mailnews.message_display.disable_remote_image Ah, we have a separate setting for that from the "Simple HTML" setting? OK. If the existing <meta> setup doesn't work for you, then we need more core infrastructure here; I believe that right now the only times we avoid preloading is from https: pages and via the <meta> tag. We could either add docshell type checks here or change the check for https to treat mail as a "secure" context or various other things... but we need a bug tracking it and blocking 1.9.1 so we make sure it actually happens.
bienvenu feels it's a blocker. Can someone who understands the Core bug file it and nominate it for 1.9.1?
Thunderbird might be able to get away with setting network.dns.disablePrefetch
Filed bug 492196.
OK, the change I made in bug 492196 makes DNS prefetch default to off in TYPE_MAIL and TYPE_EDITOR docshells. It's now configurable for all docshells, with child shells inheriting the parent shell value by default. Someone with more mailnews clue than I should check what else remains to be done here for SM and tbird.
Looks good - I couldn't reproduce with any of my testcases.
Is this all fixed?
My recollection of the APP_TYPE_MAIL stuff is that it applies to all docshells in the mail window, which means that while the security bug should be fixed, it has come at a cost of turning off DNS prefetching in web content tabs as well. Resetting this bug to UNCONFIRMED, as we should have someone verify that. Whether or not that's the case, my reading is that bz's patch should have made the privacy issue go away, so I think this bug wants to be resolved as a DUP of bug 492196. If my understanding is correct, we also want a new bug to be filed about the DNS prefetching in web content tabs in Thunderbird. bz/Standard8, can you confirm or deny my understanding?
Status: NEW → UNCONFIRMED
Ever confirmed: false
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
> My recollection of the APP_TYPE_MAIL stuff is that it applies to all docshells > in the mail window That recollection is incorrect. The APP_TYPE_* stuff is not inherited; it only applies to the docshell it was explicitly set for. Now the DNS prefetch value _is_ inherited, so any descendants of an APP_TYPE_MAIL docshell will default to having it off per bug 492196. I don't know which docshell in mail has the APP_TYPE_MAIL set, offhand.
So can we mark this fixed, and get a new bug for enabling dns prefetching in thunderbird web content, if needed?
Whiteboard: [fixed by bug 492196]
The additional fixes done in bug 544745 now mean this is fixed as well (and there are test cases confirming the fix).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.