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