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.
|
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.
|
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...
|
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.)
|
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 :-)]
|
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.
|
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"
|
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:...)
|
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
|
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?
|