Brian and Alissa, Glen pointed me/us to that spam policy statement and I read it some weeks ago (as well as when it was posted). What I found notable about it in the context of the present discussion is something Brian calls out: "c. Past behavior by that particular sending IP address;". Our not knowing whether the reason for the rejection was specific to a particular IP address (whether a sending one or one announced in EHLO) was exactly the reason I thought that submitting the trouble ticket was in order. If Glen had responded "we didn't accept your mail transaction because the relevant address had behaved badly in the past", that would have been very clear, clearly within policy, and we would not be having this discussion. Instead, he told us that the IETF was blocking _all_ mail sessions that contained an IP address literal, a piece of syntax that is authorized, and (at least normally) required to be accepted by an IETF Standards Track specification, syntax with which we have had more than 37 years of wide deployment and experience. I can find nothing in the anti-spam policy that says "if some spammers are using a particular SMTP feature, we will ban the feature" or even "if this SMTP feature appears to be used more often by spammers, than by legitimate message senders, we will ban the feature". As long as no wording to that effect is present, there may be good reasons for rejecting mail session setup commands that contain IP address literals, but the decision to reject them is not mandated by or even supported by the policy statement. Somewhat cynically, I also note that, if the generally-held belief that there are more spam messages on the Internet these days than legitimate messages, an argument that something should be banned because more spammers than legitimate senders use it would be an argument for shutting down SMTP entirely. Because there is nothing in the spam control principles statement that authorized blocking all message transactions that use IP address literals (or any other feature specifically authorized by SMTP, especially ones associated with "MUST NOT reject" language, this actually is a standards matter, not just an operational policy matter. It may be the latter too, but my note to the IETF list was prompted by the former and the question of whether, like Julius Caesar's supposed comment about his wife, the IETF should be extremely observant and above suspicion wrt the applicability of its own standards. The questions of whether, if RFC 5321 said nothing on the subject, IP address literals should be blocked, what the anti-spam policy says and whether it should be updated to cover this case are really interesting. The technical aspects of them have been discussed at considerable length (and, IMO, technical depth) on the ietf-smtp list. I tried to keep those discussions from being repeated on the IETF list, in part because of assorted policies about what belongs on this list when there are other lists dedicated to the particular discussion area. I don't believe that anyone who participated actively in the discussion of the ietf-smtp list would claim that the discussion that did occur on the IETF list represented a comprehensive summary of that earlier (and continuing) discussion among those with enough involvement in SMTP to be following that list. However, when I introduced a piece of the subject on the IETF list, I was interested in only one question here. That question was whether the IETF was now ok with operational decisions that put the IETF's practices out of conformance with IETF standards. Whether one thinks that the 5321 requirement for acceptance of IP address literal overrides or becomes subsidiary to its very general statements about exceptions for operational purposes affects whether this IP address literal issue is a sufficient approximation to a smoking gun to make a good example or not, but not the question. The discussion led to an additional question and hence my "three questions" note to Jay. It is moot if we don't care whether "we" conform to our standards or not (and, again, separate from whether this is a good example of that or not). Given his response and Alissa's note, an updated version of that question would be whether, if it appears to be operationally appropriate for our practices to be non-conformant to our standards, how does that decision get made and what procedures, if any, are needed to be sure the IETF LLC and its contractors are aware of possible standards non-conformance. I note in that regard that reasonable people might construe an IETF LLC or contractor (the Secretariat included) decision to not conform to an IETF standard as the LLC getting involved in the standards process, something the community (or at least the IASA2 WG) was assured would not happen. best, john p.s. Jay's response is much appreciated even though I see subtle issues there that I infer from the response that he may not see. And I still owe Rich a response to his comment claiming I'm in the rough (and implying, I think, that I should just shut up). --On Wednesday, December 18, 2019 09:40 +1300 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > On 18-Dec-19 06:15, Alissa Cooper wrote: >> Hi John, all, >> >> The principles that the IESG has laid out for spam control on >> IETF lists are available here: >> <https://www.ietf.org/about/groups/iesg/statements/spam-contr >> ol-2008-04-14/>. > An interesting feature of that statement is that it contains > this: "This supercedes [sic] a previous IESG statement on this > topic, dated 9 Jan 2006." However, the hyperlink to "previous > IESG statement" is incorrect as it is actually a link back to > the identical 2008 statement. Applying my archaeological > skills, the original statement is at: > https://www6.ietf.org/iesg/statement/spam-control-2006-01-09.h > tml > > It did mention "c. Past behavior by that particular sending IP > address;" as a criterion. So this is not a recent addition by > any means. I agree of course that it's a policy choice, not a > standards issue. > > As far as I can tell there was no specific committee; the 2006 > statement was drafted by Bill Fenner who wrote to the IESG > that "It's been discussed on the wgchairs list a few times, > and this document is the result of the feedback." > > (There's an even older version at > https://www6.ietf.org/IESG/STATEMENTS/mail-submit-policy-20020 > 313.txt) > > Brian > >> These principles continue to guide spam control as >> implemented by the AMS IT team. The IESG is not involved in >> day-to-day decisions about how the principles are >> operationalized and was not involved at all in the handling >> of the ticket you cite below. >> >> With Glen's help this week I've come to understand the >> history here, which was unknown to me before. It seems there >> was some sort of committee or group that existed a decade >> ago. Once when they met, one of their discussion topics was >> spam. Many measures including the one discussed in this >> thread were proposed, considered, and implemented. I don't >> know much else about the group but it does not exist now. >> >> As you've seen from Jay's email, he has taken the lead on >> operationalizing a response. Based on discussions with him >> and Glen I think they both know they can reach out to the >> IESG at any time if they have questions in interpreting the >> IESG statement above or any other IESG statements. >> >> Best, >> Alissa on behalf of the IESG >> >>> On Dec 15, 2019, at 4:15 PM, John C Klensin >>> <john-ietf@xxxxxxx> wrote: >>> >>> Hi. >>> >>> It has long been my personal belief that, in its operation of >>> various of its own services on the Internet the IETF should >>> adhere closely to its own standards. If we do not do so, we >>> lose all credibility in recommending to others that they >>> follow our standards. This practice has been referred to in >>> many discussion threads over the years as "eating our own >>> dog food". >>> >>> It has recently come to the attention of several of us, via >>> an extended discussion on the SMTP list, that the IETF email >>> servers are rejecting all SMTP connections whose EHLO >>> commands contain IP address literals. While the text >>> describing the appropriateness of use of IP literal is RFC >>> 5321 is more complicated than it probably ought to be, the >>> discussion in Section 4.1.4 of that document seems quite >>> clear that an SMTP server MUST NOT reject a message simply >>> because an IP address literal (or a domain name that does >>> not point to a host) is used. Those interested in the >>> niceties of that issue should review the correspondence on >>> the ietf-smtp@xxxxxxxx list and comment there if appropriate. >>> >>> A ticket ( [www.ietf.org/rt #282782] ) was generated early in >>> the month about the ietf.org mail servers apparently >>> rejecting messages with IP address literals in the EHLO >>> field. The rejection is accompanied by a reply message that >>> appears to be inappropriate in multiple ways; again, those >>> interested should see the ietf-smtp list for an >>> already-extensive discussion. The Secretariat responded by >>> indicating that all such addresses were being rejected and >>> that the rejection was occurring under instructions from >>> IETF leadership, instructions that were reaffirmed after the >>> ticket was filed. Whatever the problem is, and indeed, >>> whether there is a problem, the Secretariat is therefore >>> blameless. I suggest that the IETF has a problem. >>> >>> The purpose of this note is _not_ to evaluate the underlying >>> technical issues, what should be done about them, or whether >>> the text in RFC 5321 should be improved. Those, it seems to >>> me, are topics for the ietf-smtp list. They have been >>> discussed there at length and presumably will continue to be >>> discussed there. It is whether there is consensus among IETF >>> participants that "the leadership" (I presume whatever >>> bodies, individuals, or their designees are relevant) should >>> have the authority to instruct the Secretariat to violate an >>> IETF standard without consultation of appropriate experts >>> within the community (presumably on relevant mailing lists), >>> evidence of IETF rough consensus, and/or Internet Drafts >>> that specify alterations to the relevant standard(s). I >>> also don't want to cast blame about decisions of the past, >>> only to understand what the process is for giving >>> instructions to the Secretariat (or approving their >>> suggestions) is now and whether IETF conformance to IETF >>> standards is something we care about for the future. >>> >>> john >>> >> >> >
