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




13 years ago
13 years ago


(Reporter: olh, Unassigned)






13 years ago
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

13 years ago
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

13 years ago
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 email-notifications@bugzilla.bugs and I
cc you or assign this to you, every mail is sent twice. bad if
email-notifications@bugzilla.bugs is a workgroup and you want to get the updates
and email-notifications@bugzilla.bugs has to stay in cc list.

Comment 3

13 years ago
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

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

Index: bugzilla-2.20rc2/Bugzilla/
--- bugzilla-2.20rc2.orig/Bugzilla/
+++ bugzilla-2.20rc2/Bugzilla/
@@ -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

13 years ago
From RFC 822:


        [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

13 years ago
suggesting WONTFIX

Comment 7

13 years ago
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.
Last Resolved: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.