GNOME Bugzilla – Bug 635347
Message lacks ID when submitted for sending
Last modified: 2011-09-30 12:39:01 UTC
I sent a '[PATCH 0/2]' overview mail to a development mailing list, then used 'git format-patch --in-reply-to=1290258564.30970.59.camel@i7.infradead.org' to generate the followup mails with the actual patches. I found the Message-Id of my first outbound message by going to my outgoing Fcc folder and hitting Ctrl-U to see the full message, then I cut and pasted the Message-Id from there. But when I received my messages *back* from the mailing list, the threading was broken; my patches were *not* tagged as being in reply to the original message. Closer investigation shows that the Message-Id isn't actually present in the message in the Fcc folder at all. But Evolution generates a *new* one every time I hit Ctrl-U to view the message! When we generate a Message-Id for sending a message, we *have* to write that to the Fcc too. And we definitely shouldn't make up message-ids when displaying messages which lack them.
This started happening for me on November 10th. I think I hadn't updated for a while before then. The previous working version was also adding X-Mailer: headers saying 'Evolution 2.91.2', and the lack of Message-Id: header coincides with that changing to 'Evolution 2.91.3'. I'd probably start by looking at commit 6709cd6e5879adf9505bf25306b34932ceb6b5a6 and related changes. Or just looking hard at mbarnes... :)
I just observed a user complaint that this is still happening in 3.0.3
Probably what's happening is a CamelMimeMessage with no Message-ID is generated by the composer and fed to two different output streams: one to the SMTP server and one to the Fcc folder. The CamelMimeMessage.write_to_stream() method has logic to generate a Message-ID if there is none, so it's probably doing that for each of the two output streams. Seems like a straight-forward solution would be for new CamelMimeMessage instances to generate a Message-ID right off the bat, and if it gets overwritten by the MIME parser then so be it, but at least then all instances will have an ID at all times. As usual with Camel, there's probably some nasty corner cases or bad assumptions hidden in the logic that this would break... but we can try it.
David explained to me on IRC why my solution is wrong, since some received messages may actually lack a Message-ID header and we don't want to just make one up for it. So I guess we'll just explicitly generate one in the composer. This should do it: http://git.gnome.org/browse/evolution/commit/?id=b93fe51d70f19853d8d1f5a4c5e4db96ab437235
For those who would like to cherry-pick this for 3.0.x, please note that the patch alone does not fix the issue. Something else is needed.
*** Bug 660556 has been marked as a duplicate of this bug. ***