Re: [Nmh-workers] problem with long field names

[John Heidemann]

On Mon, 17 Mar 2008 09:41:27 EDT, Josh Bressers wrote: 
>> 
>> This is cut-and-pasted from=20
>> https://bugzilla.redhat.com/show_bug.cgi?id=437652
>> 
>> Description of problem:
>> Recently (in the last month or so), linkedin.com has started sending very l=
>> ong From fields.  As a result, pick fails with messages like this:
>> 
>> 
>> 
>> pick: field name "From notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0=
>> address@hidden  Mon Mar " exc=
>> eeds 127 bytes
>> pick: format error in message 169
>> 
>> Here's the start of the message:
>> 
>> From address@hidden > Mon Mar  3 02:03:01 2008
>> Return-Path: <address@hidden>
>> ...
>
>Ah ha, I now see the problem!
>
>It looks like you're trying to view an mbox as a mh message.  the From is
>missing a :, and the line doesn't look like a normal From header.
>
>Try to inc that file into your inbox, and you should be OK.  The
>question now becomes, how did it get there.

Ok, two corrections.

First, my original statement about how to reproduce the problem was
incorrect.  The exact command that reprodcues the problme is:

        pick -after -1 +savebox -sequence test

Giving these kind of messages on a system without the patch I made
available:

        pick: field name "From notif+qSVakQSqxx...(stuff omitted)address@hidden 
 Mon Mar " exceeds 127 bytes
        pick: format error in message 169
        88 hits

Second, I can confirm that the message IS in an mh folder.
However, I agree that colon-less From is an mbox.  It looks like this
came from procmail, which although it supports dropping into MH folders,
may not do it quite correctly.

If I actually inc it, rather than let procmail deliver it, then nmh
rewrites the From into a Return-path with a colon that does not trigger
the error.

I will try and follow up this bug with procmail.  (If you want to make
mh robust to this incorrectness of someone else, it looks like a 2-line
change to m_getfld.c will do so.  Please let me know if you're
interested.)

Thanks for the help.

   -John Heidemann