Re: [apps-discuss] Adoption of draft-kucherawy-received-state?

Alessandro Vesely <vesely@tana.it> Sun, 15 January 2012 18:58 UTC

Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1E621F8472 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 10:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.611
X-Spam-Level:
X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDbUsXF-p3L3 for <apps-discuss@ietfa.amsl.com>; Sun, 15 Jan 2012 10:58:15 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF0C21F8442 for <apps-discuss@ietf.org>; Sun, 15 Jan 2012 10:58:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1326653893; bh=zq9zVkQsYDClmohiXyKTuXw02esOS+X7AL+gy3UC500=; l=2002; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Mh2cbUnwVnLjRn1/jtKiTu4KTOMU0AAa3WXsyFKGkYD2oAEM0ZDc8DiG4zN09R0Bi RK8f6PIcVYKli3DXsuU0aBbv3KtuL1LSVmjeeqPhQoZQPSzXxNBiICiXdzb/ERee92 MGYYdK8DTCV8St3E1YLMyqd2cekSl6tX50DjQ8LI=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 15 Jan 2012 19:58:13 +0100 id 00000000005DC039.000000004F1321C5.00001E58
Message-ID: <4F1321C5.7000807@tana.it>
Date: Sun, 15 Jan 2012 19:58:13 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <F5833273385BB34F99288B3648C4F06F19C6C15818@EXCH-C2.corp.cloudmark.com> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar> <k.com@missing-host.mrochek.com> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <4F122257.10301@dcrocker.net> <01OAT5KFXSHA000HW1@mauve.mrochek.com>
In-Reply-To: <01OAT5KFXSHA000HW1@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jan 2012 18:58:16 -0000

On 15/Jan/12 16:53, Ned Freed wrote:
> 
> We have a problem to solve here, and unfortunately all of the 
> possible solutions have issues. In my judgement out of all the
> available options the best is to extend Received:, messy syntax and
> all. All of the other options, including but not limited to
> additional trace fields, replacing Received: with something else,
> replacing Received; while retaining generation of Received; for
> backwards compatibility, are even worse.

This judgment is difficult to understand, for me at least, without
considering an actual alternative.  For an example trace field to be
paired with "Received:", I'd pick "Sent:".  Consider:

  Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40])
    by ietfa.amsl.com (Postfix) with ESMTP id 489FA21F845E;
    Sun, 15 Jan 2012 08:15:57 -0800 (PST)
  Sent: to ietfa.amsl.com to-addr 12.22.58.30 to-port 25
    by mauve.mrochek.com by-addr 66.59.230.40 by-port 1438
    date "Sun, 15 Jan 2012 08:15:57 -0800 (PST)"
  Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com
    (PMDF V6.1-1 #35243) id <01OAT5KHWWNK000FER@mauve.mrochek.com> for
    apps-discuss@ietf.org; Sun, 15 Jan 2012 08:15:54 -0800 (PST)
  ...

That "Sent:" field is to be written on the fly, and if the message is
rejected (5xx) or delayed (4xx), then the field gets discarded.

There is a lot of redundant data.  It wastes bandwidth, but can be
used to check proper ordering, synchronization, and consistency.  The
format can be similar and new at the same time.  Both fields can be
extended, but no coordination between their formats is to be mandated.

An advantage of the new field, for the problem at hand, is that it
allows to make a final statement rather than forecasting a state.  It
would be possible to tell this is the 4th attempt in 15 minutes, as
after greylisting.

> And the worst option is effectively saying that additional trace
> information can never be added again. That would really suck.

+1.