Re: [yam] Request for comments: draft-ietf-yam-5321bis-smtp-pre-evaluation-00

[Alessandro Vesely <vesely at tana.it>]

S Moonesamy wrote:
> Please post your comments about proposed changes or non-changes to RFC 
> 5321, or any issue related to 
> draft-ietf-yam-5321bis-smtp-pre-evaluation-00 to the YAM mailing list.

I think it would be useful for the WG (and possibly for the IESG) if 
we list and discuss specific changes in pre-evaluation, e.g. as 
subsections of sect. 2.4. I propose to add six subsections with the 
following points:


*** Section 6.1: rewording
In the first paragraph, last clause: substitute

  Some reasons that are not considered frivolous
  are discussed in the next subsection and in Section 7.8.

with

  Some reasons that are not considered frivolous
  are discussed in the next Section 6.2 and in Section 7.8.

Rationale: the "next subsection" phrase, not containing a link, can be 
easily missed by a hasty reader.


*** Section 4.4: remove typo
In the last but one paragraph before production rules, remove the clause

 Note that the key difference between handling aliases (Section 3.9.1)
 and forwarding (this subsection) is the change to the
 backward-pointing address in this case.

Rationale: Section 4.4 is about trace information, not forwarding.


*** Section 2.2.2: add a bullet for the definition of extensions.
It should say that "Future SMTP extensions SHOULD explicitly specify 
if they are valid on the Submission port." [RFC 4409, Sect. 7]

Rationale: not 100% sure, because while RFC 4409 says that, it doesn't 
formally update RFC 2821 (nor RFC 2476 updated RFC 1869.)


*** Section 4.1.1.3 Recipient: missing text.
I don't have specific text to propose here, but I'd recommend 
relegating some or all of the text meant to illustrate source routes 
to an historical appendix. Instead, I would move here the discussion 
on failed recipients (both 4xx and 5xx cases), which I currently find 
difficult to locate.

Rationale: Banning source routes had been a hot issue at the time of 
the DRUMS. Nowadays, non-existence of source routes could simply be 
implied by the fact that they are not mentioned in the Full Standard.


*** Section 3.9.2: remove extra text
Remove the last but one sentence of the first paragraph, the one saying

 Note that the key difference between handling aliases (Section 3.9.1)
 and forwarding (this subsection) is the change to the
 backward-pointing address in this case.

Rationale: this subsection's title is "list", not "forwarding". Since 
the same term is also contrasted with "redistribution" within the same 
paragraph, it results in confusing terminology.


*** Section 3.9: add tiny subsection
I know that adding sections is considered out of topic, but propose 
this change in order to reflect the structure of the protocol more 
clearly. I tentatively number the new subsection as "0", to maintain 
the current numbering of the other two; thus the proposed layout would be:

 3.9 Forwarding
  3.9.0 Backup MX
  3.9.1 Alias
  3.9.2 List

Rationale: Those three subsection would match the available operations 
on the envelope's addresses: 0=unchanged, 1=change recipient(s) only, 
2=change both recipient(s) and sender (the remaining logical 
possibility, change sender only, is not considered in the protocol.)