Adam Morris writes: > What I'm saying is that if a member posts a message they don't see > it at all even though all other members do.
This is a familiar problem with GMail, and with sites that delegate their email handling to Google. Google refuses to change it or provide a user option to control it. It's really not our problem. The logic to deal with this sanely has been well-known since before I started using email heavily (around 1985), but it can only be implemented by the receiver, not by the mailing list or the author. Google got it wrong and has doubled down on their bug. If there were something we could do to mitigate the problem without causing other problems, yes, we'd be happy to do that. Unfortunately, there's nothing riskless that we can do about it. Changing the Message-ID is non-conformant to Internet standards, and it means that two messages that are for almost all intents and purposes[1] the same message will be treated as separate messages. There are several ways this can happen to real mail, and it's very annoying if it happens a lot. It would then be our responsibility to address that, because we broke the rules and thereby broke people's mail streams. There is one case where the receiver legitimately "sees" a different Message-ID from the original, and that is when the message is "wrapped" in a digest or a MIME forward. If this is useful to the subscriber, they can select digest mode in their options page. If the purpose is to be sure the message reached the list, then the "ack" option can perform that function. In theory we could offer a per-message "wrap-mine" user option (rather than multiple-message digest) to avoid delays waiting for the daily digest delivery time. The functionality for wrapping messages is already implemented, but triggered by a list setting and the DMARC policy of the sender ISP, rather than a subscriber option. However, no MUA I know of handles wrapped messages well, and some can't do anything useful with wrapped messages at all. That would require some discussion to add to the code base, although we could provide a patch to be applied by users for testing purposes. I'm sorry not to be of more help, but I think it's likely that the best we will offer are the digest option and the "ack" functionality so that users will know the mailing list received the message. Steve Footnotes: [1] The only functions the list message message performs that the original in the Sent folder does not are (1) confirmation that the list received and resent the message, (2) getting the list's post-varying text (eg, message sequence number), and (3) checking the trace headers added by the list. (1) is satisfied by the "ack" option, (2) by the "digest" option, and (3) is extremely specialized. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org https://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-users/archive%40jab.org
