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

John C Klensin <john-ietf@jck.com> Mon, 16 December 2019 17:50 UTC

Return-Path: <john-ietf@jck.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 EBFE4120033; Mon, 16 Dec 2019 09:50:34 -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, SPF_HELO_NONE=0.001, SPF_NONE=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 Zo6Rg-EftBx8; Mon, 16 Dec 2019 09:50:33 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4015C12001A; Mon, 16 Dec 2019 09:50:33 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1iguVn-0008su-IO; Mon, 16 Dec 2019 12:50:27 -0500
Date: Mon, 16 Dec 2019 12:50:21 -0500
From: John C Klensin <john-ietf@jck.com>
To: Nick Hilliard <nick@foobar.org>, Glen <glen@amsl.com>
cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
Message-ID: <4D7EEBF62E149D1F23BA6A32@PSB>
In-Reply-To: <16306b3a-63bd-621e-636c-dd7626f74733@foobar.org>
References: <8EE11B75E1F8A7E7105A1573@PSB> <m2a77ttff6.wl-randy@psg.com> <CABL0ig4Wz-0dk7bsRpaN6pni2rHEc-jPnygwed_Hygy+CiehQA@mail.gmail.com> <16306b3a-63bd-621e-636c-dd7626f74733@foobar.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/F-P4HaQpnLBI6GSZJgqu4du7fSc>
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 17:50:35 -0000


--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