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

On 2007-07-16 10:04:28 -0700, SM wrote:

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 (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.


I think expressing the same meaning in clearer, more straight-forward
text should not be a problem. What we can't do is change semantics,
except where that change reflects current practice and then only very
cautiously. And this of course means that in rephrasing a requirement,
one has to be very careful not to change it. This is why I pointed out
below that I have "probably changed the intended meaning a bit". So that
others could comment on whether there is a change at all and if so,
whether it matters. (I think it doesn't matter, otherwise I wouldn't
have proposed that wording)

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.


I don't think it does. "The string argument is used to identify a user,
a mailbox or a mailing-list" covers the successful case, i.e., a 250
response. The paragraph you quoted covers a 553 response i.e., a special
case of of failure.

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.


Yes, it may. I think it shouldn't (at least not to unauthenticated
users), but that's a policy decision and belongs into the section about
security considerations. I don't think my reformulation changed anything
in this respect.

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.


In practice, yes. I am talking about the assumed intention of the author
here. Of course I don't *know* what they intended, but:

|  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
|  name

sounds to me very much as if the authors saw a contrast between "local
mailbox" and "local-part(_at_)domain". Otherwise, why would the second
sentence start with "however"? And why is it there at all if it was
already stated earlier that a mailbox is identified by an address of the
form "local-part(_at_)domain"? The phrase "user name and domain" earlier in
the section strengthens that impression.

I don't want to step on the toes of John as the editor and other the
contributors of RFC 2821. I know how hard it is to arrive at clear and
consistent formulations, especially if you are rewriting an existing
document and get lots of input from different people with a slightly
different nomenclature. But section 3.5 leaves very much the impression
that it was extended sentence by sentence from what was in RFC 821, and
while each new sentence made perfect sense the whole thing became a bit
inconsistent.

We may have local-part(_at_)domain returning more than one possibility.


Yes, but I don't see what this has to do with my point (and in any case
I'd regard an implementation where this cannot be turned off as of very
low quality).

 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_)


Yes, of course. What are you trying to say?

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.


I think the current RFC is rather clear that pointed brackets are not
required. An implementation may accept them, but it may not require
them. I know that implemenations exist which do require them but I think
they are very rare and am willing to treat that as a bug and would
rather not include it into the RFC. VRFY is already enough of a mess.

        hp

-- 
   _  | 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"

signature.asc
Description: Digital signature