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

Randy Bush <randy@psg.com> Sun, 15 December 2019 22:03 UTC

Return-Path: <randy@psg.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDE812003F; Sun, 15 Dec 2019 14:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0ZyoL9m-d7B; Sun, 15 Dec 2019 14:03:28 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621DB120013; Sun, 15 Dec 2019 14:03:28 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from <randy@psg.com>) id 1igbz4-0002GA-C1; Sun, 15 Dec 2019 22:03:26 +0000
Date: Sun, 15 Dec 2019 14:03:25 -0800
Message-ID: <m2a77ttff6.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: John C Klensin <john-ietf@jck.com>
Cc: IETF Rinse Repeat <ietf@ietf.org>, Social Engineering Steering Group <iesg@ietf.org>
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
In-Reply-To: <8EE11B75E1F8A7E7105A1573@PSB>
References: <8EE11B75E1F8A7E7105A1573@PSB>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/yGKJdpu4xw-nrKm29RebejxtleY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Dec 2019 22:03:30 -0000

> 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@ietf.org 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.

excuse if i stay out of the above layer seven issue(s) you raise.
american, brit, ietf, ... politics disgust me, and discussion seems
futile.

but, as one of my hats is in ops, i gotta ask two technical questions.

  o would it be technically easy for the smtp servers to accept ip
    literals in a conforming manner?  yes, this is a question for my
    esteemed friend glen and his partner in crime, matt.

  o what would the technical and/or security exposure or other
    downside(s) be of doing so?

randy