On Sat, Apr 11, 2009 at 10:16:25AM +0200, Rocco Rutte wrote: > > If you read RFC (2)822, this seems clearly wrong. The only character > > you are allowed to insert for line wrapping is a newline, which MUST > > be inserted before whitespace. > > ACK. The algorithm to me seems quite simple and clear (simply insert > CRLF before the word that would make line too long, just as you > described) which is why I don't understand why the function is that > complicated in the first place. Whenever I stumble about code that seems > to complicated for me, I assume it's there for a reason. Never ASS U ME... ;-) Actually, taking another look at this, I don't understand why this function exists at all... As far as I can tell, there are no circumstances under which a header should *ever* contain any characters other than 7-bit ASCII. RFC (2)822 clearly states so, and the only other standard I'm aware of related to the formatting of headers is RFC 2047, allowing for encoded words to represent non-ASCII character sets; however even here, the non-ASCII characters MUST be encoded using only 7-bit ASCII. The only time this shouldn't be true, as far as I can tell, is when mutt is actually displaying the header to the user, who quite naturally shouldn't be expected to be able to parse RFC-2047 encoded words in his head. But the decoded header should only ever exist in memory for purposes of display; Mutt should never write it out decoded anywhere else. I suspect the fundamental problem is that whoever wrote this wanted it to be used both for writing the headers when sending the message, and also when displaying it... and probably that's the Wrong Thing(tm), since those two operations are inherently very different. But I would need to dig into this much more than I had time for. Anyone know for a fact that I'm wrong? Or, for that matter, that I'm right? Now I'm really not sure what to do here... It would be useful if the original author of mutt_write_one_header() could be identified and brought in for questioning. ;-) Regarding your comments about ticket 2956, clearly using isspace() is problematic, and iswspace() must be also for the same reason. I think the correct way to code that is to write a function that only recognizes 0x20 and 0x09, as those are the only characters allowed by RFC 2822 to be considered linear white space. Anything else very likely has the potential to break someone's e-mail. I won't have time to look into this again until at least this coming weekend... :( Thanks Rocco. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
Attachment:
pgpOhDjPsEzPI.pgp
Description: PGP signature