Re: [ietf-smtp] parsing SMTP replies

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 18 March 2021 22:58 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 D71DA3A0D09 for <ietf-smtp@ietfa.amsl.com>; Thu, 18 Mar 2021 15:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 blg3RQW8L305 for <ietf-smtp@ietfa.amsl.com>; Thu, 18 Mar 2021 15:58:18 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 79B4B3A0D07 for <ietf-smtp@ietf.org>; Thu, 18 Mar 2021 15:58:18 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 2A394D123B; Thu, 18 Mar 2021 18:58:16 -0400 (EDT)
Date: Thu, 18 Mar 2021 18:58:16 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf-smtp@ietf.org
Message-ID: <YFPbCG/VA86H5iyi@straasha.imrryr.org>
Reply-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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7aaaef02-bcdb-dbac-530e-580693a10cd7@linuxmagic.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/fEORSAIKw-4Ue3qbHv0Ff2K8WWk>
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 22:58:20 -0000

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.

-- 
    Viktor.