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

Eliot Lear <lear@cisco.com> Wed, 18 December 2019 08:12 UTC

Return-Path: <lear@cisco.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 ADEC21200DF; Wed, 18 Dec 2019 00:12:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 8ta2ROoI9smk; Wed, 18 Dec 2019 00:12:28 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BC4120105; Wed, 18 Dec 2019 00:12:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19094; q=dns/txt; s=iport; t=1576656748; x=1577866348; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=QOTsuB2h322f7RXXn9vDikQ3yIS0N1wN2bJBoCSNLi0=; b=ZscTOK5AhZgUF3ranGq7FAC208EAyOJjTqMepiapirzmzBF6Ai5fy/cO xHrCdGOkzAk/okRp8XMPZN9jWpzEBm4cyk8BrSUV/Ox1HfAF8l/uVvStX fWXa5L19pp/WlmqM6/XBEaHDKNHeM1Ps8/8cZ9oc9Pvsq61rFhwznDsSa A=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CHAADg3vld/xbLJq1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYF+gRxTghISKoQEiQOIEyWHOYtshiOBZwIHAQEBCQMBAS8BAYRAAoI9OBMCAw0BAQQBAQECAQUEbYVDhV4BAQEBAgEjSwsFCwsYKgICVwYTG4MHAYJXIKxadYEyhU+EcRCBNoFTil+CAIERJwwUgU5QLj6EFgERAgEIgyYygiwEjXSIOWGIW48ggj6CQ4EciQiJKxuCQ4wTJ4tRhEChNYMnAgQGBQIVgWkiZ3EzGggbFTsqAYJBPhIRFFaMSBeOJEADMI8lAQE
X-IronPort-AV: E=Sophos;i="5.69,328,1571702400"; d="asc'?scan'208,217";a="20517574"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Dec 2019 08:12:24 +0000
Received: from [10.61.204.232] ([10.61.204.232]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id xBI8CNQM010253 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Dec 2019 08:12:24 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <58595081-6F4F-45E2-9798-B691AC919D28@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_C9413CB4-B5FD-4641-8FCD-64C8075B8E81"; protocol="application/pgp-signature"; micalg="pgp-sha256"
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 09:12:23 +0100
In-Reply-To: <4D7EEBF62E149D1F23BA6A32@PSB>
Cc: ietf <ietf@ietf.org>, The IESG <iesg@ietf.org>
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> <4D7EEBF62E149D1F23BA6A32@PSB>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
X-Outbound-SMTP-Client: 10.61.204.232, [10.61.204.232]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/M-aeK53LdxAzBQpBoglbBf5Zris>
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: Wed, 18 Dec 2019 08:12:32 -0000

Hi John,

On the general issue, as the late Brian Kantor said, RFCs serve us best when they document existing practice.  This is entirely in accord with the “running code” part of our mantra: if network needs dictate that the RFC not be followed to the letter, then so be it.  I would actually like that we are demonstrating this point and reenforcing that our standards are voluntary, but for the fact that I don’t think the standard was substantially violated.  That’s my second point.

If one looks at RFC 5321, there are three reasons to think that really the standard does not prohibit the behavior being described.  First, the text in 4.1.4 doesn’t actually prohibit the rejecting literals.  Here is what is said:

   If the EHLO command is not acceptable to the SMTP server, 501, 500,
   502, or 550 failure replies MUST be returned as appropriate.

At this point in the transaction, it may not be readily apparent that the EHLO indeed is unacceptable.  That’s because the server may need to gather more information, such as the recipient, in order to check against SPF records or other inputs delivered later to make a decision.

   An SMTP server MAY verify that the domain name argument in the EHLO
   command actually corresponds to the IP address of the client.
   However, if the verification fails, the server MUST NOT refuse to
   accept a message on that basis.

That “MUST NOT” conflicts with the most important principle we have to go with in order to defend against spam and malware, as clearly stated in Section 7.9:

    It is a well-established principle that an SMTP server may refuse to
   accept mail for any operational or technical reason that makes sense
   to the site providing the server.

And so the server chose to reject a message.  I would add that an erratum should be filed to resolve this conflict.

Finally, we cannot CANNOT CANNOT micromanage secretariat and mailing list operations on the IETF list. This does NOT impact open participation, when anyone can get free email service on any number of platforms that work just fine with the IETF.  That this message didn’t meet the extremely low barrier of setting up a PTR record when > 99% of SMTP client connections are best classed as attacks.  That THAT isn’t recognized as THE problem the IETF should work on with regard to email is disturbing.

Eliot

> On 16 Dec 2019, at 18:50, 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
>