Continued header lines?

Continued header lines?

[Simon Josefsson]

I found a IMAP server [1] that completely garble mail (data
corruption) if you use long header lines such as

Foo: bar
 baz

e.g. padding continuation header lines with SPC.  Using TAB instead
seems to work.  Maybe Gnus should do what most other mailers seem to
do (use TAB, that is)?

[1] The server is the kind of server you often wish you could
exchange, if you catch my drift.

Re: Continued header lines?

[Jesper Harder]

jas@extundo.com (Simon Josefsson) writes:

> I found a IMAP server [1] that completely garble mail (data
> corruption) if you use long header lines such as
>
> Foo: bar
>  baz
>
> e.g. padding continuation header lines with SPC.  Using TAB instead
> seems to work.  Maybe Gnus should do what most other mailers seem to
> do (use TAB, that is)?

I think that would be wrong according to RFC 2822. If you fold

Foo: bar baz

as

Foo: bar
<HTAB>baz

Then you would get

Foo: bar<HTAB>baz

when unfolding the header, which isn't the same as the original.

Re: Continued header lines?

[Simon Josefsson]

On Tue, 2 Oct 2001, Jesper Harder wrote:

> > e.g. padding continuation header lines with SPC.  Using TAB instead
> > seems to work.  Maybe Gnus should do what most other mailers seem to
> > do (use TAB, that is)?
>
> I think that would be wrong according to RFC 2822. If you fold
>
> Foo: bar baz
>
> as
>
> Foo: bar
> <HTAB>baz
>
> Then you would get
>
> Foo: bar<HTAB>baz
>
> when unfolding the header, which isn't the same as the original.

Argh, you are right.  I guess I'll have to trust that the server vendor
fixes the bug then...

Re: Continued header lines?

[Paul Jarc]

Simon Josefsson <jas@extundo.com> wrote:
> On Tue, 2 Oct 2001, Jesper Harder wrote:
>>> e.g. padding continuation header lines with SPC.  Using TAB instead
>>> seems to work.  Maybe Gnus should do what most other mailers seem to
>>> do (use TAB, that is)?
>>
>> I think that would be wrong according to RFC 2822.
...
> Argh, you are right.  I guess I'll have to trust that the server vendor
> fixes the bug then...

Gnus could use long header lines instead of wrapping them, couldn't
it?  Or would that cause problems with other badly-written things?


paul

Re: Continued header lines?

[Jesper Harder]

prj@po.cwru.edu (Paul Jarc) writes:

> Gnus could use long header lines instead of wrapping them, couldn't
> it?  Or would that cause problems with other badly-written things?

It would violate RFC 2822:

,----
|    There are two limits that this standard places on the number of
|    characters in a line. Each line of characters MUST be no more than
|    998 characters, and SHOULD be no more than 78 characters, excluding
|    the CRLF.
`----

Re: Continued header lines?

[Jesper Harder]

jas@extundo.com (Simon Josefsson) writes:

>> [Header folding with SP or HTAB]
>
> Argh, you are right.  I guess I'll have to trust that the server vendor
> fixes the bug then...

Hmm, it probably wouldn't hurt to use HTAB for folding in mail headers,
which aren't supposed to be displayed.

E.g. it doesn't really matter if the msg.id's in the References header
are separated by SP or HTAB. But it *does* matter if SP is replaced by
HTAB in the Subject.

But for news USEFOR thinks that HTAB shouldn't be used for whitespace at
all:

,----[ 4.2.3.  White Space and Continuations ]
|
|    Posters and posting agents SHOULD use SP, not HTAB, where white space
|    is desired in headers (some existing software expects this), and MUST
|    use SP immediately following the colon after a header-name. Relaying
|    agents SHOULD accept HTAB in all such cases, however.
`----

Re: Continued header lines?

[Jeff Senn]

Jesper Harder <harder@ifa.au.dk> writes:

> prj@po.cwru.edu (Paul Jarc) writes:
>
>> Gnus could use long header lines instead of wrapping them, couldn't
>> it?  Or would that cause problems with other badly-written things?
>
> It would violate RFC 2822:
>
> ,----
> |    There are two limits that this standard places on the number of
> |    characters in a line. Each line of characters MUST be no more than
> |    998 characters, and SHOULD be no more than 78 characters, excluding
> |    the CRLF.
> `----

FWIW: I've even noticed that some 80<lines<998 cause (some versions
of?) Eudora to screw up it's header parsing....

-- 
-Jas   --------------------     www.maya.com
       Jeff Senn          |   / / |-/ \ / /|
       Chief Technologist |  /|/| |/ o | /-|
       Head of R&D        | Taming Complexity