On 2007-10-19 11:34:32 -0400, Charlie Brady wrote: > On Thu, 18 Oct 2007, David Nicol wrote: > >FWIW, later on http://cr.yp.to/im/address.html Bernstein says > > > >"Do not use an empty box part; it cannot appear in SMTP requests."
I think Bernstein is mistaken here. He should have written "it requires
quoting in mail headers and SMTP" like he did for many of the other
troublesome forms.
> That's actually an open question, due to what appears to be a drafting
> error in RFC2821. In 4.1.2 Command Argument Syntax, we see:
>
> ...
> Mailbox = Local-part "@" Domain
>
> Local-part = Dot-string / Quoted-string
> ; MAY be case-sensitive
>
> Dot-string = Atom *("." Atom)
>
> Atom = 1*atext
>
> Quoted-string = DQUOTE *qcontent DQUOTE
> ...
>
> But qcontent is undefined.
That's intentional:
| routes as described in appendix C. Terminals not defined in this
| document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in
| the "core" syntax [8 (section 6)] or in the message format syntax
| [32].
...
| [8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
| Specifications: ABNF", RFC 2234, November 1997.
...
| [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
| 2001.
qcontent is defined in RFC 2822.
But the ABNF in RFC 2821 is not complete and is intended only as a
supplement to the textual description. Unfortunately this won't be fixed
in RFC 2821bis, either: While creating a complete ABNF was discussed,
the risk of introducing incompatible changes was considered too high for
a transition from proposed to draft standard and nobody even tried to do
it.
> Note however the following paragraph:
>
> While the above definition for Local-part is relatively permissive,
> for maximum interoperability, a host that expects to receive mail
> SHOULD avoid defining mailboxes where the Local-part requires (or
> uses) the Quoted-string form or where the Local-part is case-
> sensitive. For any purposes that require generating or comparing
> Local-parts (e.g., to specific mailbox names), all quoted forms MUST
> be treated as equivalent and the sending system SHOULD transmit the
> form that uses the minimum quoting possible.
>
> This seems to require that "" and empty must be treated equivalently, and
> empty is clearly not valid.
I don't see that requirement. "All quoted forms" must be treated as
equivalent. That is probably intended to include non-quoted forms but I
don't think it is intended to include invalid forms.
So
<[EMAIL PROTECTED]>
<"foo.bar"@example.net>
<"\fo\o\.\b\a\r"@example.net>
must all be treated identically, but an invalid form like
<foo . [EMAIL PROTECTED]> or
<"foo"[EMAIL PROTECTED]>
must not. It's simply an error and should be treated as such.
> The sending system should also use the empty
> form, rather than quoting an empty string.
No. Clearly it cannot do this since the empty form is not valid. It
should use the minimum possible quoting, which in this case is "".
> RFC2822 also makes it clear that "quoted-string is identical to atom,
> semantically" so although ""@domain is syntactically permitted by RFC2822
> (perhaps in error), it is not semantically valid.
I don't see that either. If that meant that a quoted string can only
contain the same characters as an atom, a quoted string would not be
necessary. The quoted string exists precicely because the for some uses
the syntax of the atom is too restrictive. I doubt they really intended
to allow empty local parts in email addresses, but other forms which
cannot be represented by atoms, like mail-addresses with embedded spaces
where almost certainly intentional.
(Personally, I find the RFC 822 mail address syntax ludicrously bizarre.
At least RFC 2822 marked some of it as obsolete, but there's still a lot
of wierd stuff left, like control characters in the local part).
hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | [EMAIL PROTECTED] |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
signature.asc
Description: Digital signature
