Richard Clayton wrote in
<jszrijbynuonf...@highwayman.com>:
|-----BEGIN PGP SIGNED MESSAGE-----
|Hash: SHA1
|
|In message <20241116204935.dCb0mQcG@steffen%sdaoden.eu>, Steffen
|Nurpmeso <stef...@sdaoden.eu> writes
|
|>Having said that, if it is really acceptable to include the entire
|>history of changes in that "stack" that email headers form (hihi:
|>yes please, i find it absurd that these things have to be numbered
|>given this is a stack;
|
|there is a belief (perhaps not well-founded) that there are systems out
|there that reorder headers.[.]
That is a good question. Has this ever been truly verified
i think almost twenty years ago when DKIM was / predecessors were
invented, and *explicitly* documented as
The DKIM-Signature header field SHOULD be treated as though it were a
trace header field as defined in Section 3.6 of [RFC5322] and hence
SHOULD NOT be reordered and SHOULD be prepended to the message.
when standardardized, and where the referenced RFC says eg
When the SMTP server accepts a message either for relaying or for
final delivery, it inserts a trace record (also referred to
interchangeably as a "time stamp line" or "Received" line) at the top
of the mail data.
and in "4.4 Trace Information"
An Internet mail program MUST NOT change or delete a Received: line
that was previously added to the message header section. SMTP
servers MUST prepend Received lines to messages; they MUST NOT change
the order of existing lines or insert Received lines in any other
location.
and 5321bis discussion touched this topic if i recall correctly.
Anyhow it is plain that RFC 5321 software knows about the notion
and the pressing need to treat a message as "a stack".
This is true since RFC 822 from 1982, where one can read
4.3. TRACE FIELDS
Trace information is used to provide an audit trail of mes-
sage handling. In addition, it indicates a route back to the
sender of the message.
"An audit trail" means trace headers form a sequential well
sequence -- please let me Cc: emailcore@ as the new wording is in
my opinion by far worse than what RFC 822 says, indeed.
But now the fun of it: it seems according IETF methodology RFC 822
is actually *the* standard that counts, at least until RFC 5321bis
is released, *if* i got that. If that isn't funny, you know.
If i add these things together i see DKIM signatures as part of
a stack. Sure, this is SHOULD not MUST, and the newer SMTP RFCs
dilute (sorry, dear John!) the notion one can get, i really
perceive RFC 822 so that i think Douglas McIlroy could bask in
this concise text.
(No more SMTP below this point.)
But, really, ever since i look i have yet to see that reordering
of DKIM signatures took place. Oh, reordering happens super
frequently for all address fields (including sender, reply-to
etc), subjects, date, and in general all those fields that can be
seen in MUAs and mailing-lists, as well as spam etc milters,
prepended, appended, scrambled even, and the emlm mailing-list
manager is likely alone in its quest to prepend the List- headers,
whereas all others "append" (or better, insert somewhere at the
tail, mlmmj "more heavily" so than mailman). That is, all over
the place. But it seems DKIM-Signature and Authentication-Results
is not along those.
I say thus, let it happen. Make it a MUST. It is a trace header.
All relevant persons listen here (on emailcore). Any MTA
developer or giant appointed specialist whose software does not
comply could speak out. They listen, they then (as appointed
specialists) even know RFC 822 is the "real thing", hence it is
crystal clear that trace is an audit trail and thus sequential.
(It is not as if anyone cares for this -- how much is it,
1 percent or less? -- tiny corner of the internet that is not
covered by the giants (and/or their software), by postfix, exim,
qmail, opensmtpd (and all those comply), anyhow.
What belief is this you are talking about?
((It is overengineering.))
|[.]Numbering means that these can be tolerated
|the actual cost of numbering is very low, and it provides significant
|clarity and reassurance -- so I don't know why you are arguing it should
|not be present in the design -- and I am even less clear what it has to
|do with the proposed charter for a Working Group
Ah. Methodology.
|- --
|richard Richard Clayton
|
|Those who would give up essential Liberty, to purchase a little temporary
|Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
Off-topic, but what is "liberty"? Under-educated under-informed
under-aware (and how did they get *there*?) people making greedy
decisions. Over 76 percent loss of life (diversity) since 1970,
the Club of Rome "the limits to growth" report of 1972 it is we
comply to completely -- so much to "clarity and reassurance",
hah!. I have a techno song as part of a set of a wordwide known
DJ from around Y2K that i truly could find, it says "Freedom is
relevant. Self-determination is relevant. You must comply". And
sorry, the white man has simply failed. He never embraced the
problem and paved a way for "the whole thing". And never
will. Other civilizations and philosophies did (at least *think*)
so before ours existed.
|-----BEGIN PGP SIGNATURE-----
|Version: PGPsdk version 1.7.1
|
|iQA/AwUBZzlJ8t2nQQHFxEViEQLJSQCg9WYPovauvcaZZddKq39S0JDC9pIAnjpm
|x9w8oAzvWwSb4bNYUy8NeD7t
|=+Muk
|-----END PGP SIGNATURE-----
--End of <jszrijbynuonf...@highwayman.com>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
