Re: [ietf-smtp] parsing SMTP replies

Richard Clayton <> Sun, 21 March 2021 17:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4167C3A0E4B for <>; Sun, 21 Mar 2021 10:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cto9ROkroD4M for <>; Sun, 21 Mar 2021 10:06:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 911343A10FE for <>; Sun, 21 Mar 2021 10:06:59 -0700 (PDT)
Received: from localhost ([]:15909 by with esmtp (Exim 4.94) (envelope-from <>) id 1lO1XS-000OwT-1m for; Sun, 21 Mar 2021 17:06:54 +0000
Message-ID: <>
Date: Sun, 21 Mar 2021 17:05:25 +0000
From: Richard Clayton <>
References: <CF0247A810AF9482CBB155E8@PSB> <> <> <> <> <4EC92B6CFDD4220E0F692CF0@PSB> <> <> <> <> <YFPbCG/> <> <>
In-Reply-To: <>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.03 M <vPz$+rGj77$okMKLD2e+duyd9O>
Archived-At: <>
Subject: Re: [ietf-smtp] parsing SMTP replies
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\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Mar 2021 17:07:04 -0000

Hash: SHA1

In message <>om>, Ned Freed
<> writes

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

I think that you will find that the very large mailbox providers will
advertise <N> as the maximum value that they will accept from good
senders (since it will cause these good senders to gracefully shut
connections when the limit is reached) ... and they will continue to
refuse to accept as many as <N> from bad senders.

Since good/bad is a judgment by the receiver (and may be a view which is
being dynamically changed by complex ML systems during the email
reception process) the result of the new system is to add more
complexity to sender codebases (because they must cope with the world
just as it is at present, alongside the new scheme).

The cost to the receiving system is likely to be small -- since I cannot
imagine that a receiving system is going to freely advertise any more
than 1 bit of information (accept/reject connection) of its current view
of the good/bad state of the sender at EHLO time.

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

it's also one more step towards constructing a camel (as the DNS folk
call the issue of ever-increasing complexity in their specifications)

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

Version: PGPsdk version 1.7.1