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