Request for review: Report on Evaluation of Websites for Acceptance of E-mail Addresses, 2019
Dear all, Please find attached a recent study undertaken on the request of UASG on the Global Evaluation of Websites for Acceptance of E-mail Addresses 2019, for your review and feedback. Please send your feedback on ua-discuss@icann.org<mailto:ua-discuss@icann.org> list (visit https://uasg.tech/subscribe to subscribe) by 29 July. We look forward to your input. Regards, Sarmad
Please find attached a recent study undertaken on the request of UASG on the Global Evaluation of Websites for Acceptance of E-mail Addresses 2019, for your review and feedback. Please send your feedback on ua-discuss@icann.org<mailto:ua-discuss@icann.org> list (visit https://uasg.tech/subscribe to subscribe) by 29 July. We look forward to your input.
As I understand it, the tests checked whether a web form accepted an address, but it didn't check whether the site could actually send mail to that address. There's a lot of places where EAI mail can fail between the browser and the recipient's MTA, so the report should make it clear that the percentages reported are an upper bound, with the actual numbers likely being somewhat less. With respect to the HTML5 pattern for e-mail addresses, I have talked to people in WHATWG about it. That pattern is correct for ASCII addresses and it's not going to change to an EAI pattern because that would lead to web sites with ASCII mail systems accepting addresses to which they can't send mail. They would be open to adding a new "eaimail" input type that accepts EAI addresses, to allow an easy upgrade when sites have EAI capable back ends. Nothing is going to happen in WHATWG until one of their large members says they'll implement it which hasn't happened. I've made some inquiries and gotten polite responses, but I can't do much more since I have no funding. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On 12 Jul 2019, at 15:06, John R. Levine wrote:
Please find attached a recent study undertaken on the request of UASG on the Global Evaluation of Websites for Acceptance of E-mail Addresses 2019, for your review and feedback. Please send your feedback on ua-discuss@icann.org<mailto:ua-discuss@icann.org> list (visit https://uasg.tech/subscribe to subscribe) by 29 July. We look forward to your input.
As I understand it, the tests checked whether a web form accepted an address, but it didn't check whether the site could actually send mail to that address. There's a lot of places where EAI mail can fail between the browser and the recipient's MTA, so the report should make it clear that the percentages reported are an upper bound, with the actual numbers likely being somewhat less.
agreed. I wrote similarly in a email sent almost at the same time as yours.
With respect to the HTML5 pattern for e-mail addresses, I have talked to people in WHATWG about it. That pattern is correct for ASCII addresses and it's not going to change to an EAI pattern because that would lead to web sites with ASCII mail systems accepting addresses to which they can't send mail. They would be open to adding a new "eaimail" input type that accepts EAI addresses, to allow an easy upgrade when sites have EAI capable back ends.
Nothing is going to happen in WHATWG until one of their large members says they'll implement it which hasn't happened. I've made some inquiries and gotten polite responses, but I can't do much more since I have no funding.
from https://w3c.github.io/test-results/html53/implementation-report.html, done back in september, Firefox seems to support, while others were not tested. Marc.
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Fri, 12 Jul 2019, Marc Blanchet wrote:
With respect to the HTML5 pattern for e-mail addresses, I have talked to people in WHATWG about it. That pattern is correct for ASCII addresses and it's not going to change to an EAI pattern because that would lead to web sites with ASCII mail systems accepting addresses to which they can't send mail. They would be open to adding a new "eaimail" input type that accepts EAI addresses, to allow an easy upgrade when sites have EAI capable back ends.
Nothing is going to happen in WHATWG until one of their large members says they'll implement it which hasn't happened. I've made some inquiries and gotten polite responses, but I can't do much more since I have no funding.
from https://w3c.github.io/test-results/html53/implementation-report.html, done back in september, Firefox seems to support, while others were not tested.
Ah, that is as we say a can of worms. The actual HTML spec that major browser vendors implement is the WHATWG living standard. W3C copies that spec verbatim into their own standard, except that they make some incompatible changes. WHATWG has repeatedly asked W3C not to do that, but W3C persists. One of those incompatible changes is e-mail addresses. WHATWG has a recommended address validation pattern pattern which is a subset of the RFC5321/5322 spec that matches what real mail systems accept well. W3C changed that to accept any UTF-8 which is wrong for many reasons. One is that it's gratuitously incompatible, another is that it provides no way to distinguish between EAI and non-EAI back end mail systems, and a third is that real EAI mail systems are unlikely to accept all of the random mixes of scripts and punctuation that the W3C pattern allows. The way people use the WHATWG pattern is that they cut and paste it into their javascript libraries and the browser just runs the javascript. So long as everyone follows WHATWG it hardly matters what W3C does. Before WHATWG will add an EAI pattern for programmers to use, it needs an eaimail input type to distinguish EAI and non-EAI mail backends, which needs browser and web server support. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On 7/12/19 16:20, John R. Levine wrote:
On Fri, 12 Jul 2019, Marc Blanchet wrote:
With respect to the HTML5 pattern for e-mail addresses, I have talked to people in WHATWG about it. That pattern is correct for ASCII addresses and it's not going to change to an EAI pattern because that would lead to web sites with ASCII mail systems accepting addresses to which they can't send mail. They would be open to adding a new "eaimail" input type that accepts EAI addresses, to allow an easy upgrade when sites have EAI capable back ends.
Nothing is going to happen in WHATWG until one of their large members says they'll implement it which hasn't happened. I've made some inquiries and gotten polite responses, but I can't do much more since I have no funding.
from https://w3c.github.io/test-results/html53/implementation-report.html, done back in september, Firefox seems to support, while others were not tested.
Ah, that is as we say a can of worms.
The actual HTML spec that major browser vendors implement is the WHATWG living standard. W3C copies that spec verbatim into their own standard, except that they make some incompatible changes. WHATWG has repeatedly asked W3C not to do that, but W3C persists.
Happily, W3C and WHATWG have agreed that the WHATWG living standards should be authoritative, and that W3C will no longer publish a conflicting document. https://www.w3.org/blog/2019/05/w3c-and-whatwg-to-work-together-to-advance-t... --Wendy -- Wendy Seltzer -- wseltzer@w3.org +1.617.715.4883 (office) Strategy Lead, World Wide Web Consortium (W3C) https://wendy.seltzer.org/ +1.617.863.0613 (mobile)
On 12 Jul 2019, at 16:20, John R. Levine wrote:
On Fri, 12 Jul 2019, Marc Blanchet wrote:
With respect to the HTML5 pattern for e-mail addresses, I have talked to people in WHATWG about it. That pattern is correct for ASCII addresses and it's not going to change to an EAI pattern because that would lead to web sites with ASCII mail systems accepting addresses to which they can't send mail. They would be open to adding a new "eaimail" input type that accepts EAI addresses, to allow an easy upgrade when sites have EAI capable back ends.
Nothing is going to happen in WHATWG until one of their large members says they'll implement it which hasn't happened. I've made some inquiries and gotten polite responses, but I can't do much more since I have no funding.
from https://w3c.github.io/test-results/html53/implementation-report.html, done back in september, Firefox seems to support, while others were not tested.
Ah, that is as we say a can of worms.
I know. actually, the table states that Firefox works, but my testing shows otherwise on my environment. And the table does not tell version number, platform, etc…
The actual HTML spec that major browser vendors implement is the WHATWG living standard. W3C copies that spec verbatim into their own standard, except that they make some incompatible changes. WHATWG has repeatedly asked W3C not to do that, but W3C persists.
yeah. I know all that story and we talked about it extensively when I was on the IAB… Marc.
One of those incompatible changes is e-mail addresses. WHATWG has a recommended address validation pattern pattern which is a subset of the RFC5321/5322 spec that matches what real mail systems accept well. W3C changed that to accept any UTF-8 which is wrong for many reasons. One is that it's gratuitously incompatible, another is that it provides no way to distinguish between EAI and non-EAI back end mail systems, and a third is that real EAI mail systems are unlikely to accept all of the random mixes of scripts and punctuation that the W3C pattern allows.
The way people use the WHATWG pattern is that they cut and paste it into their javascript libraries and the browser just runs the javascript. So long as everyone follows WHATWG it hardly matters what W3C does. Before WHATWG will add an EAI pattern for programmers to use, it needs an eaimail input type to distinguish EAI and non-EAI mail backends, which needs browser and web server support.
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
reviewed. some comments: - would be good to have access to the data ( mongodb (or a dump of it)) so we can independently assess the numbers or test. It would also be useful to the actual sites owners that were tested. Currently, we and they don’t know who was tested and the actual results. - I agree that automation of these tests can not be done on all web sites, but if 50% were automated, then it is a big saving of time, especially if this survey is repeated. - yes, html5.3 needs to be defined as the new standard and that would resolve the issue of the html form for email addresses. However, even at standard level, it will take time to get it deployed. But that is not the end of it. it just scratches the surface. The fact that a browser accepts UTF8 on the left side of an email address by complying to HTML5.3 does not warrant that the processing of the form will work. In fact, it may be the inverse since the developer would receive UTF8 data it does not expect as the previous html was not enabling utf8 to be received from the user filling the form. On this, I would suggest to include the URL of the deployment page (while seems not updated since sep2018) for html5.3 in the report, so people can see the state of the deployment of this issue: https://w3c.github.io/test-results/html53/implementation-report.html Regards, Marc. On 12 Jul 2019, at 11:19, Sarmad Hussain wrote:
Dear all,
Please find attached a recent study undertaken on the request of UASG on the Global Evaluation of Websites for Acceptance of E-mail Addresses 2019, for your review and feedback.
Please send your feedback on ua-discuss@icann.org<mailto:ua-discuss@icann.org> list (visit https://uasg.tech/subscribe to subscribe) by 29 July. We look forward to your input.
Regards, Sarmad
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Fri, 12 Jul 2019 21:13:11 +0200, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
- yes, html5.3 needs to be defined as the new standard and that would resolve the issue of the html form for email addresses.
Sadly (IMHO) that won't happen. W3C threw HTML 5.3 under the bus last year as part of its effort to hand over HTML to 4 browsers.
On this, I would suggest to include the URL of the deployment page(while seems not updated since sep2018) for html5.3 in the report, so people can see the state of the deployment of this issue: https://w3c.github.io/test-results/html53/implementation-report.html
As the person who did the testing for EAI on that issue, I don't think that is a good idea. Relations between some parts of "the 4" browsers, and W3C's HTML spec reached a nadir at the point where browser engineers deliberately re-engineered code to break compatibility. I would be unsurprised if Firefox' implementation (such as it was) was changed in this way. Besides which, as everyone has noted, the implementation wasn't sufficient to work end to end. The implementation document was only ever work in progress, the specification was a Working Draft and specifically never reached the point where we did the careful checking to decide what was in the Recommendation and what to defer until a later version. cheers Chaals -- Using Opera's mail client: http://www.opera.com/mail/
Hi Chaals. It is not necessarily related to UA, but what you wrote makes me even more suspicious about DNS over HTTP. Cheers, Roberto
On 13.07.2019, at 13:52, Charles 'chaals' (McCathie) Nevile <chaals@yandex.ru> wrote:
On Fri, 12 Jul 2019 21:13:11 +0200, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
- yes, html5.3 needs to be defined as the new standard and that would resolve the issue of the html form for email addresses.
Sadly (IMHO) that won't happen. W3C threw HTML 5.3 under the bus last year as part of its effort to hand over HTML to 4 browsers.
On this, I would suggest to include the URL of the deployment page(while seems not updated since sep2018) for html5.3 in the report, so people can see the state of the deployment of this issue: https://w3c.github.io/test-results/html53/implementation-report.html
As the person who did the testing for EAI on that issue, I don't think that is a good idea. Relations between some parts of "the 4" browsers, and W3C's HTML spec reached a nadir at the point where browser engineers deliberately re-engineered code to break compatibility. I would be unsurprised if Firefox' implementation (such as it was) was changed in this way.
Besides which, as everyone has noted, the implementation wasn't sufficient to work end to end. The implementation document was only ever work in progress, the specification was a Working Draft and specifically never reached the point where we did the careful checking to decide what was in the Recommendation and what to defer until a later version.
cheers
Chaals
-- Using Opera's mail client: http://www.opera.com/mail/
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On 13 Jul 2019, at 7:52, Charles 'chaals' (McCathie) Nevile wrote:
On Fri, 12 Jul 2019 21:13:11 +0200, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
- yes, html5.3 needs to be defined as the new standard and that would resolve the issue of the html form for email addresses.
Sadly (IMHO) that won't happen. W3C threw HTML 5.3 under the bus last year as part of its effort to hand over HTML to 4 browsers.
On this, I would suggest to include the URL of the deployment page(while seems not updated since sep2018) for html5.3 in the report, so people can see the state of the deployment of this issue: https://w3c.github.io/test-results/html53/implementation-report.html
As the person who did the testing for EAI on that issue, I don't think that is a good idea. Relations between some parts of "the 4" browsers, and W3C's HTML spec reached a nadir at the point where browser engineers deliberately re-engineered code to break compatibility. I would be unsurprised if Firefox' implementation (such as it was) was changed in this way.
good. but my point is that we shall provide to people reading the document some ways to find the status of the issue. Marc.
Besides which, as everyone has noted, the implementation wasn't sufficient to work end to end. The implementation document was only ever work in progress, the specification was a Working Draft and specifically never reached the point where we did the careful checking to decide what was in the Recommendation and what to defer until a later version.
cheers
Chaals
-- Using Opera's mail client: http://www.opera.com/mail/
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Sat, 13 Jul 2019 15:32:03 +0200, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
good. but my point is that we shall provide to people reading the document some ways to find the status of the issue.
Sure... but I think we need to do our own testing rather than rely on that information that may well be out of date (and was only ever rough "work in progress" even when it was new). Note that there are quite a lot of browsers with substantial usage, which choose when to do something different, beyond "the 4" that control the WHAT-WG. Testing some of those - or filing issues for them to support EAI - might be worthwhile. cheers Chaals -- Using Opera's mail client: http://www.opera.com/mail/
On 13 Jul 2019, at 10:20, Charles 'chaals' (McCathie) Nevile wrote:
On Sat, 13 Jul 2019 15:32:03 +0200, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
good. but my point is that we shall provide to people reading the document some ways to find the status of the issue.
Sure... but I think we need to do our own testing
sure. testing the html email form of a browser for support of EAI is a matter of 1 minute by hand. So even with many versions and many platforms, this is not too complicated to do. However, as John and I were saying, the rest of the processing of this input remains probably the biggest issue in the long term and that requires much more work in testing, either automated or manual or a combination. Marc.
rather than rely on that information that may well be out of date (and was only ever rough "work in progress" even when it was new).
Note that there are quite a lot of browsers with substantial usage, which choose when to do something different, beyond "the 4" that control the WHAT-WG. Testing some of those - or filing issues for them to support EAI - might be worthwhile.
cheers
Chaals
-- Using Opera's mail client: http://www.opera.com/mail/
In article <op.z4vd4xybag6dn2@chaalss-macbook-pro.home> you write:
Note that there are quite a lot of browsers with substantial usage, which choose when to do something different, beyond "the 4" that control the WHAT-WG. Testing some of those - or filing issues for them to support EAI - might be worthwhile.
Unless I missed something fairly basic, the browser has no effect a web site accepting EAI addreses. Every browser in the past decade has enough UTF-8 support to allow sites to input EAI addresses. The site's Javascript does the address validation and the site's servers either handle EAI addresses or don't. The WHATWG pattern is just a regular expression for programmers to use to validate user input. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On 15 Jul 2019, at 14:52, John Levine wrote:
In article <op.z4vd4xybag6dn2@chaalss-macbook-pro.home> you write:
Note that there are quite a lot of browsers with substantial usage, which choose when to do something different, beyond "the 4" that control the WHAT-WG. Testing some of those - or filing issues for them to support EAI - might be worthwhile.
Unless I missed something fairly basic, the browser has no effect a web site accepting EAI addreses.
well, if one puts <input type=‘email’>, then the browser is involved. And my current basic tests on my platform show that none of them accepts EAI.
Every browser in the past decade has enough UTF-8 support to allow sites to input EAI addresses.
if one puts <input type=‘text’>, then browser accepts utf8
The site's Javascript does the address validation and the site's servers either handle EAI addresses or don't. The WHATWG pattern is just a regular expression for programmers to use to validate user input.
that is the next level of validation. First one depends on how the <input> tag is used. Marc.
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
On Mon, 15 Jul 2019, Marc Blanchet wrote:
well, if one puts <input type=‘email’>, then the browser is involved. And my current basic tests on my platform show that none of them accepts EAI.
Every browser in the past decade has enough UTF-8 support to allow sites to input EAI addresses.
if one puts <input type=‘text’>, then browser accepts utf8
Oh, OK. Now we're back to getting one of the WHATWG members to be interested enough to add EAI support. Regards, John Levine, john.levine@standcore.com Standcore LLC
Thanks Mark for finally getting this available. I’m assuming that someone will perform a copy editing effort on the document to address grammar and punctuation and such, so I won’t worry about that. A better structure and reordering some sections will be useful I think. Does the report show the actual email addresses that you used? Did you find any correlation between the acceptance of IDN or EAI addresses and the domain email server’s EAI capability? John Levine ran some analysis on the websites you tested some months ago. Have you done a direct comparison between the domains that are common between the 2017 and the 2019 studies to see if progress have been made between the two dates? That would show whether progress had actually been made rather than just some statistical noise. When we first discussed this second test the plan was for the ICANN GSC team to start reaching out to those websites that were NOT UA Ready and provide direct advice to them. Toward that end, it will be helpful to provide Seda et al with the list of sites tested and the results. (Or the UASG could crowdsource this activity – with 400+ subscribers, if each took just four websites the outreach could be done in a day) I would like a better understanding of “An “already registered” e-mail message was displayed3.” I find it interesting that there were some malware sites in the Alexa top 1000. Not a UA issue, but perhaps an Alexa issue. From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Sarmad Hussain Sent: Saturday, 13 July 2019 3:19 AM To: ua-discuss@icann.org Subject: [UA-discuss] Request for review: Report on Evaluation of Websites for Acceptance of E-mail Addresses, 2019 Dear all, Please find attached a recent study undertaken on the request of UASG on the Global Evaluation of Websites for Acceptance of E-mail Addresses 2019, for your review and feedback. Please send your feedback on ua-discuss@icann.org <mailto:ua-discuss@icann.org> list (visit https://uasg.tech/subscribe to subscribe) by 29 July. We look forward to your input. Regards, Sarmad
Hello everyone, on behalf of the team, I would like to thank you for the feedback. It's great to finally get this document out after it having been held back by unforeseen issues with ICANN Legal. Now that the discussion has settled a bit, I am uploading a new version of the document that addresses some feedback. You can find it in attachment. A bit of a changelong: John's EAI issue has been addressed; Wendy's link has been added for clarification; some of Charles' comments were used to further some points; extra consideration was given to the HTML5 issue based on your constructive debate and that section has been enhanced. Some direct answers: Marc: We don't know the legality of making the website data available, and I don't feel very inclined to take another swim at ICANN Legal's pool. Perhaps the leadership can set this consultation as a goal. We handed the csv of the results over to them. Don: we had a limited time and budget to produce this document, all the while rewriting the methodology to create a stronger basis for future tests. We propose an UA Dashboard as a next project to take on, as it would allow for whatever correlations to be made between all tests this group produces. An "already registered" e-mail can happen when a website shares its user database with another... this can happen in e-commerce, for example. Best regards, On 12/07/2019 12:19, Sarmad Hussain wrote:
Dear all,
Please find attached a recent study undertaken on the request of UASG on the *Global* *Evaluation of Websites for Acceptance of E-mail Addresses 2019*, for your review and feedback.
Please send your feedback on ua-discuss@icann.org <mailto:ua-discuss@icann.org> list (visit https://uasg.tech/subscribe to subscribe) by 29 July. We look forward to your input.
Regards, Sarmad
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES
Hi Mark What possible legal problem could there be with releasing the website data? I can’t see any and I’m a bit concerned that the approach of “always say no until the lawyers say yes” will have a chilling effect on transparency. Cheers Jay (sent from my phone) -- Jay Daley Managing Director techobscura Limited +64 21 678840 skype: jaydaley
On 16/07/2019, at 3:41 AM, Mark Datysgeld <mark@governanceprimer.com> wrote:
Hello everyone,
on behalf of the team, I would like to thank you for the feedback. It's great to finally get this document out after it having been held back by unforeseen issues with ICANN Legal.
Now that the discussion has settled a bit, I am uploading a new version of the document that addresses some feedback. You can find it in attachment.
A bit of a changelong: John's EAI issue has been addressed; Wendy's link has been added for clarification; some of Charles' comments were used to further some points; extra consideration was given to the HTML5 issue based on your constructive debate and that section has been enhanced.
Some direct answers:
Marc: We don't know the legality of making the website data available, and I don't feel very inclined to take another swim at ICANN Legal's pool. Perhaps the leadership can set this consultation as a goal. We handed the csv of the results over to them.
Don: we had a limited time and budget to produce this document, all the while rewriting the methodology to create a stronger basis for future tests.
We propose an UA Dashboard as a next project to take on, as it would allow for whatever correlations to be made between all tests this group produces.
An "already registered" e-mail can happen when a website shares its user database with another... this can happen in e-commerce, for example.
Best regards,
On 12/07/2019 12:19, Sarmad Hussain wrote: Dear all,
Please find attached a recent study undertaken on the request of UASG on the Global Evaluation of Websites for Acceptance of E-mail Addresses 2019, for your review and feedback.
Please send your feedback on ua-discuss@icann.org list (visit https://uasg.tech/subscribe to subscribe) by 29 July. We look forward to your input.
Regards, Sarmad
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. -- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES <UA Global Email Report 2019 RC.pdf>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Hey there, Jay. This decision is not up to me as project leader. We have delivered the raw results and now we are also waiting and seeing what will happen next. Best, On 16/07/2019 09:04, Jay Daley wrote:
Hi Mark
What possible legal problem could there be with releasing the website data? I can’t see any and I’m a bit concerned that the approach of “always say no until the lawyers say yes” will have a chilling effect on transparency.
Cheers Jay
(sent from my phone)
-- Jay Daley Managing Director techobscura Limited +64 21 678840 skype: jaydaley
On 16/07/2019, at 3:41 AM, Mark Datysgeld <mark@governanceprimer.com <mailto:mark@governanceprimer.com>> wrote:
Hello everyone,
on behalf of the team, I would like to thank you for the feedback. It's great to finally get this document out after it having been held back by unforeseen issues with ICANN Legal.
Now that the discussion has settled a bit, I am uploading a new version of the document that addresses some feedback. You can find it in attachment.
A bit of a changelong: John's EAI issue has been addressed; Wendy's link has been added for clarification; some of Charles' comments were used to further some points; extra consideration was given to the HTML5 issue based on your constructive debate and that section has been enhanced.
Some direct answers:
Marc: We don't know the legality of making the website data available, and I don't feel very inclined to take another swim at ICANN Legal's pool. Perhaps the leadership can set this consultation as a goal. We handed the csv of the results over to them.
Don: we had a limited time and budget to produce this document, all the while rewriting the methodology to create a stronger basis for future tests.
We propose an UA Dashboard as a next project to take on, as it would allow for whatever correlations to be made between all tests this group produces.
An "already registered" e-mail can happen when a website shares its user database with another... this can happen in e-commerce, for example.
Best regards,
On 12/07/2019 12:19, Sarmad Hussain wrote:
Dear all,
Please find attached a recent study undertaken on the request of UASG on the *Global* *Evaluation of Websites for Acceptance of E-mail Addresses 2019*, for your review and feedback.
Please send your feedback on ua-discuss@icann.org <mailto:ua-discuss@icann.org> list (visit https://uasg.tech/subscribe to subscribe) by 29 July. We look forward to your input.
Regards, Sarmad
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES <UA Global Email Report 2019 RC.pdf>
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES
On Tue, 16 Jul 2019, Mark Datysgeld wrote:
A bit of a changelong: John's EAI issue has been addressed;
Thanks for the update, but I regret to say that your test of the domain's MTA while sort of interesting, tells you nothing about whether the site you tested could actually send mail to the address you entered. Sites that sign up large numbers of people use CRM or e-commerce software which sends the mail through a specialist provider like Salesforce or Mailchimp or Sendgrid, so it depends on that provider's EAI support. The server you tested is for the company's office mail. The only way to see if the mail works is to get far enough in the signup process that it sends a message to the address you entered, which I realize is more than you're funded to do. But to get real useful results, that's what we need in the future.
Marc: We don't know the legality of making the website data available, and I don't feel very inclined to take another swim at ICANN Legal's pool. Perhaps the leadership can set this consultation as a goal. We handed the csv of the results over to them.
Yeah, dealing with legal is usually a losing battle. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
John, I am confused. I got these statistics from a test you ran yourself in April following up on a request made by Don. From your e-mail: "Of those [domains] I found MXes for 862 of them, and 414 of the domains had mail servers that support EAI. As you can see from this summary, 85% those have mail hosted at gmail, 10% at Microsoft." Regards, On 16/07/2019 19:44, John R. Levine wrote:
On Tue, 16 Jul 2019, Mark Datysgeld wrote:
A bit of a changelong: John's EAI issue has been addressed;
Thanks for the update, but I regret to say that your test of the domain's MTA while sort of interesting, tells you nothing about whether the site you tested could actually send mail to the address you entered. Sites that sign up large numbers of people use CRM or e-commerce software which sends the mail through a specialist provider like Salesforce or Mailchimp or Sendgrid, so it depends on that provider's EAI support. The server you tested is for the company's office mail.
The only way to see if the mail works is to get far enough in the signup process that it sends a message to the address you entered, which I realize is more than you're funded to do. But to get real useful results, that's what we need in the future.
Marc: We don't know the legality of making the website data available, and I don't feel very inclined to take another swim at ICANN Legal's pool. Perhaps the leadership can set this consultation as a goal. We handed the csv of the results over to them.
Yeah, dealing with legal is usually a losing battle.
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
-- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES
In article <03c069fb-bf3c-d907-6617-7f64151b3552@governanceprimer.com> you write:
-=-=-=-=-=- -=-=-=-=-=-
John,
I am confused. I got these statistics from a test you ran yourself in April following up on a request made by Don. From your e-mail: "Of those [domains] I found MXes for 862 of them, and 414 of the domains had mail servers that support EAI. As you can see from this summary, 85% those have mail hosted at gmail, 10% at Microsoft."
It's not measuring the same thing. I looked at the corporate inbound mail servers, but for your tests it's the outbound e-commerce or CRM mail servers that matter. Other than in the tiniest organizations, they're rarely the same. Unfortunately, there's no way to test those latter servers other than by signing up and getting them to send you something. FYI, I did that test for Don in about half an hour by tweaking my existing tools that sample TLD zone files. If it had been a lot of work I would have told him it wasn't worth the effort since it doesn't tell us very much. One thing this discussion does tell us is that the next time around it would be a good idea to have someone with mail experise on the testing team who can check the tests and reports for these kinds of issues. R's, John
Interesting. This was not within the scope of the study, but since a test had been performed anyway, we ended up including it. To be honest, we did consider early on checking for this support using the test mailboxes, but that in itself presents issues, seeing as at times you register on a website that has the domain "test.com", but the e-mail arrives at your mailbox from "example.com". This happened quite a few times, actually. Other websites just don't send confirmation messages even when you directly interact with their forms. This seemed really inconsistent to track across a dataset of 1.000 entries, so the idea was dropped. It's always good to engage in constructive discussion, but we do need to close this document for distribution, so can we agree on removing the eai paragraph for now and taking this matter to the Measurements group for future discussion? Regards, On 17/07/2019 12:46, John Levine wrote:
In article <03c069fb-bf3c-d907-6617-7f64151b3552@governanceprimer.com> you write:
-=-=-=-=-=- -=-=-=-=-=-
John,
I am confused. I got these statistics from a test you ran yourself in April following up on a request made by Don. From your e-mail: "Of those [domains] I found MXes for 862 of them, and 414 of the domains had mail servers that support EAI. As you can see from this summary, 85% those have mail hosted at gmail, 10% at Microsoft." It's not measuring the same thing. I looked at the corporate inbound mail servers, but for your tests it's the outbound e-commerce or CRM mail servers that matter. Other than in the tiniest organizations, they're rarely the same. Unfortunately, there's no way to test those latter servers other than by signing up and getting them to send you something.
FYI, I did that test for Don in about half an hour by tweaking my existing tools that sample TLD zone files. If it had been a lot of work I would have told him it wasn't worth the effort since it doesn't tell us very much.
One thing this discussion does tell us is that the next time around it would be a good idea to have someone with mail experise on the testing team who can check the tests and reports for these kinds of issues.
R's, John
-- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES
To be honest, we did consider early on checking for this support using the test mailboxes, but that in itself presents issues, seeing as at times you register on a website that has the domain "test.com", but the e-mail arrives at your mailbox from "example.com". This happened quite a few times, actually. Other websites just don't send confirmation messages even when you directly interact with their forms. This seemed really inconsistent to track across a dataset of 1.000 entries, so the idea was dropped.
I understand that it was out of scope for what you did, and I agree that getting sites to send you stuff can be a pain. But if we really want to know whether web sites support EAI addresses, it's what we have to do. Ship this one, now we know what we have to do next time. It'll be more work and cost more but UASG certainly has the money. Regards, John Levine, john.levine@standcore.com Standcore LLC
It's always good to engage in constructive discussion, but we do need to close this document for distribution, so can we agree on removing the eai paragraph for now and taking this matter to the Measurements group for future discussion?
The comment that the actual support is likely less than what you measured due to back end mail issues should stay, the stuff about my quick scan can go. Regards, John Levine, john.levine@standcore.com Standcore LLC
Thank you for the feedback, John. One of my main goals in undertaking this task in the first place was to help establish a more structured approach to UA research by identifying gaps and finding loose ends, thus aiding in the group's evaluation of priorities. Hopefully, the discussion surrounding this document accomplished that to some degree. Release Candidate 2 follows in attachment. Regards, On 17/07/2019 14:17, John Levine wrote:
It's always good to engage in constructive discussion, but we do need to close this document for distribution, so can we agree on removing the eai paragraph for now and taking this matter to the Measurements group for future discussion?
The comment that the actual support is likely less than what you measured due to back end mail issues should stay, the stuff about my quick scan can go.
Regards, John Levine, john.levine@standcore.com Standcore LLC
-- Mark W. Datysgeld from Governance Primer [www.markwd.website] Representing businesses in IG together with AR-TARC and ABES
participants (10)
-
Charles 'chaals' (McCathie) Nevile -
Don Hollander -
Jay Daley -
John Levine -
John R. Levine -
Marc Blanchet -
Mark Datysgeld -
Roberto Gaetano -
Sarmad Hussain -
Wendy Seltzer