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