Re: [ietf-smtp] parsing SMTP replies

Ned Freed <ned.freed@mrochek.com> Fri, 19 March 2021 14:46 UTC

Return-Path: <ned.freed@mrochek.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 3BD433A16F9 for <ietf-smtp@ietfa.amsl.com>; Fri, 19 Mar 2021 07:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 ihofMvI3vrNP for <ietf-smtp@ietfa.amsl.com>; Fri, 19 Mar 2021 07:46:25 -0700 (PDT)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 911E03A16F8 for <ietf-smtp@ietf.org>; Fri, 19 Mar 2021 07:46:25 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWUEX0IRPC00EB70@mauve.mrochek.com> for ietf-smtp@ietf.org; Fri, 19 Mar 2021 07:41:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1616164881; bh=pCUC/lagDxEOsPG/b1WzO8sQDbknKulc5mnzJes/nJk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Bx/0gHHLNnQQLq6brESL1KdYvwazVxocsS511KhgOgjWEooiJEYsiXebjvCp0Xr1O 8bZ/M9Bu8eeUUptghEZp7RXpUR/unhL/fbOklHTkswTdeH5Y0QH+ValW4zDOyAdauS 7XPfWMvgr3kZljHB9z3TYELm89GiVoumfzIFS3bo=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWJORF3ZF4005PTU@mauve.mrochek.com>; Fri, 19 Mar 2021 07:41:19 -0700 (PDT)
Cc: ietf-smtp@ietf.org
Message-id: <01RWUEWYVWKQ005PTU@mauve.mrochek.com>
Date: Fri, 19 Mar 2021 07:28:14 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 18 Mar 2021 16:15:07 -0700" <7b9a865d-435d-55cc-7a8a-c7d984296b15@linuxmagic.com>
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> <7b9a865d-435d-55cc-7a8a-c7d984296b15@linuxmagic.com>
To: Michael Peddemors <michael@linuxmagic.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/9dDZCLYrqWO5Fb-vgHmMwIAfiPM>
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: Fri, 19 Mar 2021 14:46:28 -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.

Not really. As has been previously pointed out in the discussions of this
matter, there are quite a few subtleties in implementing proper handling of 4YZ
replies when multiple recipients are involved. Fail to get this right and your
mail doesn't get through, and even if it does it may experience sigfniciant
delays.

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

But that's precisely the point: They can't currently do this in an
interoperable way because there's no standard for it.

You seem to be arguing that that a standard in this area necessarily has to
evolve from some sort of widely used nonstandard practice. If so, I strongly
disagreee: While this happens fairly often, it's actually a lousy way to do
standardization work.

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

Of course it is. That's how standardization is done. We try to anticipate
need whenever possible. And sometimes we get it right, other times
we get it wrong.

When I first did the pipelining SMTP extension - based on work done earlier by
Marshall Rose -  I faced a high degree of pushback in the IETF from people who
didn't think there was or would ever be any interest in optimizing email
transfer to this extent.

In hindsight, do you think that effort was a waste of everyone's time?

Of course in this case we're coming to the party much later, and this makes the
problem that much harder to solve. And we may end up with something nobody
is willing to implement. You pay your money and you take your chances.

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

I absolutely plan to implement the server side of this and hope that
clients pay attention so they can optimize their behavior accordingly.

				Ned