Hi John,
My apologies for my delay in response. In responding, I am looking at
the -32 version while my comments originally referred to -31.
On Wed, Oct 16, 2024, at 2:22â AM John C Klensin <john-ietf@xxxxxxx> wrote:
> ...
>
> Because the response below proposes several changes to the document
> and to encourage them to check my explanations, I've explicitly
> copied the WG mailing list.
Sure, I should have copied the WG on my initial message.
> ...
>
> When EMAILCORE was chartered, and even going back to the first draft
> charter in September 2020, the explicit plan was for it to produce
> three documents: The first two were to be Internet Standard
> replacements for RFC 5321 and 5322. They were constrained, by both
> the charter and by the rules for Internet Standard, to the scope and
> coverage of their predecessors. The third document (which is
> mentioned at the end of Section 1.2 and that is still in progress in
> the WG as draft-ietf-emailcore-as) was to be an Applicability
> Statement that addressed other work and related issues in the email
> world. The result of those constraints and decisions was that a
> discussion of, e.g., DMARK and DKIM was out of scope for the current
I did not suggest a discussion of DMARK or DKIM. I suggested that they
be mentioned.
> document and very much in scope for that A/S. There are additional
> issues about they, and related work, should be handled there, more on
> that inline below.
>
> ...
>
> On to specifics.
>
> --On Friday, October 11, 2024 23:56 -0400 Donald Eastlake
> <d3e3e3@xxxxxxxxx> wrote:
>
> > ...
> >
> > The summary of the review is Has Issues.
> >
> > This document is an obsoleting revision of RFC 5321 on the Simple
> > Mail Transfer Protocol (SMTP), incorporating Errata, etc. It is a
> > mix of specification, operational, and historic information.
> > Changes from RFC 5321 are summarized in Appendix F. I did not
> > review the Acknowledgements or References sections or Appendices C
> > or E.
> >
> > Security
> > --------
> >
> > This document has an extensive Security Considerations section
> > which covers most points. But I have the following suggestions:
> >
> > Section 7: Could be clearer on what the threat model is.
>
> I agree, but going much further than the current text goes would
> probably take us down a rather deep rabbit hole (or several of them).
> The WG therefore decide to kick the rabbits down the road to the A/S.
If some of the Security Considerations are actually deferred to the
Applicability Statement, then this document should clearly say that is
what is being done. It should say that in the Security Considerations
section, perhaps between the 7. and the 7.1 headers.
> The question that obviously raises is whether the Last Call on this
> document should be held until some of it can be reviewed in parallel
> with a version of the A/S that the WG thinks is ready for
> publication. I would prefer to avoid that because it would create a
> near-invitation for going back and forth about what should be in the
> A/S and what details or explicit references should be slipped back
> and forth between the A/S and this document. FWIW, the WG spent many
> months on similar issues involving the relationship between the
> current document and draft-emailcore-rfc5322bis, which has gone
> through IETF LC and has been approved by the IESG. Holding this
> document (referred to below as rfc5321bis) would also be a good
> argument for holding rfc5322bis. I think it is safe to say that
> neither the WG nor our long-suffering AD would be happy about such
> holds. My personal concern is that it might result in further
> attrition among those active in the WG, possibly reducing the breath
> of perspectives and quality of the work, especially on the A/S, and
> consequently considerably extend the time it will take to get all
> three documents out.
It seems unusual for much of the Security Considerations for an IETF
protocol specification to be in a separate Applicability Statement
document. Maybe the Applicability Statement should be renamed to
something more inclusive. If the threat model is in part deferred to
the other document, this document should clearly say so in the
Security Considerations section.
> ...
>
> > Section 7.1, particularly re 1st paragraph: Shouldn't there be some
> > mention of DMARC (RFC 7489) and DKIM (RFC 6376) and perhaps other
> > things that don't come to my mind immediately?
>
> No. See above.
As above, I asked for a mention, not a discussion of these.
This document is extraordinarily focused on what are, to my mind, 2nd
order application-level security concerns and gives essentially no
weight to the obvious primary threat of observation of plain text
email in flight. The concerns covered are real concerns and I am not
suggesting taking anything out, but it is a symptomatic security flaw
of this document that the character string "encrypt" occurs nowhere in
the main body of the document. That you can spoof mail, leak
information in trace lines and through some commands, and the few
other things mentioned are not the only thing insecure about SMTP.
It's like this document was written before pervasive surveillance was
a thing (RFC 7258).
Suggest changing the beginning of Security 7.1 from "SMTP mail is
inherently insecure ..." to "The authenticity of SMTP mail is not
secure..." since that's what Section 7.1 is about.
> And those two documents in particular have a
> difficult relationship with part of the threat model. Some people
> would argue that most (or nearly all) of the Internet's email goes
> directly from the administrative domain of the sender to the
> administrative domain of the recipient. A few would even argue that
> the numbers are large enough that the hop-by-hop model --one has been
> part of mail transport since about the time the community gave up to
> transporting mail over FTP -- should be deprecated. Perhaps
I like the SMTPhop-by-SMTPhop model. I don't see why you are dragging
this issue into the discussion. This document is clearly based on the
SMTPhop-by-SMTPhop model and I don't see how I have suggested any
change in that model. Your paragraph above seems to have almost
nothing to do with my comments.
> unfortunately, counterexamples abound because even simple mail
> forwarding and list expansion introduce intermediary systems. Those
> intermediary systems -- whether mail relays or something more
> complicated -- have the potential to alter any part of the mail
> headers they receive. Whether such alterations are deliberate or
> accidental results of other processing, there are many examples of,
> e.g., DKIM/DMARC not being trustworthy beyond the most recent hop
> and, in a multihop environment, therefore fairly useless in
> authenticating the sender or the identity of the received message to
> the original one.
The Security Considerations for DKIM/DMARC are issues for the Security
Considerations of the RFCs for those protocols. This document should
mention them and point to their Security Considerations in their RFCs.
There is little need to discuss their Security Considerations in this
document, just mention them and point to them.
> The problem runs even deeper: running SMTP over TLS provides
> encryption protection in transit between hosts but, if any
> intermediate host is compromised, the message is (at least as far as
> any protection from TLS) sitting on that host in the clear.
Of course, that's obvious. It is a general characteristic of link
security being unable to provide end-to-end security and a general
characteristic of "store and forward" systems (even if the
implementation is actually pipelined).
In a unified Security Considerations section for SMTP, it would be
reasonable to classify most of those Considerations into end-to-end
considerations and SMTPhop-by-SMTPhop considerations. I'm not asking
for detailed Security Consideration in SMTP documents for any of such
end-to-end or SMTPhop-by-SMTPhop protocols. Their Security
Considerations should be in their RFCs. You mention PGP and S/MIME but
don't discuss them. I have not seen from you any good reason to not,
in an analogous way, mention DKIM and DMARC without discussing them.
> I hope I'm not just passing the buck here, but I believe that
> documentation of these threats are more properly something that
> should be done in Security Area documents than somehow discussed in
> depth as part of SMTP or even in the proposed A/S.
I'm not an AD and the boundaries between Areas in the IETF are quite
flexible. But I think that generally the Security Area does not
consider it to be the Security Area's job to do threat analysis for a
particular application protocol that is in another area.
> > Section 7.1, particularly re 2nd paragraph: I think it would be
> > useful to mention something like the following:
>
> > 1. Transport authentication between SMTP systems could improve the
> > authenticity of the Received line added by a server but does not
> > protect those lines against modification, in violation of this
> > document, by subsequent SMTP systems.
> > 2. Nation State intelligence agencies and others on occasion, have
> > been known, even in the case of extremely high bandwidth traffic
> > mixing many streams, for example between large data centers, as
> > well as lower bandwidth connections, to capture and hold immense
> > quantities of raw traffic for potential later analysis, so there
> > may be good reason to encrypt transmissions between SMTP systems.
>
> See Section 6 of the draft A/S. I personally don't think that goes
> far enough and have said so in correspondence within the WG; your
> suggestions add to that belief or might suggest an additional
> document.
Feel free to use any text I suggest in any of the documents.
> > Non-Security
> > ------------
> >
> > Section 6.1, 6.2: I do not quite understand saying that something is
> > mandatory/required and then talking about where it is impossible or
> > impractical to do that thing. Section 6.1 says, concerning a host
> > holding an email message, "It MUST NOT lose the message for
> > frivolous reasons, such as because the host later crashes ...".
> > "frivolous" does not seem very well defined for a mandatory
> > implementation requirement. The only examples given later of
> > non-frivolous reasons seem to be spam or "hostile" (infected?)
> > messages. Maybe this should be more like "In so far as practical,
> > messages MUST NOT be accidentally lost. For example, messages and
> > their processing state should be committed to non-volatile storage
> > until responsibility is taken for that message by the next host in
> > the delivery path." or something like that. In Section 6.2, how
> > does it make sense to say that something is required and
> > impractical?
>
> Yeah. This problem goes back to RFC 2821, i.e., it has been with us
Perhaps I am sacrilegious, but I don't care how far back it goes. That
something was poorly or contradictorily stated in obsoleted
predecessor documents and there has not been a disaster is not a
reason to refrain from simple obvious improvements to the text in this
document.
> since decisions made in the last century. Indeed, that particular
> text goes back more than another decade: it is copied, almost
> exactly, from RFC 1123 (and I didn't write that paragraph then
> either). The ideal solution, at least in or before RFC 2821 was
> published in 2001, would have been to completely restructure and
> rewrite this rather complicated combination of previous documents.
> See Section 1.2 for an explanation of that problem. We could
> re-think and tune some localized text now, but it is not clear that
> it would make much difference. Some of the obvious fixes would be
> substantive (e.g., if something is not really mandatory/required,
> probably any associated or implicit MUSTs should be changed to
> SHOULDs and then explained better. This time around, the WG has been
> very reluctant to make changes like that and has decided to minimize
> change especially when there was no significant evidence of real harm
> or serious confusion in the last 16 years (or much longer).
>
> Again, and at least in retrospect, I think we should have completely
> rewritten the thing during DRUMS in 1995-2001. We (the WG at the
> time) decided to not do that, in part because the risk of introducing
> errors that would effect existing deployed implementations. Now,
I do not think that changing the documentation actually reaches out
and changes the deployed successfully running code to introduce
errors.
> even if we wanted to do so, I don't believe that there is either
> sufficient energy or resources to do that rewrite, nor am I confident
> that a subsequent review that would catch all discrepancies. The WG
> very briefly discussed the "full rewrite" option and reached the same
> conclusion.
I have not suggested a complete rewrite. I have not suggested even one
change of a "MUST" to a "SHOULD". I am above just suggesting improved
wording in Section 6.1 and complaining about the conflict in Section
6.2
6.2 could be trivially fixed by simply replacing "requires that
messages that can be delivered should be delivered" with "benefits
when messages that can be delivered are delivered". I do note that
this "requires" statement does not use a capitalized keyword and is
softened by the lower case "should". I did not notice any
self-contradiction as egregious as this elsewhere in the document.
> ...
>
> > Minor
> > -----
> >
> > Global: RFC 821 is obsolete. It was published 42 years ago and
> > obsoleted 21 years ago. Is there really a need for references to it
> > in this document?
>
> Procedural/nitpicky explanation: Due to a twitch in our vocabulary
> and how aspects of RFC 2026 have been implemented, "obsoleted" is a
> tricky term. Yes, RFC 2821 listed RFC 821 as being obsoleted but the
I do not think "obsoleted" is "tricky" for the purposes of this
document. I see the purpose of a Standards Track protocol document as
enabling developers to produce interoperable implementations. If the
IETF says "X obsoletes Y" then they are correct if you can do such
implementations based on X. If you still have to read Y to produce
interoperable implementations, then the declaration of obsolescence
was wrong.
> RFC index and metadata still lists it as STD 10 and is the only
> Internet Standard among core email documents (unless you count RFC
> 6409). I have believed, at least on and off, for a long time that any
> standards Track or BCP document that is obsoleted should have its
> status changed to "Obsolete" or something like that. But that is not
> what the RFC Editor does and, when I have raised this with a few
> generations of RFC Editors (but probably not to RSWG), they expressed
> the view that it would require a change to RFC 2026. I could
> certainly see getting rid of the NCP, NITS, and X.25 appendices (the
> latter if someone could prove it is really dead worldwide). But even
I have looked at the X.25 appendix to RFC 821. It is only one sentence
and all it says is that if your lower level transport is X.25, you
should use TCP over it. seems pretty vacuous to me.
> that would require more, possibly error-attracting, fussing with the
> text than anyone in the WG was inclined to propose.
>
> That does suggest one addition to the document. In Section 1.2, the
> paragraph starting "It obsoletes" should perhaps contain an
> additional sentence explicitly removing the "Internet Standard"
> status from RFC 821. If that is needed, draft-emailcore-rfc5322bis
> should be similarly patched. Do you (and others) think such a fix
> would be desirable?
I see this has been added.
> More substantive answer: the present document contains significant
> text copied from RFC 821 but without the context being copied. The
> references to 821 could be removed but only at the expense of
> rewriting sections to include more of that context. Similar comments
> might be made about some of the other very old documents being
> referenced although 821 is the oldest. It is probably the one that
> is most sensitive to citations vis-a-vs the later ones.
In my opinion, the purpose of a Standards Track protocol RFC is to
provide the information developers need to produce interoperable
implementations. If you are saying that there is material in RFC 821
that developers must read to produce interoperable implementations,
then you should just plain confess that the chain of obsoletes going
back from this document is wrong and you should tell developers up
front in this document that they have to study RFC 821 as well as this
document in order to produce an interoperable implementation. If you
are saying that there are historical aspects or ultra fine gradations
of something or other that might be conveyed by reading RFC 821 but
don't affect implementation, then you should say that and you should
re-assure developers that this document is sufficient to develop
interoperable implementations of SMTP and that they do NOT need to
study RFC 821 despite the dozens and dozens of references to RFC 821
in this document. References which, in my opinion, add nothing for a
developer and which give the impression that RFC 821 should be checked
on most things.
Every time I came across the numerous cases where this document says
~as in RFC 821~ or the like, the thought always popped into my head:
"Why would I, as a consumer of this protocol specification, care what
RFC 821 said?" Either this document is the protocol specification for
SMTP or it isn't.
Part of the problem is that this document is a tangle of protocol
specification, operational considerations, historical information, and
general motivational essays. I like historical information. A number
of my RFCs have Historical Notes in them, but always as an aside, not
scattered through the text. There is a section (1.2) designated for
such material. Some might say it should be an Appendix, but I am fine
with having 1.2 up front. I understand that disentangling the
specifications and operational guidance would be hard at this point
and am not pushing for that. But ideally historic stuff would not
clutter up the protocol specification but should be concentrated in
one section to make the protocol specification crisper.
> > Section 1.2, last paragraph: Future commitments always seem a bit
> > risky. Suggest replacing "forthcoming" with "planned".
>
> Normally, I would agree. But, not only is the A/S well along but
> describing it simply as "planned" runs directly into the discussion
> above about the importance of discussing, e.g., privacy, integrity,
> or authentication protocols associated with mail. See there,
> including the discussions about holding this document until the A/S
> is ready .. in this case for concurrent publication.
As long as the AD and IESG are willing to go along with this somewhat
peculiar relationship between this document and the so called
"Applicability Statement" document.
> > Section 2.3.5, last paragraph (before the final two bullet points):
> > The first sentence of this paragraph is of questionable grammar
> > and, in any case, extremely hard to parse. Assuming I have parsed
> > it correctly, how about "Unless further restricted in this
> > document, domain names used in SMTP are names that can be resolved
> > to MX or address (A or AAAA) RRs (see also Section 5), or to CNAME
> > RRs that can be resolved to an MX or address RR."
>
> Good catch. This sentence resulted from too much patching (my notes
> show at least four partial rewrites since its predecessor first went
> into the document) and should have been caught and rewritten earlier.
> Let me consider your proposed new text, but I will rewrite this
> somehow in the working version. Unless instructed to the contrary,
> that version will appear before the IESG starts its deliberations.
> If it seems controversial, I'll follow up on this part of your review.
Looks good in version -32.
> > Section 2.3.12, first sentence: Appears to have missing text and/or
> > have grammatical errors and is hard to parse. How about something
> > like : "This document distinguishes between two concepts: (1) an
> > "SMTP session (aka "mail session") that starts when a connection is
> > made between client and server and ends when than connection
> > terminates", and (2) a "mail transaction that is started and
> > terminated by particular SMTP commands."
>
> Another good catch with the original being more complicated by a
> wording (near-typographical) error. I think even your proposed fix
> may be too complicated and obscure (although far better than the
> original). How about:
>
> 'This document distinguishes between an "SMTP session" and a
> "mail transaction". An SMTP session, often called a "mail
> session", starts when a connection is made between client and
> server, ending when that connection is terminated. Â A "mail
> transaction" is started and terminated by particular
> commands, most often MAIL and RSET or QUIT (the latter also
> instructs the server to close the SMTP session).'
I'm quite happy with your change in version -32.
> > Section 3.5.1/4.1.1.3: I saw the text in Section 1.3 about this,
> > but it still seems dubious to include real domain names like
> > foo.com and xyz.com in examples. Is it really going to cause
> > confusion to go with example.com or the like? (In any case, if you
> > are using "foo" or "bar" or "foobar", you should consider adding
> > RFC 3092 to the references.)
>
> For the reasons given in 1.3, I'm loathe to make changes to the
> examples, but, if you or others think it would be helpful, I could
> add, as a last sentence of that section, something like:
>
> 'In particular, some of those examples use variations on
> "foo", a convention explained in RFC 3092.'
>
> Does that work for you? Does anyone else have a problem with it?
Fine on foo. I guess on the non-reserved example domain names, we will
see what the AD/IESG say.
> > ...
> ...
>
> > Section 4.1.3: Isn't a "1*" prefix, as in 1*dcontent, superfluous?
>
> My understanding of ABNF is that "*dcontent" means "any number of
> those including zero", while "1*dcontent" means there must be at
> least one of those. Â If ABNF experts speak up and say otherwise, I
> could, I suppose, change it to something like
>   Standardized-tag ":" dcontent  [ *dcontent ]
> but that seems at least equally likely to confuse readers.
Sorry, don't know what I was thinking. The ABNF is fine.
> > Section 4.1.4, etc.: Why isn't there a state diagram? Instead, we
> > have somewhat verbose and redundant prose that is basically trying
> > to provide a state diagram and transition rules.
>
> I think the simple answer is that a state diagram would be extremely
> difficult to construct and error-prone, especially given the added
> complexities introduced by optional SMTP extensions. The verbosity
Sure, I meant a state diagram or table(s) for this document covering
the basics specified in this document, not extensions specified
elsewhere. I would normally guess that if it is "extremely difficult"
to construct a correct state machine, as you say, then the protocol
isn't understood. An implementer necessarily has to directly or
indirectly figure out all the states, events, and transition rules
they are implementing whether they implement that in an organized
tabular fashion or in spaghetti code. In general, it seems to me
better to have organized table(s)/diagram(s). But if there isn't
enough energy to make the improvement, then I agree we have gotten
along with it as is.
> is a result of the problem discussed in Sections 1.2 and 1.3 -- the
> document was created by merging text from several others and there
> has been great reluctance (first extensively discussed as what become
> RFC 2821 was coming together) to try to smooth things out lest errors
> be introduced. This is a case in which, if there are strong feelings
> that a state diagram would be helpful _and_ the WG is willing to
> review it, I'd be willing to give it a shot, or, better, review a
> draft prepared by someone else. But, absent that feedback, I
> recommend leaving it alone.
>
> > Section 4.1.4, page 48, 5th paragraph: Says server can verify
> > domain name argument in EHLO command. Can it also do that for HELO?
> > And what should it do if the verification fails?
>
> You are talking about the paragraph starting "An SMTP server MAY
> verify..." and talking about checking for an address record, right?
> If it tries and fails, the implementation has two choices: to reject
> the command as unacceptable (see two paragraphs earlier and the
> discussion of codes) or to conclude that the problem isn't worth the
> energy, reply with a 2yz code, and move on. That may sound strange,
> but there are some perfectly reasonable exception cases. For
> example, suppose we had
> EHLO big-cluster.example.com or even
> EHLO example.com
> but that a lookup yielded only MX records because the actual hosts
> either didn't have public DNS names at all or were
> cluster1.example.com
> cluster2.example.com
>
> One would certainly hope the command would not be rejected.
>
> As to HELO, please look at the second paragraph of Section 2.2.1,
> especially the last sentence. If you think HELO should be called out
> specifically in the portion of Section 4.1.4 referenced above, please
> propose a rule about when it should or should not be identified and
> discussed when ELHO is mentioned.
You always seem to think that a request to mention (or identify)
something is a request to add an extended discussion to the document.
Not so.
Seems simple enough to me. There are ~83 occurrences of EHLO in the
document. There are plenty of places where it is clear that EHLO is
mentioned in relation to extensions, so HELO is irrelevant. And there
are a number of places where "EHLO (or HELO)" is already used. For the
remaining sections where EHLO is mentioned, I suggest replacing the
first and only the first occurrence of "EHLO" in each of the following
numbered sections with "EHLO (or HELO)":
3.3
4.1.1.5
4.1.4
4.2
4.2.4.1
4.2.4.2
4.4.1 and
4.4.3
> ...
> > Section 4.1.4, page 49, 3rd paragraph: This "MAIL MUST NOT be sent"
> > text seems confusing at a minimum. To most readers MAIL is "being
> > sent" with every RCPT command, with the DATA command, and with
> > every new line of mail content. Please re-word it so it's something
> > about "initiating" the sending of mail or the like.
>
> This is much like several cases where the WG decided to not change
> the text because the same wording (in this case, with the exception
> of removing discussion of SEND, SOML, and SAML) has been present
> since RFC 2821 and no actual issues with interoperability or even
> confusion have been demonstrated in more than 23 years. Â I'm open to
> suggested text and discussion in the WG, but I fear that any
> improvements would be subject to confusion on other points. Â As I
> reread it, I could see changing "MAIL MUST NOT be sent" to "message
> content MUST NOT be sent". Â Would that help? Â (Question addressed to
> the WG and community, not just Donald).
I think we are talking somewhat at cross purposes here. I simply
misread the text. I read it as if it said "Mail MUST NOT be sent ...".
Perhaps just change to "The MAIL command MUST NOT be sent ...".
> > Section 4.2, page 50, right after the ABNF: the "where ..."
> > construct is normally used to provide more information for
> > something appearing in the immediately preceding
> > ABNF/diagram/whatever but "Greeting" does not occur in the ABNF
> > which is confusing. Reading further, apparently the actual quoted
> > word "Greeting" is not meant, which is also confusing. If it's any
> > generic greeting message, maybe just use lower case unquoted
> > greeting.
>
> But "Greeting" does appear in the ABNF. Â The first two text lines of
> the ABNF in that section are, separated by a blank line,
>
> 'In ABNF, server responses are:
> Greeting = ( "220 " (Domain / address-literal)'
>
> Am I missing something?
Sorry, my mistake.
> > Section 4.2, page 51, first complete paragraph: For the IETF, what
> > is the difference between a Standard and a Standards-Track
> > specification? It seems like bad practice to put IANA assignment
> > criterion in the middle of body text like this.
>
> To the first question, IIR, back when we had a fantasy about the
> (then) three-level Standards process being actively used, those
> levels were "Proposed Standard", "Draft Standard", and "Standard",
> with an expectation that the distinction would be taken seriously.
> The preference for "Internet Standard" to refer to the latter came
> much later.
>
> I'd like instructions from the WG or some sort of
> community consensus, but I am open to
> (i) Leaving the text alone
> (ii) Putting "Internet" in front, i.e., making that "new
> Internet Standards or Standards-Track specifications"
> (iii) Dropping "Standards or".
>
> However, for (iii), note that many in the IETF, including some IESG
> decisions, have argued or assumed that BCPs are really
> standards-track documents. Because of that, the current text is
RFC 8126 says that the "Standards Action" assignment policy is the
issuance of a Standards Track or Best Current Practice RFC in the IETF
Stream. Thus, at least for regular IANA Considerations purposes, a BCP
is not a Standards Track document but its issuance is a Standards
Action. Which makes sense since, while the Standards Track has only
two steps as opposed to the three it used to have, there is still a
track to progress through but there is no such track for BCP. My
point, however, was that any IETF "Standard" is clearly included in
"Standards Track" documents. So, the current text of "... new codes
may be added as the result of new Standards or Standards-Track
specifications." is strictly redundant and "Standards orÓ" should be
stricken.
> possibly deliberately ambiguous and we should be careful what we wish
> for because an alternative to it could require a very careful, and
> possibly contentious, revision.
I see no reason why the assignment policy for SMTP reply codes should
be contentious. That sort of thing (reply codes, error codes, etc.
that may have to be interpreted by an implementation of an older
version of a protocol) is normally Standards Action (e.g., DNS
RCODEs). But if desired it could be tightened to "Standards Action
other than BCP".
> Second, I don't see this text as specifying IANA assignment criteria,
> especially since there is no registry for SMTP reply codes, only the
> discussion in Section 4.2 and any updates that might be applied in
> the future. If you believe there should be such a registry, please
An assignment policy is an assignment policy. Its existence should not
be buried in the middle of a large specification if you want people to
notice it and pay attention.
> make that case, but note that the interrelationships covered by the
> subsections in Section 4.2 would be quite hard to capture in a
> conventional IANA registry. In that regard, also note that the "rare
If there are believed to be unusual constraints on or procedures for
the allocation of code points for an IANA Registry, you shouldn't
include an essay as a note with the registry, you just include a
pointer to the appropriate RFC section.
> and significant" comment in Section 4.2 is intended to discourage new
> codes in favor of enhanced reply codes and/or new text with existing
> codes.
The document should create an IANA registry for SMTP reply code
points. This is straightforward. I have attached some suggested XML.
> > Section 4.2.2: OK, but what are these "Functional Groups"? Some
> > sort of subheadings (not necessarily part of the hierarchical
> > numbering) are needed.
>
> These groupings, and the use of that terminology without a further
> breakdown or description or subheadings, come straight out of RFC
> 821. That is more than 40 years with no evidence that it has been
> the source of a problem. It might be that the difference in
> formatting between RFCs 821 (and 2821) and their successors is
> helpful. The formatting in the current document is identical to that
> in RFC 5321 (2821 followed the 821 model but was probably prepared
> using xml2rfc version 1 (i.e., the RFC 2629 version) and translated
> to nroff). I have figured out how to make xml2rfc restore that
> earlier layout but, if we want to do that, the WG is going to need to
> very carefully review the new groupings since there are codes that do
> not appear in RFC 821 or even in RFC 2821 and the ordering of some of
> the existing codes was changed (even between 2821 and 5321).
Thanks for at least re-establishing the groupings. This probably
raises the utility of this section to just above zero. If the groups
were actually labeled with their functional theme, it would be even
better.
> > Section 4.3.2, for EHLO 450 says "see note above" but it seems
> > unclear what note how far above.
>
> The page break in this version of the draft is the problem. If you
> scroll up to the bottom of page 60, you will see the note. Given
> alternate rendering forms for RFCs, etc., I've tentatively changed
> the note to read 'see note immediately above under "CONNECTION
> ESTABLISHMENT"'. Does that work for you and everyone else?
It's better.
Maybe it's just me but the problem is that when I read "see note
above", I think of a free-standing piece of text and look above for
"Note:" or the like at/near the left margin. Failing to find that, I
might look for a "Note " embedded in other text. Failing both of
those, I give up. I think the best thing would be to duplicate the
parenthetical annotation. If not that, then maybe "450 (see
parenthetical annotation to 450 immediately above)".
> > Section 4.5.3.2: It seems confusing that the first paragraph talks
> > about "each buffer of the data transfer" but there is only one mail
> > data buffer at the server for a particular mail message and the
> > subject of 4.5.3.2.5 uses "block" while the contents of 4.5.3.2.5
> > uses "chunk" and "TCP SEND call"s.
>
> I need WG advice as to what, if anything, to do about this. And I
> hope someone will correct me if the explanation below is not quite
> right.
>
> While I'm fairly certain that no one anticipated it when RFC 821 was
> being written, there are server implementations out there that need
> to transfer the incoming mail message somewhere else -- relaying it
> or putting it into a mailbox or non-SMTP delivery queue. They will
> process received commands through DATA, but will then (or soon
> thereafter) open the next connection in sequence, go through EHLO,
> MAIL, RCPT, and DATA commands, and then possibly start sending out
> message content while the content from the original message is still
> arriving. In addition to reducing the time between message sending
> and delivery, this allows those implementations to report most errors
> from the destination site while the incoming connection is still open
> (i.e., without later constructing bounce messages that can pose their
> own problems in the contemporary Internet, including security-related
> ones). If that isn't clear, ask and I'll try to draw a picture.
It's great that there are pipelined mail servers. All I'm bothered by
is the word "buffer" because I see this use as somewhat conflicting
with other uses of "buffer" in the document. Why can't it say for
"each chunk of" or for "each block of" or anything other than for
"each buffer of"?
> > Section 8.1.1.1, last paragraph: The existing IANA model is
> > intended to minimize IANA "judgement" and, in general, make IANA's
> > job mechanical. Since the idea is to avoid name conflicts, this
> > document should request one table with the assignment model
> > indicated in a column or the like.
>
> A general comment about the many suggestions about Section 8 in this
> review:
> Perhaps, in my writing and discussions with the WG over the almost
> five years we've been struggling with this document (including a few
> drafts in the year before the WG was chartered), I'm still suffering
> from some unreasonable nostalgia for an IANA that operated somewhat
> independent of the IETF/IESG and actually made decisions (even some
> the IETF didn't like). At the same time, I've got considerable
> respect for the people who are there now and for their knowledge and
> insights about registry organization, parallels with other
> registries, and so on. Yes, the IETF can, these days, tell them
> exactly what to do and expect them to do it unless they clearly
> explain why it is impossible. But at least IMO, that does not mean
> we need to assume they are not competent to make educated judgments.
I don't recall ever seeing a draft which explicitly orders IANA to do
something in so many words. They are almost always politely worded as
requests, which gives IANA plenty of room to push back if they
perceive some difficulty or wish to provide some advice. But it is
also normally the case that, except for the very unusual case of
something like an RFC about IANA Considerations, like RFC 8126, the
WG/author/AD/... understand the technical aspects of what is being
documented much better than IANA does.
> That section has been carefully reviewed with IANA and the text
> mentioned above is not one of their reported concerns. The IANA
> comments (see the datatracker entry if you are interested) point out
> that that there are extensive interactions with other registries and
> cross references. There are also, IIR, other registries that are
> split depending on how things got there, e.g., separating provisional
> and permanent registrations. One thing I'm sure of --and another
> motivation for that language -- is that figuring out exactly how
> registries should be organized is not a core competence of the WG.
> So, while my personal instinct matches yours, I think this document,
> at this point, should say as-is for now.
Ok.
> My personal hope is that the IESG and IANA can work out whatever is
> best to do during IESG review or before publication and this text can
> then be adjusted to reflect what is being done or has been done
> rather than giving advice or talking about the future.
In my experience, IANA and the RFC Editor cooperate to re-write the
IANA Considerations section, if it requests any IANA actions, to show
what has been done. It is rare for the IESG to spend any cycles to
"work out" something with IANA.
> > Section 8.3, first line: Should be phrased as a request to IANA
> > such as "IANA is requested to reorganize the Mail Parameters
> > Registry Group as follows:"
>
> All of Section 8 is, formally, requests to IANA. While that change
Then perhaps text should be inserted between the 8. header and the 8.1
header. Maybe "The following subsections present this document's
requests to IANA."
> would not be harmful, see above. I hope the final RFC can simply
> reflect what has been done.
In my experience, the IANA Considerations section of the final RFC
gets re-written, completely re-written if necessary, by IANA and the
RFC Editor, so it *always* reflects what has been done.
> > Section 8.3, item (1) and Item (4): "should be" -> "is".
>
> But they aren't. These are more requests (or, if you prefer,
> instructions to) IANA. Either "is" is appropriate only after the
> changes are made. The alternative is that we should anticipate those
> changes being made and not be talking about requests at all.
In general, drafts should be worded so they are true when issued as an
RFC. That's why drafts don't say "It is proposed ..." throughout. It
is entirely reasonable to say "The following is a request to IANA: ...
x is changed to y ..." or the like.
But since this is all going to get re-written by IANA anyway, I should
have classified this as a nit, not an issue. It's not important enough
to argue about.
> > Section 8.3, item (2): Should not tell IANA to "consider" anything.
> > Either ask IANA to do it or don't ask IANA to do it. This is all
> > going to get massaged in connection with IESG/IANA review anyway.
>
> See above. It is not clear that the exact organization of registries
> is within scope for the WG. The text was written on the assumption
> that IANA might have had reasons (even long-forgotten instructions)
> for organizing and labeling things the way they are. Some of these
> registries and their contents and organization date from very long
> ago, were not specified by the IETF, and, if there are notes or
> memories about particular choices of language and/or organization,
> neither I nor the WG have been given access to them. But the
This is the first time I have heard the theory that IANA might be the
custodian of Ancient Occult Knowledge and Manuscripts that they
conceal but use to make wise decisions if decisions are specifically
deferred to them.
> important thing, IMO, is the "massaged" part (consistent with my
> comments above). I'd prefer to focus on getting the document
> approved, working with IANA to get the registries organized in a
> reasonable way and all of the associated loose ends tied up, and then
> adjust the document to reflect what happened rather than spend time
> modifying the document over terminology, requests, etc.
Ok.
> > And what IANA cares most about is clarity and lack of ambiguity.
>
> Yes, and, as mentioned above, IANA has already done a Last Call
> review of this document and they didn't raise any of the concerns
> about Section 8 that you are identifying.
IANA will review it again after changes to resolve IESG ballot comments...
> > Section 8.3, item (3): It is generally not IANA's job to review
> > registry names to judge whether they are "appropriate" which seems
> > like a technical question rather than a clerical question. Perhaps
> > IANA could chime in on whether a Registry name was excessively long
> > or confusing similar to another registry or the like, but if you
> > want to change the registry name, just request IANA to do that.
> > (Actually, with the change above, all these points are part of a
> > request to IANA.)
>
> Yes, and see above although I would argue that, when there are either
> many interrelated registries or ones with complex structures, it is
> reasonable to expect IANA to have opinions about consistency of
> naming, structure, etc.
Ok.
> > Section 8.3, items (...): Changes in line with the above.
>
> See above.
>
> > Section 8.3, items (5) and (6): suggest combining these so it is
> > clear what "Those bullets ..." refers to.
>
> I think combining them would create other problems (and, again, IANA
> has already reviewed this and not objected). How would you feel
> about changing "Those bullet point fields" at the beginning of (6) to
> "The bulleted items identified immediately above"? I've tentatively
> made that change to the working draft.
Ok.
> > Section 8.3, item (9): Appears to have an open technical question
> > that should be resolved.
>
> Whoops. No idea how that slipped through except that the WG has
> sometimes been moving too slowly or intermittently. I've made a note
> in the working draft. WG??
>
> > Appendix D: I think this one paragraph of material should be
> > somewhere in Section 3.7.
>
> This was Appendix E of RFCs 5321 and 2821, with rather clear
> decisions made at RFC 2821 time to put it there. I'm reluctant to
> move it given the "has not caused identified problems in 23 years"
> principle, at least without either evidence of harm, clear WG
> consensus, or both.
I have re-read Section 3.7 and Appendix D. It continues to be obvious
to me that the material in Appendix D belongs in Section 3.7 and that
moving it there would improve the document. Can't you at least add a
reference to Appendix D in Section 3.7?
> ...
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
<section>
<name>SMTP Reply Codes</name>
<t>IANA is requested to create the following Registry.</t>
<artwork>
Name: Simple Mail Transfer Protocol (SMTP) Reply Codes
Reference: [this document]
Registration Procedure: Approval of a Standards Track RFC.
Note: The currently unsassigned codes and theory of SMTP
Reply Codes are not enumerated below. See Section
4.2 of [this document].
</artwork>
<table>
<thead>
<tr><th align="center">Code</th><th
align="center">Meaning</th><th>Reference</th></tr>
</thead>
<tbody>
<tr><td>211</td><td>System status, or system help reply</td><td>[this
document]</td></tr>
<tr><td>214</td><td>Help message (Information on how to use the
receiver or the meaning of a particular non-standard command; this
reply is useful only to the human user)</td><td>[this
document]</td></tr>
<tr><td>220 <domain></td><td>Service ready</td><td>[this
document]</td></tr>
<tr><td>221 <domain></td><td>Service closing transmission
channel</td><td>[this document]</td></tr>
<tr><td>250</td><td>Requested mail action okay,
completed</td><td>[this document]</td></tr>
<tr><td>251</td><td>User not local; will forward to
<forward-path></td><td>Section 3.4.1 [this document]</td></tr>
<tr><td>252</td><td>Cannot VRFY user, but will accept message and
attempt delivery</td><td>Section 3.5.3 [this document]</td></tr>
<tr><td>354</td><td>Start mail input; end with <CRLF>.<CRLF></td><td>[this
document]</td></tr>
<tr><td>421 <domain></td><td>Service not available, closing
transmission channel (This may be a reply to any command if the
service knows it must shut down)</td><td>[this document]</td></tr>
<tr><td>450</td><td>Requested mail action not taken: mailbox
unavailable (e.g., mailbox busy or temporarily blocked for policy
reasons, or server temporarily unavailable if returned before a mail
transaction is started)</td><td>[this document]</td></tr>
<tr><td>451</td><td>Requested action aborted: local error in
processing</td><td>[this document]</td></tr>
<tr><td>452</td><td>Requested action not taken: insufficient system
storage (also preferred code for "too many recipients"</td><td>Section
4.5.3.1.10 [this document]</td></tr>
<tr><td>455</td><td>Server unable to accommodate
parameters</td><td>[this document]</td></tr>
<tr><td>500</td><td>Syntax error, command unrecognized (This may
include errors such as command line too long)</td><td>[this
document]</td></tr>
<tr><td>501</td><td>Syntax error in parameters or
arguments</td><td>[this document]</td></tr>
<tr><td>502</td><td>Command not implemented</td><td>Section
4.2.4.1 [this document]</td></tr>
<tr><td>503</td><td>Bad sequence of commands</td><td>[this
document]</td></tr>
<tr><td>504</td><td>Command parameter not implemented</td><td>[this
document]</td></tr>
<tr><td>521</td><td>No mail service</td><td>Section 4.2.4.2 [this
document]</td></tr>
<tr><td>550</td><td>Requested action not taken: mailbox unavailable (e.g., mailbox
not found, no access, or command rejected for policy
reasons)</td><td>[this document]</td></tr>
<tr><td>551</td><td>User not local; please try <forward-path
></td><td>Section 3.4.1 [this document]</td></tr>
<tr><td>552</td><td>Requested mail action aborted: exceeded storage
allocation.</td><td>[this document]</td></tr>
<tr><td>553</td><td>Requested action not taken: mailbox name not allowed (e.g.,
mailbox syntax incorrect). This code is also used as an
"ambiguous mailbox" response to VRFY.</td><td>Section 3.5.1 [this
document]</td></tr>
<tr><td>554</td><td>Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here" although 521 is now preferred for
the latter.</td><td>Section 4.2.4.2 [this document]</td></tr>
<tr><td>555</td><td>MAIL FROM/RCPT TO parameters not recognized or not
implemented</td><td>[this document]</td></tr>
<tr><td>556</td><td>No mail service at this domain.</td><td>Section
4.2.4.2 [this document]</td></tr>
</tbody>
</table>
</section>
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
