ietf-smtp
[Top] [All Lists]

Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax

2007-07-16 10:18:22

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