Re: [ietf-smtp] Updated draft for "SMTP Response for Detected Spam"
John C Klensin <john-ietf@jck.com> Thu, 31 March 2022 02:16 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 0BC063A0DFC for <ietf-smtp@ietfa.amsl.com>; Wed, 30 Mar 2022 19:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 z56T-HGjtIEb for <ietf-smtp@ietfa.amsl.com>; Wed, 30 Mar 2022 19:16:09 -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 4A0373A0DE2 for <ietf-smtp@ietf.org>; Wed, 30 Mar 2022 19:16:08 -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 1nZkM2-0007Ol-IM; Wed, 30 Mar 2022 22:16:06 -0400
Date: Wed, 30 Mar 2022 22:15:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: Richard Clayton <richard@highwayman.com>, ietf-smtp@ietf.org
Message-ID: <EDDB8A4D3F9043845213F866@PSB>
In-Reply-To: <XJ7mEBMGrMRiFAps@highwayman.com>
References: <CH2PR11MB4342C5648A79FFEC1DE0FC45F71F9@CH2PR11MB4342.namprd11.prod.outlook.com> <b0a1c8d3-212d-2b67-035d-18963ca41109@linuxmagic.com> <20220330181324.GA96148@veps.esmtp.org> <XJ7mEBMGrMRiFAps@highwayman.com>
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/vovOLCzBo0DimTPgVSuZlBy0DuY>
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 02:16:16 -0000
--On Wednesday, March 30, 2022 22:25 +0100 Richard Clayton <richard@highwayman.com> wrote: > In message <20220330181324.GA96148@veps.esmtp.org>, Claus > Assmann <ietf- smtp@esmtp.org> writes > >> Please don't use up all the 25x codes, >> use the enhanced status code for this purpose. Claus, Yeah. See the note I just posted for an extra reason or two to use enhances codes rather than making up a new primary one. > Since the receiver knows the message is spam I was wondering > why the code was 259 rather than 559 ... > > ... also, the text mentions all sorts of terms of art like > "spam folder" and "Email Service Provider" which I can't find > in RFC5598 or defined in later sections (assuming that their > meaning is relevant ?) Richard, as I understand the text, the plan is to tell the sender-SMTP that the message is believed to be spam, but then deliver it to one of those "spam folders" anyway. That calls for a 2yz code (I think 250 with one or more new enhanced status codes for different cases) because returning a 5yz code and then delivering the message anyway (no matter to whom and which folders, whatever a folder is) would be a rather serious violation of the SMTP specification and model. As Dave Crocker has at least hinted, there are several other issues with (or at least questions about) this document. As one example, if one looks at SMTP, the introductory paragraph of this I-D is just plain wrong. All SMTP does is move mail transactions from a sender-SMTP to a receiver-SMTP. If we are talking about an "inbox" or some sort of folder, that isn't about SMTP any more. It might be something specific to what SMTP calls the final delivery server or system, but there we need to start thinking about exactly how to define what is often known as a Message Delivery Agent (MDA) and, while we use the term informally and there is at least one clear definition (in RFC 5598), there has never been a standards-track specification for what one of those does and how it behaves (i.e., one paralleling RFC 6409 at the other end of the pipeline). As Dave also more or less suggested, if a version of this document were to be considered for Standards Track, I think all of those issues would need to be sorted out. For an Experiment, some of them could probably be deferred. 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