--On Thursday, 21 February, 2008 01:37 +0100 "Alfred H?nes"
<ah(_at_)tr-sys(_dot_)de> wrote:
Hello,
just found the updated version, draft-klensin-rfc2821bis-07
and roughly checked what happened with my comments.
I clearly accept that editorials are going to be deferred to
the RFC Editor, although this tends to increase their work
load. I hope that the messages pointing out the editorial
details are getting forwarded along with the draft to ensure
they must not be dectected again.
Yet, there remain two serious inconsistencies I had pointed
out.
(A) ---- 'supplemental information' in EHLO ----
Section 4.1.1.1, 2nd para, says:
RFC2821, and some earlier informal practices, encouraged
following the literal by information that would help to
identify the client system. That convention was not widely
supported and many SMTP | servers considered it an error. In
the interest of interoperability, | it is probably wise for
servers to be prepared for this string to | occur, but SMTP
clients SHOULD NOT send it.
^^^^^^^^^^^^^^^^^^
Contrary to that recommendation, Section 4.1.4, 5th para says:
The SMTP client MUST, if possible, ensure that the domain
parameter to the EHLO command is a primary host name as
specified for this | command in Section 2.3.5. If this is
not possible (e.g., when the | client's address is
dynamically assigned and the client does not have | an
obvious name), an address literal SHOULD be substituted for the
| domain name and supplemental information provided that will
assist in | identifying the client.
Sorry. The first pointer I got to this was sufficiently
imprecise that I couldn't find the problematic text and hence
assumed it had been removed already. " and
supplemental...client" has been deleted from the statement above
in -08.
...
To resolve this issue, one of the two paragraphs needs to be
changed. Perhaps the least invasive change might be to modify
the 4.1.4 para as follows:
The SMTP client MUST, if possible, ensure that the domain
parameter to the EHLO command is a primary host name as
specified for this command in Section 2.3.5. If this is
not possible (e.g., when the client's address is
dynamically assigned and the client does not have an
obvious name), an address literal SHOULD be substituted for the
| domain name, and supplemental information MAY be provided
that will ^ ^^^^^^^
assist in identifying the client.
This results in the general SHOULD NOT accompanied by the
specific MAY under well described exceptional conditions.
The conclusion from list discussion was that this should be a
MUST NOT, partially because, apparently, many implementations
would reject such a string. So the change above has been made.
If we want to revisit this subject, I think we are headed back
into another Last Call (but that is just my opinion).
(B) ---- multiple recipients and tracing ----
Section 2.3.6 introduces the buffer model.
[ BTW: the "and" in the last line there *is*
confusing/distorting and should better be replaced by
"or"! ]
"and" is actually important since, e.g., it would be common to
discard the buffer associated with a message state (e.g., MAIL
... DATA) and revert to the session state (which might contain
client or server authentication, etc.). That paragraph could be
rewritten completely but I'm reluctant to do anything that would
force another Last Call at this point and that change, IMO,
would. Tony may feel differently, of course.
Section 3.3 says:
The decision to restrict FOR to a single argument was made very
explicitly on the list after a fairly long discussion, including
a discussion about the information loss if multiple addresses
were not listed in response to multiple RCPT commands. That
decision, and the associated syntax restriction, are consistent
with RFC 821 which has
<stamp> ::= <from-domain> <by-domain> <opt-info> ";"
<daytime>
<opt-info> ::= [<via>] [<with>] [<id>] [<for>]
<for> ::= "FOR" <SP> <path> <SP>
that syntax permitted neither multiple FOR clauses nor multiple
paths in a given FOR clause.
Please see if the proposed corrections below adequately realign
other text with that decision. I don't see any way to change
the decision itself unless you can convince Tony to ask Lisa to
reopen the Last Call.
The second step in the procedure is the RCPT command. This
step of the procedure can be repeated any number of times.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
[...]. If accepted, the SMTP
server returns a 250 OK reply and stores the forward-path.
[..] ^^^^^^^^^^^^^^^^^^^^^^^
...
The third step in the procedure is the DATA command (or some
alternative specified in a service extension).
...
The end of mail data indicator also confirms the mail
transaction and tells the SMTP server to now process the
stored recipients and mail data. [...]
^^^^^^^^^^^^^^^^^^^^^
This means that the mail server has taken responsibility for
delivery of the message to *all* recipients from the accepted
RCPT TO commands.
Yes, that is correct. This, so far, has nothing to do with
what information appears in trace header fields.
That's what the trace header field added for this mail
transport 'hop' is presumed to describe precisely.
In making the decision to restrict "For" to one address (and to
revert the specification of this field from 2821 to 821), the
list concluded that this presumption did not exist.
Therefore, in Section 4.4, the 3rd bullet correctly states,
regarding the "Received" trace header field:
o The FOR clause MAY contain a list of <path> entries when
multiple RCPT commands have been given. This may raise
some security issues and is usually not desirable; see
Section 7.2.
This should have been corrected when the decision was
implemented to restrict FOR to one <path>. The text has been
tentatively changed to
If the FOR clause appears, it MUST contain exactly one
<path> entry, even when multiple RCPT commands have been
given. Multiple <path>s raise some security issues and
have been deprecated, see Section 7.2.
Alternate suggestions for text would be welcome as long as they
are consistent with the decision to have only one FOR <path>
clause.
As can be seen, consistent with due diligence, all recipients
should be listed in the FOR clause (unless it is suppresssed
for policy reasons); otherwise, debugging of complicated
forwarding problems would become impossible.
That is not the conclusion reached on the list. That conclusion
was, again, that (i) FOR clauses with multiple paths had not
been widely implemented and supported since provision was made
for them in 2821 and (ii) the security issues associated with
that information outweighed the debugging advantages.
The MAY above cannot be followed unless the syntax allows to
do so. Nonetheless, the ABNF at the very end of Section 4.4
says:
For = CFWS "FOR" FWS ( Path / Mailbox )
This syntax only allows for a *single* RCPT entry.
This is a serious inconsistency with all other related
portions of the memo, as exemplified above. This also is a
significant change from RFC 2821 not expected in this update.
Also, the current draft does not contain any provisions for
the receiving MTA to select from multiple RCPTs for entry of
only a single recipient address into the "Received" trace
header field it has to add.
Therefore, this ABNF rule must be in error.
So please change the ABNF rule back to what RFC 2821 says:
For = CFWS "FOR" 1*( FWS ( Path / Mailbox ))
Again, see above.
best regards,
john