Samuel Pigg <b44729@achilles.ctd.anl.gov> wrote:
Actually what I was proposing was the direct usage of SMTP itself rather than going through the host machine's mail system. As anyone can do it, it would help with the usage of student accounts as remailers. And with direct SMTP (socket connections to port 25 of the receiving machine) you have some control over the header information that is generated.
The protocol is outlined in RFC821 if anyone wants to look at it.
The trouble is, one side (the receiver) is still keeping logs, since only sendmail (or some other root process doing the same job) can bind to port 25. On most machines, that means logs. There are plenty of ports over 1000 that user processes can bind to, and that cypherpunk remailers can support, if we want to go that way. I think it's worth thinking about. (This is in addition to receiving mail delivered normally to their e-mail adresses, probably either by port-25/sendmail or uucp). We could start by having cypherpunk remailers talk to _each_other_ on an agreed- upon, unlogged port, using RFC 821 protocol. Final hops to non-remailer addresses will have to be handled on port 25, of course, but within the remailer web we can avoid sendmail logs entirely. After that's implemented, we could talk about using a different protocol. A new protocol is probably the cleanest way to solve the problem of traffic analysis of messages addressed with encrypted address blocks. The best way to get security in a remailer chain is to nest your encryption, so only one layer gets peeled off in each remailer hop. That isn't possible with encrypted address blocks, since the sender will only know the address (and public key) of the first remailer in the chain. All hops after the first one must send the same message out as they got in, with just a layer off the encrypted address block. But if remailers talked to each other by first doing RSA-signed Diffie- Hellman key exchange, then encrypting the traffic, a packet snooper wouldn't be able to correlate incoming and outgoing messages. The latter is one of the "expensive" attacks, I think, and should be thought about after we make sure the logs aren't being kept. Thoughts? Joe (they're trying to pry me away from my NeXT, so don't reply directly to the From: line; use jthomas@mitre.org)