Hi Peter,
At 00:46 16-07-2007, Peter J. Holzer wrote:
> 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:
You are right. That wasn't my intent.
For the VRFY command, the string is a user name or a user name and
domain and the response MUST be in either of the following forms:
| 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
| forms:
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.
Yes. It would be better if the text was more straight-forward. But
it may be too big a change as you mentioned in a previous email.
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.
That changes the meaning somewhat as the string now identifies one
user or one mailbox. Quoting draft-04:
"When a name that is the argument to VRFY could identify more than one
mailbox, the server MAY either note the ambiguity or identify the
alternatives."
Although your text is clearer, it changes the above. Stepping back,
VRFY is there to verify a "user name" and is useful for
debugging. The response may identify the alternative mailboxes if
there is no exact match.
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
forms.
No, local mailboxes does not refer to the local part of the address
only. A host may handle mail for more than one domain. We may have
local-part(_at_)domain returning more than one possibility. All this may
sound ambiguous when compared with the other sections of the RFC.
In this example:
C: VRFY <smith(_at_)example(_dot_)com>
S: 250 smith <smith(_at_)example(_dot_)com>
the mailbox is smith(_at_)example(_dot_)com(_dot_)
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.
I'd prefer that too. But it may not be possible if it affects
existing implementations. However, if people agree to the change,
please use "pointed" brackets instead of angle brackets.
Regards,
-sm