Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Email peering (Was: Economics of SPAM [Was: Micorsoft's Sender IDAuthentication......?]

  • From: Steven M. Bellovin
  • Date: Thu Jun 16 14:45:42 2005

In message <Pine.WNT.4.63.0506161337060.3276@jvc>, Todd Vierling writes:
>
>On Thu, 16 Jun 2005, Michael.Dillon@btradianz.com wrote:
>
>> > The proponents of "email peering" typically want to switch from the
>> > current model (millions of independant email servers) to a different
>> > model, with only a few big actors.
>>
>> I don't know who these proponents are, that you refer to. However,
>> in my earlier message I quite clearly described a model that allows
>> for millions of independent email servers organized in roughly
>> 3 levels of hierarchy and I described how it could be done so
>> that email peering IS NOT LIMITED to a few big actors.
>
>You mean like ucbvax?  (If you don't know what that means, you have no
>business talking about Internet e-mail.)
>
>Seriously, the mess you're proposing was already done.  It didn't scale.
>Taken from http://en.wikipedia.org/wiki/UUCP :
>
>=====
>  People often published compound bang addresses using the { } convention
>  (see glob) to give paths from several big machines, in the hopes that
>  one's correspondent might be able to get mail to one of them reliably
>  (example: ...!{seismo, ut-sally, ihnp4}!rice!beta!gamma!me). Bang paths of
>  8 to 10 hops were not uncommon in 1981.
>=====
>
>You're lost in the past.  Study history and stop repeating it back to us.
>

Although I agree that email peering is a seriously bad idea, I don't 
think that the analogy to uucp is correct.  Uucp users had to know 
explicit paths; today, we'd use routing protocols.  (I tried the 
equivalent for uucp back in 1982, but the map data -- think routing
registry -- was of too low quality.  Hmm -- today's routing registry 
isn't very complete, either.  But we have BGP, which uucp didn't have.)

Uucp also relied on relative names, rather than absolute domain names.  
This scheme would retain domain names.

The other big difference from early uucp is the presence of business 
agreements.  A lot of uucp email (and netnews) traffic was, shall we 
say, not always carried in accord with corporate goals.  People today 
are accustomed to paying for basic Internet services such as access; 
that was rarely possible in uucp days.  (For more details, see
http://www.cs.columbia.edu/~smb/papers/pathalias.paper.pdf by myself 
and Peter Honeyman, published in 1986.)

There are, however, three very big problems.  First, it forces people to 
pay for services that they don't pay for today.  I'm not talking about 
Jo[e] Consumer, I'm talking about a modest-sized business or ISP.  They 
have the ability to deliver email today and will resist being told to 
pay.  Nor will paying stop them from receiving spam -- at best, they 
see less spam if *you* pay.  In other words, the incentives are 
backwards.

A second problem is that multi-hop email seriously reduces reliability. 
That is indeed a lesson we learned in uucp days.  It's mentioned in the 
paper; it was present even more explicitly in the original pathalias 
software package I released.

But the biggest issue is control: if you have to pass email through a 
site, that site controls whether or not it can be delivered.  Yes, that 
might stop (some) spam.  Might it also stop unpopular political ideas, 
or provide a facility for government (or whomever) to profile you?  
Maybe my upstream email provider, 3 hops away, is Google; does that 
mean I've consented to let Google associate keywords in my email with 
my email address?  (I won't reprise the debate about gmail and privacy, 
save to note that as of this morning, the Google web page on *sender* 
privacy still doesn't address that point.)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb






Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.