On 2023-03-08 at 11:24 +0100, Alessandro Vesely wrote: > On Tue 07/Mar/2023 20:02:48 +0100 Slavko wrote: > > > > > 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.
There are more ways to change a Content-type for abuse. Suppose there is a web form that is expected to send a plain text message saying: "Hello Alessandro Thanks for registering on example.com, please click the following link to validate your account: https://example.com/register..."; These kind of forms are already abused by using "names" such as "buy our viagra at great price on http://spamurl.com"; The "I received a scam letter from Paypal" thread a few months ago is also based on the same concept. Now, let's suppose that email is DKIM-signed but the Content-type: text/plain header is not. And the form is filled out by «Bobby <style>* { color: white; background-color: white; } .phish * { color: black}</style><div class="phish"><h1>Important notification from your bank</h1> <p>Your password has expired. Please <a href="https://phishing.com";>Renew it here</a></p></div>» and attacker changes the Content-type from text/plain to text/html... Another venue would be changing the charset to utf-7 This was a common way of bypassing XSS filters on browsers. It is now unsupported by all browsers, and forbidden by the spec [1]. I don't know if there is any MUA which allows that (or even used to support it) Determining which headers to sign (or not to sign) is complex, brittle and reasons for that unintuitive and not well-known. A reference document that provided guidance (if not even a direct recipe) would surely be helpful to the email community. 1- https://html.spec.whatwg.org/multipage/parsing.html#character-encodings older versions were even more explicit that UTF-7 must not be used https://github.com/whatwg/html/commit/a73180679a40fce96b8e8fb6dfa5815a9bce30eb#diff-41cf6794ba4200b839c53531555f0f3998df4cbb01a4d5cb0b94e3ca5e23947dL14674 _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
