Re: [art] Auto-configuring Email Clients via WebFinger

Steffen Nurpmeso <steffen@sdaoden.eu> Thu, 18 July 2019 18:46 UTC

Return-Path: <steffen@sdaoden.eu>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180D0120B3E for <art@ietfa.amsl.com>; Thu, 18 Jul 2019 11:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 QBXh03GS3EJh for <art@ietfa.amsl.com>; Thu, 18 Jul 2019 11:46:36 -0700 (PDT)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 B83E712006B for <art@ietf.org>; Thu, 18 Jul 2019 11:46:35 -0700 (PDT)
Received: by sdaoden.eu (Postfix, from userid 1000) id 9CDB116057; Thu, 18 Jul 2019 20:46:32 +0200 (CEST)
Date: Thu, 18 Jul 2019 20:46:32 +0200
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Cc: art@ietf.org
Message-ID: <20190718184632.a4kqY%steffen@sdaoden.eu>
In-Reply-To: <9c6cde19-be14-4d13-9194-eff01770a61e@gulbrandsen.priv.no>
References: <20190717154133.928D850B9EE@ary.qy> <20190717223114.cO5Om%steffen@sdaoden.eu> <20190718051756.130D5510A29@ary.local> <9c6cde19-be14-4d13-9194-eff01770a61e@gulbrandsen.priv.no>
Mail-Followup-To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, art@ietf.org
User-Agent: s-nail v14.9.13-132-g2b425bda
OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt
BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs.
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/O7FZClkFnpI-UP6YxVIG-FbQmHI>
Subject: Re: [art] Auto-configuring Email Clients via WebFinger
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Jul 2019 18:46:38 -0000

Arnt Gulbrandsen wrote in <9c6cde19-be14-4d13-9194-eff01770a61e@gulbrand\
sen.priv.no>:
 |On Thursday 18 July 2019 07:17:55 CEST, John Levine wrote:
 |>> In the end i will have to implement actions aka "clickable" URLs
 |>> for a text-mode mail reader.
 |>
 |> I don't understand that at all.  Why would you need to do that?
 |
 |It sounds as if Steffen hasn't looked at Thunderbird autoconfiguration, at 
 |all, and is arguing that something else would be bad.
 |
 |BTW, Thunderbird is unlikely to be the only client that uses its scheme. 
 |The relevant stack overflow questions overwhelmingly point to the 
 |Thunderbird scheme.
 |
 |https://stackoverflow.com/search?q=%5Bimap%5D+autoconfiguration
 |https://stackoverflow.com/search?q=%5Bmail%5D+autoconfiguration

The final pages [1] and [2] would benefit from an update, to me
direct TLS connection via POP3S/SUBMISSIONS etc. are not
"old-style", but i personally prefer them over STARTTLS/STLS etc.
Also "remove the following and leave to client/user?" and "<!--
not yet supported -->" i would like to know the final outcome of
before possibly writing code and having the need to start linking
against expat in order to get this stuff right.

I personally fail to see the value in not making that a plain
UTF-8-by-definition text file in Windows resource file format,
maybe [section.subsection] or [section/subsection] so to group the
key/value pairs, and # comments.  It has to be XML / JSON / CBOR.
(I would go for the latter two if plain text is not feasible.
That is a ~500 line C code parser at maximum, which does not count
for such a feature, especially in a codebase like Thunderbird.)

  Please support authentication with CRAM-MD5. It is simple to
  implement, and to set up, and you can still use RADIUS or
  a database that stores passwords in plaintext, so you don't need
  ...

  As an ISP, you should ideally store passwords in encrypted
  format, which removes the risk of mass password theft (and
  possibly reuse on other sites) if somebody hacks your
  servers. You can still support plaintext passwords in this case,

It is often wise to reiterate things in public!
Please do not store the passwords on a server that is exposed to
the internet, get it from an internal server via TCP/TLS or
whatever; maybe the internal service could require a client
certificate before responding, that would be nice.  (I am not an
administrator, i really lack that much of knowledge for being
a good one even, but i became a bit frightened.)

  [1] https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration/FileFormat/HowTo
  [2] https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat

So many things are moving to .well-known now.  If this here
passes, then maybe S/MIME certificates via .well-known are not
that far away, too.  (My German passport does not offer any keys
or certificates for digital credentials, which is very sad.)

Personally i do not understand why this cannot be in DNS.  I have
seen SRV being brought up, and isn't that exactly the information
that DNS is designed for?

And all the best to your wife, Mr. Cridland!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)