Re: [ietf-smtp] G.7.3 --- resolvable FQDNs

John C Klensin <john-ietf@jck.com> Mon, 10 August 2020 21:16 UTC

Return-Path: <john-ietf@jck.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 38C893A0D9A for <ietf-smtp@ietfa.amsl.com>; Mon, 10 Aug 2020 14:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Level:
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.212, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 8oUV18qIMXmk for <ietf-smtp@ietfa.amsl.com>; Mon, 10 Aug 2020 14:16:45 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-136.nh.cpe.atlanticbb.net [65.175.133.136]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FDD3A0D99 for <ietf-smtp@ietf.org>; Mon, 10 Aug 2020 14:16:45 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1k5F9H-000Aju-RI; Mon, 10 Aug 2020 17:16:03 -0400
Date: Mon, 10 Aug 2020 17:15:43 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael Peddemors <michael@linuxmagic.com>, ietf-smtp@ietf.org
Message-ID: <A073D29E7925698B1FD93E8E@JcK-HP5>
In-Reply-To: <6d79b01d-9fa1-0e12-ab62-d4fc58631f56@linuxmagic.com>
References: <20200808020843.9FB881E604C5@ary.qy> <58713b65-01a4-f07f-5fe4-6876001c20d1@linuxmagic.com> <20200810192324.GA76181@kiel.esmtp.org> <6d79b01d-9fa1-0e12-ab62-d4fc58631f56@linuxmagic.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/quloJM3EPLEi82IyD29HdwkMPQc>
Subject: Re: [ietf-smtp] G.7.3 --- resolvable FQDNs
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: Mon, 10 Aug 2020 21:16:47 -0000


--On Monday, 10 August, 2020 13:15 -0700 Michael Peddemors
<michael@linuxmagic.com> wrote:

> On 2020-08-10 12:23 p.m., Claus Assmann wrote:
>> On Mon, Aug 10, 2020, Michael Peddemors wrote:
>> 
>>> There SHOULD be a URL that responds to http://example.com,
>>> where information
>> 
>> This is e-mail, not some web stuff.
>> The contact information for various purposes are defined in
>> the RFCs (e.g., postmaster for e-mail).
> 
> The reason is for all the people who are NOT engineers, have
> an easy way to contact someone for ANY issues related to that
> domain.

That is the first difficulty.  It is not unusual, probably even
common these days, for the person or group managing the domain
to be different from the person or group managing the email
systems for that domain.  For the domain management, you've got
too hooks-- whois (or the registry database du jour) and the
email address in the SOA record.  If one is useless and the
other is even less maintained than Postmaster, tell it to ICANN:
Allowing domains without available "help" or other contact
information is a policy decision, not a technical one that is
going to be solved by new or different mechanisms.  For the
email side, what causes you to believe that an email system
operator who does not listen to Postmaster will listen or
respond to a special URL?

> As well, with everyone hiding 'whois', and so many companies
> that don't have a proper postmaster, or even check the
> postmaster mailbox, it does make sense, which is why it was
> recommended as a best practice.

At least IMO, it doesn't make sense unless and until there is
evidence that the operators or policy makers who cannot or will
not make information available or respond to queries via
established protocols will decided to make it available given a
new mechanism.

> There are more than just engineers out there that want to find
> out who is behind the 'mask'..

Sure.  But the direction of things favors "right to be masked"
rather than "right to find out who or what is causing a problem
and get it fixed".

And do note that mailto:postmaster@example.com is a URL.

> But yes, maybe it doesn't strictly belong in SMTP language,
> but a 'suggestion' might be in order..

You could try writing an Internet-Draft pointing out that it is
really, really, important to have that information available.
But, given the conflict between that goal and privacy, I
wouldn't be optimistic about its getting traction.

   john