Fwd: RE: Delete all and replace is practical
Einar Stefferud <[email protected]>
| Newsgroups | gmane.mail.ng |
|---|---|
| Message-ID | <v0422084fbc41f23e3014@[192.168.1.14]> |
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 [email protected] 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: <[email protected]> >Delivered-To: [email protected] >Received: from above.proper.com (above.proper.com [208.184.76.39]) > by ns1.vrx.net (Postfix) with ESMTP id 203E7D3B4 > for <[email protected]>; 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 <[email protected]>; Sat, 31 Jan 2004 13:27:21 -0800 (PST) > (envelope-from [email protected]) >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 [email protected] 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 <[email protected]>; Sat, 31 Jan 2004 13:27:19 -0800 (PST) > (envelope-from [email protected]) >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@mou1wnexm02.vcorp.ad.vrsn.com> >From: "Hallam-Baker, Phillip" <[email protected]> >To: "'Einar Stefferud'" <[email protected]>, > Chuq Von Rospach <[email protected]> >Cc: "Hallam-Baker, Phillip" <[email protected]>, > Chuq Von Rospach <[email protected]>, [email protected] >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: [email protected] >Precedence: bulk >List-Archive: <http://www.imc.org/mail-ng/mail-archive/> >List-Unsubscribe: <mailto:[email protected]?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.