Hi, I did get travel permission (while I was writing that mail yesterday, actually). ICANN’s pretty good about such things, even if the processing time can be a little random. On reflection, I think the strong caution against sending even a single message deserves admiration. It’s one of the things that distinguishes honest mass mailers from spammers: “When in doubt, when in even a little bit of doubt, don’t send mail to that address.” It makes life difficult for us, but IMO it’s an admirable stance all the same. Arnt From: "Mark Svancarek (CELA)" <marksv@microsoft.com> Date: Wednesday, 22 May 2024 at 21:58 To: Arnt Gulbrandsen <arnt.gulbrandsen@icann.org>, UA EAI WG <ua-eai@icann.org>, UA Technology Working Group <ua-tech@icann.org> Subject: [Ext] RE: [UA-EAI] Validating email addresses, and the HTML5 <input type="email"> spec Thanks, Arnt, this is clear and helpful. I understand the situation much better. LMK if you don’t get the travel budget, I will help look for someone who can represent on your behalf. That would be very unfortunate (and I can’t be sure of finding such a person) so don’t take that as an excuse for your management not approving the travel. /marksv From: UA-EAI <ua-eai-bounces@icann.org> On Behalf Of Arnt Gulbrandsen via UA-EAI Sent: Wednesday, May 22, 2024 2:02 AM To: UA EAI WG <ua-eai@icann.org>; UA Technology Working Group <ua-tech@icann.org> Subject: [EXTERNAL] Re: [UA-EAI] Validating email addresses, and the HTML5 <input type="email"> spec Hi, I’ve been out and about talking to people, and you’d be surprised: Some of them know their work and do it well. Some of those web people know the web better than I do. There are people whose entire job is contact forms. For such people, a contact form has three purposes: 1. Allow real people to do what they need to do. (If a customer wants to send a message to customer service, then the form’s primary purpose is to get the message there.) 2. Never send even a single message in response to bad guys. (There’s someone who goes around sending one of my addresses to contact forms, perhaps in the hope that I’ll visit spammers at home and bring an axe.) 3. Provide the site owner with actionable data. (If it’s a telco and the contact form is for customers, then add a required field, “your phone number” so customer service will know which customer it is.) Handling email syntax correctly isn’t on that list because it isn’t even nearly as important as those three. It’s not something they forgot because they’re ignorant. They know their work and they know their three big priorities. We’re not going to persuade anyone by insisting. In particular, if I ask the question “what’s most important to you, supporting all valid email addresses or rejecting input from bad guys?” the answer is that they prefer rejecting input, at once, without doubt. I know someone who has the email address #@example.com<mailto:#@example.com> (except that it’s a different domain). That address has very little chance of being accepted by a contact form. Is that OK? I keep my opinion to myself, because I’m writing this at work. My job is to further UA and I’d rather not digress into #@. He’s a nice guy and he has written software that helps us all, but he has a rare and unusual address, not one of my top-50 problems. Instead I’ll present an argument that #@example.com<mailto:#@example.com> is an invalid address: “Most people will think it’s invalid or be puzzled by the address”. You all agree that most people will think so? Yes? There’s a kind of mentally agreed syntax for email addresses, and # isn’t allowed in that. Building on that, “if a telco wants to assess an address and guess whether it’s from a prospective customer or not, then #@ is a sign that it isn’t”. Prospective customers have addresses that match the general public’s general idea of an email address. The W3C has a fairly good regex for ASCII email addresses. It’s not perfect, but it’s not bad. If the general public considers an address valid, then that regex does, too, and the regex doesn’t accept very much else. They’ve been trying to extend it for Unicode, and not getting anywhere. I now think I understand why: a regex can’t provide the same good match in the case of Unicode. A regex will either be too strict or surprisingly lax, it won’t provide the same sort of fit. (The github issue that started this discussion is IMO doomed to repeat in cycles.) By coincidence, there’s also unhappiness in the IETF about the Unicode address syntax. That held up publication of RFC 9553 for a little while. I think the time is right to get an RFC published that * satisfies the IETFers who think that 1*UTF8CHAR is too lax for email localparts * matches the general notions of the people who validate email addresses for a living * can be referenced in a W3C document such as that for type=email and * accommodates the kinds of addresses Xgenplus and Coremail hand out to customers. I still don’t have travel permission to the next IETF meeting, in July, but if I get it, I’ll submit a draft before the event and will be talking as smoothly as I can about it. I know roughly what I want to say, there’s some doubt about particular details (e.g. concerning ASCII digits in non-ASCII email addresses). Arnt