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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp