Re: [regext] Internationalized Email Addresses and EPP

Taras Heichenko <> Tue, 24 November 2020 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D54FF3A1695 for <>; Mon, 23 Nov 2020 23:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id asLdZ3JEqyNf for <>; Mon, 23 Nov 2020 23:19:12 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C921A3A1692 for <>; Mon, 23 Nov 2020 23:19:11 -0800 (PST)
Received: from [] by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from <>) id 1khSbP-000Kws-Gt; Tue, 24 Nov 2020 09:19:09 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Taras Heichenko <>
In-Reply-To: <>
Date: Tue, 24 Nov 2020 09:19:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20201123205504.4A58627C7661@ary.qy> <> <> <> <> <>
To: Patrick Mevzek <>
X-Mailer: Apple Mail (2.3654.
X-Spam-Score_int: [] -28
Archived-At: <>
Subject: Re: [regext] Internationalized Email Addresses and EPP
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Nov 2020 07:19:14 -0000

> On 24 Nov 2020, at 01:26, Patrick Mevzek <> wrote:
> On Mon, Nov 23, 2020, at 18:12, Taras Heichenko wrote:
>>> This is completely orthogonal to anything related to email addresses.
>>> Long gone are the days when only an email sent was enough to trigger a transfer,
>>> and for good reasons.
>> I said nothing about only an email address but complete contact 
>> information. Most
>> of our registrars were checking an entire Contact object to identify 
>> the user requesting
>> a transfer to avoid court. 
> I fail to see how this authenticates anything
> (and to be able to do this any registrar needs to be allowed to do contact:info
> on any contact, with a transfer in the future or not, which is surely a privacy
> problem at least, or the data must be public in whois/RDAP which is another privacy
> issue also, besides the fact that in this case anyone can just impersonate anyone
> else by reading the output in this model), but in all cases this is completely
> irrelevant to the discussion in this thread so no real point discussing one specific
> registry policy around transfers, yes they are many out there, none to my knowledge
> relying only on email value being known/available to reply.

Two notes:
- the authinfo field in a Contact object allows opening personal data to only one registrar
- it is not registry policy, it is the registrar's agreement

> If registrars want to compare contact data before even staging a transfer request,
> and can per registry procedures/policies in which they operate,
> then there is no problem regarding EAI: if the customer gives an "internationalized" email
> to the registrar, and the registrar does not handle it, the problem will not be solved
> by anything done at the EPP level, so is completely out of scope here.
> The registrar will have to fix its systems first, and we are back to Mr. Levine point.
> Which is fine if registries want to do that, understanding that in that case some
> registrars may decide not to sell their TLDs, which can be fine or not, but a problem
> for the registry to decide and for which this protocol called EPP can not do anything.

I just wanted to say that if a registrar cannot handle the internationalised email of new
customer it will lose new customers and this situation force it to fix its EPP.

> -- 
>  Patrick Mevzek
> _______________________________________________
> regext mailing list

Taras Heichenko