[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Update to draft-onions-822-mailproblems-01.txt
- To: info-ietf-smtp@xxxxxxxxxxxx
- Subject: Re: Update to draft-onions-822-mailproblems-01.txt
- From: Paul Overell <paulo@xxxxxxxxxxxx>
- Date: Wed, 29 Mar 1995 14:59:16 +0100
- Newsgroups: info.ietf.smtp
- Organization: Turnpike Ltd
- References: <firstname.lastname@example.org>
In article <email@example.com>, Julian Onions
>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
> @host,host2:user@host3 "J.Onions"@nexor.co.uk List: firstname.lastname@example.org;
> (comment) JOnions (comment) @ (comment) nexor.co.uk (comment)
I assume these are meant to be 5 examples of legal, but unusual,
3 List: email@example.com;
4 (comment) JOnions (comment) @ (comment) nexor.co.uk (comment)
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
Example 5 contains quoted-pairs, to be legal these must be in a quoted-
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
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 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