Re: IETF Policy on dogfood consumption or avoidance - SMTP version

[John C Klensin <[e-mail]>]

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
<[e-mail]> 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
>>> <[e-mail]> 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 [e-mail] 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
>>> 
>> 
>> 
>