bugThe nmh Mail Handling System - Bugs: bug #14975, Envelope From Limited to 128 Bytes

 
 

bug #14975: Envelope From Limited to 128 Bytes

Submitter:  Ben Mead <benoden>
Submitted:  Mon 14 Nov 2005 03:51:56 AM UTC
   
 
Category:  compatibility Severity:  3 - Normal
Priority:  * 5 - Normal Status:  None
Assigned to:  None Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 23 Oct 2008 06:38:59 PM UTC, comment #9: 

Closed:
1) Raised NAMESZ to 999 bytes, to allow 998 characters in a field name.  RFC 2822 limits line lengths to 998 characters, so field names can't be any longer.  And a field name must be followed by a  colon, so the name itself can be at most 997 characters long.
2) Fixed warning message in m_getfld.c to display NAMESZ - 2 "exceeds" instead of NAMESZ - 1.
3) Added note to docs/MAIL.FILTERING on removing procmail -f or -r options to try to suppress generation of a "From " line on incoming messages.

David Levine <levine>
Group administrator
Tue 22 Nov 2005 09:27:55 PM UTC, comment #8: 

I'm confused now. What is the first line in the file ~/Mail/whatever/nnnn in your MH directory, then? Does it begin with a '>' or not? If not then everything should be fine -- we correctly ignore that line completely. If it does begin with a '>' then we can either (a) handle that the way we do plain 'From ' or declare that anything putting that line into the mail file is broken. I'd still like to know why that '>' is getting there, and I still think you should try the test I suggested.

Also, the file you attached seems to be DOS-line-endings. Can you use tar/gzip or zip or something on your file in the MH directory to keep it out of anybody's mangling clutches and attach it to this bug as a binary, please? (Quote me the md5sum too so I know it's come through cleanly.)

Whether we should accept the full RFC-permitted 800+-byte-long From-nanana-[...]-nanana: header is a separate issue.

Peter Maydell <pm215>
Group administrator
Tue 22 Nov 2005 08:26:51 PM UTC, comment #7: 

My email delivery is clean, but I got bit by over zealous email escaping.  I emailed myself the message as an attachment, then uploaded it, which shouldn't neccessarily put > in front, I'm pretty sure, but Yahoo did.  Sorry about that! 

Thanks for looking into this, Peter.  I agree, taking from and splitting it into Return-Path: and Delivery-Date: would be the way for rcvstore to deal with it consistently, but maybe that makes this bug into something that should wait until the rewrite version, since removing the "From " from the top when using rcvstore may mix up some people's post-filtering.  It's best not to break a lot in minor releases, probably.  I'd love to have this fixed, but I can filter the thing in procmail.

The problem with using inc for delivery is that it takes a file, not standard in. (This came up recently on the list, but I don't think it makes sense to modify inc, unless we want to make rcvstore and inc be the same program with different invocations) Anyway I'd have to put these emails into a temp file and call inc on it at some point to get it in my alerts folder.

Anyway, I understand the MH way for this, and simply bumping the buffer up in size isn't neccessarily consistent, I'll agree there...

Ben Mead <benoden>
Sun 20 Nov 2005 03:23:56 PM UTC, comment #6: 

A test I'd like you to do: send yourself an email that goes via this procmail/rcvstore path which includes a line in the body which starts with "From " (those exact 5 characters, no leading space, no colon, one trailing space). Does it arrive in your MH mail folder correctly or does it have a '>' prepended?

(If it arrives with a '>' then you have a more general problem with something mangling your mail, and if you fix it then the complaints  from scan will go away too. If it doesn't have a leading '>' then more thought is required on our part.)

Peter Maydell <pm215>
Group administrator
Sat 19 Nov 2005 05:21:16 PM UTC, comment #5: 

It looks like the problem is that rcvstore isn't removing the initial From headers from the email (as inc does) and then anything subsequently looking at the file barfs on it. My inclination is to say that it's rcvstore's fault for putting mail into the folder in the wrong format.

"mail can't be automatically delivered to a folder from inc"

What do you mean by that? inc +foldername works... (Genuine question, I'm trying to work out what rcvstore does that inc doesn't, since I don't use it myself.)

NB: re rcvstore bug: (a) if you don't want to update unseen you could always say -nounseen and (b) I believe that nmh 1.2 does locking on the context file so shouldn't suffer from this bug. [I'd like to check that more thoroughly, though :-)]

Peter Maydell <pm215>
Group administrator
Mon 14 Nov 2005 04:47:09 PM UTC, comment #4: 

Attached long_from_test.txt which exhibits this error if either moved to a maildir folder, or piped to rcvstore.  inc -file on this file works, but because mail can't be automatically delivered to a folder from inc, this isn't a satisfactory solution to the problem.

Ben Mead <benoden>
Mon 14 Nov 2005 04:44:32 PM UTC, comment #3: 

More details on this bug.  This is actually a but existant in 1.1-RC4, the current one, not the ancient RC.  It turns out that inc wraps the long lines, but neither procmail nor rcvstore wrap the long header lines, allowing maildir files to have long lines.  It doesn't surprise me that procmail doesn't wrap delivery to maildir folders, but I'd rather have mh commands deal with larger fields than have to do inc or use a patched rcvstore because of the following bug as quoted in the manpage:

If you use the "Unseen-Sequence" rcvstore could  try  to update  the  context while another nmh process is also trying to do so. This can cause the context to become corrupted.  To avoid this, do  not use rcvstore if you use the "Unseen-Sequence"


Ben Mead <benoden>
Mon 14 Nov 2005 12:58:10 PM UTC, comment #2: 

Can you attach an example message and quote a scan command line that would trigger this bug [along the lines of 'scan -file badfile.txt ...']? An easy reproduce case would make this more likely to get fixed. (The files in my Mail/ directory don't have a From header at all, only From:...)

Peter Maydell <pm215>
Group administrator
Mon 14 Nov 2005 03:58:30 AM UTC, comment #1: 

Oh, by the way, this is the error message:
scan: field name "From alerts.kmydqmbqgu3tonjvgy2dmllcofkfmr2bjnghs3cknq4dq5lofztwm4dfpb2u2oksgqwq-artagel_993=excite.com@returns.bulk.yahoo.com " exceeds 127 bytes

Ben Mead <benoden>
Mon 14 Nov 2005 03:51:56 AM UTC, original submission:  

I'm running 1.1rc1, and I'm getting alerts for various Yahoo news stories that have the top from From line longer than 128 bytes.  (The address alone is 126 bytes)  Can this be increased to something like 256 or 512, or at least something configurable at build time?  (I assume it's not at least...)  How tight do we want to be with memory?

Ben Mead <benoden>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #2690:  long_from_test.txt added by benoden (7KiB - text/plain - This file, when piped to rcvstore tickles this bug. With inc, the long lines are wrapped.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by levine (Posted a comment)
  •  

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-10-23 levine Open/ClosedOpen Closed
    2005-11-14 benoden Attached File- Added long_from_test.txt, #3105

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code