The Grumpy Troll

Ramblings of a grumpy troll.

How private is your mailing-list subscriber list?

If you have a supposedly private mailing-list, you may be surprised how much information about your subscriber-list may be disclosed to anyone who can post, by the operators of the mail-systems of those who subscribe. Not email addresses, but counts of subscribers at gmail, indications of forwarding services used, and more.

Similarly, if you're hiding behind a mail-forwarding service but use one of the big freemail providers, someone who wants to may be able to identify which provider you're using. This isn't much, but if you're a dissident trying to hide from oppressive authorities, their being able to find out that you use a provider who will pay attention to their sub-poenas may not be what you wanted.

To be able to track reputation in email, DKIM can be used by those who send mail to provably tie an identity to the mail other than “the IP address you happened to receive it from”. See Email Cooperation (2010/04) for some background.

A domain owner can choose to advertise a policy which says "if you receive email purporting to be from me and it's not signed, it's fake; so reject it". The main mechanism most are familiar with for this is ADSP; RFC 5616, "Author Domain Signing Practices".

This grumpy one recently chose to investigate DMARC,“ Domain-based Message Authentication, Reporting & Conformance”. It's an alternative to ADSP with a number of very useful features, especially for those who are trying to gradually improve the ability of others to verify the authenticity of mail coming from them. It lets an ADSP-like policy be published at an “organisational domain” level such as "example.com" which establishes different behaviour for handling "notifications.example.com" than for "example.com" in one record. DMARC uses TXT records in DNS, much as does ADSP.

DMARC also lets mail senders sign up for reports on the analysis of the mails received; a DMARC verifying recipient can choose to send reports to an end-point specified in the DMARC record. They're not obliged to, it's helpful behaviour. Friendly, cooperative, useful for debugging. It's also a privacy violation and one for which the impact is likely unintended and not well understood. There's no malice or evilness here, but there is a problem caused by unintended consequences.

So this grumpy troll published a DMARC record which said that reports should be sent by email to the usual postmaster address for the troll's main domain. A little later, an email was sent to a public mailing-list with a wide distribution. It happens that it was the exim-users mailing-list. Please note that I do have administrative access to that mailing-list so could retrieve the subscriber list anyway, but that isn't an issue here: anyone sending to the mailing-list can get the same information.

The next day, a friendly report arrived from Google, detailing the exact count of subscribers to exim-users who are subscribed with their Google-hosted email addresses and received the mail directly from the mail-system which handles mail for exim.org. It also broke down the number of mails coming from all sorts of other IP addresses, with counts of 1 message received, showing that it was forwarded, was a mailing-list, often identified as exim-users and with information about the SPF records used to allow the mail to be accepted, letting me know the domain-name used by the forwarding service.

The same would happen if I sent the mail to a non-list forwarder, which someone is maintaining as a shield. If the email were forwarded onto Gmail, I'd get a report letting me know. I might not know the email address used, but I would then know who to serve a sub-poena to.

DMARC has the potential to be so awesome. It could probably be fixed. But it needs to have a policy of “if the signing domain for whom we're considering generating a report is not the domain of the detected mailing-list, roll everything up and hide the counts, merely note that messages were received; if it clearly came via a forwarder, do not list it at all”. This reduces the engineering value of the reports, but seems to be necessary.

-The worried grumpy troll.

Comments

Phil P
For clarity: if you are in an oppressive nation (and I don't count the USA) then Gmail is probably the best choice of mail provider for you, with very few commercial services being as good.

HTTPS-only, two-factor account authentication, HSTS with certificate pinning; at this point, Gmail is ahead of dedicated IMAP clients unless they're using mandatory certificate-based authentication with exceptionally clueful users to manage the trusted CA list. Plus a first class security department managing intrusion detection and a business culture which is prepared to make world headlines and pull services from a country if needed.

As a former Google employee, I remain proud of Gmail.

What this problem means is that at present, if you have a very private forwarder which you expected to hide even the domain behind it, then the forwarder probably needs to strip DKIM keys entirely, since even without DMARC, the verifier will look up the DKIM key in DNS and an inquisitor can find where the mail went. If you run a very private mailing-list which only delivers outbound over SMTP/TLS and you cache known certificates of SMTP MX servers to avoid man-in-the-middle attacks, you might want to verify DKIM, include the verification information in a header, change the From: header to be from a list address and then DKIM sign yourself and publish a DMARC record, just in case a subscriber is leaking to where they shouldn't be, so you can smack them.

There are subtleties to the dimensions of the data leaked here, compared to what would be leaked anyway, which makes it hard to avoid misleading sound-bites. I might be guilty of this myself, but I think everything I said was accurate and honest, while capturing why folks might want to pay attention and read carefully.
Categories: email dkim dmarc privacy