Hi,
I was hoping someone can shed some light on the proper syntax an SMTP
server should use according to RFC 5321 in the following cases:
1. The syntax definition for commands such as VRFY and EXPN (e.g.
section 4.1.1.6) is
vrfy = "VRFY" SP String CRLF
with the syntax of "String" defined in section 4.1.2 as:
String = Atom / Quoted-string
however, section 3.5.1 states:
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.
I'm not seeing a conflict here. You appear to be reading this as saying that
there are not and cannot be restrictions on the argument syntax. I don't read
it that way. Rather, I read as saying that the syntax cannot be further
restricted from what the syntax currently allows, that is, an Atom or
Quoted-string. And I'm not seeing much justification for reading it any other
way.
Of course in pratice processors allow all sorts of stuff that doesn't
meet these syntax restrictions - addresses are particularly common - but
I'm doubtful there is a consensus to loosen the syntax further, with all that
implies.
What is not entirely clear to me is which is true - is any string of
characters valid (syntax-wise), or must it be a Quoted-string (in double
quotes) if any non-atext characters appear in it. This is especially
confusing having seen various examples online (and some discussions on
this mailing list as well) where pointed brackets are included in the
VRFY argument (using a Path syntax similar to the one defined for the
MAIL FROM and RCPT TO commands), but with no quoting.
And there are processors that accept unadorned addresses too. But I'm not
seeing such examples in RFC 5321. It's hardly news that there's incorrect stuff
out on the 'net and people tend to be pretty careless when throwing examples
around in list mail too.
2. Section 4.1.2 defines the backslash-escaped character mechanism in
quoted-pairSMTP, which is used only in a Quoted-string (within
double-quotes), and does not mention such escaping outside of a
Quoted-string. The following text section states:
Note that the backslash, "\", is a quote character, which is used to
indicate that the next character is to be used literally (instead of
its normal interpretation). For example, "Joe\,Smith" indicates a
single nine-character user name string with the comma being the
fourth character of that string.
So, it is unclear whether this paragraph applies only to the
Quoted-strings defined above, or to any characters in any argument to
any command, or only to mailboxes (discussed in the preceding paragraph)
or some other definition of when it does and does not apply.
On the contrary, I think it's actually pretty clear from the context that this
is discussing the *semantics* (as opposed to the syntax) of backslash within
quoted strings. And this is an important point - it's important to understand
that
"Joe Blow"
and
"Joe\ Blow"
are semantically the same.
That said, I would not object to changing the "Note that the backslash" to
"Note that backslashes in Quoted-String elements" or something similar. But I
don't think this rises to the level of an outright error.
3. Still regarding VRFY (and maybe also EXPN?) section 3.5.1 states:
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:
User Name<local-part@domain>
local-part@domain
Whereas section 3.5.2 claims:
When normal (2yz or 551) responses are returned from a VRFY or EXPN
request, the reply MUST include the<Mailbox> name using a
"<local-part@domain>" construction
This is actually kind of silly in and of itself - since the domain may have to
be determined by some sort of lookup operation on VRFY argument, how can it
possibly be appropriate to require that a 252 "I didn't do anything" response
include a domain? When our server is configured to return 252 responses to
VRFY, it most certainly violates this restriction because it simply echoes the
supplied argument.
Notably, the second example in the former section does not comply with
the latter section (as it contains no pointed brackets). Which is the
correct form?
Well, when you have two conflicting but overlapping requirements, the
safest course is usually to restrict yourself to the overlapping case that
meets both. But this one does warrant an erratum.
Ned