On 4/27/19 1:09 PM, Bill Cole wrote:
Yes, because the signature included the Sender and List-* headers, probably non-existent originally, which mailing lists typically (including this one) add to messages they relay.
Thus the Sender and List-* headers were oversigned.
Signing the non-existence of the Sender and List-* headers on messages sent to mailing lists is a perfect recipe for broken signatures.
Are you saying that a sending server should have different behaviors based on the destination of an email? Particularly if it's going to a mailing list or not?
Whoever made the signing choices for Brielle's mail made wrong choices.
I question that.Are you implying that mailing list managers (software and / or administrators) have no culpability in the fact that downstream recipients detected that the original sender's message has been modified (by the mailing list manager)?
Rejecting mail simply for a broken DKIM signature when the relevant DMARC record includes p=none is bad practice. It particularly unwise when, as in this case, the signer has oversigned headers that do not exist in the message at all. It is certainly within anyone's rights to reject mail for any whimsical reason they like, but a mail system that rejects messages for this reason is unfit for general use. It's being used as a toy.
~chuckle~That's not the first time I've heard Gmail referred to as a toy (or an experiment).
I look forward to the resulting world where people have direct experience with the ways mail provider quality varies and create actual competition on more than name recognition and webmail UI cuteness.
Agreed. I'm not holding my breath.
Beyond that, any system that understands DMARC should never use DKIM failure as an absolute rejection criteria if p=none. That's an explicit statement by the domain owner that it is WRONG to treat a bad DKIM signatures in their name as basis for rejecting mail. Google is being intentionally user-hostile here, intentionally and knowingly degrading their service for their users.
I'm choosing to maintain hope that there is something else in addition to the DKIM failure that triggered Gmail to reject messages. But I have no inside information to that.
I'd call it "stupid" except that I know they are not this stupid.
I do have some inside information to know that Google employees are human and do make mistakes. Some of them bone headed that should never happen.
There are really 3 actions that mailing lists need to take if there is any possibility of them breaking a signature:1. From headers with domains with p=reject or p=quarantine DMARC records must be munged by the mailing list, because any signature failure OR ABSENCE will cause rejection of mail.2. Existing signatures should be removed or relabeled.3. If the From is munged, the message should be re-signed by the mailing list system with whatever domain is used in the munged header.
I completely agree. I do question why #3 shouldn't be done cart blanch.
Note that there are a lot of non-obvious ways a mailing list can break signatures by doing things that have long been considered acceptable or even best practices for mailing lists. Even actions which are theoretically allowable for mail in general such as header refolding or address format normalization can break signatures.
Agreed.Which is why I think that the DKIM header's usefulness ends when it gets to the mailing list manager. As such, I think that #2 and #3 above are critical.
It is not accidental that some of the drivers of the development of DKIM and DMARC and "leaders" in aggressive enforcement have been entities which run their own captive discussion list systems which work best for users who also have mailboxes under the same provider's umbrella. A conspiracy theorist might think that Google, Yahoo, and AOL (now one with Yahoo) wanted to kill off traditional provider-independent discussion mailing lists.
I feel like it's quite possible to configure mailing list managers to behave in such a way that is compatible with the aforementioned providers and many others. Particularly if steps #1, #2, and #3 are done.
-- Grant. . . . unix || die
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
