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.