Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

> In my read of the code ultimately comes from
> g_mime_parser_construct_message rejecting the message.
> I reported this to GMime, and they said that the problem is that notmuch
> insert is using the mbox mode:
> https://github.com/jstedfast/gmime/issues/58
> (Sample email is attached there).

This issue (or a related one) has come up before

     https://nmbug.notmuchmail.org/nmweb/search/postfix+mbox

Generally it seems to be caused by tools that add mbox 'From ' headers,
without actually mbox escaping the file. We haven't yet reached
consensus on a good solution (generally people just want to fix their
own mail, which is understandable). A workaround discussed in the
messages I reference above is to strip the 'From ' header before passing
to notmuch-insert. Perhaps some scholar of the RFCs can convince us that
that is "always" the right thing for notmuch insert to do.

> As far as I can tell, this is all coming from
> _notmuch_message_file_parse() which sets the is_mbox flag when it sees
> the "^From " line at the start of the file ... which kinda makes sense
> in general terms, but for notmuch-insert I think that's the wrong thing
> to do.  Maybe a solution is to pass a flag down from notmuch-insert.c's
> add_file all the way down to _notmuch_message_file_parse telling it not
> to treat the file as an mbox.
>

I'd be worried about letting notmuch-insert deliver messages that
notmuch-new would not be able to parse. In particular we'd like to keep
the property that a Maildir + the output of notmuch-dump should be
enough to completely recover the notmuch database.
_______________________________________________
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch