Re: Update to draft-onions-822-mailproblems-01.txt

[Paul Overell <paulo@xxxxxxxxxxxx>]

In article <9098.796288742@nexor.co.uk>, Julian Onions 
<j.onions@nexor.co.uk> writes
>
>6.2. RFC-822 addresses
>
>   RFC-822 addresses are more complex than might appear at first  sight.
>   The  simple  use  of  <user>@<host> is by far the most prevelant, but
>   when writing a parser, care must  be  taken  with  the  more  unusual
>   format  of addresses. Many implementations deal very badly, or not at
>   all with the more unusual forms  of  addresses.  Take  the  following
>   cases,  which  all  seem  to  cause  one  or  another  implementation
>   indigestion.
>
>      @host,host2:user@host3 "J.Onions"@nexor.co.uk List: user@host.domain;
>      (comment) JOnions (comment) @ (comment) nexor.co.uk (comment)
>      \"f\"@b.foo
>

I assume these are meant to be 5 examples of legal, but unusual, 
addresses:

1       @host,host2:user@host3
2       "J.Onions"@nexor.co.uk
3       List: user@host.domain;
4       (comment) JOnions (comment) @ (comment) nexor.co.uk (comment)
5       \"f\"@b.foo

However, I think examples 1 and 5 are illegal according to RFC-822.  
Example 1 is a route-addr which must be enclosed in <> and is missing 
the "@" before "host2" 

        rout-addr = "<" [route] addr-spec ">"
        route = 1#("@" domain) ":"

So it should read

1      <@host,@host2:user@host3>

Example 5 contains quoted-pairs, to be legal these must be in a quoted-
string.

        local-part = word *("." word)
        word = atom / quoted-string
        atom = 1*<any CHAR except specials, SPACE and CTLs>
        quoted-string = <"> *(qtext / quoted-pair) <">
           
So it should read

5      "\"f\""@b.foo


If these were not intended to be legal then I apologize for my pedantry.

>
>6.3. Received Lines
>
>
>   Note  also  that the "id" construct takes a msg-id construct which is
>   of the form "<" addr-spec ">".
>
RFC1123 seems to have relaxed this syntax

RFC1123 page 53

        *       The ID field MAY contain an "@" as suggested in RFC-822,
                but this is not required.

>
>7.4. Wrapped lines
>
>   Another interesting  little  problem  is  where  a  UA,  or  MTA  has
>   helpfully  wrapped the text of the field to improve readability. Some
>   interesting examples are presented here.
>
>      Content-Type: multipart/mixed; boundary="message
>           -separator" Content-Type: multipart/mixed;
>      boundary="abcdefghijklmno:  boundary:fixed01"
>
>   The first case is debateably correct input, although few MTA/UAs will
>   be  able  to  reconstruct  the  correct separator. The second case is
>   illegal, ambiguous and awkward to treat well.
>

Can we resolve this debate?

        RFC-822 3.1.1. LONG HEADER FIELDS

        ...
        The general rule is that wherever there may be linear-white-
        space (NOT simply LWSP-chars), a CRLF immediately followed by AT
        LEAST one LWSP-char may instead be inserted.

A quoted-string can contain LWSP-chars but not linear-white-space so the 
field cannot be folded here.


-- 
Paul
-------------------------------------------------------------------------
Paul Overell, T U R N P I K E  Ltd                   tel: +44 1306 747747
Dorking Business Park, DORKING, Surrey, UK. RH4 1HN  fax: +44 1306 747749