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

[Alessandro Vesely <[e-mail]>]

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 <[e-mail]> for
    [e-mail]; 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.