Fwd: RE: Delete all and replace is practical

[Einar Stefferud <Stef@xxxxxxx>]

Hi Phil -- the days of endless relaying are pretty much in the past  
With better IP connectivity of the net, most mail is delivered directly 
from posting host to maildrop host.  In my own case, I insert an extra 
hop with an MX for incoming mail to stef@xxxxxxx for local reasons. 

Looking at the hops for your message between you and me, after initial posting 
there are 2 hops inside VeriSign and one hop to IMC, two hops inside IMC's listserver, and one hop to my Maildrop server. 

I do not attribute all these hops to bad system design, but instead to the 
functionality required for mailing list handling, plus some unexplained 
hops inside VERISIGN. 

The need for extra hops has more to do with functionality demands/requirements 
of various business structures, which are not the fault of EMail design. 

But, perhaps I am missing some needed information.

Cheers...\Stef


>Return-Path: <owner-mail-ng@xxxxxxxxxxxx>
>Delivered-To: steflist@xxxxxxx
>Received: from above.proper.com (above.proper.com [208.184.76.39])
>	by ns1.vrx.net (Postfix) with ESMTP id 203E7D3B4
>	for <Steflist@xxxxxxxxxxxx>; Sat, 31 Jan 2004 17:03:01 -0500 (EST)
>Received: from above.proper.com (localhost [127.0.0.1])
>	by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VLRLi2094640
>	for <mail-ng-skb@xxxxxxxxxxxxxxxx>; Sat, 31 Jan 2004 13:27:21 -0800 (PST)
>	(envelope-from owner-mail-ng@xxxxxxxxxxxx)
>Received: (from majordom@localhost)
>	by above.proper.com (8.12.11/8.12.9/Submit) id i0VLRLPh094639
>	for mail-ng-skb; Sat, 31 Jan 2004 13:27:21 -0800 (PST)
>X-Authentication-Warning: above.proper.com: majordom set sender to owner-mail-ng@xxxxxxxxxxxx using -f
>Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71])
>	by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VLRJLc094633
>	for <mail-ng@xxxxxxx>; Sat, 31 Jan 2004 13:27:19 -0800 (PST)
>	(envelope-from pbaker@xxxxxxxxxxxx)
>Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53])
>        by pigeon.verisign.com (8.12.10/) with ESMTP id i0VLRLTs025408;
>        Sat, 31 Jan 2004 13:27:21 -0800 (PST)
>Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19)
>	id <D4TK5KFQ>; Sat, 31 Jan 2004 13:27:21 -0800
>Message-ID: <2A1D4C86842EE14CA9BC80474919782E011133EA@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
>From: "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>
>To: "'Einar Stefferud'" <Stef@xxxxxxx>,
>	Chuq Von Rospach <chuqui@xxxxxxxxxxxxxx>
>Cc: "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>,
>	Chuq Von Rospach <chuqui@xxxxxxxxxxxxxx>, mail-ng@xxxxxxx
>Subject: RE: Delete all and replace is practical
>Date: Sat, 31 Jan 2004 13:27:17 -0800
>MIME-Version: 1.0
>X-Mailer: Internet Mail Service (5.5.2653.19)
>Content-Type: text/plain
>Sender: owner-mail-ng@xxxxxxxxxxxx
>Precedence: bulk
>List-Archive: <http://www.imc.org/mail-ng/mail-archive/>
>List-Unsubscribe: <mailto:mail-ng-request@xxxxxxx?body=unsubscribe>
>List-ID: <mail-ng.imc.org>
>X-UIDL: <L"#!RGk!!o!H"!7o]!!
>
>
> > One of the nasty features of Gateways is that they are 
> > generally forced to 
> > lose information, just because some of it cannot be translated.  
>
>I'm not talking about gateways. I'm talking about protocol switching at the
>originating client.
>
>The problems of X.400 and Bitnet are not something I want to repeat. This is
>not the time to go back to to EBSIDC.  
>
>The core problem of email as far as I am concerned is the interminable
>forwarding problem. Each link the message gets sent over has a potential for
>failure.
>
>We are breaking something fundamental to the Internet model here, we are
>putting complexity in the core of the Internet. Worse, we are doing it
>without recognising what we are doing.
>
>I think there is certainly a case to be made for the three corner
>client-server-client model and even a case to be made for the
>client-server-server-client four corners model of messaging transfer. But I
>would like to get away from the email model where messages bounce aimlessly
>from server to server without a concrete idea of where they came from or
>where they are headed.