On 22-Apr-22 02:12, Stephen J. Turnbull wrote:
tlhackque via Mailman-users writes:
An up-to-date Thunderbird user - the message with the "mail-with-defect.txt" attachment, as forwarded by [MME-users] (selected headers below for ID) displays as blank. Interestingly, the Thunderbird error console has no error message related to this.
So there's really no point in passing it along, unless "pass these defects" turns into "repair these defects".
That's a Thunderbird problem, though, and nonconforming to the Postel Principle.
As I subsequently wrote, I agree and logged a bug report for TB. Apparently the other people who reported experiencing the issue here never did. However, it's not clear whether it's the same "blank display" issue - I'm pretty sure mine was due to the broken signature; others seemed to indicate the CTE headers. So I hope those with the ability to sort that out will add to the bug report...
The Postel Principle is a useful, sweeping generalization. It's not an absolute. It doesn't say "be so liberal in what you accept that you do something sensible with all possible input faults, including those that you never thought of and any input contrary to a specification". One could argue that TB was liberal enough not to crash. I don't expect any MUA to display non-conforming messages as the sender intended. It's unquestionably a bug that TB failed to display anything, even "I don't understand this malformed message". If it did that, further conformance to the Postel Principle would be a matter of degree. It could display the raw message body, try to intuit and format the most involved content, fall back to any text/plain part, offer to send a bug report to vendor of the MUA identified in the headers, or...
However, the point I tried to make with this example is that passing-on defects isn't a good solution. At best, receivers whose MUA tolerates a defect (or interprets it in a useful way) benefit. But to others, MM looks like a flaky source - some people can read some messages some of the time. And it amplifies the impact of the defect by distributing it to a large(r) audience. (Similar to the DDOS DNS amplification attacks.) So if there's an issue identified that causes pain for the MM community, I think it best to either (a) bounce the message with an explanation or (b) if possible (and in a Postelish spirit) repair the defect.
Note that MailMan is encapsulating a multipart/signed message in a multipart/mixed in order to append it's footer, and reports that it removed the signature part of the multipart/signed. This makes the signed message format invalid. So at least, MM3 needs to handle signed messages better: either include the signature or remove the signature headers (an unwrapping exercise to convert the message to unsigned)...
For the former, we already try pretty hard to include the signature. At least on this list "Pass types" is
multipart message/rfc822 text application/pgp-signature application/x-pkcs7-signature application/pkcs7-signaturealthough I see Mark just added that last one or two. Of course, "x-" tokens are deprecated except for private use, maybe we should be unsympathetic to x-pkcs7-signature, too? :-)
The last two were added in response to my analysis. There are a lot of x-mime types that were subsequently standardized. There's no good solution for migrating from an experiment to a standard. Your friend the Postel Principle gets in the way - since it's clear that the semantics are identical, you should generate the standard, but accept both the experimental and standard... :-)
Converting to unsigned, while possible, is a bad idea in the vast majority of cases. More later.
In either case, corrupting messages is a MM issue.
I disagree, in part. Although you do address this, let me use the example of this case where the signed body is multipart/alternative. I think it's perfectly reasonable for a list to configure to remove the text/html part, which will break the signature. Then there are three possible ways to go: (1a) leave the signature in place, broken, thus informing recipients it was supposed to be signed and leaving it to them to follow up, (1b) to change the multipart/signed content-type to multipart/mixed and replace the signature with a "removed" notice, and (2) to remove the signature and multipart structure, leaving recipients unaware that the message was intended to be signed. Each of those is problematic, each in its own way. Supporting all of them and the list configuration infrastructure to allow admins to choose would be an unwarranted burden on us, IMO.
The fourth, and probably correct, possible action is to bounce the message. Someone signed it for a reason. If its content violates the list policy, it can't be fixed and stay signed. So tell the sender why it can't be accepted, and give him the option to remove the banned part(s) or remove the signature. If someone signs a message, substituting the judgement of some random remote list manager (human or automaton) doesn't seem like the right thing to do...
multipart/signed should imply accepting the signature part (in this case, application/x-pkcs7-signature). If signatures aren't allowed by policy, then multipart/signed should be bounced.
I find it hard to believe that anyone would want a "deny signed bodies" policy
So would I. But I sign messages by default, and run into this. And the argument goes "the signature doesn't add anything. It occupies space (itself and it can cause e.g. base64 encoding of plain text) and my users don't care and it's a techie's vanity exercise and it causes problems (like the ones discussed here), and..."
, but it's easily implemented. Put multipart/signed in "Filter types". A configuration explicitly banning signature algorithms but not multipart/signed is a user error in that case.
Yes. And (I won't mention the PP here, but...) it's clear that even experienced administrators (e.g. Mark) fall into this trap. In fact, I think accept "multipart" (meaning multipart/*) is a default or at least recommended configuration. So MM should either detect it, or behave reasonably. I'm suggesting that a reasonable behavior would be:
If an incoming message is signed and the associated signature part is not explicitly banned, accept the signature part. If signed and the signature part is banned, or if signed and signed mail is banned: bounce the message.
I guess I can imagine wanting to ban certain types (eg, known exploitable algorithms), and if one has such a use case and wants the message rejected rather than simply stripping the signature as unusable, "patches welcome" -- I can't see that level of care as worth our time, though.
I'm not going as far as selective algorithm enforcement. That would only make sense if MM got smart enough to validate signatures of signed mail - e.g. to bounce mail with bad signatures. (Which might be a worthy goal, but out of scope of this exchange...)
But I stand by "if the sender signed it, then accept it or bounce it." Messing with it only leads to where there be dragons.
(I don't think it's reasonable to expect MM admins to "know" to configure their lists to pass signature parts if accepting signed - after all, this list is run by experts :-)
I agree with that. It's not clear that we should do something about it, though. There are two possibilities: (1) the list admin doesn't care about signatures, and simply wanted to allow multimedia mail, and (2) the list admin wants to admit signatures on purpose, for some purpose.
In case (1), this is mostly a cosmetic problem, and possibly involves minor annoyance. The signature validation will fail and maybe there's a text notice about removed parts, that's cosmetic. A subscriber who cares about the signature might have to contact the author for validation, that's the annoyance. In case (2), we do not know what the requirements are. We should refuse to guess and we can assume that list admin knows [more about what] she's doing [than we possibly can] and leave it up to her.
I'm taking the position that the originator's intent should control.
If (s)he doesn't sign a message, then MM/the admin is free to change the content per (hopefully published) list policy.
If (s)he did sign a message, the MM must either deliver it with the signature intact, or bounce it for policy reasons.
If you think that we can know a lot about a very common use case in principle, I'd like to hear about it, but for now that's my stance,
Steve