Re: [ietf-smtp] parsing SMTP replies

Michael Peddemors <michael@linuxmagic.com> Thu, 18 March 2021 23:15 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 858A93A0DBC for <ietf-smtp@ietfa.amsl.com>; Thu, 18 Mar 2021 16:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Ak4j-S1R2jMv for <ietf-smtp@ietfa.amsl.com>; Thu, 18 Mar 2021 16:15:09 -0700 (PDT)
Received: from mail-ob1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id DF5943A0DBA for <ietf-smtp@ietf.org>; Thu, 18 Mar 2021 16:15:08 -0700 (PDT)
Received: (qmail 24059 invoked from network); 18 Mar 2021 23:15:08 -0000
Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (c7afa416-883f-11eb-835f-33f592158599); Thu, 18 Mar 2021 16:15:08 -0700
To: ietf-smtp@ietf.org
References: <CF0247A810AF9482CBB155E8@PSB> <01RWP85B98S4005PTU@mauve.mrochek.com> <20210316061139.GA26514@kiel.esmtp.org> <0d5912b5-6aba-728b-00de-a75397ad8ad8@tana.it> <01RWRTQUWB8Q005PTU@mauve.mrochek.com> <4EC92B6CFDD4220E0F692CF0@PSB> <cone.1616031446.909688.90196.1004@monster.email-scan.com> <7d448367-d5a0-7baf-3df4-dcafe1859437@network-heretics.com> <1B7BC0D7-5D34-4688-9D8A-BEA925D0ACCD@dukhovni.org> <7aaaef02-bcdb-dbac-530e-580693a10cd7@linuxmagic.com> <YFPbCG/VA86H5iyi@straasha.imrryr.org>
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
Message-ID: <7b9a865d-435d-55cc-7a8a-c7d984296b15@linuxmagic.com>
Date: Thu, 18 Mar 2021 16:15:07 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <YFPbCG/VA86H5iyi@straasha.imrryr.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-MagicMail-OS: Linux 2.2.x-3.x
X-MagicMail-UUID: c7afa416-883f-11eb-835f-33f592158599
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/sQ0N-1SNFRx1YsSG6GJlFahz0lQ>
Subject: Re: [ietf-smtp] parsing SMTP replies
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, 18 Mar 2021 23:15:11 -0000

On 2021-03-18 3:58 p.m., Viktor Dukhovni wrote:
> On Thu, Mar 18, 2021 at 10:57:12AM -0700, Michael Peddemors wrote:
> 
>> Personally, think the IETF should just stay out of recommending any
>> limits, or advertisement of limits, we already have mechanisms via the
>> 4xx and 5xx to tell the remote MTA what to do, and even a reason why we
>> did it, but there is no real 'standard' that is evident out there, so
>> why are we (IETF) attempting to set standards..
> 
> IETF standards are there to define interoperable behaviour.  Barring a
> change in the SMTP protocol that deprecates multi-recipient envelopes,
> an MTA relaying a message needs to know how many recipients it can
> reasonably expect to bundle up into a single delivery.
> 
> The standard specifies that servers are expected to handle at least 100,
> and that way be likely to avoid interoperability issues, since senders
> need to be able to handle servers that support only 100 and no more.
> 
> A server that supports fewer than 100 recipients per envelope may fail
> to interoperate reliably with conformant sending MTAs.  If the sender
> is in fact a source of unwanted junk, lossy email service is feature.
> But otherwise, if low limits are applied too broadly, the receiving
> MTA may face issues receiving multi-recipient messages in a timely
> manner or at all.
> 
> So I strongly take issue with "the IETF should just stay out...".
> 
>> This should come from the industry, and right now, every MTA admin has
>> different ideas on this, depending on their usage scenario.
> 
> Industry gets to participate in the IETF process to help define
> interoperable specifications.
> 

Not trying to start a flame war, just my position on THIS particular 
issue.. As pointed out, we have interoperability already through the use 
of 4xx and 5xx, and it isn't a case where systems are currently 
advertising a limit of recipient counts, where we now need to set a 
common standard.

If you show me MTA's currently advertising limits on how much they 
accept, then it may be something that needs to be addressed.

This seems to be a case of building a cart before the horse.

I think this is a case of sender's who 'hope' that MTA's advertise this 
maybe?

Either way, it seems like the wrong time/place to put in standards for a 
need that is not yet apparent.

But I bow out of this thread then.. I made my opinion known, which I 
also is part of my right to participate in the conversation.

(But I sure would like to see an opinion from an MTA developer that they 
are looking for a standard to advertise how many recipients they 
accept.. I don't think it is on anyone's radar .. oh, we should start 
advertising this.. )

And most sysadmin's still try to hide what MTA they are even running ;)

I now go back to my corner..


-- 
"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.