Re: IETF Policy on dogfood consumption or avoidance - SMTP version
Hector Santos <hsantos@isdg.net> Thu, 19 December 2019 01:42 UTC
Return-Path: <hsantos@isdg.net>
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 587A7120026 for <ietf@ietfa.amsl.com>; Wed, 18 Dec 2019 17:42:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=SMAej8Bq; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=oG6/bx1T
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 F3E1BIBc59mn for <ietf@ietfa.amsl.com>; Wed, 18 Dec 2019 17:42:12 -0800 (PST)
Received: from mail.winserver.com (groups.winserver.com [76.245.57.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3314B120CCC for <ietf@ietf.org>; Wed, 18 Dec 2019 17:42:11 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=9167; t=1576719721; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=fcrluhzRO3s3ToejiqjqVz0jC5w=; b=SMAej8BqFZkOXgQyyBzw2TcEsH1hw8YGTMcnShYGw6Lz08FWnhD3QSkAu5Ltao YZwS+gozD9+6Qmhwb6wRHx54pgETCymT6pzheVEqScG9aXU9YU5l93RBGA73cGm4 ChDU2bHl0j828caVh1OhL+AsyXdviyLR4btFT/sMR9PZ0=
Received: by winserver.com (Wildcat! SMTP Router v8.0.454.9) for ietf@ietf.org; Wed, 18 Dec 2019 20:42:01 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 332102627.42331.3052; Wed, 18 Dec 2019 20:42:00 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=9167; t=1576719565; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=sQqPArA uOYGx/hFHjTU17dzWVw1FyIDWT8HnE9OcU7g=; b=oG6/bx1Tl2pFGBKv264FMHa XOC0TekrMCV7jCIx2tWuBMO9TZ7zsPMdWQGej6fgXbWzSv94cPynD9uqmDB1rzMF tKnP0W8ZWYUAtLNbVsWoawKc/kEB7E3I1yJ03TQ3SiNjDurcwieHgyrYJl1cxefz CaGOa5rwTp0CrfX75UcA=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.9) for ietf@ietf.org; Wed, 18 Dec 2019 20:39:25 -0500
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.9) with ESMTP id 894744750.1.5908; Wed, 18 Dec 2019 20:39:24 -0500
Message-ID: <5DFAD569.5060504@isdg.net>
Date: Wed, 18 Dec 2019 20:42:01 -0500
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
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> <58595081-6F4F-45E2-9798-B691AC919D28@cisco.com> <8b77885c-6094-f7cd-e0c2-97db2dd46d6b@network-heretics.com>
In-Reply-To: <8b77885c-6094-f7cd-e0c2-97db2dd46d6b@network-heretics.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/k86DaS9hmWmN9Jfuw9GmnrtoJYY>
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: Thu, 19 Dec 2019 01:42:18 -0000
+1 Well said Keith. It represents my view as well. Thank you. On 12/18/2019 6:03 PM, Keith Moore wrote: > On 12/18/19 3:12 AM, Eliot Lear wrote: > >> On the general issue, as the late Brian Kantor said, RFCs serve us >> best when they document existing practice. > > I do not think this is defensible as a general statement, at least not > when stated in that way. There are cases when this is true, such as > when existing practice has evolved to figure out what actually works > well, and RFCs have evolved to document it. But that neglects the very > purpose of engineering of our protocols, which is to determine what > will work well before it becomes existing practice. Engineering is > imperfect, of course, which is why we revise those RFCs in light of > experience, but good engineering produces good practice much more > often than not. > > Sometimes our first RFC documents a protocol that is already in use, > in which case we have a dilemma - should the RFC document existing > practice or should it document what is believed to be good practice? > I have seen many instances in which this conflict produces poor > specifications, in which either documenting existing practice, or > specifying what is believed to be good practice, would produce a more > useful result than trying to do both. It is imperative that the WG > in such a case have clear instructions as to which it should do. But > it's not always the case that the WG should favor existing practice. > > Another problem with that statement is that, if taken as true on its > face, _any_ existing practice, no matter how poorly chosen or rarely > employed, can be used to argue for ignoring an RFC or changing text in > the RFC when it is revised. > > In the case of SMTP, of course, many changes made between RFC 821 and > RFC 5321 reflect lessons learned in the ~26 years of experience with > SMTP during that interval, just as RFC 821 reflected several years of > experience with email-over-FTP prior to the invention of SMTP. The > rule in RFC 5321 that permits an IP address literal in HELO/EHLO is > one such example. Servers that rejected messages based on HELO/EHLO > were found to frequently reject valid mail. Perhaps unfortunately, > RFC 5321 only reflects the change learned from that experience and > does not record the experience that led to that decision - so people > today may naively believe that the language in 5321 is a mistake or > accident. It was neither of those. > > Email usage does continue to change, so a decision should not be taken > as valid forever just because it was once sound. This is equally > true, BTW, for the language in RFC 5321, as it is for an operational > change to reject EHLO with IP address literals. > > I do support empowering operators, in exigent circumstances, to do > whatever appears to be necessary to allow successful operation to > continue. But the process should not stop there. When the effect of > such decisions accumulates over time, and the corrective measures > continue to be justified because "they've been that way forever", the > result is generally to degrade the ability of the network to support > applications and changing usage patterns. So IMO there's a need to > document the reasons for such measures, and to measure and track their > effectiveness over time. And because this check happens before the > message content is actually transmitted, the only way to measure > effectiveness of a rejection on EHLO arguments is to let some > statistically representative sample of such messages through from time > to time and actually measure how valid a check it turns out to be. > >> 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. >> > This is not "running code" in the sense that we usually use the > term. It's not a change made by a well-supported SMTP server. It's a > configuration change made by one site for which very little evidence > to support it has been cited. Even then, the assertion was that this > configuration was more efficient, not that it resulted in a better > overall ham-to-spam ratio. And of course IETF is not just an > ordinary site, it sets (or should set) an example for others to follow. > >> >> 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. > I disagree. The EHLO argument is immaterial to any check on validity > of a recipient address. And one subtlety of SMTP is that a response > to a RCPT TO command is generally taken as a response for that > specific recipient, so it's generally not appropriate to complain > about EHLO in response to RCPT TO. >> >> 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. > > The MUST NOT exists for the very reason that rejection of messages > because of EHLO arguments was found to be detrimental to > interoperability, because too many SMTP servers were conducting > inappropriate checks. > >> >> And so the server chose to reject a message. I would add that an >> erratum should be filed to resolve this conflict. > > I disagree. Or at least, I don't think IETF should dismiss the many > person-decades of experience that went into RFC 5321, based on a > single assertion by one operator that they found it beneficial to do > so. I do think IETF should probably research the matter, but I'm not > sure that an erratum is appropriate. > >> Finally, we cannot CANNOT CANNOT micromanage secretariat and mailing >> list operations on the IETF list. > > I mostly agree, but this is still a red flag. When the secretariat > or operators believe they see a need to violate IETF consensus, they > should at least explain to IESG why they are doing so, and IESG should > refer the matter to the appropriate area or working group for > investigation. Partially because this is potentially valuable > feedback for IETF standards, but also because it reflects poorly on > our organization and impairs the perceived value of our standards when > we refuse to eat our own dog food. > > And it should be fine to discuss these things on the IETF list or on > an appropriate topical IETF mailing list. But neither the IETF list > nor an IETF WG should not be trying to issue any kind of immediate > instructions to IETF operations personnel, unless asked to do so by > the IESG. > >> 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. > > As I understand the situation, that wasn't the problem. Messages > were/are being rejected merely because they used IP address literals > in EHLO, whether or not there was a PTR record. > >> That THAT isn’t recognized as THE problem the IETF should work on >> with regard to email is disturbing. > > To me the disturbing thing is that so many operators feel empowered to > impose arbitrary and often meaningless checks on email in the name of > filtering supposed spam, checks that are quite often not backed up by > careful and continued measurement and appropriate use of > statistics. But again, this may be due to a failure of IETF to make > appropriate protocol changes and/or operational recommendations to > facilitate more accurate spam filtering. IMO the "operators can do > whatever they want" idea has degraded interoperability for far too > long, but we can't really expect operators to do better unless we give > them better tools. > > Keith > > -- HLS
- 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)