s-o-1036 June 1994
[< Prev]
[TOC] [ Next >]
5.2. From
The From header contains the electronic address, and possi-
bly the full name, of the article's author:
From-content = address [ space "(" paren-phrase ")" ]
/ [ plain-phrase space ] "<" address ">"
paren-phrase = 1*( paren-char / space / encoded-word )
paren-char = <ASCII printable character except ()<>\>
plain-phrase = plain-word *( space plain-word )
plain-word = unquoted-word / quoted-word / encoded-word
unquoted-word = 1*unquoted-char
unquoted-char = <ASCII printable character except !()<>@,;:\".[]>
quoted-word = quote 1*( quoted-char / space ) quote
quote = <" (ASCII 34)>
quoted-char = <ASCII printable character except "()<>\>
address = local-part "@" domain
local-part = unquoted-word *( "." unquoted-word )
domain = unquoted-word *( "." unquoted-word )
(Encoded words are described in section 4.5.) The full name
is distinguished from the electronic address either by
enclosing the former in parentheses (making it resemble a
MAIL comment, after the address) or by enclosing the latter
in angle brackets. The second form is preferred. In the
first form, encoded words inside the full name MUST be com-
posed entirely of <paren-char>s. In the second form,
encoded words inside the full name may not contain charac-
ters other than letters (of either case), digits, and the
characters "!", "*", "+", "-", "/", "=", and "_". The local
part is case-sensitive (except that all case counterparts of
"postmaster" are deemed equivalent), the domain is case-
insensitive, and all other parts of the From content are
comments which MUST be ignored by news software (except
insofar as reading agents may wish to display them to the
reader). Posters and posting agents MUST restrict them-
selves to this subset of the MAIL From syntax; relayers MAY
accept a broader subset, but see the discussion in section
9.1.
NOTE: The syntax here is a restricted subset of
the MAIL From syntax, with quoting particularly
restricted, for simple parsing. In particular,
the presence of "<" in the From content indicates
that the second form is being used, otherwise the
first form is being used. The major restrictions
here are those already de-facto imposed by exist-
ing software.
INTERNET DRAFT to be NEWS sec. 5.2
NOTE: Overly-lenient posting agents sometimes per-
mit the second form with a full name containing
"(" or ")", but it is extremely rare for a full
name to contain "<" or ">" even in mail. Accord-
ingly, reading agents wishing to robustly deter-
mine which form is in use in a particular article
should key on the presence or absence of "<", not
the presence or absence of "(".
The address SHOULD be a valid and complete Internet domain
address, capable of being successfully mailed to by an
Internet host (possibly via an MX record and a forwarder).
The pseudo-domain ".uucp" MAY be used for hosts registered
in the UUCP maps (e.g. name "xyz.uucp" for registered site
"xyz"), but such hosts SHOULD discontinue this usage (either
by arranging a proper Internet address and forwarder, or by
using the "% hack" (see below)), as soon as possible. Bit-
net hosts SHOULD use Internet addresses, avoiding the obso-
lescent ".bitnet" pseudo-domain. Other forms of address
MUST not be used.
NOTE: "Other forms" specifically include UK-style
"backward" domains ("uk.oxbridge.cs" is in the
Czech Republic, not the UK), pure-UUCP addressing
("knee!shin!foot" instead of
"foot%shin@knee.uucp"), and abbreviated domains
("zebra.zoo" instead of "zebra.zoo.toronto.edu").
If it is necessary to use the local part to specify a rout-
ing relative to the nearest Internet host, this MUST be done
using the "% hack", using "%" as a secondary "@". For exam-
ple, to specify that mail to the address should go to Inter-
net host "foo.bar.edu", then to non-Internet host "ein",
then to non-Internet host "deux", for delivery there to
mailbox "fred", a suitable address would be:
fred%deux%ein@foo.bar.edu
Analogous forms using "!" in the local part MUST not be
used, as they are ambiguous; they should be expressed in the
"%" form.
NOTE: "a!b@c" can be interpreted as either "b%c@a"
or "b%a@c", and there is no consistency in which
choice is made. Such addresses consequently are
unreliable. The "%" form does not suffer from
this problem, and although its use is officially
discouraged, it is a de-facto standard, to the
point that MAIL recognizes it.
Relayers MUST not, repeat MUST not, repeat MUST not, rewrite
From lines, in any way, however minor or innocent-seeming.
Trying to "fix" a non-conforming address has a very high
probability of making things worse. Either pass it along
INTERNET DRAFT to be NEWS sec. 5.2
unchanged, or reject the article.
NOTE: An additional reason for banning the use of
"!" addressing is that it has a much higher proba-
bility of being rewritten into mangled unrecogniz-
ability by old relayers.
Posters and posting agents SHOULD avoid use of the charac-
ters "!" and "@" in full names, as they may trigger unwanted
header rewriting by old, simple-minded news software.
NOTE: Also, the characters "." and ",", not infre-
quently found in names (e.g., "John W. Campbell,
Jr."), are NOT, repeat NOT, allowed in an unquoted
word. A From header like the following MUST not
be written without the quotation marks:
From: "John W. Campbell, Jr." <editor@analog.com>
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../rfc1036/From.out December 1987
+++ ../s-o-1036/From.out June 1994
@@ -1,37 +1,129 @@
-2.1.1. From
+5.2. From
- The "From" line contains the electronic mailing address of the
- person who sent the message, in the Internet syntax. It may
- optionally also contain the full name of the person, in parentheses,
- after the electronic address. The electronic address is the same as
- the entity responsible for originating the message, unless the
- "Sender" header is present, in which case the "From" header might
- not be verified. Note that in all host and domain names, upper and
- lower case are considered the same, thus "mark@cbosgd.ATT.COM",
- "mark@cbosgd.att.com", and "mark@CBosgD.ATt.COm" are all equivalent.
- User names may or may not be case sensitive, for example,
- "Billy@cbosgd.ATT.COM" might be different from
- "BillY@cbosgd.ATT.COM". Programs should avoid changing the case of
- electronic addresses when forwarding news or mail.
-
- RFC-822 specifies that all text in parentheses is to be interpreted
- as a comment. It is common in Internet mail to place the full name
- of the user in a comment at the end of the "From" line. This
- standard specifies a more rigid syntax. The full name is not
- considered a comment, but an optional part of the header line.
- Either the full name is omitted, or it appears in parentheses after
- the electronic address of the person posting the message, or it
- appears before an electronic address which is enclosed in angle
- brackets. Thus, the three permissible forms are:
- From: mark@cbosgd.ATT.COM
- From: mark@cbosgd.ATT.COM (Mark Horton)
- From: Mark Horton <mark@cbosgd.ATT.COM>
-
- Full names may contain any printing ASCII characters from space
- through tilde, except that they may not contain "(" (left
- parenthesis), ")" (right parenthesis), "<" (left angle bracket), or
- ">" (right angle bracket). Additional restrictions may be placed on
- full names by the mail standard, in particular, the characters ","
- (comma), ":" (colon), "@" (at), "!" (bang), "/" (slash), "="
- (equal), and ";" (semicolon) are inadvisable in full names.
+The From header contains the electronic address, and possi-
+bly the full name, of the article's author:
+
+ From-content = address [ space "(" paren-phrase ")" ]
+ / [ plain-phrase space ] "<" address ">"
+ paren-phrase = 1*( paren-char / space / encoded-word )
+ paren-char = <ASCII printable character except ()<>\>
+ plain-phrase = plain-word *( space plain-word )
+ plain-word = unquoted-word / quoted-word / encoded-word
+ unquoted-word = 1*unquoted-char
+ unquoted-char = <ASCII printable character except !()<>@,;:\".[]>
+ quoted-word = quote 1*( quoted-char / space ) quote
+ quote = <" (ASCII 34)>
+ quoted-char = <ASCII printable character except "()<>\>
+ address = local-part "@" domain
+ local-part = unquoted-word *( "." unquoted-word )
+ domain = unquoted-word *( "." unquoted-word )
+
+(Encoded words are described in section 4.5.) The full name
+is distinguished from the electronic address either by
+enclosing the former in parentheses (making it resemble a
+MAIL comment, after the address) or by enclosing the latter
+in angle brackets. The second form is preferred. In the
+first form, encoded words inside the full name MUST be com-
+posed entirely of <paren-char>s. In the second form,
+encoded words inside the full name may not contain charac-
+ters other than letters (of either case), digits, and the
+characters "!", "*", "+", "-", "/", "=", and "_". The local
+part is case-sensitive (except that all case counterparts of
+"postmaster" are deemed equivalent), the domain is case-
+insensitive, and all other parts of the From content are
+comments which MUST be ignored by news software (except
+insofar as reading agents may wish to display them to the
+reader). Posters and posting agents MUST restrict them-
+selves to this subset of the MAIL From syntax; relayers MAY
+accept a broader subset, but see the discussion in section
+9.1.
+
+ NOTE: The syntax here is a restricted subset of
+ the MAIL From syntax, with quoting particularly
+ restricted, for simple parsing. In particular,
+ the presence of "<" in the From content indicates
+ that the second form is being used, otherwise the
+ first form is being used. The major restrictions
+ here are those already de-facto imposed by exist-
+ ing software.
+
+INTERNET DRAFT to be NEWS sec. 5.2
+
+
+ NOTE: Overly-lenient posting agents sometimes per-
+ mit the second form with a full name containing
+ "(" or ")", but it is extremely rare for a full
+ name to contain "<" or ">" even in mail. Accord-
+ ingly, reading agents wishing to robustly deter-
+ mine which form is in use in a particular article
+ should key on the presence or absence of "<", not
+ the presence or absence of "(".
+
+The address SHOULD be a valid and complete Internet domain
+address, capable of being successfully mailed to by an
+Internet host (possibly via an MX record and a forwarder).
+The pseudo-domain ".uucp" MAY be used for hosts registered
+in the UUCP maps (e.g. name "xyz.uucp" for registered site
+"xyz"), but such hosts SHOULD discontinue this usage (either
+by arranging a proper Internet address and forwarder, or by
+using the "% hack" (see below)), as soon as possible. Bit-
+net hosts SHOULD use Internet addresses, avoiding the obso-
+lescent ".bitnet" pseudo-domain. Other forms of address
+MUST not be used.
+
+ NOTE: "Other forms" specifically include UK-style
+ "backward" domains ("uk.oxbridge.cs" is in the
+ Czech Republic, not the UK), pure-UUCP addressing
+ ("knee!shin!foot" instead of
+ "foot%shin@knee.uucp"), and abbreviated domains
+ ("zebra.zoo" instead of "zebra.zoo.toronto.edu").
+
+If it is necessary to use the local part to specify a rout-
+ing relative to the nearest Internet host, this MUST be done
+using the "% hack", using "%" as a secondary "@". For exam-
+ple, to specify that mail to the address should go to Inter-
+net host "foo.bar.edu", then to non-Internet host "ein",
+then to non-Internet host "deux", for delivery there to
+mailbox "fred", a suitable address would be:
+
+ fred%deux%ein@foo.bar.edu
+
+Analogous forms using "!" in the local part MUST not be
+used, as they are ambiguous; they should be expressed in the
+"%" form.
+
+ NOTE: "a!b@c" can be interpreted as either "b%c@a"
+ or "b%a@c", and there is no consistency in which
+ choice is made. Such addresses consequently are
+ unreliable. The "%" form does not suffer from
+ this problem, and although its use is officially
+ discouraged, it is a de-facto standard, to the
+ point that MAIL recognizes it.
+
+Relayers MUST not, repeat MUST not, repeat MUST not, rewrite
+From lines, in any way, however minor or innocent-seeming.
+Trying to "fix" a non-conforming address has a very high
+probability of making things worse. Either pass it along
+
+INTERNET DRAFT to be NEWS sec. 5.2
+
+
+unchanged, or reject the article.
+
+ NOTE: An additional reason for banning the use of
+ "!" addressing is that it has a much higher proba-
+ bility of being rewritten into mangled unrecogniz-
+ ability by old relayers.
+
+Posters and posting agents SHOULD avoid use of the charac-
+ters "!" and "@" in full names, as they may trigger unwanted
+header rewriting by old, simple-minded news software.
+
+ NOTE: Also, the characters "." and ",", not infre-
+ quently found in names (e.g., "John W. Campbell,
+ Jr."), are NOT, repeat NOT, allowed in an unquoted
+ word. A From header like the following MUST not
+ be written without the quotation marks:
+
+ From: "John W. Campbell, Jr." <editor@analog.com>