Re: [ietf-smtp] what's not a trace field

[John C Klensin <[e-mail]>]

--On Wednesday, February 17, 2021 13:02 -0800 Dave Crocker
<[e-mail]> wrote:

> On 2/17/2021 10:46 AM, Ned Freed wrote:
>>> https://mailarchive.ietf.org/arch/msg/ietf-smtp/fzCKQu9CyhTc
>>> dr1IQ-j43qk8-U8/ 
>>> 
>> 
>> 
>>> It offers revised text and it would help to have people read
>>> it and comment on what problems it causes for use of the
>>> draft.
>> 
>> Sorry to have to say it, but the old text was (marginally)
>> better.
>> 
>> The new text says "add at top" but saying nothing about
>> grouping and prohibiting reordering. Both of which are really
>> important requirements.
> 
> 
> OBE.  The draft I submitted text covers that concern.  Alexeys
> note surfaced the ordering issue that I -- and based on the
> thread here, everyone else -- had missed.
> 
> See the diffs at:
> 
> 
> https://www.ietf.org/rfcdiff?url2=draft-crocker-email-delivere
> dto-01

Dave, Ned, others,

Looking at the new text at the end of Section 1, this is a
question, not a suggestion or objection:

It seems to me that, with "Delivered-to:" and a large number of
non-standard headers, we are creating a rather long list of
mechanisms for "detecting a delivery sequence loop" as compared
to the times 821 (and even 2821) were written when the
expectation was, more or less, that "Received:" was both
necessary and sufficient for that job.   With the understanding
that this I-D is probably not the place to put the text, do we
need to offer/specify advice about how that selection of fields
might used in relationship to each other for such detection.
Or are we happy saying "this can be used for loop detection" in
several documents and leave which ones to use up to
implementation creativity?

      john