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

Brian E Carpenter <brian.e.carpenter@gmail.com> Tue, 17 December 2019 20:40 UTC

Return-Path: <brian.e.carpenter@gmail.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 05C2612087A; Tue, 17 Dec 2019 12:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 EoSDdjrXPUli; Tue, 17 Dec 2019 12:40:41 -0800 (PST)
Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1A5120125; Tue, 17 Dec 2019 12:40:41 -0800 (PST)
Received: by mail-pg1-x534.google.com with SMTP id b137so6311903pga.6; Tue, 17 Dec 2019 12:40:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Z3/V+c+/uF3K0AZG4m7fadcmpmP/ug92pmYM2bG/6yU=; b=XpJXeasbJ4E18nLHySVkoYWh576ejKW0mE/FgHgz39HdAb+JCuAr8i7XuNlowsxFIs qlN4D/+3RVfGZ1GvYjvJA6RjKkVhdR8raoGt1WvDvsz5hfuWih6lDoiMWTUHAJXsDkYy aq2iTnLnnkcIF8lWhnb/T+IVtxrF6mZLV/c0lRZQC8XraJctZdxYdGzrzHoM1TOwEDAH 1GaKJ/hBbuazb1pyrvCvCpsnO2iPy71bYRGDJQFakVuwPJVczyaGry1/AScrlk9lXnSU exa/fZqWlQrITX+TY799qIJXn/yleb2esM4Dd7xfPUDbL6bpyf4AUy/FQlRG1ohr9n+n 67Tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Z3/V+c+/uF3K0AZG4m7fadcmpmP/ug92pmYM2bG/6yU=; b=uItQbMHToVgQBmg5Q7vwi1aWgk903vOgk+NQ9KtNqKzcnTaZfPfxrBp610hHVhgcM1 s49lVULmEdo0l9CF0BFczwt/i/SKsFG0/24eeuq7EwCBNc2JyAy4f1T8Pm7d+aQ3IGX6 uCtquLzU366ZYGVX31iR1VJ10ckmBRqzGRDt1XJUW2ekEDrRnJL2Ewl9GQ3mZcXeQc3y WnAhbz9Hcw3EMBDCsfRpJZq0YnnDwtsdu1ZmKO9Pi7MhHWDau+ZAZS2aFpH9O+jxFxB9 VTjvMT7BAfArfJbq6679hG3mnsS/WaBIhgdWIzWcDUUQpRXDe3jDo9O4TobpexYBfh+b Q2tw==
X-Gm-Message-State: APjAAAXVL0+IJwML/EMCO8LU5ezvf4L8B9+9flQHoEjgDLln+6/ypHiC 3VrnZDvzSAH4oadaWZJDz4K9/20z
X-Google-Smtp-Source: APXvYqxA0ADmR42sxmaybdDGZODxXfJU07aLdcKzZ5J3s+q0pSX7b3zEJydEaZgeiCE/UOYl0zFVmA==
X-Received: by 2002:a63:3404:: with SMTP id b4mr27158739pga.438.1576615240714; Tue, 17 Dec 2019 12:40:40 -0800 (PST)
Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id k9sm4460091pje.26.2019.12.17.12.40.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Dec 2019 12:40:40 -0800 (PST)
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
To: Alissa Cooper <alissa@cooperw.in>, John C Klensin <john-ietf@jck.com>
Cc: IETF discussion list <ietf@ietf.org>, IESG <iesg@ietf.org>
References: <8EE11B75E1F8A7E7105A1573@PSB> <E4FAF576-566C-4109-A183-F72239A5B340@cooperw.in>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <49881d08-d0ea-2621-e68d-8445f95b16aa@gmail.com>
Date: Wed, 18 Dec 2019 09:40:35 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <E4FAF576-566C-4109-A183-F72239A5B340@cooperw.in>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/trOo4RjoQj_EMNNk7Vc1cT4FquA>
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: Tue, 17 Dec 2019 20:40:45 -0000

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-control-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.html

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-20020313.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@jck.com> 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@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.
>>
>>  john
>>
> 
>