On Tue 07/Mar/2023 20:02:48 +0100 Slavko via mailop wrote:
Dňa 7. marca 2023 17:36:17 UTC používateľ Alessandro Vesely via mailop
<mailop@mailop.org> napísal:
Yeah, RFC4871 was a proposed standard, RFC6376, four years later became an
Internet standard. Once there was a level in between...
Seems that 4 years was not enough ;-) Or we understand idea behind that
RFC wrongly...
We seem to agree. But then, why does people sign Content-Transfer-Encoding:?
Good question, but bad target ;-) But you can guess answer itself:
how many people expect, that when 7bit is enough for them, it must
be enough for all? Or another group of people who even don't know
about transfer encoding at all... And we must not forget about Homo
Copy&paste ;-)
BTW, our Minister of Informatics have (had) own video on youtube,
including notebook (to we all see that she is expert) and on notebook
yellow sticker with (readable) password. What one can expect from
that expert? Only that Mira2020 (or so) is by government approved
password, which all have to use :-P
I slightly lean toward the hypothesis of our understanding the idea behind that
RFC wrongly, because, for example, John Levine, to name a mailopper who is
neither a copycat nor a fake expert, does so.
And why does RFC8058 require that fields such as List-Unsubscribe-Post: MUST be
signed?
Is it special "One click" case? I was not interested in it yet...
Neither am I. I saw it because someone asked me to sign that field by default.
I was surprised to see Section 4 saying:
The List-Unsubscribe and List-Unsubscribe-Post headers MUST be
covered by the signature and included in the "h=" tag of a valid
DKIM-Signature header field.
It was already discussed that the URL (presumably pointing to the same domain)
must include an opaque token by which the target can check authenticity.
IOW, signing gently allows greater flexibility, while signing heavily doesn't
prevent replaying.
We can define third group: sign carefully :-)
But here i see one big problem. One have to select signed headers list
on per message base, as what constructs core of message can differ
for any message. My system is not prepared for that and i will guess
that many other systems are the same. I use one domain for all types
of messages, some even use same sender address for that. Guessing
how/what to sign properly in that generic environment is near to
impossible... The same applies to shared hostings (common for
emails here).
I'm thinking to add a third header field list. From OpenDKIM, I have
requiredhdrs, which are the header fields to be signed /if they exist/. Then I
have oversignhdrs, which are the ones to unconditionally append to h=. The
third list would contain the fields to be signed once even if they don't exist.
I'd put Subject:, To: and Cc: in the third list, for example.
Do you have such settings?
Why do you sign Content-Type: since you know it is going to be changed?
Do you mean exactly me, or it was generic question? If you mean me:
Do you want change the text/plain message, eg. to multipart/alternative
with text/html appended? Of course, in my case that change will invalidate
body signature too (as i sign whole body), but anyway, it constructs core
of message, thus (IMO) fulfill RFC.
Yes, I meant you, since you (are among the ones who) do it.
The change to multipart can only happen using the deprecated l=. It allows to
completely replace the body appearance. As you don't use l=, the only added
protection is against an improbable collision between the original bh= and the
hash of the modified body.
When/where do you expect Content-Type change? What i miss?
MLM wraps the MIME structure if you PGP-sign the message. Otherwise even if
C-T is kept text/plain, it is rewritten without regard to the original. That is:
Content-Type: text/plain; charset=utf-8
instead of:
Content-Type: text/plain;
charset=utf-8
It doesn't matter if canon is relaxed, but "UTF-8" would differ.
Best
Ale
--
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
