Project MAC, where we met S at MIT A the Software Arts building where we worked together T and the attic N where VisiCalc was written
Other writings on our personal sites:

RSS Feeds:



Comments from Frankston, Reed, and Friends

Tuesday, March 26, 2002

DPR at 11:35 AM [url]:

Holding our email hostage

OK, it's becoming clear to me that the spammers are winning. Not because of spam, but because of the responses from various ISPs to spammers, blackholers, and other warring parties. Just as terrorists win when they trigger a breakdown in the system, the spammers, through their unwitting agents and amplifiers, the blackhole vigilantes, seem to be on the verge of causing email providers to create larger and larger disconnects among us poor users.

I can't seem to avoid being an unwilling participant in this battle. As a systems designer, the mess all three sets of players are making appalls me. I guess that's what you get when people style themselves as warriors, rather than problem solvers. So here's an analysis from my point of view as an advanced email user and "protocol critic".

I hosted "reed.com" with Interland because I wanted a stable name for web and email. I pay them >$400/year for this. After some interaction with Interland customer support about the latest "spam blocking" requirements I have encountered from access providers, it seems that the only way I can send email "from reed.com" when I am connected through various dialup and hotel services (and perhaps eventually ATTBI.com) will be to use their "web interface".

Why is this?

Well, first of all, the email community has proposed that when you post mail for relay to someone not local to that SMTP server, you must a) authenticate yourself, and b) use a "return address" that matches that authenticated name. Some ISPs are already doing one or both of these things, unilaterally. ATTBI enforces (b) when you authenticate yourself via SSL, as preparation to a later plan where they will require (a) as well. So for authenticated senders, you must be "xxx@attbi.com" and certainly not "xxx@reed.com".

The email community is also encouraging all access providers (such as STSN in hotels) to firewall-block or firewall-intercept all attempts by transient users to connect to port 25 (SMTP) on hosts outside their network. This is because many spammers try to use dialup lines to conceal their identity, and because too many providers provide "open relays". I discovered a month ago that STSN, which provides high speed internet in hotels, is intercepting port 25 connections for all IP destinations, and directing them to STSN's server. The problem for STSN is that it doesn't support authentication, so if you have set up your computer to talk using SMTP AUTH standard authentication, your client rejects STSN's server as an alien, and won't send (properly, I might add, since STSN has no right to pretend to be who it is not! It acts like a standard "man in the middle attack").

Those who need to work around the "outbound port 25" blocking are encouraged to use either a) the SSL/TLS alternate SMTP port (465), or b) the obsolescent "SUBMIT Port" (587). Port 465 (smtps - secure SMTP) is, according to the IETF, no longer part of the acceptable standard - at the request of the "email community" (the relevant paragraph appears in various places where I researched this on Google) Eudora 5.1, and perhaps Outlook Express, support port 465. Now I understand why they do this - ports 465 and 587 are usually secured, so there are few or no "open relays" on those ports.

However, most mail server operators (such as Interland) don't support ports other than 25 (given that these seem to have been deprecated by the IETF, they have some justification!), and the ISPs that implement "outbound port 25" blocking tend not to provide a means to post email using a "from address" that doesn't correspond to the ID you are dialed up with. After all, if they are trying to block unauthenticated spam, they don't want to be the cause of the problem...

Well, so far, I've been able to find workarounds (mostly by finding and exploiting open relays that are at risk of being blackholed any day now).

But I'm worried that Interland is recommending that my only option for posting email from my reed.com is to use their "web-based" email interface (doing "reply-to-all" to mail I get in Eudora is not at all easy via the "web-based" interfaces, and I use PGP a lot, also not possible). Because by doing so, they are encouraging me to look for an alternative hosting service who can both host reed.com and allow me to post email "from reed.com" when dialed up as I travel. I represent the majority of their customers, I suspect - it's just that the majority may not travel. Of course, there are not a lot of hosting services that pride themselves on running "authenticated SMTP" just yet, so it is hard to find out if there is a reasonable alternative to Interland...

And I'm also worried that the email transport community and the access provider community has not spent a lot of time thinking through this problem - instead their responses seem to be knee-jerk capitulation to the "blackholers" who have no program, just vigilante attacks, as their goal.

At a philsophical level, the deep problem is that "my identity" (dpreed@reed.com) is fragmented into a set of pieces carved up by an industry structure that just has no coherent concept of identity. SMTP mail transport has no way to understand identity (and from the point of view of the end-to-end argument, it cannot possibly understand most of the issues of identity). Yet we try to delegate identity there, where various actors try to enforce rules that depend on understanding identity.

Any sensible design would be working hard on creating an identity system at the edges. It may be that the SMTP transport will self-destruct by failing to provide connectivity sufficient to be useful, in which case, the smart money would best be placed on providing an alternative, universal internet that doesn't try to understand identitiy at all, surrounded by better email clients that understand identity, because they deal directly with users and authenticate users on an end-to-end basis. It's easy to kill spam in such a system, and since the spam warriors are about to kill the present system, it'll have to be ready for the refugees.

For more, see the Archive.

© Copyright 2002-2008 by Daniel Bricklin, Bob Frankston, and David P. Reed
All Rights Reserved.

Comments to: webmaster at satn.org, danb at satn.org, bobf at satn.org, or dpreed at satn.org.

The weblog part of this web site is authored with Blogger.