On Sat 2019-08-17 19:12:26 -0300, Jorge P. de Morais Neto wrote: > I have attached a tarball with three homonymous messages from Dell. The > last (most recent) two have the same subject and bodies, but the first > (earliest) one is different and yet they all have Message-Id 1. I have > included the Notmuch list as a recipient because the tarball is a mere > 11252B. thanks for this. Looking at the headers, it occurs to me that the problem might actually be that Dell ("idd_messaging_email@dell.com") might not including a message-id header at all, and it is being added their IronPort/Sophos AV client as it passes through their mail system. I suspect this possibility because the placement of the Message-ID header itself is supiciiously high up in the list of headers (it looks like it might have been placd there by the initial relaying MTA, rather than the MUA). If this is the case, it could be solved in one of two ways: they could inject a proper unique Message-ID before handing the message off to IronPort; or they could fix their IronPort appliance to inject a proper unique Message-ID header. That's all about fixing it on the sender side though. Are there possible fixes on the receiving side? one thought is that notmuch could treat an obviously low-entropy message-ID the same way that it treats a message with no Message-ID at all. Of course, that raises the question: what is a low-entropy message ID? A single-character message-id is pretty clearly too low-entropy to be useful, but if we said "1-character long" was too short, it would at least avoid this particular mistake. i also note that NEWS claims (in the section for notmuch 0.17) that notmuch treats "overlong" message-ids in the same way as missing message-ids, but i don't see where that distinction is done in the code. It doesn't appear to be in lib/message-file.c, where the notmuch-sha1-* generation is done. But anyway, if we are treating "overlong" message-ids as missing, it's nicely symmetric to treat "overshort" message-ids in the same way. --dkg