Re: [ietf-smtp] parsing SMTP replies

Ned Freed <ned.freed@mrochek.com> Mon, 22 March 2021 16:22 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 670C03A0C06 for <ietf-smtp@ietfa.amsl.com>; Mon, 22 Mar 2021 09:22:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 zjGtGw0i0y8R for <ietf-smtp@ietfa.amsl.com>; Mon, 22 Mar 2021 09:22:47 -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 6186B3A0C01 for <ietf-smtp@ietf.org>; Mon, 22 Mar 2021 09:22:47 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWYPA1EOS000G4OG@mauve.mrochek.com> for ietf-smtp@ietf.org; Mon, 22 Mar 2021 09:21:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1616430085; bh=PncaicxYxGTu7Kuz4LeeE/WdX5G7J/9eTneU+I48bkk=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=rTBLVht8A9WcqLDRRd3H3AFIs41OwRuoaAGP8h3ZrdHXE5M6/wTevePUFT7+aBm8M oSq73JRkYVaHBIn1vaoDG62XIlbgL7Wbq5NXXPBxg5Q4ATVlsRkML6eu8tkhiRp4Vg vuW3daioGzCuSdj5vn2CYz8Zw2d8/MEQ33ApX7S4=
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=utf-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RWYMIKSOB40085YQ@mauve.mrochek.com>; Mon, 22 Mar 2021 09:21:19 -0700 (PDT)
Cc: ietf-smtp@ietf.org
Message-id: <01RWYP9ZH87A0085YQ@mauve.mrochek.com>
Date: Mon, 22 Mar 2021 08:57:26 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 22 Mar 2021 08:45:05 +0000" <EF538EC2-9D1F-4C05-948D-7CFA29052B3A@wordtothewise.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> <6057EFF6.7030401@isdg.net> <EF538EC2-9D1F-4C05-948D-7CFA29052B3A@wordtothewise.com>
To: Laura Atkins <laura@wordtothewise.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/nNenAHWXMxsi672C7whW5O-HgKI>
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: Mon, 22 Mar 2021 16:22:52 -0000

> Most of the very big senders, the ones sending to hundreds or millions of
> people at a time, use VERP.

Often combined with private header fields that carry additional information. Of
course you can't rely on getting the headers back in all cases, but you usually
do.

> Depending on what is known about the domain MXs they open a set of connections and send the mail.

Aka MX rollup. Unfortunately MX rollup runs afoul of things like systems that
only allow the specification of a single domain in a session. Caching
RCPTDOMAINMAX values may help with this, and make use of MX rollup more
automatable.

It's somewhat temping to add some sort of "the MXes pointing at this server
can be rolled up" indicator to the limits specification, but since it's not
a limit it doesn't really fit. If done it needs to be a separate EHLO
announcement.

> Most of the bulk mail is sent with one RCPT TO:. This is true for marketing mail
> but even more true for transactional mail.

There's also per-recipient customization in the mix, both for personalization
and display tracking.

> >  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.
> (https://wordtothewise.com/2019/11/theres-something-about-bounces/)

Packages like Simimai exist for a reason.

				Ned