Re: [ietf-smtp] why are we reinventing mta-sts ?

"Valdis Kl=?utf-8?Q?=c4=93?=tnieks" <valdis.kletnieks@vt.edu> Tue, 08 October 2019 14:06 UTC

Return-Path: <valdis@vt.edu>
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 A2E3912007C for <ietf-smtp@ietfa.amsl.com>; Tue, 8 Oct 2019 07:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wx3zT90oqXjN for <ietf-smtp@ietfa.amsl.com>; Tue, 8 Oct 2019 07:06:37 -0700 (PDT)
Received: from omr2.cc.vt.edu (omr2.cc.ipv6.vt.edu [IPv6:2607:b400:92:8400:0:33:fb76:806e]) (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 46E4F120052 for <ietf-smtp@ietf.org>; Tue, 8 Oct 2019 07:06:37 -0700 (PDT)
Received: from mr3.cc.vt.edu (mr3.cc.vt.edu [IPv6:2607:b400:92:8500:0:7f:b804:6b0a]) by omr2.cc.vt.edu (8.14.4/8.14.4) with ESMTP id x98E6ZiD029679 for <ietf-smtp@ietf.org>; Tue, 8 Oct 2019 10:06:36 -0400
Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) by mr3.cc.vt.edu (8.14.7/8.14.7) with ESMTP id x98E6U8l001627 for <ietf-smtp@ietf.org>; Tue, 8 Oct 2019 10:06:35 -0400
Received: by mail-ua1-f70.google.com with SMTP id r21so3083998uao.16 for <ietf-smtp@ietf.org>; Tue, 08 Oct 2019 07:06:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=pTWjJza14AiBX+IG16FIMkYyCSAnck6Iqs21yCddCB0=; b=P5dYOeaZiiWzQcLJd5IF46An/WuPlRfF6U9yHJvbJ6NjesXRzuWPWN6d/TBYyFs7Kt LCkGQ/n+2UTiYej+3POW6zPS/O23q/+thdz/AXrvricLUnMbniYMX45tb4DRvOrk7EVv 3LeIePs+n49pt/gv3rQ98u8l4KhuI+QvewJ05rQAjlfwT6lNVS4bXbIbqIrvEwZN9yPG wgTxYlyePLndG4oJMCm2+I/neOKie3JOg0srvQO9X7rXTa7GqT72GD8k2cu1x4wLlpdG /+iXrIsaK4ZzoUxNf7k5sMESOXgBbK03A6wXVfWQnxRio70JJd+404Sjzhxx+ansCEfJ /GDA==
X-Gm-Message-State: APjAAAVgBP9tmVe1r6uFfsbgOv++zD8i9HCfXRjjEruwuRImBv0qdx6P tQo/Pzsnn98Zk1RoeHXYOj1RSEYnd8m8V0cM4XsZTSuSZAVFCy4Dw8Z2xmgD6lj0oHeo2CsPXts bCsAH5RuKvIWJdp/eBD3Vqw==
X-Received: by 2002:a0c:ffa7:: with SMTP id d7mr31548114qvv.12.1570543105075; Tue, 08 Oct 2019 06:58:25 -0700 (PDT)
X-Google-Smtp-Source: APXvYqysNnqJe3j4ky+pZy1t5BZkZhsazHvozzNtirzi3pJr7xYYc06gi8oQbY8L/tfc2YjV4mgBAQ==
X-Received: by 2002:a0c:ffa7:: with SMTP id d7mr31548086qvv.12.1570543104633; Tue, 08 Oct 2019 06:58:24 -0700 (PDT)
Received: from turing-police ([2601:5c0:c001:4341::9ca]) by smtp.gmail.com with ESMTPSA id a190sm10661919qkf.118.2019.10.08.06.58.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Oct 2019 06:58:23 -0700 (PDT)
Sender: Valdis Kletnieks <valdis@vt.edu>
From: Valdis Kl=?utf-8?Q?=c4=93?=tnieks <valdis.kletnieks@vt.edu>
X-Google-Original-From: "Valdis Klētnieks" <Valdis.Kletnieks@vt.edu>
X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev
To: Stan Kalisch <stan@glyphein.mailforce.net>
Cc: Viruthagiri Thirumavalavan <giri@dombox.org>, SMTP Discuss <ietf-smtp@ietf.org>
In-Reply-To: <f7b9f700-7303-449d-8212-147f29d0bdfd@www.fastmail.com>
References: <20191007002348.GA23742@x2.esmtp.org> <20191007015616.BE113BB3D68@ary.qy> <CANtKdUeC0NVfvVpbHtwd=OoO=BoT8KNWVx8BGF-GPZPU-zo6QA@mail.gmail.com> <CAOEezJTH4Jukz2J4jSDfixECg2Jyyk4+cDnasiAoa4Q2F9=ZZw@mail.gmail.com> <b0dae4ca6e95dc83ca70f71ad780a1432273bcf5.camel@aegee.org> <CAOEezJRXUZkPoJn_kV92q=OQoUs32VzTR5a0JeAKg6NYBW55=Q@mail.gmail.com> <19705.1570469430@turing-police> <f7b9f700-7303-449d-8212-147f29d0bdfd@www.fastmail.com>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_1570543102_19279P"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Tue, 08 Oct 2019 09:58:22 -0400
Message-ID: <78878.1570543102@turing-police>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/0jfIPV2d41YCdQLpPxqOF2M6aBM>
Subject: Re: [ietf-smtp] why are we reinventing mta-sts ?
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, 08 Oct 2019 14:06:39 -0000

On Mon, 07 Oct 2019 15:10:29 -0400, "Stan Kalisch" said:

> That may be, but I do not think, however, that this addresses Viruthagiri's
> assertion about the cost being prohibitive for some in developing countries.

The point is that there's 3 basic cases:

1) You're outsourcing the e-mail to a company. The added cost for the webserver
will probably be close to zero, because if the proposal gets enough traction to matter,
hosting companies will be able to do it at scale, and bundle it for free.

2) You're doing low-volume e-mail in-house. The added resources needed for
the webserver will probably be close to zero, because somebody will write a
"how-to" or even write an open-source program that you enter your domain name
and host name, and it writes the config files for you.

3) You're doing in-house e-mail at a volume that the web server resources matter.
At this point, you're *already* going to be fighting with scaling issues with  your SMTP
system and the web server is the least of your worries....

Yes, in some situations the cost of e-mail for an organization can be prohibitive.
However, this isn't a proposal that doubles the cost of doing it. It's more likely
going to add a half-percent or so - there's probably going to be a half-dozen things
applying more economic pressure.

And it's probably *far* too early in the protocol design process to be saying "oh,
but this *might* be a problem for a very very small percentage of sites" - especially
since we're talking about an *optional* extension.