Hi-
I took another pass over rfc2821-08 and came up with a few things I
thought worthy of note, although given how late this is they may
not be worthy enough to do anything about, so ignore if you wish.
Nevertheless, here's the bunch.
====================
2.1, paragraph 7(?), third paragraph on pg 8, ends with:
> the protocol requires that a server MUST either accept responsibility
> for either delivering the message or properly reporting the failure
> to do so (see Section 6.1, Section 6.2, Section 7.8, below).
There's too many "either"s. This looks like it happened when adding the
"MUST". Perhaps there was some intent to say that the server must either
reject the message or: accept responsibility for either delivering the
message or properly reporting the failure to do so. That would explain
the extra "either," because those are the cases. But since the text is
already focused on what happens after a "success response at the
end of the mail data" I suspect it's just an extra "either". It might
be clearer to specifically say that this is still talking about the
situation where the message has been accepted, e.g.:
the protocol requires that after this handoff a server MUST accept
responsibility for either delivering the message or properly
reporting the failure to do so (see Section 6.1, Section 6.2, Section
7.8, below).
Sorry that this is such a long comment on such a trivial thing.
====================
3.1, paragraph 3, begins:
> The SMTP protocol allows a server to formally reject a transaction
> while still allowing the initial connection as follows: a 554
> response MAY be given in the initial connection opening message
> instead of the 220.
Realizing that this text comes from (at least) 2821 and is not new, I
believe this is actually a way to reject a "session" and not a
"transaction". Since "transaction" (or "mail transaction") is a
specific term used in this document to refer to something within a
session, I think that it's not correct here.
====================
3.3, Mail Transactions, paragraph 8 (or so) says:
> If a
> RCPT command appears without a previous MAIL command, the server MUST
> return a 503 "Bad sequence of commands" response.
Again this text is not new.. but it's really more accurate to say "when
a mail transaction is not in progress" than "without a previous MAIL
command" since that's what's intended. e.g. there may have been a
previous MAIL command in a previously completed transaction; there
may have been a previous MAIL command that was rejected, etc.
Just to be consistent in commenting, although I don't think it is
possible to misunderstand, there's similar text later in the section re
the DATA command:
> If there was no MAIL, or no RCPT, command, or all such commands were
> rejected, the server MAY return a "command out of sequence" (503) or
> "no valid recipients" (554) reply in response to the DATA command.
which really means "if there is no transaction open, or no RCPT commands
have been accepted," ...
I also notice that there is nothing that explicitly says when the
processing of the DATA command ends a transaction, from the server state
point of view. There is the statement that the end of mail indicator
"confirms the mail transaction" but this is not the same thing. My
understanding has been that once a DATA command has been OKed (with a
354 reply) and the subsequent response to the data transfer has been
sent (even from data timeout), the server should then go into a state
where no transaction is in progress. But nothing in the text says that.
With this ambiguity, one could believe that another DATA command could
be issued at this point, or that further RCPTs could be given, etc.
While section 4.1.4 (Order of Commands) has a remark about DATA and
transactions (and see later comment), I think that this does belong in a
section called "Mail Transactions" but of course understand that making
these comment at this late time is problematic.
====================
3.5.2. VRFY Normal Response, paragraph 1 begins:
> When normal (2yz or 551) responses are returned from a VRFY or EXPN
> request, the reply normally includes the mailbox name, i.e.,
> "<local-part(_at_)domain>", where "domain" is a fully qualified domain
> name, MUST appear in the syntax.
Again this is not new text, it was in 2821. But... I don't think that's
even a sentence. By the time you get to "MUST appear in the syntax" ,
it's hard to know what exactly must appear in the "syntax". Is this
referring to the mailbox name? If so, then maybe it's clearer to say
something like:
When normal (2yz or 551) responses are returned from a VRFY or EXPN
request, the reply MUST include the mailbox name, i.e.,
"<local-part(_at_)domain>", where "domain" is a fully qualified domain
name.
Not that anybody is really worrying about VRFY; I just tripped over the
wording.
====================
4.1.4 Order of Commands, paragraph 9, contains:
> Once started, a mail transaction consists
> of a transaction beginning command, one or more RCPT commands, and a
> DATA command, in that order. A mail transaction may be aborted by
> the RSET, a new EHLO, or the QUIT command. There may be zero or more
> transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be
> sent if a mail transaction is already open, i.e., it should be sent
> only if no mail transaction had been started in the session, or if
> the previous one successfully concluded with a successful DATA
> command, or if the previous one was aborted with a RSET.
Again, the text is not new. But to be complete, the last sentence
should end with "or a new EHLO" or even "if the previous one was
aborted, e.g. with a RSET or a new EHLO".
And re ambiguity about DATA and transactions: "successfully concluded
with a successful DATA command" leaves one to wonder, what about
"unsuccessfully concluded with a successful DATA command" or other
variations. I would think more like "the previous one concluded by
acceptance and processing of mail data with the DATA command."
In fact I would rather that the document fully define a mail transaction
in only one place (like section 3.3) and refer to that definition, here
saying something like "must not be sent if a mail transaction is already
open (see section 3.3)."
====================
4.2 SMTP Replies, after paragraph 5:
> Greeting = ( "220 " (Domain / address-literal) [ SP text ] CRLF
> ) /
> ( "220-" (Domain / address-literal) [ SP text ] CRLF
> *( "220-" [ text ] CRLF )
> "220" [ SP text ] CRLF )
should mention be made here of the '554' style greeting? The document
does caution that the narrative is authoritative over the abnf, I dunno
if that means it's better to omit it here though. One thought is to
adjust the paragraph below:
> where "Greeting" appears only in the 220 response that announces that
> the server is opening its part of the connection.
to be something like:
where "Greeting" describes only the response that announces that
the server is opening its part of the connection, and where its
numeric code can be either 220 or 554 as discussed in Section 3.1 .
====================
4.3.2 Command-Reply-Sequences, in the DATA description:
> DATA
>
> I: 354 -> data -> S: 250
>
> E: 552, 554, 451, 452
>
> E: 450, 550 (rejections for policy reasons)
If I interpret the indentation correctly, the "E:" cases are for when
the '354' has been given and the mail data sent by the client. This
does not cover the case where a negative response is sent instead of
354. Maybe:
I: 354 -> data -> S: 250
E: 552, 554, 451, 452
E: 450, 550 (rejections for policy reasons)
E: 503, 554
====================
Appendix B, paragraph 2 (numbered "1.") ends:
> If none do, then a bcc: header field with no
> additional information SHOULD be inserted as specified in [32].
I imagine this is under control, but I think [32] means [10].
====================
Appendix D.4 Verifying and Sending Scenario
Do we really want an example using the "SEND FROM" command? Maybe the
point of this is whooshing over my head, but if somebody implements a
server according to this document, the SEND FROM command in this example
will be rejected (particularly since it's not advertised in the EHLO
response as per F.6)
====================
Yours,
-mm-