Re: IETF Policy on dogfood consumption or avoidance - SMTP version
"Andrew G. Malis" <agmalis@gmail.com> Mon, 16 December 2019 18:54 UTC
Return-Path: <agmalis@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 3C5661208E3; Mon, 16 Dec 2019 10:54:30 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 SQSU6WFbsKNz; Mon, 16 Dec 2019 10:54:28 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 234061208D8; Mon, 16 Dec 2019 10:54:28 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id x1so6078120qkl.12; Mon, 16 Dec 2019 10:54:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ey+9c+srp4DFg3zR9Xh1z83qDbxmn0skkuz23YZPkYA=; b=MSsdV1z9q/kBG3qtXcx2HxG/H/OXFQXgMEijChb2bwqh4Ze5W6dVYoz3GFgGVJ7sYA RptnPDtSuXxAoLEZs7KN/GNV8+g6j6TpaAHsE/znDV8p5pmn9ZKfHQn9HEOA7Lrh2aVI AMnj3vgDyPGqLY1MnIE0Ydb5qWS90ndYucORS1I4qIc2bHmEFDFoKTGqeOIrm6AOqw9c ajLes+cQrbQjHGhF5rgm63aonpGWDBF6smCAA/zn8OuNH4xo9nBfQdNOw4kpDAuS1cnx j9H+yWC9wOOgR+joYeL9idOAcx2XJXR4dWtAPPL+TK3TNf7d7h6ukqCI2uMVbZZDZT+P UW4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ey+9c+srp4DFg3zR9Xh1z83qDbxmn0skkuz23YZPkYA=; b=CeqEyRMGtUpSN1YIroZxAFBwkADn/350V3sWW9DvIIipxzxEvLRHaFPeCR2Zu8mFF8 i+PRfMiI7NXXD0JpY+RPwRm77UQUJlrogdPAIZYJWz0zsvYNHb2MfbNRw1g6cmfSghAh ySA4u8ZdX9YYHbzlbxB3ZC4XCMskJlS98oVb2WaEQjQMtasldg+X6Lx/hUIJ+jt7URFY HSWMxrVwisD5yKaNCoOanxOBgl83Xcuo8rQiVK/TOXq1iSojnGZ5fif7N9fmI1Ns91T9 Lxrj5jUHAnVzukwIc1Yi7HjOa6B9ZfbmJMRqF/Qd74E3TTgau1Il62hl44U6G7lbB1Bq WYTg==
X-Gm-Message-State: APjAAAUcX3RD6trk+Y/5N1vx0CBc8ctz9P7fMAY8pYh3Ed7SBQIa7S8W JsjlYulz6OSu7jmnkU2d+iDrlfDrLUxM0ho03rgxZLxf
X-Google-Smtp-Source: APXvYqxrwtqowbGdHEqAZl+aIFzLufPu4RnaRY5zFlv7RT5A7ZsJFJnRfWePg+/M5ruSpEgTQ4QgrAlyw2tv5RkNn0o=
X-Received: by 2002:a37:a4cf:: with SMTP id n198mr754868qke.483.1576522466936; Mon, 16 Dec 2019 10:54:26 -0800 (PST)
MIME-Version: 1.0
References: <8EE11B75E1F8A7E7105A1573@PSB> <m2a77ttff6.wl-randy@psg.com> <CABL0ig4Wz-0dk7bsRpaN6pni2rHEc-jPnygwed_Hygy+CiehQA@mail.gmail.com> <16306b3a-63bd-621e-636c-dd7626f74733@foobar.org> <4D7EEBF62E149D1F23BA6A32@PSB>
In-Reply-To: <4D7EEBF62E149D1F23BA6A32@PSB>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 16 Dec 2019 13:54:15 -0500
Message-ID: <CAA=duU0c3=pLm7AKr5eRe7n+N+BQeOnmhnTGiSPE-7h80WgV_g@mail.gmail.com>
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
To: John C Klensin <john-ietf@jck.com>
Cc: Nick Hilliard <nick@foobar.org>, Glen <glen@amsl.com>, IETF Discussion <ietf@ietf.org>, IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009f4bef0599d6bd61"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/klL6p0nvtF-dJGp5gkKuAqlCVpE>
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: Mon, 16 Dec 2019 18:54:30 -0000
John, As I said on another email earlier today, I disagree with you that we're non-conformant to RFC 5321. Cheers, Andy On Mon, Dec 16, 2019 at 12:50 PM John C Klensin <john-ietf@jck.com> wrote: > > > --On Monday, December 16, 2019 16:18 +0000 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/ > > > > + let's move on. > > Nick, > > (1) Again, this is more of an issue for the ietf-smtp list than > this one, but, because RFC 5321 says, early in Section 4.1.4, > "If the EHLO command is not acceptable to the SMTP server, 501, > 500, 502, or 550 failure replies MUST be returned as > appropriate" and not, e.g., "whenever the server gets around to > it" or "it is ok to wait until after the first RCPT command", > there is still probably a violation of the standard. Since you > and others are encouraging just changing the error report and > moving on, there is also the mostly-technical question of > whether saying "policy violation" and leaving legitimate senders > to guess what undocumented rule they might have tripped over or > explaining that the problem is with the argument to EHLO (even > though it might encourage the bad guys (including spammers) to > get smarter) is better. > > (2) One thing Glen did not mention is that, noting that it is > hard to imagine that fixing something that has been in place and > unchanged for a decade is a screaming emergency, I encouraged > him to not rush to make changes until some consensus emerged, > particularly on the ietf-smtp list, as to whether the right > solution was to tune the error message, to remove the check, or > do something else _and_ until whatever mechanism is used to tell > him, as a vendor, what "we" want him to do makes a decision and > revises the instructions (or not). > > (3) Once again, it is the apparent violation of the standard by > an IETF server that caused me to raise the issue on this list. > If we don't care about non-conformance to our own specs, then, > although I'd be interested in knowing what percentage of the > total number of messages the IETF servers reject a day these IP > literals in EHLO represent, I'm likely persuaded from Glen's > figures that accepting them is not worth the added cycles. If > we do care, then either we should be accepting the mail session > opening attempt and dealing with the problems later in the > process (and accepting the marginal overhead) or we should be > seeing a proposal to change the standard. And, again if we > care, we should be looking at, or encouraging someone to look > at, whether we should make some adjustments to lower the odds of > similar non-conformance with IETF standards occurring in the > future. > > Finally, to summarize part of an off-list discussion that may be > relevant, I am not accusing anyone (especially not Glen) of > having done something wrong here. I simply believe that the > question of whether we feel an obligation to conform to our own > standards is important. If the answer is "yes", then some > adjustments are probably in order going forward, adjustments > that might include a little more transparency about how > instructions to Glen and his colleagues that might interact with > IETF standards are generated and by whom and/or a requirement > that a decision to deviate from relevant standards requires > either an I-D proposing a change to those standards or one > explaining why the deviation is appropriate. And, for the > record, I have no reason to believe that those who generated the > instructions to Glen were aware that they were directing > non-conformance with the relevant standard. I assume it just > slipped by (5321 is really hard to read on these issues) and > that the question is only what, if anything, we should do > differently in the future to lower the odds of a recurrence > (again, if we care). > > best, > john > >
- 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)