Hi John,
I have some personal thoughts below, speaking as an individual participant. 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.
No one has claimed that enforcement of these anti-spam rules is mandated by the IESG statement. But the rules are consistent with the statement. The whole point of a high-level statement like this is to provide guardrails for the support staff to operate within, not to dictate in detail what they can or cannot do.
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..
The two tools the community has for articulating policy of this sort are consensus RFCs and IESG statements. Personally I think a policy that would require every aspect of our IT operation to be fully standards-compliant would put us out of touch with reality and make it even more difficult to run the operation and serve the needs of our community than at present. In the real world operators find themselves in situations where the overall benefits to their own users of deviation or non-implementation of a standard outweigh the drawbacks, and we too live in that world. I will note that even the IETF tools team that largely develops its tools from scratch expresses a preference but not a requirement for its tools to be standards-based: https://ietf.org/about/groups/tools/.
I also believe that our IT staff know more about IETF standards conformance and non-conformance than any IT staff in the world. The suggestion to consider additional procedures to educate them belies all they do already to understand how to operationalize the technologies that we standardize.
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,
I disagree that this would be a reasonable conclusion. The standards process is specified in BCP 9 and operational decisions about how the IETF’s IT systems work are not within the scope of that BCP.
Best, Alissa
something the community (or at least the IASA2 WG) was assuredwould not happen.best, johnp.s. Jay's response is much appreciated even though I see subtleissues 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 inthe 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
|
