Au Revior, SMTP

With AOL and Earthlink now blocking all SMTP access from IP addresses deemed residential, a precedent has been set, and it’s not a good one. This blocking doesn’t affect every ComCast/RoadRunner/etc customer, but it does affect those that run their own mailservers, such as yours truly. I will admit that the loss of my ability to email users@aol.com isn’t going to keep me up at night, but the idea that a large entity can unilaterally decide to deny their millions of customers the ability to receive mail from a certain segment of the Internet is chilling.

The rationale behind this decision is to limit the amount of spam AOL and Earthlink receive from DSL and cable-based systems. While it’s certainly the case that there are more than a few open relays on residential broadband circuits, there are also more than a few open relays in Japan and Korea, but they don’t seem to be blocking SMTP access from netblocks in Asia.

The simple solution for some users will be to relay all their mail through their providers mailservers. This isn’t feasible for all, however, since providers such as Verizon will not relay mail from any domain other than verizon.com, regardless of the originating IP address. If you’re running a domain on your broadband circuit, you’re off the air as far as AOL and Earthlink are concerned. Especially concerning are the number of businesses that have cable and DSL broadband. Their mailservers are blocked as well, since they have static IP addresses in the “residential” netblocks. Note that AOL and Earthlink customers didn’t have a say in this; it was implemented without fanfare, and without any form of warning or announcement.

This is a significant problem.

In addition to the above, AOL is also bouncing email to postmaster@aol.com. This is also a really unfortunate decision. As RFC2821 section 4.5.1 – Minimum Implementation says:

Any system that includes an SMTP server supporting mail relaying or delivery MUST support the reserved mailbox “postmaster” as a case-insensitive local name. This postmaster address is not strictly necessary if the server always returns 554 on connection opening (as described in section 3.1). The requirement to accept mail for postmaster implies that RCPT commands which specify a mailbox for postmaster at any of the domains for which the SMTP server provides mail service, as well as the special case of “RCPT TO:” (with no domain specification), MUST be supported.

SMTP systems are expected to make every reasonable effort to accept mail directed to Postmaster from any other system on the Internet. In extreme cases –such as to contain a denial of service attack or other breach of security– an SMTP server may block mail directed to Postmaster. However, such arrangements SHOULD be narrowly tailored so as to avoid blocking messages which are not part of such attacks.

An RFC is exactly that; a Request for Comments. Internet standards aren’t enforced as law, nor are there any direct punishments for violation of an RFC (some will argue that there should be, but that’s another diatribe). RFC’s are only useful if everyone plays by the rules. Without this, there would be no such thing as integration. Think of the screwdriver. Once there were dozens of screwdriver types, all incompatible with each other. Finally, it was boiled down to flathead and Phillips, with a nod to Torx, but the overwhelming majority of screws in the world fall into one of two categories, and everyone has a screwdriver that will work. If suddenly every ISP or email provider decided that they were going to block email from a large portion of the Internet, email would quickly become useless, since the basis for email communications is “we can get there from here”. Once that proves unreliable, then the medium loses value immensely.

When the SMTP RFCs were originally written, and even to fairly recent additions and extensions, spam wasn’t a serious problem. The original goal of SMTP was to provide a common framework for all mail transfer agents to use when distributing email throughout the Internet. Functionality was an imperative, selective use of the protocol wasn’t a glimmer in anyone’s eye. Since then, spam has become a serious problem. Take jpj.net, for instance. the core mailserver runs SpamAssassin, which truly is a savior of sanity. While spamassassin is great, the amount of spam it catches for a relatively small overall mail volume is staggering. Estimates on total Internet spam volume range from 10% to 50%. jpj.net is right in the middle at about 30%. Something needs to be done.

That something might be the death of SMTP, or at least a major reworking. If all mailservers were forced to present valid (not necessarily signed) certificates when delivering mail, there might be a bit more accountability available. Since anyone can self-sign a certificate with completely erroneous data, perhaps an “Mail Server License” is another variation, where a signed certificate is free if you validate the server and the administrator. Another idea might be a DNS-based valid server clearing house, or something akin to WHOIS, which would contain relevant information about a mailserver. If that mailserver is registered, then other participating mailservers will accept mail from that server, regardless of it’s physical location. This turns the concept of email as an open system on it’s head, and turns the delivery of email into whitelisting. Believe me, I wish I wasn’t talking about this, but it’s a rather tough nut to crack.

Regardless, in the “Wild West” of the Internet these days (which is a far cry from the “Wild West” of the mid nineties), where corporations make technical decisions based solely on politics and lawyers’ advice, change must be in the wind if we’re to avoid a complete fracture of the Internet’s original killer app, the simple email.