Re: IETF Policy on dogfood consumption or avoidance - SMTP version

Alessandro Vesely <vesely@tana.it> Thu, 19 December 2019 09:00 UTC

Return-Path: <vesely@tana.it>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BCB1201AA for <ietf@ietfa.amsl.com>; Thu, 19 Dec 2019 01:00:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 zndcnqRYB64T for <ietf@ietfa.amsl.com>; Thu, 19 Dec 2019 01:00:26 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 8CA10120152 for <ietf@ietf.org>; Thu, 19 Dec 2019 01:00:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1576746022; bh=XbS8mQ2tyJJ40+ccx6PwDHUf6HEVONhs8BvH4GMBAAw=; l=978; h=To:Cc:References:From:Date:In-Reply-To; b=BiMSTCRPLqZUH9WnjVY4euGsI4RdecjqeZd3TExqMopglrL3NXYwuBH0Hd/InEVU4 f3k1yggkosNHbm7CPQSPVBrqCke8DehuOBDjxScYCfrjI2t9dk93IUIW0HnKIFWZTF ZPsphKXYorbyClygLegqoPdpGYnwgCGhWMioa0aFJJSUPoU70h/Fux6nHnuZf
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.2, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC08B.000000005DFB3C26.0000779A; Thu, 19 Dec 2019 10:00:22 +0100
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
To: Eliot Lear <lear@cisco.com>
Cc: John C Klensin <john-ietf@jck.com>, ietf <ietf@ietf.org>
References: <8EE11B75E1F8A7E7105A1573@PSB> <m2a77ttff6.wl-randy@psg.com> <CABL0ig4Wz-0dk7bsRpaN6pni2rHEc-jPnygwed_Hygy+CiehQA@mail.gmail.com> <16306b3a-63bd-621e-636c-dd7626f74733@foobar.org> <4D7EEBF62E149D1F23BA6A32@PSB> <58595081-6F4F-45E2-9798-B691AC919D28@cisco.com> <15D46124EFC1486F3613EF01@PSB> <0D67643B-00ED-482A-BCE0-1CF5A513C61F@cisco.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <1fdc9df2-b66b-26cc-0e83-e973d30b8ec0@tana.it>
Date: Thu, 19 Dec 2019 10:00:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <0D67643B-00ED-482A-BCE0-1CF5A513C61F@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4WUOr7c8IrRtUgHSn9I6qLH45MU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 09:00:28 -0000

On Thu 19/Dec/2019 09:16:23 +0100 Eliot Lear wrote:
> If you can’t manage to get a PTR into the DNS, there are a great many options
> that include, but are not limited to using a free or pay-for mail service.  You
> can still build your own, but you may have to use a data center that agrees to
> update the PTR record for you (this is what I have done).  A mechanism even
> exists to accomplish this with EC2 at very nominal prices (~USD $10/month)


That's hardly acceptable.  For one point, being forced to virtualize the mail
server, to locate it in a remote data center, or to outsource its service
tout-court is not the kind of solution to be encouraged.  It exacerbates the
trend toward few giant email operators.

I respect IETF's decision to outsource the management of its mailing lists.  On
the other hand, the standard should respect the will to keep mail servers in
house, and try and ease doing so at current market conditions.


Best
Ale
--