[Asrg] Re: Email service assumptions and making system-wide changes

Frank Ellermann <nobody@xyzzy.claranet.de> Thu, 19 January 2006 07:48 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzUWg-00027l-Lg; Thu, 19 Jan 2006 02:48:10 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzUWc-00026p-RG for asrg@megatron.ietf.org; Thu, 19 Jan 2006 02:48:07 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27965 for <asrg@ietf.org>; Thu, 19 Jan 2006 02:46:39 -0500 (EST)
Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzUf2-0004WJ-Gn for asrg@ietf.org; Thu, 19 Jan 2006 02:56:53 -0500
Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EzUWE-0000Ij-2c for asrg@ietf.org; Thu, 19 Jan 2006 08:47:44 +0100
Received: from pd9fba91f.dip0.t-ipconnect.de ([217.251.169.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <asrg@ietf.org>; Thu, 19 Jan 2006 08:47:42 +0100
Received: from nobody by pd9fba91f.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <asrg@ietf.org>; Thu, 19 Jan 2006 08:47:42 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: asrg@ietf.org
From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Thu, 19 Jan 2006 08:44:23 +0100
Organization: <URL:http://purl.net/xyzzy>
Lines: 27
Message-ID: <43CF4357.50B@xyzzy.claranet.de>
References: <17356.38171.951736.912706@world.std.com> <OFFE10648F.FD8AB2E7-ON802570FA.0035C93C-802570FA.0035EABB@slc.co.uk> <17358.53777.280181.751442@world.std.com> <20060119063333.GA2368@ender>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: pd9fba91f.dip0.t-ipconnect.de
X-Mailer: Mozilla 3.0 (OS/2; U)
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Subject: [Asrg] Re: Email service assumptions and making system-wide changes
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/asrg>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
Sender: asrg-bounces@ietf.org
Errors-To: asrg-bounces@ietf.org

Laird Breyer wrote:

> I think what Danny means is that an effective solution needs
> to be end-to-end (RFC1958). Only the sender and recipient
> should be involved, the intervening network should only
> transport bits.

1958 is an informational RfC not talking about SMTP.  For SMTP
there's a point where mail from one side (MON, mail originating
network in Keith's terminology) reaches the other side (MRN, a
mail receiving network).

It's the point where a last MTA in the MON does a query=mx to
find a first MTA in the MRN.  That singularity is the point
where "unknown strangers" are forced to talk with each other.

The "path registration" schemes (Dave's terminology) focus on
precisely this one singularity to sort it out.  Any mess before
this point is the problem of the MON, and any issues behind it
are the problem of the MRN.

MAIL FROM, Return-Path, and reverse path are no metaphors, they
are used to report problems.  Where RFC 2821 said "originator
as indicated in the Return-Path" it's now in most cases a lie.

                           Bye, Frank



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg