Re: [ietf-smtp] parsing SMTP replies

Laura Atkins <> Mon, 22 March 2021 08:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B64C63A0ADB for <>; Mon, 22 Mar 2021 01:45:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dCxlYSmHGfRH for <>; Mon, 22 Mar 2021 01:45:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E06A33A0AD4 for <>; Mon, 22 Mar 2021 01:45:09 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 5531B9F149 for <>; Mon, 22 Mar 2021 01:45:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=aardvark; t=1616402708; bh=awnh8M5nZPhfL4dImmyoJb1H0IhX3VDnNC81yneCB0o=; h=From:Subject:Date:References:To:In-Reply-To:From; b=PhdHGt+rJq6kADXrEfkAuEKTYknj7CYf+DUsSEek08cMa2j+X9+cWZiLwG9ctvqWx fZMa/bRvQ9zWLhB3IPV+WC9nQHDnHB7u+W7xxiDZ2LXC7ek93ZZAxSiQqs5JdEgnNM vhFUq1OimOYAdjFIZrGJYEIXc2Aaa6Gq7j9R4RXA=
From: Laura Atkins <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E2DF5DD2-4B85-4BD2-9500-FD9E6D18543A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 22 Mar 2021 08:45:05 +0000
References: <CF0247A810AF9482CBB155E8@PSB> <> <> <> <> <4EC92B6CFDD4220E0F692CF0@PSB> <> <> <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3608.
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: Mon, 22 Mar 2021 08:45:15 -0000

> On 22 Mar 2021, at 01:16, Hector Santos <> wrote:
> On 3/17/2021 10:39 PM, Keith Moore wrote:
>> On 3/17/21 9:37 PM, Sam Varshavchik wrote:
>>> I believe that the generally good track record of historical interoperability of SMTP implementations goes back to what's in section 4.5.3 of RFC 821, that gives the minimal limits of various things, like line lengths. And, incidentally, the minimum number of recipients that an SMTP server should accept is 100 recipients. 
>> It's been a long time but I'm pretty sure I've seen situations in which it made sense for the recipient limit to be 1.�� For example: a special-purpose device (e.g. email to fax, email to printer) or a gateway to a dissimilar mail system, or anything for which it makes sense to insist that per-recipient errors get immediately reported to the client.
> Despite any standard, pseudo or otherwise, the ultimate limit is the local receiver/system and the minimum for a protocol complete SMTP transaction would be 1.
> Our system has no limit out of the box and its system wide (global registry value). No current out of the box logic per user.  There might be a 3rd party RCPT command override p-code script (smtpcmd-rcpt.wcx) that may place a limit.  Can't a typical system handle 1000, 10K, 100K+ RCPTs?  How does a big list send mail 1 million subscribers?  

Most of the very big senders, the ones sending to hundreds or millions of people at a time, use VERP. Depending on what is known about the domain MXs they open a set of connections and send the mail. Most of the bulk mail is sent with one RCPT TO:. This is true for marketing mail but even more true for transactional mail. 

>  When our MLS is going thru a submission distribution, it has a transport to SMTP or create UUCP-ready files option.  The former method gets to learn from the SMTP receiver RCPT responses where a permanent 5yz result could  unsubscribe the user after a number of consecutive different message times.  Any permanent negative results with the intention of just being a limit could be interpreted as a user does no longer exist.

I may have agreed with you a decade ago. But that’s not true for modern bulk senders. Bounces are classified and sorted. We are long past the days where any permanent negative result is interpreted as a user no longer exists. ( 


Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
(650) 437-0741		

Email Delivery Blog: