Re: [ietf-smtp] Updated draft for "SMTP Response for Detected Spam"
Michael Peddemors <michael@linuxmagic.com> Wed, 30 March 2022 18:06 UTC
Return-Path: <michael@linuxmagic.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 5DE5C3A00E4 for <ietf-smtp@ietfa.amsl.com>; Wed, 30 Mar 2022 11:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 JqYL0ZhKNS6L for <ietf-smtp@ietfa.amsl.com>; Wed, 30 Mar 2022 11:06:38 -0700 (PDT)
Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) (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 8CAD43A00E3 for <ietf-smtp@ietf.org>; Wed, 30 Mar 2022 11:06:38 -0700 (PDT)
Received: (qmail 1108294 invoked from network); 30 Mar 2022 18:06:36 -0000
Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (TLS_AES_128_GCM_SHA256 encrypted) SMTP (23d775a6-b054-11ec-b511-2bebb5ad2cc7); Wed, 30 Mar 2022 11:06:36 -0700
Message-ID: <b0a1c8d3-212d-2b67-035d-18963ca41109@linuxmagic.com>
Date: Wed, 30 Mar 2022 11:06:36 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-US
To: ietf-smtp@ietf.org
References: <CH2PR11MB4342C5648A79FFEC1DE0FC45F71F9@CH2PR11MB4342.namprd11.prod.outlook.com>
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
In-Reply-To: <CH2PR11MB4342C5648A79FFEC1DE0FC45F71F9@CH2PR11MB4342.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MagicMail-OS: Linux 2.2.x-3.x
X-MagicMail-UUID: 23d775a6-b054-11ec-b511-2bebb5ad2cc7
X-MagicMail-Authenticated: michael@wizard.ca
X-MagicMail-SourceIP: 104.128.144.8
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <michael@linuxmagic.com>
X-Archive: Yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/Da0McmqahmozL_UWqTWqYPw2H5M>
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: Wed, 30 Mar 2022 18:06:44 -0000
While there is not anything TECHNICALLY wrong with the concept, the problem is that most people in the threat detection space have already decided NOT to advertise to a potential spammer that they know the message is spam. And any RFC which says you SHOULD and yet will promptly be ignored, is probably not the best use of time/RFC's. But for those who DO want to advertise it to the sender, it is good if there is a standard set out, but the RFC should be clear that this is simply a standardization, and NOT a recommendation. As a company who spends a lot of time doing analysis directly in the SMTP layer, it also opens up a can of worms. Do we add a code for every use case? 258 Deliver to the Marketing Folder 257 Stripped Attachments before delivery 256 Added your IP to our Blacklist 254 Accepted, but stripping headers (Poor examples, but helps address my point) Suggest that for those that want to present additional information, that it simply be textual on the 250 OK. Especially since the same message from a different sending MTA might get a different result, or maybe we only want to help a certain MTA or company get more information, eg an ESP Hope my feedback is valuable. On 2022-03-30 10:37, Brotman, Alex wrote: > Hey folks, > > 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. > > https://www.ietf.org/archive/id/draft-brotman-srds-01.txt > https://datatracker.ietf.org/doc/html/draft-brotman-srds-01 > > Thanks > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > _______________________________________________ > ietf-smtp mailing list > ietf-smtp@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-smtp -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
- [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