mail-ng
[Top] [All Lists]

Fwd: RE: Delete all and replace is practical

2004-01-31 17:14:31

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(_at_)nma(_dot_)com 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(_at_)mail(_dot_)imc(_dot_)org>
Delivered-To: steflist(_at_)vrx(_dot_)net
Received: from above.proper.com (above.proper.com [208.184.76.39])
      by ns1.vrx.net (Postfix) with ESMTP id 203E7D3B4
      for <Steflist(_at_)thor(_dot_)nma(_dot_)com>; 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(_at_)above(_dot_)proper(_dot_)com>; Sat, 31 Jan 2004 
13:27:21 -0800 (PST)
      (envelope-from owner-mail-ng(_at_)mail(_dot_)imc(_dot_)org)
Received: (from majordom(_at_)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(_at_)mail(_dot_)imc(_dot_)org 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(_at_)imc(_dot_)org>; Sat, 31 Jan 2004 13:27:19 -0800 (PST)
      (envelope-from pbaker(_at_)verisign(_dot_)com)
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(_at_)mou1wnexm02(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
From: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>
To: "'Einar Stefferud'" <Stef(_at_)nma(_dot_)com>,
      Chuq Von Rospach <chuqui(_at_)plaidworks(_dot_)com>
Cc: "Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com>,
      Chuq Von Rospach <chuqui(_at_)plaidworks(_dot_)com>, 
mail-ng(_at_)imc(_dot_)org
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(_at_)mail(_dot_)imc(_dot_)org
Precedence: bulk
List-Archive: <http://www.imc.org/mail-ng/mail-archive/>
List-Unsubscribe: <mailto:mail-ng-request(_at_)imc(_dot_)org?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.


<Prev in Thread] Current Thread [Next in Thread>