On Fri, May 25, 2012 at 10:44:02AM -0600, Aaron Toponce wrote: > On Fri, May 25, 2012 at 10:50:07AM -0500, Derek Martin wrote: > > There's a lot to wade through, but the answer is here: > > > > http://dev.mutt.org/trac/ticket/2995 > > > > It turns out this is kind of hard to get exactly right. > > Paying closer attention to some other headers, it appears that some > software uses the <tab>, some use a single <space>, and some use 8 > <spaces>. Also, RFC 2822 only mentions what happens on the unfold, not how > a fold itself should be created, although I can understand the argument on > why a <tab> would be "a bad idea".
It's probably worth noting that this is less of an issue for most modern clients, because they are GUI apps that use text boxes to input/display the relevant headers as you're composing (and thus do not require any fancy machinations to display the headers neatly), and (typically) just dump the entire message in a read-only text box or similar control when reading. This issue originally arose in Mutt because it formats the message for editing, it wraps long headers with tab characters, and sent the message out that way. But some mail clients don't correctly handle a tab character in displayed headers. It seems your specific problem (adding custom headers outside the editor) is a case that wasn't thought of / tested when the original bug was fixed... Or, it was (I myself made some mention of replacing tabs with spaces late in that bug) and deemed to be acceptable loss. It is odd though, because all (or nearly all) of the other long headers in your message are apparently wrapped with tab characters. -- 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.
pgpztrbem1S1B.pgp
Description: PGP signature
