Email tapping by ISPs, forwarder addresses, and crypto proxies

Thomas Shaddack shaddack at
Tue Jul 6 17:01:17 PDT 2004

On Tue, 6 Jul 2004, Hal Finney wrote:

> > There are various email forwarding services, which are nothing more than a 
> > SMTP server with pairs of recipient at -- 
> > recipient at
> Right, mostly for use as disposable email addresses.  I've used
> spamgourmet to good effect, myself.

I wrote the patch for qmail's fastforward for similar purposes. Everything 
in the name that is beyond the specified wildcard is ignored when 
resolving the mail alias (but stays there for procmail processing). As 
added benefit, the addresses that receive spam can be used for teaching 

> > Messages in storage have much lower judicial protection than messages in 
> > transit. (This does not have much technical merit, in the current 
> > atmosphere of "damn the laws - there are terrorists around the corner", 
> > but can be seen as a nice little potential benefit.)
> One thing I haven't understood in all the commentary is whether law
> enforcment still needs a warrant to access emails stored in this way.
> Apparently the ISP can read them without any notice or liability, but
> what about the police?

Let's expect them so as well. The ISP can hand them over to the police 
anyway, like a nosy neighbour fink finding your grass stash.

> Also, what if you run your own mail spool, so the email is never stored
> at the ISP, it just passes through the routers controlled by the ISP
> (just like it passed through a dozen other routers on the internet).
> Does this give the ISP (and all the other router owners) the right to
> read your email?  I don't think so, it seems like that would definitely
> cross over the line from "mail in storage" to "mail in transit".

If it passes through their SMTP servers, I am not sure. If it goes only 
through their routers, I'd think it's definitely in transit.

> > There can be an easy enhancement for such forwarder service; GnuPG proxy. 
> > Every email that arrives to the forwarder address, before it is forwarded 
> > to the real recipient, is piped through a GnuPG script; the recipient has 
> > then to upload his public key during the registration of the target 
> > address, otherwise the function is the same.
> That's a great idea.  You'd want to be sure and encrypt the whole message
> including headers, and make the whole thing an encrypted attachment.
> Has the added side benefits of compressing the email, and you could even
> have the server do some spam filtering.

The original idea I based it on was encrypting everything including the 
headers on the sender, then decrypting it on the receiver relay, and 
adding the data about the decryption of the message into the headers in 
some unspoofable way (eg. if the headers were there already when the 
message arrived to the decrypting script, prepend X- to them - not 
really bulletproof but rather decent).

> > For added benefit, the forwarder should support SMTP/TLS (STARTTLS) 
> > extension, so the connections from security-minded owners of their own 
> > mailservers would be protected.
> STARTTLS support at the proxy should pretty much go without saying these
> days, so you might as well do it, but if you're already PGP encrypting
> then it's not adding that much security.  Well, maybe it does, but you're
> talking about a different threat.

It hides the fact encrypted comm is in use. Which may be handy on its own.

> For the problem that ISPs can read your email in storage, STARTLS 
> doesn't help much because it will only protect the email until it gets 
> to your local ISP, who will store your email for you and can read it 
> then (which is where the PGP comes in).

That's true. But it protects the data in transit nearly for free.

> Where STARTTLS would help is with power users who run their own mail
> servers.  But those people don't suffer from the problem we are talking
> about here, legal access to the email by the ISP (I think, see above).
> Nevertheless a mail-receiving proxy that uses STARTTLS connections to
> power users would be kind of cool because it would keep anyone local
> from knowing anything about the incoming mail.  Hopefully, STARTTLS will
> eventually become so widespread that this functionality will be redundant,
> but we are not there yet.

STARTTLS is by far not widespread. Few people use it, including the 
knowledgeable ones. :(((

> > (I know, auto-decryption is dangerous, but we now talk about the system 
> > for one's grandma, transparent to use.)
> Absolutely, look at the threat model.  You're not worried about someone
> breaking into your computer, you're worried about your ISP legally
> reading your email.  To address this threat, auto-decryption is a
> perfect solution.

It's always better to select overly restrictive threat model and then 
loose it when necessary, than the other way. An omission then results in 
more work instead of a security hole.

> He would configure his mailer to connect to localhost:4949 or whatever, 
> just like any other POP server.

With a local SMTP server, you can run such service as a daemon (or from 
cron) with function similar to fetchmail. Whatever is downloaded is fed to 
local mail delivery.

> The service would periodically go out and poll for email using the fancy 
> protocol, but then it would make it available to the local mail agent in 
> perfectly vanilla form.  The point is that this architecture hides the 
> complexity and makes it transparent for end users to use arbitrarily 
> complex crypto for mail receiving.  Something similar would be perfect 
> for your idea.

Proxies rock :)

I designed the idea with procmail and sendmail/qmail in mind. Didn't think 
much about Windows, as it's a pain to develop for them, but it shouldn't 
be too difficult to port it.

> > What do you think about this scheme?
> I think it's a great idea.  Of course as you say there is still the
> problem that the forwarding server could read your email, so you have
> only moved the threat from the ISP to another operator.

That's very true, however there can be operators you trust more than your 
ISP, eg. a group of friends running such forwarder offshore.

Especially if your ISP is untrustful or restrictive, eg. an university, a 
bigger corporation, or anything with a potential for nosing or censoring.

> The difference I suppose is that the forwarder would be selling privacy 
> services, hence different ones would compete to get a good reputation.  
> Any cheating might be detected by insider whistle blowers or perhaps 
> some kind of audit.

I didn't think about it as a sellable thing, though it's definitely 
possible. Instead of several paid services I thought more along the lines 
of thousands little servers for a handful of people each.

But it's pretty likely to be marketable. The key here is low resource 
requirements and low cost of operation - which a combo of a small SMTP 
server and procmail could meet pretty well.

More information about the cypherpunks-legacy mailing list