Re: [ietf-smtp] spinning our wheels, was Fwd: New Version Notification for draft-crocker-email-deliveredto-02.txt

[Dave Crocker <[e-mail]>]

On 2/21/2021 12:28 PM, John Levine wrote:
> The original motivation for this draft was to document the way that
> existing MTAs such as Postfix, Courier, and qmail have added
> Delivered-To headers for over 20 years.
> 
> This draft does not do that.  What it describes is nothing like the
> behavior of those MTAs, so I don't understand what it is supposed to
> do.

To press my continuing query further, here is what I've seen from your
postings, in reverse order:


On 2/18/2021 8:28 AM, John Levine wrote:
> In article <3073462D484914E07B452E20@PSB> you write:
>> If I correctly understand the intended use of Delivered-to and the
>> meaning of "added at the time of delivery", I believe that the
>> examples in Section 4 are in error. ...
> 
> The examples show long standing practice so if they disagree with
> the text, the text is wrong.

That's an explicit statement that at least the example is correct,
rather than 'nothing like the behavior of those MTAs'.



On 2/17/2021 2:52 PM, John Levine wrote:
> Old:
...
>     A sequence of deliveries, such as when
> a message goes through multiple mailing lists, SHOULD be recorded
> with a series of Delivered-To: header fields.  As with some other 
> information, each additional Delivered-To: header field MUST be 
> placed at the current 'top' of the message -- as the first header 
> field, in a fashion similar to some fields specified in [SMTP], such 
> as in Section 4.1.1.4.  In addition, and as with other fields placed 
> at the current top, the Delivered-To header field MUST NOT be 
> reordered, with respect to other Delivered-to fields AND those other 
> fields.
> 
> New:
...
>      A sequence of deliveries, such as when
> a message goes through multiple mailing lists,May be recorded with a

That's a normative difference of MAY instead of SHOULD.


> series of Delivered-To: header fields.  As with some other 
> information, each additional Delivered-To: header field is a trace 
> header field and so it MUST be placed at the current 'top' of the
 >         message -- as the first header
> field, in a fashion similar to other trace header fields specified
 >         in [SMTP]
> in Section 4.1.1.4.  In addition, and as with other trace header
 >         fields
> the Delivered-To header field MUST NOT be reordered, with respect to
> other Delivered-to fields AND those other fields.

Wording differences that have no semantic or operational difference.



and just to be complete, here's the comparable text from today's version 
of the draft:


>   a series of Delivered-To: header fields.  As with some other
>    information, each additional Delivered-To: header field MUST be
>    placed at the current 'top' of the message -- as the first header
>    field, in a fashion similar to the trace fields specified in [SMTP],
>    such as in Section 4.1.1.4.  In addition, and as with other fields
>    placed at the current top, the Delivered-To header field MUST NOT be
>    reordered, with respect to other Delivered-to fields AND those other
>    fields.


So, John, I've looked back through Feb 15 and am not finding any 
semantic or operational difference other than in that one normative choice.

What else is there, that explains your terminal assessment?



d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net