In message
<1333106220.03.0.265807397089.issue2550752@psf.upfronthosting.co.za> ,
Tom de Vries writes:

>New submission from Tom de Vries <tom@codesourcery.com>:
>we're using roundup as issue tracker and exchange as email server.
>
>We have a problem related to an issue with both:
>- me and,
>- a mailing list I'm a member of in the nosy list.
>
>When I do an update of the issue, emails get send to me and the mailing
>list (due to configuration option NOSY_EMAIL_SENDING == single), with
>each email containing only a single addressee.
>
>when the 2 messages arrive, one stays in my inbox, the other one is
>filtered to the mailing list folder.
>
>The problem is that sometimes only one message arrives (any of the two).
>I've tracked this down to the following:
>when a message arrives at the exchange server, and that message has the
>same Message-id and the same Date field as an earlier message, the
>second message is dropped (documented here:
>http://technet.microsoft.com/en-us/library/dd577073%28v=exchg.80%29.aspx#1
>).
>
>When roundup sends the 2 emails, it sends it with the same message-id,
>but not necessarily with the same Date.
>
>So if the Date field is different, I receive 2 emails. If the Date field
>is the same I receive 1 email (the first one to arrive).
>
>From my user perspective, this is bad: I expect the email addressed to
>me to appear in my inbox.
>
> [...]
>If we force the Date to be the same for all messages, I'll never get two
>messages, only one (timing-dependent which one).
>
>If we force the Date to be different for all messages, I always get two
>messages, but it's a not so pretty workaround for the specifics of
>exchange duplicate message detection, and may not work for other similar
>duplicate elimination programs.

True, but I think changing the message-id will be more difficult. It
should definatly be an option regardless of which solution is adopted.

It's really stupid that exchange can't turn that off. I have had
duplicate detection in my email chain for a couple of decades, and
it's only considered a duplicate if it's the same message (messageid)
handled the same way (i.e. is delivered to the same mailbox/folder).

>I think the cleanest fix would be to have a different message-id for
>each message. But, I'm not sure about the drawbacks of doing that.

Well one of the issues is that clients use the In-Reply-To: <msgid>
header for threading in a client.

The comment in:

   ./roundup-1.4.19/roundup/mailgw.py:
        # try in-reply-to to match the message if there's no nodeid

indicates that it does compare the in-reply-to (whose value is the
message id of the message being responded to) and expects a message id
matching what it sent. I am not sure if there is support for a many->1
message-id -> actual message mapping which would be needed if a
message resulted in multiple message-id's.

>What I understand from the standard (http://tools.ietf.org/html/rfc5322)
>though is that same or different message-id depends on the intent of the
>sender:
>...
>In all cases, it is the meaning that the sender of the message wishes to
>convey (i.e., whether this is the same message or a different message)
>that determines whether or not the "Message-ID:" field changes, not any
>particular syntactic difference that appears (or does not appear) in the
>message.
>...
>One could argue that the 2 emails messages are different because each
>has a different addressee.

Well I would claim the message is a response to a single event:

  the roundup update

It really is a single message going to multiple people.  Roundup is
just changing the envelope addressing and not really the message.