Eliot, I'm obviously not being clear enough about what I'm concerned about and looking for, so I should stop commenting for a while. Before I do and in line with your note... (1) If an issue has already been discussed, at length and by participants who are well-informed on the issues, on a topic-specific IETF mailing list, making decisions based only on a much more abbreviated discussion on the IETF list is probably not a good idea. While we have historically not made a distinction between non-WG lists that are created for discussions by a person or two and non-WG lists that are the result of WG efforts that resulted in standards and that were explicitly left open for discussions as issues with those standards arise, perhaps we should do so. In that regard, I applaud Warren's and the IESG's decision to distinguish, by name, between affinity group lists and lists on which it is sensible to talk about IETF consensus. (2) I believe that my continued pushing back on making technical decisions on the IETF list (or the Last Call list), other than in response to well-formulated Last Calls when there has already been extensive discussion on a specialized ex-WG list, especially if there has been no effort at a careful and balanced summary of that prior discussion, is a bad idea from a technical standpoint. I believe that is true whether there is an issue in which the Secretariat is involved or not. I think that position is entirely consistent with the policy statements about the IETF list, SAA efforts to push technical discussions onto more specialized lists, etc. (including IAB decisions to push strategic discussions of RFC Editor Function futures onto rfc-interest as reflected in Ted's recent notes). Personally, I don't like some of the implications of those policies and have said so, but I'm trying to conform and think others should too. (3) I don't believe anyone is proposing micromanagement in this area, just somewhat more awareness of what we are doing. Let me borrow an idea from your note as a possible suggestion in that area. Suppose we decide that operational decisions that diverge from IETF standards should be associated with errata (or announcements to ex-WG lists, or both) indicating that the standard has gotten out of touch with reality and practice. That would completely meet my needs, at least if discussion of those errata on relevant mailing lists was not prohibited. However, it does imply two other issues about which we should be aware: (i) Most such errata are (IMO completely appropriately) going to get marked "hold for document update" and then ignored until a decision is made to revise the document for other reasons. However, an AD, a document author, or an ordinary IETF participant who happens to notice the erratum may bring the erratum up as an issue on the relevant ex-WG mailing list, perhaps even to stimulate a discussion of whether it is time to revise the document or produce a new document updating it. Should a discussion occur as a result and relatively clear consensus emerge that the erratum is incorrect and the implied requested change inappropriate, I would hope that there would be a reasonable way to communicate that result to the Secretariat and/or the IETF LLC ExecDir and would hope that the earlier decision would be reviewed and revised as appropriate. (ii) I do not believe that the job descriptions of either the Secretariat or the IETF LLC ExecDir includes evaluating conformance with IETF Standards or the skills and background needed to do so. If we want these kinds of decisions, including any requirement to generate errata, to be delegated to them, then it is probably appropriate to review and update the relevant contracts and job descriptions and make resource adjustments as appropriate. Again, this has nothing to do with micromanaging anything or anyone. It has to do with being aware of what we are doing. (4) If we are going to honor the principle that IETF standards (and/or RFCs generally) should be consistent with existing (and changing) practices in the field (whether in Brian's formulation or otherwise), we need either a better and more systematic way to notify the community (or the subset of the community concerned about a particular standard) than waiting for someone to complain or generate trouble tickets. Having the Secretariat and/or IETF LLC ExecDir be sensitive to when they are departing from the standard and notify someone would be one way. Your idea about errata might be another. Another would be to shift to a model similar to the one ISO and many of its National Member Bodies adopted some years ago in response to very similar problems. In their case, there is a required review of every standard on a three-year cycle after which it must be either revised, explicitly reaffirmed, or withdrawn. In any event, at the time RFC 5321 was published, it represented the rough consensus among those involved, affirmed in an IETF Last Call that was somewhat more active and technically-specific than I think has been the norm lately, that it was closely aligned with existing practice. So no problem with Brian's observation or anything else at that time. Prior to a discussion that started only a month or two ago, there has been no serious consideration of revising it in the subsequent eleven plus years. So, again, if you don't believe the way decisions are made about what the IETF servers will allow needs tuning, and even if you are not bothered by those servers departing from IETF Standards, it seems to me that we have an issue with the absence of a systematic process for being sure that our standards remain current with changing practices. (5) Your analysis of the reasons that a response to an IP address literal in an EHLO command is interesting. It is a bit inconsistent with the command-response model of RFC5321, but, perhaps, if there were evidence that what is being done represented very common practice, that would be irrelevant. However, there is no such evidence and, perhaps more to the point, it is not what Glen says the IETF servers are doing -- they are rejecting _all_ EHLO commands with IP address literals as the argument but, for reasons I haven't asked him about, deferring the responses until after a RCPT command is received. Such deferred responses may be consistent with pipelining, but pipelining was not requested in this case. Again, it seems to me that this is a topic for the ietf-smtp list, not the main IETF one for the reasons given above. (6) Finally, I think we need to be cautious about saying that it is ok if conforming SMTP clients don't work with the IETF servers because people can always find free email services that work with those servers. In general, we know who the most obvious of those free email services are. Several of them are not strictly standards-conforming (although they may involved in a sufficient fraction of Internet mail traffic that an extreme interpretation of Brian's statement, one that I think Brian would not have agreed to, is that _they_ are the standard, not whatever the IETF specs have to say), they raise some of the issues about concentration that the IAB has been trying to address, and they raise some privacy concerns as well (even though I personally believe that nothing said to the IETF that might influence a standard should be treated as private or allowed to be anonymous). More generally, I don't find "a workaround exists" to be a satisfactory answer if we are going to claim to be in the standards business. best regards, john --On Wednesday, December 18, 2019 09:12 +0100 Eliot Lear <lear@xxxxxxxxx> wrote: > Hi John, > > On the general issue, as the late Brian Kantor said, RFCs > serve us best when they document existing practice. This is > entirely in accord with the "running code" part of our > mantra: if network needs dictate that the RFC not be followed > to the letter, then so be it. I would actually like that we > are demonstrating this point and reenforcing that our > standards are voluntary, but for the fact that I don't think > the standard was substantially violated. That's my second > point. > > If one looks at RFC 5321, there are three reasons to think > that really the standard does not prohibit the behavior being > described. First, the text in 4.1.4 doesn't actually > prohibit the rejecting literals. Here is what is said: > > If the EHLO command is not acceptable to the SMTP server, > 501, 500, 502, or 550 failure replies MUST be returned as > appropriate. > > At this point in the transaction, it may not be readily > apparent that the EHLO indeed is unacceptable. That's > because the server may need to gather more information, such > as the recipient, in order to check against SPF records or > other inputs delivered later to make a decision. > > An SMTP server MAY verify that the domain name argument in > the EHLO command actually corresponds to the IP address of > the client. However, if the verification fails, the server > MUST NOT refuse to accept a message on that basis. > > That "MUST NOT" conflicts with the most important > principle we have to go with in order to defend against spam > and malware, as clearly stated in Section 7.9: > > It is a well-established principle that an SMTP server may > refuse to accept mail for any operational or technical > reason that makes sense to the site providing the server. > > And so the server chose to reject a message. I would add that > an erratum should be filed to resolve this conflict. > > Finally, we cannot CANNOT CANNOT micromanage secretariat and > mailing list operations on the IETF list. This does NOT impact > open participation, when anyone can get free email service on > any number of platforms that work just fine with the IETF. > That this message didn't meet the extremely low barrier of > setting up a PTR record when > 99% of SMTP client connections > are best classed as attacks. That THAT isn't recognized as > THE problem the IETF should work on with regard to email is > disturbing.
