Re: [ietf-smtp] parsing SMTP replies

George Schlossnagle <george@sparkpost.com> Fri, 19 March 2021 12:15 UTC

Return-Path: <george@sparkpost.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 0BB253A112E for <ietf-smtp@ietfa.amsl.com>; Fri, 19 Mar 2021 05:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.077
X-Spam-Level:
X-Spam-Status: No, score=-1.077 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, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sparkpost.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 s0jZhDc2c684 for <ietf-smtp@ietfa.amsl.com>; Fri, 19 Mar 2021 05:15:14 -0700 (PDT)
Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96A53A1135 for <ietf-smtp@ietf.org>; Fri, 19 Mar 2021 05:15:10 -0700 (PDT)
Received: by mail-ej1-x633.google.com with SMTP id u9so9345276ejj.7 for <ietf-smtp@ietf.org>; Fri, 19 Mar 2021 05:15:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sparkpost.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=SxuzttEJ+M8pRFLz+im7NIoPjkLzieClsbu9N/deVCk=; b=E1nfVXy98JmDKc7T2AiPHa+aHqBQWo0k9R9OCGHsIrcd3cSHSHbyLS+1CFFiXUX4qF Uzjs/JREMJhF+M7YjDAG7ybMmEDSh2nU5sJY9OI/n7h309kxQEpntb9GIg+hH+grUApe t9UPKPu6H1c7kcq/BdfoXVljL0Ai5Bw9XC3cw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=SxuzttEJ+M8pRFLz+im7NIoPjkLzieClsbu9N/deVCk=; b=lWHOUN0+eFrpHVTWLPIc6/BuZb3ZMl6MfWIx9FLeMeezMHYpZ/8w8oXHlyUDPmxlDj 3lgvO6Lk99mBkHP9Dks5hJ1DaIhi5shMZBEUVc9JKVN0vNTW5G5XzBSgQtTO0RGi21Vb 6vlVrdbx2MV4c6DJWsK+1Yt67dgUaFggzN3CbeC2wW+y+FbO3my0j4Gfw7OyC/WcHL7u 8yRK8oWDnqCrQFNio0HN6h/PiM08o4Oqp9idhmjKH6x7yIINgWJG1tQ2oer75aB0/Ko2 uDuCALk9SsnKmylm/WvCSzer/usnScWP7sw4uD3BP1kgOsfBQ3EU+sjZf5d7OPFyOlu+ z7iw==
X-Gm-Message-State: AOAM532Og4f47TmlO8pkATCCXzMrX+bMYK8EystAKN3XwObBWBotGDeG obUDz6VHSxEanEnQDXvpC603QdDTfNAzHa198YNMaSWx1Q==
X-Google-Smtp-Source: ABdhPJylxVm73mhIx5Wo2hJvfbQj7BI/o+63tNNpYXGMt+75JvnAR4KnxJyIbpYKvbOtUHypN78iIymmkgfHljpuSRc=
X-Received: by 2002:a17:906:4055:: with SMTP id y21mr3881282ejj.507.1616156108790; Fri, 19 Mar 2021 05:15:08 -0700 (PDT)
MIME-Version: 1.0
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> <1B7BC0D7-5D34-4688-9D8A-BEA925D0ACCD@dukhovni.org> <7aaaef02-bcdb-dbac-530e-580693a10cd7@linuxmagic.com> <YFPbCG/VA86H5iyi@straasha.imrryr.org> <7b9a865d-435d-55cc-7a8a-c7d984296b15@linuxmagic.com> <a82d482d-0c4e-281e-49a5-6cd68cac51e7@wizmail.org> <032A2CA7-E1CC-412F-BEF6-96981784FB05@wordtothewise.com>
In-Reply-To: <032A2CA7-E1CC-412F-BEF6-96981784FB05@wordtothewise.com>
From: George Schlossnagle <george@sparkpost.com>
Date: Fri, 19 Mar 2021 08:14:57 -0400
Message-ID: <CAO=DXp87KU=U9eAiSJA_gCEs94yrzwXeuv-isK+b1qFe04OH4Q@mail.gmail.com>
Cc: ietf-smtp@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c4305005bde2aa23"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/a9Johr64hICQdDaEXU91rcOboMY>
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: Fri, 19 Mar 2021 12:15:16 -0000

Hi,

We (MessageSystems/SparkPost, makers of the Momentum and PowerMTA mtas)
already support interpreting smtp responses to infer requested behavior in
regards to the number of connections and message velocity limits. As Laura
notes, this is already established behavior with some large providers.
Today we have to parse the whole response string to comply with different
providers bespoke strings. A set of extended codes to make this
standardized and easier to parse would be fantastic.

George

On Fri, Mar 19, 2021 at 04:55 Laura Atkins <laura@wordtothewise.com> wrote:

>
>
> On 18 Mar 2021, at 23:27, Jeremy Harris <jgh@wizmail.org> wrote:
>
> On 18/03/2021 23:15, Michael Peddemors wrote:
>
> If you show me MTA's currently advertising limits on how much they accept,
> then it may be something that needs to be addressed.
>
>
> Apart from people building prototypes to demo this proposal, there are no
> such MTAs precisely because there is no standard to do so.
>
>
> The MTAs aren’t advertising limits, but the companies running the MTAs do
> set limits on senders. There’s just no programatic way to advertise them.
>
> Yahoo: limits connections, also limits the number of emails per connection
> and will just close connections after that limit has been reached.
>
> Gmail: prefers fewer connections and as much mail shoved through it as
> possible.
>
> Microsoft: admits there is a limit to connections, but does not make that
> public.
>
> Modern bulk MTAs have built in controls so these limits can be manually
> configured. They also have AI / ML / automatic processes that will modify
> sending behavior on the fly. These can be per MX, IP, MX cluster, or
> whatever.
>
> These things are happening already (and have been for a decade) they’re
> just not standardized.
>
> laura
>
>
>
> Either way, it seems like the wrong time/place to put in standards for a
> need that is not yet apparent.
>
>
> The need is for a more efficient, in roundtrips, way of communicating
> limits
> than getting individual command responses.
> --
> Cheers,
>  Jeremy
>
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>
>
> --
> Having an Email Crisis?  We can help! 800 823-9674
>
> Laura Atkins
> Word to the Wise
> laura@wordtothewise.com
> (650) 437-0741
>
> Email Delivery Blog: https://wordtothewise.com/blog
>
>
>
>
>
>
>
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>
-- 
*GEORGE SCHLOSSNAGLE*
chief evangelist
www.sparkpost.com
(el) george@sparkpost.com