Re: [ietf-smtp] parsing SMTP replies
Hector Santos <hsantos@isdg.net> Tue, 23 March 2021 15:23 UTC
Return-Path: <hsantos@isdg.net>
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 700373A1218 for <ietf-smtp@ietfa.amsl.com>; Tue, 23 Mar 2021 08:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-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=isdg.net header.b=feodz/Ot; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=ngj3HwZZ
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 9PF2-h3H29YM for <ietf-smtp@ietfa.amsl.com>; Tue, 23 Mar 2021 08:23:36 -0700 (PDT)
Received: from mail.winserver.com (ntbbs.santronics.com [76.245.57.69]) (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 2D8083A1217 for <ietf-smtp@ietf.org>; Tue, 23 Mar 2021 08:23:35 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5789; t=1616513005; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=EuDYbqdgzkAqq16f9JokeLn/liJB iztKNgmp0Px/B24=; b=feodz/Otaic9HBvMb0QjJF4K25zEVXqfkdc3ew7FapcJ jkyVuZSATC9ljWWRHQDT4TtfTvoKL4izrJP8/BOAfh/2yZGZ0rpwSVoABQVB5JvC w0RUk2EMmXGRCp8JL4i33RlY5rtd4pNPo+qEYuhyha+//SJYuqVxl/qtVHEEMhY=
Received: by mail.winserver.com (Wildcat! SMTP Router v8.0.454.10) for ietf-smtp@ietf.org; Tue, 23 Mar 2021 10:23:25 -0500
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; dmarc=pass policy=reject author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from beta.winserver.com ([76.245.57.74]) by mail.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 546197488.19922.3048; Tue, 23 Mar 2021 10:23:25 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5789; t=1616513012; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=EuDYbqd gzkAqq16f9JokeLn/liJBiztKNgmp0Px/B24=; b=ngj3HwZZbM8asoSFEV4BZyK WMUpwqKxUZoJRp00dPSxCqo23SpVOC6BiQ6FopC/2dpMyv7e509OIYLVh9ELIOZm hCQ9DQoAQQQoAEgCPf/vQYU93yMq0x7l1VP93k6Y6GkZLsrI/gNZfOXe1DayS6b/ 96a7P4xV+mzdHX73OcMM=
Received: by beta.winserver.com (Wildcat! SMTP Router v8.0.454.10) for ietf-smtp@ietf.org; Tue, 23 Mar 2021 11:23:32 -0400
Received: from [192.168.1.68] ([75.26.216.248]) by beta.winserver.com (Wildcat! SMTP v8.0.454.10) with ESMTP id 1229856753.1.21784; Tue, 23 Mar 2021 11:23:31 -0400
Message-ID: <605A07EB.6070702@isdg.net>
Date: Tue, 23 Mar 2021 11:23:23 -0400
From: Hector Santos <hsantos@isdg.net>
Reply-To: hsantos@isdg.net
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
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> <6057EFF6.7030401@isdg.net> <EF538EC2-9D1F-4C05-948D-7CFA29052B3A@wordtothewise.com>
In-Reply-To: <EF538EC2-9D1F-4C05-948D-7CFA29052B3A@wordtothewise.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/136RE0sC_--ns2DfrNKQB-VloSQ>
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: Tue, 23 Mar 2021 15:23:41 -0000
>> >> 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. Not sure how VERP applies in the Queuing strategies other than to get a better feel for tracking, sorting bounces, i.e. how was the user and where should the bounce be directed. Outbound Queuing Strategies (OQS) can be complex. Long established strategies have been developed, fined tuned with variable retry tables, per domains, per reply code, including socket vs smtp error codes, etc. Our OQS is pretty stable. I leave it alone. It works. Just let the engine run and eventually the mail gets out or bounced. :-) So in lieu of a pre-established authorization, contract for sending, as we know receivers have connection load (balancing) limits. One growing concern is with the growth of hosting domains using the same MXs. We see the same MX behavior across different (trade) business domains. It makes the queuing strategies a bit more complex as the sorting is more MX-dependent, not domain independent. For example, I can add a rule that says private domain "MyCustomer.com" should get priority over customers using free ESP domains, but it is possible, the ESP is hosting the private domains. I don't know if the ESP has a different profiles for the hosted domains, but currently, they appear to fall under the same umbrella as their regular free ESP mail service for the general public. I do think that the big free ESP domains are very bias towards legitimate mail senders with private customer mailing list who happen to have members from these bigger ESP domains. I am not talking about the big 1 million or even 1000 list, just maybe 100 and it can cause problems. They place a big burden on the sender to the point I have informed one big domain if they continue to slow down my machines delaying deliveries with erroneous reply code & response text, despite all things checked off to comply with their requirements, I will add new logic where these free ESP domains could be restricted from mailing list subscriptions, i.e. a new (silly) option to offer mail operators. The big free ESP domains make it far too easy for one user to stop other users from getting mail and hurt a business reputation. Worst, they make it extremely difficult for support to resolve the problem. This is what puts pressure on the small guys (like myself) to just totally block the usage of the free ESP domains. > >> 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/) > Nice graph. In other words, we need to get more into parsing the TEXT responses which is now an optional concept with the extended codes? To know the reasons for the bounce? The problem I found is that most of the time, the reply text are erroneous and/or vague and there is no standard here. Among the problem, we are seeing more domains claim "DMARC" support, throwing out untrue signals it is a standard and now required for mail delivery. For example, you get a 5yz with extended information with a link to some policy and the among the list of reasons, it is DMARC, SPF and bulk related stuff, maybe even a PTR requirement. Even with all those things met, most of the time, it just happen to be some user accidentally marked you as spam. Its not hard to do via some of the ESP's primitive UI. Even if unintentionally, its very hard to almost impossible to undo. The problem is that one user will affect all the other users getting the same message or same mail from the same domain. That's a problem also when Receiver X uses a set of verification methods that differs from Receiver Y. No consistency in receiver expectations. Anyway, regarding outbound mail strategies, there is the draft proposal for "retry=" time hint to help with minimizing retry delays and this has worked beautifully among conforming servers and clients. It is obviously doable with updating SMTP software. It believe we should develop a formal language for automated response text processing in order to resolve many of these "advanced" issues, like a RCPT limit. Of course, it has to consider backward compatibility. We currently would express a RCPT LIMIT idea with a 4yz response. I believe the RCPT LIMIT proposal attempts to reduce the RCPT commands when no longer accepted but there is no harm if the client was ignorant of this proposal. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Dave Crocker
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Viktor Dukhovni
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Dave Crocker
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Viktor Dukhovni
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John Levine
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John C Klensin
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Rolf E. Sonneveld
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Sam Varshavchik
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John Levine
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John C Klensin
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Claus Assmann
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Alessandro Vesely
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Jeremy Harris
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… John C Klensin
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Sam Varshavchik
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Keith Moore
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Viktor Dukhovni
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Valdis Kl ē tnieks
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Valdis Kl ē tnieks
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… John C Klensin
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Alessandro Vesely
- Re: [ietf-smtp] parsing SMTP replies Keith Moore
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… John C Klensin
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John C Klensin
- Re: [ietf-smtp] parsing SMTP replies Michael Peddemors
- Re: [ietf-smtp] parsing SMTP replies Ned Freed
- Re: [ietf-smtp] parsing SMTP replies Viktor Dukhovni
- Re: [ietf-smtp] parsing SMTP replies Michael Peddemors
- Re: [ietf-smtp] parsing SMTP replies Jeremy Harris
- Re: [ietf-smtp] parsing SMTP replies Laura Atkins
- Re: [ietf-smtp] parsing SMTP replies George Schlossnagle
- Re: [ietf-smtp] parsing SMTP replies Ned Freed
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Ned Freed
- Re: [ietf-smtp] parsing SMTP replies (was: Propos… Ned Freed
- Re: [ietf-smtp] parsing SMTP replies Richard Clayton
- Re: [ietf-smtp] parsing SMTP replies Hector Santos
- Re: [ietf-smtp] parsing SMTP replies Laura Atkins
- Re: [ietf-smtp] parsing SMTP replies Ned Freed
- Re: [ietf-smtp] parsing SMTP replies John C Klensin
- Re: [ietf-smtp] parsing SMTP replies Hector Santos
- Re: [ietf-smtp] parsing SMTP replies Hector Santos
- Re: [ietf-smtp] parsing SMTP replies Laura Atkins
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John Levine
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Jeremy Harris
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John Levine
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… George Schlossnagle
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Hector Santos
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Mike Hillyer
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John R Levine
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Michael Peddemors
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Jeremy Harris
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… George Schlossnagle
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Sam Varshavchik
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Laura Atkins
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Arnt Gulbrandsen
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Mike Hillyer
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Dave Crocker
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Richard Clayton
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Laura Atkins
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… John R Levine
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Richard Clayton
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Ned Freed
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Tony Finch
- Re: [ietf-smtp] [Emailcore] Proposed ESMTP keywor… Viktor Dukhovni