Contact Info

(for those who care)

Instant Gratification   

Thu, 27 Jan 2005

Internet Mail 2000

Tim Bray writes about private RSS feeds which are remarkably similar to DJB’s writings on Internet Mail 2000. I was really excited about IM2000 before, but I didn’t really realize that RSS was taking us there one step at a time.

IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender’s responsibility.

Each message is stored under the sender’s disk quota at the sender’s ISP. ISPs accept messages only from authorized local users.

The sender’s ISP, rather than the receiver’s ISP, is the always-online post office from which the receiver picks up the message.

The message isn’t copied to a separate outgoing mail queue. The sender’s archive is the outgoing mail queue.

The message isn’t copied to the receiver’s ISP. All the receiver needs is a brief notification that a message is available.

After downloading a message from the sender’s ISP, the receiver can efficiently confirm success. The sender’s ISP can periodically retransmit notifications until it sees confirmation. The sender can check for confirmation. There’s no need for bounces.

Recipients can check on occasion for new messages in archives that interest them. There’s no need for mailing-list subscriptions.

The neat thing about IM2000 is that it “kills” spam. By leaving the message on a remote, required-to-be-always-on server until the user picks it up, it means zombie bots don’t really work as spam generators, and the person sending the mail (sending the mail notification message) must be responsible for “owning” that message until it is delivered. Basically putting mail transmission costs on the sender more-so than the receiver.

Let’s presume the worst possible spam attack on an IM2000 system. 1,000,000 bots, of which 80% of them are online all at the same time, each sending 1,000,000 notification messages to addresses harvested from the internet. Ouch. Anyway, since the message is traceable to an origin (no matter what that origin is), we are in a slightly better situation than before. It would be a fairly simple process to say: “Trash any messages that come from places without a reverse DNS to a legitimate domain name”. That means you can still run your own ~mail server~, but you have to buy a domain name for it (not too big of a deal) and keep it online all the time. Or contract with a hosting company to run your private mail-outgoing queues.

Then suppose that spammers buy domain names for each of their bots on a botnet (unlikely, I would hope). Costs have been raised, and then it might be possible to say: “We are suspicious of email notifications if your mail-server DNS isn’t at least 3 months old”.

Furthermore firewall at the ISP-level port 25 inbound (probably won’t end up being port 25, but just an example). Since “delivery” requires that a random PC on the internet connect to a random other PC on the internet, and we’ve stated that we’re willing to firewall customer PC’s from inbound requests, we’re doing pretty well. Would firewalling port 25 outbound have the same effect right now? I don’t know but I don’t think so. Firewalling 25 outbound means that your customers can’t send spam, but not that your customers can’t receive spam from compromised hosts in China, etc. (sorry, China. :^) Really it boils down to accountability by some single system for owning the delivery of a message.

08:38 CST | category / entries / links
permanent link | comments?

Like what you just read? Subscribe to a syndicated feed of my weblog, brought to you by the wonders of RSS.

Thanks for Visiting!