308851 - give every email for an bug update the very same Message-Id for every recipent

Status: RESOLVED WONTFIX

(Bugzilla :: Email Notifications, defect)

Description

[Olaf Hering]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.8) Gecko/20050511
Build Identifier: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.8) Gecko/20050511

This is in response to bug #31314

Now every email sent (as a result of a bug update) will get the correct
In-Reply-To: field, pointing to the Message-ID: of the intial mail.

One thing remains:

Every mail sent will get an unique Message-ID: for every recipent. Thats ok as
long as none of the recipent email addresses is an email alias. If there is an
alias and one of the recipents is a member of such an alias, then the email will
  arrive twice. But with different Message-ID: lines, but (essentially) the same
content. Filtering for duplicates is impossible that way.



Reproducible: Always



Expected Results:  
Every mail should get _one_ random Message-ID: for each and every recipent.

Think of it as a mail to a mailing list.
One mail, one Message-ID:, many recipents.

Comment 1

[Olav Vitters]

I party disagree. The mail is not the same. A mail is generated per recipient.
The contents of this mail could be the different (reasons at the bottom + in the
header). Someone changing the mail template could add other changes if wanted.
Might also break RFC.

On the other hand.. doubt if above would happen.

Comment 2

[Olaf Hering]

anyone who want to filter for the bugzilla header can still do it. but its
impossible to filter duplicates.

if you were a member of the email alias [e-mail] and I
cc you or assign this to you, every mail is sent twice. bad if
[e-mail] is a workgroup and you want to get the updates
and [e-mail] has to stay in cc list.

Comment 3

[Max Kanat-Alexander]

Well, first off, people probably shouldn't be using email aliases to receive
duplicate bugmail -- if they want to receive from some alias, they should be
using the watching feature instead.

I'm fairly sure that sending two different emails with identical Message-ID
headers could confuse some IMAP software, as it would be (as I understand it) an
RFC violation.

Comment 4

[Olaf Hering]

I'm not a perl person, but you get the idea:

Index: bugzilla-2.20rc2/Bugzilla/BugMail.pm
===================================================================
--- bugzilla-2.20rc2.orig/Bugzilla/BugMail.pm
+++ bugzilla-2.20rc2/Bugzilla/BugMail.pm
@@ -599,7 +599,10 @@ sub sendMail($$$$$$$$$$$$) {
                                      $user->id . "$sitespec>";
     } else {
         $substs{'threadingmarker'} = "In-Reply-To: <bug-$id-" .
-                                     $user->id . "$sitespec>";
+                                     $user->id . "$sitespec>\n" .
+                                "Message-ID: <bug-$id-" .
+                               
"$year$month$day$hour$minute$second-$somerandomstring" .
+                                $user->id . "$sitespec>";
     }

     my $template = Param("newchangedmail");


imagine 2 mailing lists, hosted on the same site.
one is subscribed to both of them.
now you crosspost to both.
tell me how the resulting mail violates the RFC, how they confuse IMAP servers
and how the bugzilla mails differ from the mails sent from such mailing lists.

also, how is the watch feature supposed to work? You clearly have to assign
certain bugs to someone, while keeping the alias in cc.

Comment 5

[Max Kanat-Alexander]

From RFC 822:

 4.6.1.  MESSAGE-ID / RESENT-MESSAGE-ID

        [snip] A
        message  identifier pertains to exactly one instantiation of a
        particular message; subsequent revisions to the message should
        each receive new message identifiers.

Changing to "To" field would be considered a revision of the message.

IMAP servers which use the maildir format (as I understand things) or certain
other formats sometimes use the Message-Id to index messages.

Comment 6

[Frédéric Buclin]

suggesting WONTFIX

Comment 7

[Max Kanat-Alexander]

Agreed. We won't fix this in the main Bugzilla code. Perhaps we could come up
with another way to handle the actual problem you are experiencing, though, in a
different bug.