[Mailman-Users] Mailman reusing message-id, leads to duplicate message suppression

[Stephen J. Turnbull]

Note that the subject is incorrect.  Mailman is not reusing the
Message-ID, it is refusing to alter it which is correct behavior
according to RFC 5322 (Message-ID is an originator field).

I believe that according to RFC 5322 (and predecessors) Mailman SHOULD
add a Resent-Message-ID to indicate that it handled the message, but I
doubt this would change the duplicate-suppression behavior of Gmail
and MS Exchange.

Richard Damon writes:

 > This is really a tough problem.

For us, there's nothing tough about it.  Gmail is the wrong MUA to use
if you want to compare mail received by different routes including the
"null" route, otherwise it does what most users want.[1]  Microsoft
Exchange is not a conformant MTA, no surprise there -- it's not
designed to be a conformant MTA.  It's intended to be a complete
internal communication solution, and where that conflicts with RFC
conformance, the RFCs lose.  Users will need to find ways to defend
themselves against its vagaries -- there's nothing Mailman can do
without breaking the world.

 > someone [at Microsoft] may have been confused by Usenet RFCs, and
 > applied them to email, whose system has a lot of similarity (and
 > even share some RFCs), but IS a different system.

It's highly unlikely that Microsoft thought past "users don't like
dealing with duplicates, and in our environment where people send 10MB
attachments to ALL, they can actually crash the mail system".

Just tell the user that Gmail is not a good MUA if you want to be able
to check on sent mail without asking the recipient directly, and that
Microsoft products deliberately trade reliable delivery in the
Internet sense for what the developers consider to be the convenience
of their users.


Footnotes: 
[1]  It's surprisingly difficult to handle duplicates truly gracefully.
For example, I personally consider the mailing list copy to be the
"canonical" copy of a post, but direct CCs often arrive more quickly.
In many cases there has been sufficient delay that the first copy to
arrive has already been filed in an "archive" folder by the time the
duplicate arrives.  This doesn't make naive duplicate suppression any
harder, but it does complicate maintenance of "canonical" copies in my
archive folders.