Re: [ietf-smtp] Updated draft for "SMTP Response for Detected Spam"
John C Klensin <john-ietf@jck.com> Thu, 31 March 2022 01:01 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3693A0A8A; Wed, 30 Mar 2022 18:01:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 U9tGKQEB4b6a; Wed, 30 Mar 2022 18:01:11 -0700 (PDT)
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 A53CC3A0A73; Wed, 30 Mar 2022 18:01:09 -0700 (PDT)
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 1nZjBT-0007CX-2m; Wed, 30 Mar 2022 21:01:07 -0400
Date: Wed, 30 Mar 2022 21:01:00 -0400
From: John C Klensin <john-ietf@jck.com>
To: dcrocker@bbiw.net, "Brotman, Alex" <Alex_Brotman=40comcast.com@dmarc.ietf.org>, ietf-smtp <ietf-smtp@ietf.org>
Message-ID: <44D715B7767FFD3836B2E9B5@PSB>
In-Reply-To: <e29d7a95-2341-a176-8559-1df2c4e2f78a@dcrocker.net>
References: <CH2PR11MB4342C5648A79FFEC1DE0FC45F71F9@CH2PR11MB4342.namprd11.prod.outlook.com> <e29d7a95-2341-a176-8559-1df2c4e2f78a@dcrocker.net>
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-smtp/uurLWGUerob1zbpnCZkBwoEf7P0>
Subject: Re: [ietf-smtp] Updated draft for "SMTP Response for Detected Spam"
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2022 01:01:16 -0000
--On Wednesday, March 30, 2022 10:55 -0700 Dave Crocker <dhc@dcrocker.net> wrote: > On 3/30/2022 10:37 AM, Brotman, Alex wrote: >> I wanted to send an update for this draft. I received >> (negative) feedback from one person via the list, though >> several outside of the list were supportive. I wanted to try >> to clear up some of the language in the draft. Appreciate >> feedback from those who are interested to read. > > > The basic idea of this spec seems reasonable to me. > > However, many reasonable ideas ultimately don't work out, for > a wide variety of reasons. To try to mitigate against that > outcome, a specification needs compelling clarity about use > and benefits, and a base of community support that wants that > use and benefit. > > Perhaps I've missed it, but it appears that the spec lacks > both of these, as of now. The question, then, is how to > develop both? > > I think the document has quite a bit of language that is > tentative and I think that is appropriate, at this point. > > Absent a decisive technical criticism -- which I'm not seeing, > so far -- I suggest that the document seek processing through > the Independent stream, rather than the IETF stream, and that > it seek Experimental status, rather than Standards track. > > Assuming that the Independent Stream Editor < > rfc-ise@rfc-editor.org> is willing(*), that stream has /far/ > less hassle and unpredictability than the IETF, which is > subject to all sorts of unexpected issues, depending on who > offers criticism. (Notice I didn't say 'whether'...) > > Experimental has the benefit of being an explicit request for > community action /and feedback/. This can serve to develop > that base of community support. > > d/ > > (*) The editor is new to the task and so there's no track > record to consult. Dave, Let me add one thing to your suggestions. While it does not appear in the headers, the last sentence of Section 1 of the current draft claims that this updates RFC 5321. I suppose that is necessary because it adds a reply code that is not in the list that now appears in 5321, following the model of RFC 7504. However, if an update to 5321 (or its successor) is needed, that immediately forces the document into the IETF stream. If Alex wants to pursue this as an Experiment, as you suggest (and which I agree might be a good idea), he should have a discussion with the ART ADs about whether it would be possible, today, to follow the model of RFC 1846, which added a code experimentally but with no pretence of updating RFC 821 and its reply code list. Two alternatives, more or less for completeness: (1) It would certainly be inconsistent with positions both of us have taken about minimal changes and with my concerns about the fragility of 5321/5321bis, but it would be possible to make a proposal that the reply code materials in RFC 5321 (and, so far, in rfc5321bis), be removed from that document and placed in an IANA registry. That would make documents like this much easier to handle. (2) Alex should consider whether an enhanced code of the RFC 3463 persuasion would meet his needs equally well. While a receiver would need code changes to recognize and utilize an enhanced code and whatever supplemental information is provided with it, it would also need code changes to actually recognize "259" rather than having it treated as unrecognized and falling back to the first digit only convention. That would have the added advantage of not violating an implicit SMTP convention about reply codes which is that, except for VRFY and EXPN commands and systems that use extended codes, we've tended to let the primary code capture all of the available information. >From that perspective, the reply text after the code is helpful for human debuggers who read English but "all information in the reply code" makes things much simpler for MUAs in non-English environments who get the responses because they can just use their own tables of text strings for each code rather than having to translate. If 259 requires that the receiver parse the string looking for an assuredness indicator, especially one at the end (unlike VRFY and EXPN), it requires even more special-case treatment. best, john
- [ietf-smtp] Updated draft for "SMTP Response for … Brotman, Alex
- Re: [ietf-smtp] Updated draft for "SMTP Response … Dave Crocker
- Re: [ietf-smtp] Updated draft for "SMTP Response … Michael Peddemors
- Re: [ietf-smtp] Updated draft for "SMTP Response … John Levine
- Re: [ietf-smtp] Updated draft for "SMTP Response … Claus Assmann
- Re: [ietf-smtp] [EXTERNAL] Re: Updated draft for … Brotman, Alex
- Re: [ietf-smtp] Updated draft for "SMTP Response … Richard Clayton
- Re: [ietf-smtp] Updated draft for "SMTP Response … John C Klensin
- Re: [ietf-smtp] Updated draft for "SMTP Response … Dave Crocker
- Re: [ietf-smtp] Updated draft for "SMTP Response … John C Klensin
- Re: [ietf-smtp] Updated draft for "SMTP Response … Richard Clayton
- Re: [ietf-smtp] Return codes, was Updated draft f… John Levine
- Re: [ietf-smtp] Return codes, was Updated draft f… Dave Crocker
- Re: [ietf-smtp] Return codes, was Updated draft f… Ned Freed
- Re: [ietf-smtp] Return codes, was Updated draft f… John R Levine
- Re: [ietf-smtp] Return codes, was Updated draft f… John C Klensin
- Re: [ietf-smtp] Return codes, was Updated draft f… John R Levine
- Re: [ietf-smtp] Return codes, was Updated draft f… John C Klensin
- Re: [ietf-smtp] Return codes, was Updated draft f… Ned Freed
- Re: [ietf-smtp] Return codes, was Updated draft f… John C Klensin
- Re: [ietf-smtp] Updated draft for "SMTP Response … Alessandro Vesely
- Re: [ietf-smtp] Updated draft for "SMTP Response … Brotman, Alex
- Re: [ietf-smtp] Updated draft for "SMTP Response … Brotman, Alex
- Re: [ietf-smtp] Updated draft for "SMTP Response … Hector Santos