[e2e] Fwd: Camel's nose in the tent

[David P. Reed]

Verizon DSL has instituted recently an official policy of blocking all 
email that a user sends that does not have a line in the header that says 
it is sent from verizon.net or bellatlantic.net.  This is apparently 
because they want to "stop spam", but has a number of additional effects 
(such as creating a "walled garden" for email origination).

It's yet another case where a violation of the "end-to-end" design 
principle that was embodied in the original SMTP is being accepted and 
breaking the Internet's ability to innovate, and also attacking free speech 
(I realize that not everyone in the USA or world believes in free speech, 
but innovation at the edges is a value that the technical community also 
shares, whatever their political persuasion).

I wrote the following to Farber's IP list, hoping to encourage some 
effective response against ISPs who would otherwise adopt this technology 
(know who the middlebox vendors for this are?).  Any thought on who in the 
IETF/IAB can make a statement on not violating layers like this?  The free 
speech issue is well covered, but the innovation-blocking issue is 
something the technical community ought to take an independent interest 
in.  Perhaps the problem is that the technical community is now too tied to 
income sources that don't want to offend carriers who want to mess up the 
architecture?

Scary.


>Date: Fri, 10 Aug 2001 11:00:56 -0400
>To: farber at cis.upenn.edu, ip-sub-1 at majordomo.pobox.com
>From: "David P. Reed" <dpreed at reed.com>
>Subject: Camel's nose in the tent
>
>Manny's observations about the "return address block" is different than 
>the port 80 issue (they have some kind of argument to block because the 
>presumption that 80 means "server" is accepted by people, even though 
>technically not true!)
>
>1. There has never been a requirement that the contents of an SMTP 
>"message" be formatted in any particular way.  The SMTP network is 
>supposed to route messages based entirely on information exchanged in the 
>protocols, not the headers.  Thus the Verizon policy is a technical 
>violation of the SMTP protocol standard, and has impacts such as not 
>allowing innovation in the structure of the headers that used to be only a 
>peer-level agreement between client email programs, not a function of the 
>SMTP service.  Thus, one could use SMTP in the past to transmit fully 
>encrypted messages.
>
>2. This is the "nose under the tent" for transport services to start 
>inspecting message content.  By reading headers of messages and assigning 
>meaning to them, providers are starting down a slippery slope to 
>interfering with speech.  My instructions to a user agent on the receiver 
>machine about who sent the message can be viewed as my business (perhaps I 
>want anonymity by using a pen name?).  But worse, this sets a precedent 
>for doing things like, for example, inspecting the subject: field for 
>obnoxious words that might offend the recipient, etc.  While AOL has in 
>the past been held to a standard that they are liable for the obnoxious 
>behavior of their users, this has been partly due to the idea that AOL 
>contracted with users to "read their mail" for protection.
>
>If this process of intruding inside the envelope to read the mail contents 
>is not resisted vigorously, we will suffer in two ways, equally important:
>
>Innovation in email content protocols will be held hostage to Verizon and 
>its kin, who will block innovations that do not serve their goals.  This 
>is the proper domain for IETF and the IAB to speak strongly and with one 
>voice on this issue.
>
>The right to free speech will be slowly eroded, as Verizon and its kin are 
>held to be responsible for the content of messages sent.
>
>At the moment, I am freely sending my mail through AT&T's SMTP servers, 
>despite the fact that my email is received at Interland.  Should AT&T 
>adopt the Verizon policy, my speech will be somewhat silenced.
>
>- David
>--------------------------------------------
>WWW Page: http://www.reed.com/dpr.html

- David
--------------------------------------------
WWW Page: http://www.reed.com/dpr.html