Hi. When fetchmail is unable to log into the IMAP server to fetch emails, it inject an email into the mail spool to report this problem. But the injected email lack message-id, causing the notmuch mail indexing system to not handle these emails very well. I discovered this when my scripts processing emails just failed to discover these when looping over all message-ids. Here is an example email, with the complete header: From: FETCHMAIL-DAEMON@login1.uio.no Date: Thu, 06 Feb 2014 14:52:47 +0100 (CET) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="ISO-8859-1" Subject: fetchmail authentication failed on pere@some.host Content-Length: 468 Fetchmail could not get mail from pere@some.host The attempt to get authorization failed. This probably means your password is invalid, but some servers have other failure modes that fetchmail cannot distinguish from this because they don't send useful error messages on login failure. The fetchmail daemon will continue running and attempt to connect at each cycle. No future notifications will be sent until service is restored. -- The Fetchmail Daemon Please adjust fetchmail to include a unique message-id in these emails.
Am 28.02.2014 19:26, schrieb Petter Reinholdtsen: The header is optional according to RFC5322. If "notmuch" does not cope with that, have fetchmail inject mail into an MTA that works and generates missing Message-ID headers.
[Matthias Andree 2014-05-20] While it sure is optional according to RFC5322, it is considered best practice to include in in emails. What is the reason the fetchmail developers do not want to include Message-ID into these notification? I currently use fetchmail+procmail to receive emails from IMAP servers, and the IMAP servers seem to make sure Message-ID is present. The issue at hand here are emails not originating from the IMAP servers, unfortunatly.
Am 04.12.19 um 10:14 schrieb Petter Reinholdtsen: What is the reason people use inferior software and then only to a small stretch of its possibilities, and then try to put convenience features into other packages? What is the new argument that could sway the original decision? Or think that the fetchmail developers would have to answer such questions at all? If the issue is with procmail + notmuch not generating that header, or coping without, then fix that. So? If you must use that unmaintained piece from the museum of anti-designs called "procmail", you can as well rig it to pipe all ingress mail through "formail -a Message-ID" if notmuch still fails without such a header. formail is part of the procmail package. Or you could use reformail from the maildrop package. Other options might exist.
[Matthias Andree] Perhaps the same reason people call some software systems inferior? A guess would be hybris, but I truly do not know. Anyway, I was just curious what the answer to the question "why" would be. Now I know. Thank you for the clarifying answer. :)
Am 05.12.19 um 09:07 schrieb Petter Reinholdtsen: The answer is actually a bit more complex, with aspects of "problem already solved externally", "not mandated by standards", and "not trivial to implement and document". There are so many questions that will want to be asked back, for instance, what should the domain part be, do we need to make it configurable (either way it needs documentation) and all that. High cost, little potential gain, I dare say not frequently needed, and as shown the problem has already been solved by others externally - and in a way (not quite coincidentally) that you can integrate into your setup. And it's really only necessary for the specific circumstance that further parts of the mail setup really fail in hard or very awkward ways if the Message-ID is missing, and that seems to be a feature of older notmuch implementations fixed a few releases ago. There are other feature requests that won't catch a "wontfix" tag that quickly because either they have low cost, or are hard to solve externally (for instance, expire kept messages on server after N days) or are otherwise more sensible to do without duplicating existing solutions.