--On Thursday, 21 February, 2008 01:37 +0100 "Alfred H?nes"
<[EMAIL PROTECTED]> 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
