Re: IETF Policy on dogfood consumption or avoidance - SMTP version
Jay Daley <jay@ietf.org> Tue, 17 December 2019 18:55 UTC
Return-Path: <jay@ietf.org>
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 23D58120895; Tue, 17 Dec 2019 10:55:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 P28pyM54RcEs; Tue, 17 Dec 2019 10:55:34 -0800 (PST)
Received: from macbook-pro.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 84C56120D45; Tue, 17 Dec 2019 10:55:28 -0800 (PST)
From: Jay Daley <jay@ietf.org>
Message-Id: <5574C731-C5C8-4B30-BD15-1245EB0238AB@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_00DC42C1-6856-4516-A04F-64C9C91B8D12"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
Date: Wed, 18 Dec 2019 07:55:26 +1300
In-Reply-To: <9A480FBBDB27C27DFDF96F01@PSB>
Cc: ietf@ietf.org, IESG <iesg@ietf.org>, Glen <glen@amsl.com>
To: John C Klensin <john-ietf@jck.com>
References: <8EE11B75E1F8A7E7105A1573@PSB> <m2a77ttff6.wl-randy@psg.com> <CABL0ig4Wz-0dk7bsRpaN6pni2rHEc-jPnygwed_Hygy+CiehQA@mail.gmail.com> <16306b3a-63bd-621e-636c-dd7626f74733@foobar.org> <DBADBA1F-5F81-4D14-8AF8-5F340F017DAC@ietf.org> <9A480FBBDB27C27DFDF96F01@PSB>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/rGbtfRtg5aFBgZaVhK7iOlGkp8o>
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 18:55:37 -0000
Hi John Thanks for taking the time to ask these questions and I hope my answers do not discourage you from continuing to ask such questions as it is important that my decisions, even operational ones. are not considered sacrosanct. Alissa has answered the more general question of authority and background here, but to answer your specific questions: > On 17/12/2019, at 3:59 PM, John C Klensin <john-ietf@jck.com> wrote: > > Jay, > > Three questions: > > * Did you review and understand the extensive discussion that > has occurred on the ietf-smtp@ietf.org since the beginning of > the month or just the (relatively few) comments on this IETF > list? No. First, I don’t believe it is possible for me to monitor every IETF list that may impact operational management of our services. Second, having been pointed to an extensive technical discussion I don’t believe it is my place to attempt to understand it and draw my own technical conclusions. If there were a specific list or group the exists for discussion on matters of operational guidance then I would of course monitor that, but there isn’t and so I think it is entirely reasonable for me to base my call on the messages to this IETF list. > * Did you consider the issues associated with the possibility of > IETF servers being out of conformance, whether clearly or > marginally, with IETF standards and the implications if that > were the case? That is not my job to do, that is for the community to make a call on, both in terms of what is conformance and what is not conformance, and what is the implication of that. > * Is the answer to the question of where the Secretariat will > get guidance and instructions on technical issues going forward > that it will come from you and your assessments of those issues > and community consensus about them? As I hope is clear from above I am not assessing the issues. Alissa has explained the history of community guidance being provided, which we have followed for 10+ years and the IESG spam control principles, which we are compliant with. The decision on consensus is therefore "is there consensus to overturn this long-standing practice?", which clearly there is not. In other circumstances, such as if the call were the other way around (i.e. is there consensus to do X) then a different mechanism or approach could well be required, such as the lengthy consultation on the revised privacy statement. kind regards Jay > > thanks, > john > > > --On Tuesday, December 17, 2019 10:46 +1300 Jay Daley > <jay@ietf.org> wrote: > >> Hi >> >> While there is not unanimous consensus, I think the mood is >> clearly to leave this as an operational decision. In which >> case, taking into account the following recommendation ... >> >>> On 17/12/2019, at 5:18 AM, Nick Hilliard <nick@foobar.org> >>> wrote: >>> >>> Glen wrote on 16/12/2019 16:11: >>>> /^[0-9.]+$/ 550 RFC2821 violation >>>> /^\[[0-9.]+\]$/ 550 RFC2821 violation >>>> In just seconds, I can easily change the messages, or remove >>>> the rules, either with complete ease. >>> >>> s/RFC2821 violation/policy violation/ >> >> … and the following technical comment … >> >>> On 17/12/2019, at 6:04 AM, Viktor Dukhovni >>> <ietf-dane@dukhovni.org> wrote: >>> >>> On Mon, Dec 16, 2019 at 08:11:11AM -0800, Glen wrote: >>> >>>> There is a configuration file, with two lines in it: >>>> >>>> /^[0-9.]+$/ 550 RFC2821 violation >>>> /^\[[0-9.]+\]$/ 550 RFC2821 violation >>> >>> While the patterns look similar, the first one rejects >>> non-compliant "EHLO 192.0.2.1" and similar dotted quads (or >>> more generally some mixture of digits and dots), the second >>> rejects RFC-compliant address literals. So at least the >>> second message should probably be different, if the rule is >>> retained. >> >> >> >> … the following has now changed from >> >> /^[0-9.]+$/ 550 RFC2821 violation >> /^\[[0-9.]+\]$/ 550 RFC2821 violation >> >> to >> >> /^[0-9.]+$/ 550 RFC2821 violation >> /^\[[0-9.]+\]$/ 550 Policy violation >> >> >> As to the question of data, we cannot say for certain that the >> rejected messages were all spam, but we have only received one >> complaint in 10 years and so we can reasonably assume this >> rule has not caused problems that need to be addressed. >> >> Please let me know if you have any questions, comments or >> recommendations. >> >> kind regards >> Jay > > -- Jay Daley IETF Executive Director jay@ietf.org +64 21 678840
- Re: IETF Policy on dogfood consumption or avoidan… Valdis Kl=?utf-8?Q?=c4=93?=tnieks
- IETF Policy on dogfood consumption or avoidance -… John C Klensin
- Re: IETF Policy on dogfood consumption or avoidan… Viktor Dukhovni
- Re: IETF Policy on dogfood consumption or avoidan… Randy Bush
- Re: IETF Policy on dogfood consumption or avoidan… John Levine
- Re: IETF Policy on dogfood consumption or avoidan… Viktor Dukhovni
- Re: IETF Policy on dogfood consumption or avoidan… Nick Hilliard
- Re: IETF Policy on dogfood consumption or avoidan… Keith Moore
- Re: IETF Policy on dogfood consumption or avoidan… John C Klensin
- Re: IETF Policy on dogfood consumption or avoidan… Viktor Dukhovni
- Re: IETF Policy on dogfood consumption or avoidan… Salz, Rich
- Re: IETF Policy on dogfood consumption or avoidan… Keith Moore
- Re: IETF Policy on dogfood consumption or avoidan… Valdis Kl=?utf-8?Q?=c4=93?=tnieks
- Re: IETF Policy on dogfood consumption or avoidan… John R Levine
- Re: IETF Policy on dogfood consumption or avoidan… Randy Bush
- Re: IETF Policy on dogfood consumption or avoidan… John C Klensin
- Re: IETF Policy on dogfood consumption or avoidan… Keith Moore
- Re: IETF Policy on dogfood consumption or avoidan… Nick Hilliard
- Re: IETF Policy on dogfood consumption or avoidan… S Moonesamy
- Re: IETF Policy on dogfood consumption or avoidan… Glen
- Re: IETF Policy on dogfood consumption or avoidan… Nick Hilliard
- Re: IETF Policy on dogfood consumption or avoidan… Phillip Hallam-Baker
- Re: IETF Policy on dogfood consumption or avoidan… Glen
- Re: IETF Policy on dogfood consumption or avoidan… Viktor Dukhovni
- Re: IETF Policy on dogfood consumption or avoidan… Andrew G. Malis
- Re: IETF Policy on dogfood consumption or avoidan… John C Klensin
- Re: IETF Policy on dogfood consumption or avoidan… Andrew G. Malis
- Re: IETF Policy on dogfood consumption or avoidan… Randy Bush
- Re: IETF Policy on dogfood consumption or avoidan… Jay Daley
- Re: IETF Policy on dogfood consumption or avoidan… Andrew G. Malis
- Re: IETF Policy on dogfood consumption or avoidan… Jay Daley
- Re: IETF Policy on dogfood consumption or avoidan… Rob Sayre
- Re: IETF Policy on dogfood consumption or avoidan… John C Klensin
- Re: IETF Policy on dogfood consumption or avoidan… Salz, Rich
- Re: IETF Policy on dogfood consumption or avoidan… Alissa Cooper
- Re: IETF Policy on dogfood consumption or avoidan… Jay Daley
- Re: IETF Policy on dogfood consumption or avoidan… Hector Santos
- Re: IETF Policy on dogfood consumption or avoidan… Viktor Dukhovni
- Re: IETF Policy on dogfood consumption or avoidan… Brian E Carpenter
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Salz, Rich
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Keith Moore
- Re: [ietf-smtp] the inedible parts of IETF dogfoo… John Levine
- Re: [ietf-smtp] the inedible parts of IETF dogfoo… Keith Moore
- Re: [ietf-smtp] the inedible parts of IETF dogfoo… George Michaelson
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Randy Bush
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Hector Santos
- Re: IETF Policy on dogfood consumption or avoidan… John C Klensin
- Re: IETF Policy on dogfood consumption or avoidan… Eliot Lear
- Re: IETF Policy on dogfood consumption or avoidan… Alissa Cooper
- Re: [ietf-smtp] epostage is still a bad idea, the… John R Levine
- Re: [ietf-smtp] IETF Policy on dogfood consumptio… Salz, Rich
- Re: [ietf-smtp] epostage is still a bad idea, the… Phillip Hallam-Baker
- Re: IETF Policy on dogfood consumption or avoidan… Keith Moore
- Re: IETF Policy on dogfood consumption or avoidan… Hector Santos
- Re: IETF Policy on dogfood consumption or avoidan… John C Klensin
- Re: IETF Policy on dogfood consumption or avoidan… Eliot Lear
- Re: IETF Policy on dogfood consumption or avoidan… Alessandro Vesely
- Re: IETF Policy on dogfood consumption or avoidan… Viktor Dukhovni
- Re: IETF Policy on dogfood consumption or avoidan… Eliot Lear
- Re: IETF Policy on dogfood consumption or avoidan… Hector Santos
- Re: [ietf-smtp] epostage is still a bad idea, the… Brandon Long
- Re: [ietf-smtp] epostage is still a bad idea, the… Phillip Hallam-Baker
- Re: IETF Policy on dogfood consumption or avoidan… Valdis Kl=?utf-8?Q?=c4=93?=tnieks
- Re: IETF Policy on dogfood consumption or avoidan… Hector Santos
- The dogfood discussion (was: Re: IETF Policy on d… John C Klensin
- Re: The dogfood discussion (was: Re: IETF Policy … Viktor Dukhovni
- Re: The dogfood discussion (was: Re: IETF Policy … Eliot Lear (elear)