[Pan-users] Re: Problems with some replies

[Duncan]

Jim Henderson posted on Mon, 15 Dec 2008 18:05:47 +0000 as excerpted:

> On Sat, 13 Dec 2008 16:22:43 -0600, HarryB wrote:
> 
>> Ok, so I started composing my question and decided to do some more
>> tinkering to refresh my memory. And I found a difference between the
>> way Free Agent and Pan puts information in the References area. FA puts
>> them all on the same line with a single space between the IDs. So, FA's
>> References looks like this: References: <ID> <ID> <ID> etc.
>> 
>> But, Pan's looks different. Pans puts the references on a separate line
>> and appears to have a tabbed space before each ID. Here is a sample [1]
>> of one header:
> 
> What you're showing in the header there is RFC-compliant line-breaks for
> the headers - the tab signals the server that it's a continuation line
> for the previous header.  That *shouldn't* cause a problem unless the
> server is misconfigured (which it sounds like it is).
> 
> If I remember correctly, that is. :-)

Yeah, I know this thread's old, but I'm going back thru my messages saved 
as unread for further processing later...

You're correct.  IIRC in the RFC it's referred to as "header folding".

Some further detail...  The RFCs specify that no line may be more than 
1000 chars long -- 998 plus the line terminating CRLF sequence.  However, 
that's incredibly difficult for humans to read as it involves horizontal 
scrolling.  Also, the "Internet message" RFCs cover both mail and news, 
in general, and were originally developed for mail, then adapted for 
news.  (FWIW, this is why it's quite common for a client to combine both 
mail and news functions in the same application, once one is properly 
supported, it's very little more work for a lot of additional 
functionality, to properly support the other one as well.) Back when they 
designed the mail spec, the Internet wasn't the common standard it is 
today, and there were a lot of conflicting proprietary and semi-
proprietary message formats, including some that didn't handle lines 
longer than 80 characters (the text display width of old terminals) very 
well if at all.  One of the major goals of the RFCs that became the mail 
(and thus news) standards was to create a spec that minimized difficulty 
in translating between them.  Thus, the allowance for "header folding", 
and a standardized reduced individual line length of < 80 chars (78 + 
terminating CRLF), with a properly defined method for folding longer 
headers and then unfolding them again, so (providing the spec was 
followed, of course) the end result was interpreted the same as if it had 
never been folded.

So if any server or filter isn't prepared to accept properly[1] folded 
headers, it's out of RFC compliance and doesn't deserve to be running on 
the Internet.  It's as simple as that.

More generally, of course, the legacy 80 character hardware terminal 
limit remains visible today in all sorts of applications.  Mail and news 
isn't the end of it by /far/.

Not that any of that really helps with the posted problem, except to 
clarify where it is -- not with pan.

-----

[1] Properly folded headers:  Or even "improperly" folded, provided they 
are still sane enough to make sense out of, given that the RFCs strongly 
recommend that applications be strict in what they send, complying with 
the RFCs in the strictest sense possible, but relaxed in what they 
accept, doing whatever they can to make sense of even noncompliant 
received content.  This BTW is a common rule running throughout the RFCs, 
all of them, thus applying in general to pretty much any RFC standardized 
behavior on the net at all.  Of course, in RFC parlance it's a SHOULD not 
a MUST, meaning it's strongly recommended, but they recognize that 
individual implementations will have different practical limitations 
imposed upon them, everything from being a new product that's struggling 
to implement even the MUSTs correctly, to an implementation running on a 
machine with less resources than today's common cellphone -- keeping in 
mind that's more resources than a major server often had back in those 
days.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman