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@forwarder.com -- recipient@hiscurrentisp.com.
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 bogofilter.
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.