Bug 437652 - pick fails with field name "From ...@bounce.linkedin.com" exceeds 127 bytes
pick fails with field name "From ...@bounce.linkedin.com" exceeds 127 bytes
Product: Fedora
Classification: Fedora
Component: nmh (Show other bugs)
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Josh Bressers
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-15 15:54 EDT by John Heidemann
Modified: 2008-03-18 08:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-18 08:39:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to double buffer size (NAMESZ) (401 bytes, patch)
2008-03-15 15:55 EDT, John Heidemann
no flags Details | Diff
modify the spec to apply the patch (doesn't rev version, though) (560 bytes, patch)
2008-03-15 15:56 EDT, John Heidemann
no flags Details | Diff

  None (edit)
Description John Heidemann 2008-03-15 15:54:21 EDT
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@bounce.linkedin.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@bounce.linkedin.com  Mon Mar  3 02:03:01 2008
Return-Path: <notif+qSVakQSqixxnIDNMC-T3Lx04p25VW39JQgVTHbM4Vv0ir0xnV-CG_gSQxxjCdsSEs56P_1MmEv5E0PNMxxjQFo@bounce.linkedin.com>

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. generate a message with a too-long From line
2. scan +inbox

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.
Comment 1 John Heidemann 2008-03-15 15:55:34 EDT
Created attachment 298159 [details]
patch to double buffer size (NAMESZ)

Makes error go away,
but consumes more memory.
Comment 2 John Heidemann 2008-03-15 15:56:29 EDT
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)
Comment 3 Josh Bressers 2008-03-17 08:10:31 EDT
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?

Comment 4 John Heidemann 2008-03-17 17:29:53 EDT
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

	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

Thanks for the help.

(If you agree, than this bug report should be closed NOTABUG.)
Comment 5 Josh Bressers 2008-03-18 08:39:26 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.