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

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

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