From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008030318 Firefox/3.0b4 Description of problem: Recently (in the last month or so), linkedin.com has started sending very long From fields. As a result, pick fails with messages like this: pick: field name "From notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo.com Mon Mar " exceeds 127 bytes pick: format error in message 169 Here's the start of the message: From notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo.com Mon Mar 3 02:03:01 2008 Return-Path: <notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo.com> ... Version-Release number of selected component (if applicable): nmh-1.2-20070115cvs.4.fc8 How reproducible: Always Steps to Reproduce: 1. generate a message with a too-long From line 2. scan +inbox 3. Actual Results: See description for error message. Expected Results: No error message, successful scan. Additional info: I have a patch and will attach it subsequently.
Created attachment 298159 [details] patch to double buffer size (NAMESZ) Makes error go away, but consumes more memory.
Created attachment 298160 [details] modify the spec to apply the patch (doesn't rev version, though) modify the spec to apply the patch (doesn't rev version, though)
Thanks for the bug report! I'm unable to reproduce this. Your error message seems to be coming from pick, and your reproducer tells me to run scan +inbox (which worked for me). Can you give me your pick flags that trigger this? Thanks.
Josh wrote: >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)...@bounce.linkedin.com 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. (If you agree, than this bug report should be closed NOTABUG.)
Yes, I shall close this NOTABUG, and I plan to investigate this properly upstream. I plan to see about dynamically allocating the variable in question, rather than using a stack array.