Re: NMH mail package utility "inc" aborts before incorporating first new email into an NMH folder

[2026-08-15 15:00] Michael Richardson <[email protected]>
> Philipp <[email protected]> wrote:
>     > As others alrady mentioned, the problem is a to long header field and
>     > because the pop_retr() has no way of softfailing. I have a patch for
>     > this attached. Now pop_retr returns a LENERR when a to long line is
>     > inside a mail. inc handles the LENERR with a warning and continues with
>     > the next mail.
>
> Despite the risk of breaking DKIM, etc. I would be happy for very long header
> lines to just get truncated in the local store.   I observe that they almost
> always junk that some spam filter has put it, and ought not to have.

The problem is, at this point in the code it is not known if it a random
field, an importend field or the body. So just guess that this part is
not that importend might truncate importend information.

>
>     > I haven't tested this because I have no pop server to test this. Also
>     > it might be necessary to do a bit more in the error case. I don't realy
>     > know the pop implementation.
>
> Happy to set up an account on my mail server; it does pop3s, and I use pop3s
> with inc on it.
>
>     > In general I would say inc should be able to receive this mail, but
>     > I don't have the capasity to write a patch for this.
>
> does the problem not also occur for "inc -file fubar"?

This exact error is only in the pop implementation of inc. As far as
I understand the code there are other parts in inc which could do better
error handling.

Philipp