Is that a valid domain?

On 2 Dec 2016 10:02 p.m., "Florian Häusler" notifications@github.com
wrote:

Steps to reproduce the issue

add an umlaut e-mail adress like "info@umlaut-äöü.net" to any frontend
contect
Expected result

should be outputed in html as javascript protected email
Actual result

Not protected! E-Mail in cleartext. SPAM risk
System information (as much as possible)

PHP Built On Linux h2138315.stratoserver.net 3.14.79-9.1.x86_64 #1
#1 SMP PREEMPT Mon Oct 24
19:21:31 CEST 2016 x86_64
Database Version 5.5.50-MariaDB
Database Collation utf8_general_ci
Database Connection Collation utf8mb4_general_ci
PHP Version 5.3.29
Web Server Apache
WebServer to PHP Interface cgi-fcgi
Joomla! Version Joomla! 3.6.4 Stable [ Noether ] 21-October-2016 16:33 GMT
Joomla! Platform Version Joomla Platform 13.1.0 Stable [ Curiosity ]
24-Apr-2013 00:00 GMT
User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:50.0) Gecko/20100101
Firefox/50.0
Additional comments

SPAM risk! SPAM risk! SPAM risk!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#13065, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8cHYeeVK7E9BPT4dpcFJ2950EFWJks5rEIdvgaJpZM4LC_J2
.

No, but umlaut domains and emails are now common.
Have seen the problem today for the first time live.
Might affect several websites, especially in countries like germany!

Interesting if the cloaking do not currently support IDNs, we probably
should look into extending the cloaking to the allowed non-ASCII characters
that are legit in International domain names.

This describe which characters are valid:
https://eurid.eu/en/register-a-eu-domain/domain-names-with-special-characters-idns/
and in more details in the linked pdf:
https://eurid.eu/media/filer_public/8d/18/8d18473b-ed9b-4fba-abe7-947d235f25b1/idna2008and_homoglyph_bundling_tables.pdf

On Fri, Dec 2, 2016 at 10:09 PM, Florian Häusler notifications@github.com
wrote:

No, but umlaut domains and emails are now common.
Have seen the problem today for the first time live.
Might affect several websites, especially in countries like germany!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#13065 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAwPrQEkoPLgOS3LYyvoedGUY-ed4lDvks5rEIj5gaJpZM4LC_J2
.

At least the line that matches the emails is easy to find:
https://github.com/joomla/joomla-cms/blob/staging/plugins/content/emailcloak/emailcloak.php#L119

Umlaut in a domain name are done with punycode so presumably all punycode
domains face this issue

On 2 Dec 2016 10:53 p.m., "Georgios Papadakis" notifications@github.com
wrote:

At least the line that matches the emails is easy to find:
https://github.com/joomla/joomla-cms/blob/staging/
plugins/content/emailcloak/emailcloak.php#L119

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#13065 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8TedoZfr98kVInQjMMXxcY6rL3r0ks5rEJNGgaJpZM4LC_J2
.

Tested here in article and a contact an idn mail: it is automatically saved punycode encoded in the db and mailcloak does work on it.

Example for contact

Frontend display

Source when displayed in frontend

<span class="contact-emailto">
			<span id="cloakd2c3a3e11b6dc35e6ae677ac02779bb6">This email address is being protected from spambots. You need JavaScript enabled to view it.</span><script type='text/javascript'>
				document.getElementById('cloakd2c3a3e11b6dc35e6ae677ac02779bb6').innerHTML = '';
				var prefix = '&#109;a' + 'i&#108;' + '&#116;o';
				var path = 'hr' + 'ef' + '=';
				var addyd2c3a3e11b6dc35e6ae677ac02779bb6 = 'j&#111;&#111;ml&#97;t&#101;st' + '&#64;';
				addyd2c3a3e11b6dc35e6ae677ac02779bb6 = addyd2c3a3e11b6dc35e6ae677ac02779bb6 + 'xn----7sblgc4&#97;g8bhcd' + '&#46;' + 'xn--p1&#97;&#105;';
				var addy_textd2c3a3e11b6dc35e6ae677ac02779bb6 = 'j&#111;&#111;ml&#97;t&#101;st' + '&#64;' + 'джумла-тест' + '&#46;' + 'рф';document.getElementById('cloakd2c3a3e11b6dc35e6ae677ac02779bb6').innerHTML += '<a ' + path + '\'' + prefix + ':' + addyd2c3a3e11b6dc35e6ae677ac02779bb6 + '\'>'+addy_textd2c3a3e11b6dc35e6ae677ac02779bb6+'<\/a>';
		</script>		</span>

Evidently, if a 3rd party extension does not save a mail punyencoded, it will not work.
One has to use (example here for contacts):
// Store utf8 email as punycode
$this->email_to = JStringPunycode::emailToPunycode($this->email_to);

@infograf768 so are you saying this is not an issue with the core?

@infograf768 the problem is as described with umlaut emails like (ä,ö,ü) characters and not with alphanumeric cyrillic characters!

Floran- the point is that to have an umlaut in your domain name then it is
an IDN domain name (punycode) exactly as a cyrillic domain is

That´s trure, but umlauts are currently not protected.

they are if it is stored as punycode.
the punycode (idna) for Häusler.de is xn--husler-bua.de

See the screenshot showing a mailto link created in com_content just using mail@Häusler.de as an example and the generated output. You can see it is working

That's interessting, good to know.
Then the problem exists just with text in Article like "embedded e-mail in content", such as imprint, etc..

umlauts are as any utf8 characters and are treated indeed the same way as cyrillic.

Then the problem exists just with text in Article like "embedded e-mail in content", such as imprint, etc..

In an article it works the same as for contacts. If the imprint is proposed as a custom module, it should also work the same.

I guess this can be closed.

Try to input this first:

That doesnt show me anything. The only thing that matters is how this is displayed on the front end.

This is frontend

A mail entered in text (without a mailto:) will not indeed pass through JStringPunycode::emailToPunycode() and thus idn will not get mailcloaked.

Thinked this does that job?

yes, as I said, a non IDN mail entered like this will be mailcloaked, but NOT an idn mail.
One could consider this as a bug. Not sure how to solve.

Code is here:
https://github.com/joomla/joomla-cms/blob/staging/libraries/cms/component/helper.php#L124-L135
and
https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/filter/input.php#L454-L477

Closing

Set to "closed" on behalf of @infograf768 by The JTracker Application at issues.joomla.org/joomla-cms/13065