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

Alessandro Vesely <> Sun, 15 January 2012 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C1E621F8472 for <>; Sun, 15 Jan 2012 10:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.611
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hDbUsXF-p3L3 for <>; Sun, 15 Jan 2012 10:58:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3AF0C21F8442 for <>; Sun, 15 Jan 2012 10:58:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by with ESMTPSA; Sun, 15 Jan 2012 19:58:13 +0100 id 00000000005DC039.000000004F1321C5.00001E58
Message-ID: <>
Date: Sun, 15 Jan 2012 19:58:13 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
References: <> <F5833273385BB34F99288B3648C4F06F19C6C15859@EXCH-C2.corp.cloudmar> <> <AD693E95D4252DC3E8F3832F@PST.JCK.COM> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Adoption of draft-kucherawy-received-state?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 ( [])
    by (Postfix) with ESMTP id 489FA21F845E;
    Sun, 15 Jan 2012 08:15:57 -0800 (PST)
  Sent: to to-addr to-port 25
    by by-addr by-port 1438
    date "Sun, 15 Jan 2012 08:15:57 -0800 (PST)"
  Received: from by
    (PMDF V6.1-1 #35243) id <> for; 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.