On 2007-07-15 12:11:48 -0700, SM wrote:
At 10:17 15-07-2007, Peter J. Holzer wrote:
C: VRFY <smith(_at_)example(_dot_)com>
S: 250 smith <smith(_at_)example(_dot_)com>
C: VRFY smith(_at_)example(_dot_)com
S: 250 smith <smith(_at_)specific(_dot_)example(_dot_)com>
The last two would be a separate example, I think.
It could go after the second paragraph of Section 3.5.1.
For the VRFY command, the string is a user name or a user name and
domain and it MUST be in either of the following forms:
You cut too much here. The "it" refers to the response, not the string:
| For the VRFY command, the string is a user name or a user name and
| domain (see below). If a normal (i.e., 250) response is returned,
| the response MAY include the full name of the user and MUST include
| the mailbox of the user. It MUST be in either of the following
But that snippet indicates that the notion what a "user name" is changed
during the preparation of RFC 2821: "user name and domain" just doesn't
make sense when the user name already includes the domain.
Also the description of the string argument is split into 3 paragraphs
with different material between, which makes it a bit hard to follow.
Maybe the whole section should be rearranged:
SMTP provides commands to verify a address or obtain the content of
a mailing list. This is done with the VRFY and EXPN commands, which
have character string arguments. Implementations SHOULD support VRFY
and EXPN (however, see Section 3.5.2 and Section 7.3).
The string argument is used to identify a user, a mailbox or a
mailing-list. An implementation of the VRFY or EXPN commands MUST at
least recognize the exact names of local mailboxes in the standard
"local-part(_at_)domain" format (see Section 2.3.11). Hosts MAY also
choose to recognize other strings, for example the mailbox address
enclosed in angle brackets, the local part of an address or a
substring of the full name of the user owning the mailbox.
The character string arguments of the VRFY and EXPN commands cannot
be further restricted due to the variety of implementations of the
user name and mailbox list concepts. On some systems it may be
appropriate for the argument of the EXPN command to be a file name
for a file containing a mailing list, but again there are a variety
of file naming conventions in the Internet. Similarly, historical
variations in what is returned by these commands are such that the
response SHOULD be interpreted very carefully, if at all, and SHOULD
generally only be used for diagnostic purposes.
and then the rest of the section with minor changes.
I've eliminated the term "user name", because strictly speaking that
relates only to VRFY, not to EXPN. I have also probably changed the
intended meaning a bit: I think "local mailbox" was intended to refer
only to the local part of the address (otherwise "local-part(_at_)domain
SHOULD be recognized" makes no sense) but that contradicts section
2.3.11, which states that a mailbox is identified by an address of the
form local-part(_at_)domain(_dot_) So to be consistent I've made that form
compulsory and listed "local part only" as one of the optional other
| An implementation of the VRFY or EXPN commands MUST include at least
| recognition of local mailboxes as "user names". However, since
| current Internet practice often results in a single host handling
| mail for multiple domains, hosts, especially hosts that provide this
| functionality, SHOULD accept the "local-part(_at_)domain" form as a "user
So "local maiboxes" MUST be supported ans "local-part(_at_)domain" SHOULD be
supported. But how is a mailbox specified?
| The standard mailbox naming convention is defined to be
Seems a bit redundant to prescribe the same form both via MUST and
"User name" is a fuzzy term and has been used deliberately. An
implementation of the VRFY or EXPN commands MUST include at least
recognition of local mailboxes as "user names". However, since
current Internet practice often results in a single host handling
mail for multiple domains, hosts, especially hosts that provide this
functionality, MUST accept the "local-part(_at_)domain" form as a "user
name"; hosts MAY also choose to recognize other strings as "user
names" or require the user name to be enclosed in pointed brackets.
Hmm. I'd prefer it if the RFC clearly specified one specific format
which must be recognized. If some implementations require the user name
to be enclosed in angle brackets and some require it not to be enclosed
in angle brackets the client needs to try both. See above for an
alternate clarification which makes the address without angle brackets
mandatory and with angle brackets optional, which is closer to my
understanding of the current RFC.
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Description: Digital signature