tlhackque via Mailman-users writes:
Not that I count, but I'm not particularly sympathetic to this either.
In fact, you do count. If we can get a working consensus that Mailman shouldn't try to make up for MUA SNAFUs, no matter how many trillion dollars the manufacturer's stock is worth, life would be easier for us. ;-)
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.
Assuming it's an origin issue, this really seems like an issue that can only be fixed by the sending MUA (Apple).
Obviously.
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? :-)
Note that this can be recursive where a signed message contains a message/rfc822 part that contains a signed message, that....
I'm not sure it makes sense to encrypt messages to a mailing list,
Of course it does. Maybe not to a public discussion list, but for a closed group's distribution list, I'm sure there are applications.
but the format issue is the same.
OK.
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.
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, 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. 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.
It's also the case that if a signed message contains an banned part type, simply removing it will break the signature. So in that case, the choice would either be to bounce the message, convert the message to unsigned, or accept the banned part. (The latter might be acceptable in some environments, but has obvious risks.)
Clearly, the current behavior is problematic.
That's not obvious, except as it's cosmetic.
(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.
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