Links with "@" are converted into email addresses even if there is no domain suffix present.

Here is the filter patched and re-tested locally. Validated it is working as should. Lets see what the bot thinks.

The issue has a valid point, but as this goes against the standard, it should be a decision for the maintainer whether or not this should go in. I see few things to note here:

• In the described case, where foo@bar is used, "bar" is a fully valid domain name by standard, even without the TLD.
• It might be required for example when sharing information about local environments. Example would be where a link to access local domain resources is shared (i.e. ftp://foo@bar/path/to/awesome). In this case a link is expected.
• However, it's true that the usage of "@" is becoming more common. Example "I'm meeting Johnny@home". In this case the link is not wished.
• Emails are rarely used without subdomains.

My suggestion:
Target only email addresses, requiring them to have a subdomain. This won't then affect URL's and is rarely used. I've attached a patch which sets a subdomain to be matched.

It seams working with the patch applied.

I would give +1 for this.

Patch in 11 works for me

@PavanL thank you for your participation, but please don't modify the original post unless it's exceptionally unclear in what it's saying. Your changes were good and reasonable, but it isn't really good practice to rewrite somebody else's issue. Also, how in the world this was changed to 'needs work'...?

Like #11, I'm not sure about this one (that comment contains a great summary of the pros and cons of such a change).

Either way, would need to go in Drupal 8 first, though.

Here is my approach for D7 #2354401: URL filter converting invalid emails to mailto link

Patch from #11 works for me in D7. I think afox makes a very logical suggestion to only target email patterns which will keep the bulk of the existing functionality as is. Any chance to get this committed?

@jelo you're right. We first need to get the D8 version working. So here's a D8-version with same changes (seemed to work nicely).

Great job @aFox!

BEFORE

AFTER

Testbot apparently had a glitch. Now passed.

I think we should be adding to the files used in FilterUnitTest::testUrlFilterContent() to test this

This (failing) URL lead me to this issue:
https://www.google.be/maps/place/Rue+de+la+Victoire+39,+1060+Saint-Gilles/@50.831321,4.3468107,17z/data=!3m1!4b1!4m2!3m1!1s0x47c3c4668ae4d069:0xaf2df9dc39d8f03a?hl=fr

The patch fixes the filtering of this URL in Drupal 8. However a quick backport of #23 to Drupal 7 did not. So there have been more improvements to this function compared to D7. I propose to backport the whole_filter_url() code, not just the patch.

Here's a failing test

Manually tested works fine even for the strings like now@home. @larowlan is this string worth adding to tests to check the edge case.

great idea jibran.
changed test line to

see you tomorrow@work or later@home.

RTBC++

Sorry, two nits.

1. +++ b/core/modules/filter/filter.module
   @@ -534,8 +534,13 @@ function _filter_url($text, $filter) {
   +  // a subdomain match. This allows patterns like foo@bar in text without
   

   Hrm, not a subdomain, but rather a TLD? See https://en.wikipedia.org/wiki/Domain_name#Second-level_and_lower_level_d....

2. +++ b/core/modules/filter/filter.module
   @@ -534,8 +534,13 @@ function _filter_url($text, $filter) {
   +  // being converted to a mailto -link.
   

   s/mailto -link/mailto-link/
   or
   s/mailto -link/mailto link/

+++ b/core/modules/filter/tests/filter.url-input.txt
@@ -30,7 +32,7 @@ The old URL filter has problems with <a title="kind of link www.example.com with
 <!-- <p>This url http://www.test.com is
- inside a comment containing newlines and 
+ inside a comment containing newlines and
 <em>html</em> tags.</p> -->
 
-This is the end!
\ No newline at end of file
+This is the end!

+++ b/core/modules/filter/tests/filter.url-output.txt
@@ -30,7 +32,7 @@ The old URL filter has problems with <a title="kind of link www.example.com with
 <!-- <p>This url http://www.test.com is
- inside a comment containing newlines and 
+ inside a comment containing newlines and
 <em>html</em> tags.</p> -->
 
-This is the end!
\ No newline at end of file
+This is the end!

Let's not change this here - it's out of scope and since this is testing filters potentially significant.

Fixes #35 and #36

#36 was my editor settings, but agree, could be significant with filters.

All the feedback is addressed back to RTBC.

Seems unrelated Updates for Contrib module one Other LocaleUpdateTest.php 144 Drupal\locale\Tests\LocaleUpdateTest->testUpdateImportSourceRemote()

Back to RTBC.

FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 91,590 pass(es), 2,654 fail(s), and 1,057 exception(s). this can't be true retesting.

Back to RTBC.

I think this is a good change. It is sensible to say that local domain names with no TLD are excluded because Drupal is about publishing content - but I think we need further tests. jsmith@[192.168.2.1] is a valid email address. See https://en.wikipedia.org/wiki/Email_address#Examples.

Thanks for the suggestion @alexpott. We'll fix that as well. I think you wanted to add needs tests tag. We do have this issue in D7 as well that is why we want to back port it. Feel free to clarify yourself re-adding the tag for now.

Patch in #11 failed to apply cleanly against Drupal 7.41. Re-rolled.

I'm confirming that #49 works as expected against Drupal 7.43

So patches for this issue were tested years ago, and I'm still struggling with this issue?

Maybe I can simplify the argument: nearly all of us know how to make a valid email link manually. Many content editors (ie, clients) do not. This filter is for those people.

Therefore, the filter should only convert email links if they satisfy the average standard email address. If someone has a weird email address WITHOUT a top level domain at the end (ex., jsmith@[192.168.2.1] ) -- those instances can be made into mailto links manually when the filter does not catch them. HOWEVER -- converting everything with an '@' sign in the middle of it to a mailto: link does not make sense. 'working@home' is never meant to be a valid email address; and you can not manually change this if the filter is turned on.

Can we please get this patch into D8 in the near future? This is the sort of stuff that is making me go crazy while working with D8.

Alternately -- if we could split out email conversion from regular URL conversion -- that would allow me to turn this faulty feature off. I'd settle for either option. Thanks, and I appreciate all the hours volunteers put into this. I was just very frustrated to research this issue only to find it had been discussed, patches made, and then it got effectively killed 2 years ago.

Let me try to roll out against 8.4.x

I agree with #54. It seems important to get this committed...

On Drupal 7.57 I get "error: corrupt patch at line 17" when trying to apply the patch. I will attempt to re-roll...

nevermind...I corrupted the patch myself.

I can confirm that after 3 years, patch #49 works on Drupal 7...

I would be open to commit / fix this in Drupal 7, but it needs to be fixed in Drupal 8 first.

#49 applies cleanly to 7.65

Looks like the + symbol got removed from the URL pattern regex which I think is why the tests were failing. I added that back and fixed a typo in the comments.

A new test for this functionality would be nice but I'm having trouble debugging that kernel test at the moment.

Re-rolled the D7 patch in 49 with the same changes.

Made some adjustments based on #35and #28.

Re-rolled again for D7 with the same changes.

Also, it appears I overlooked the work already done in #37. Apologies.

Patch at #76 working here (with the plus sign).

Where are we with the D8 blocker for the D7 working patch to make it into a release?

Any chance for 7.68?

Thanks for everyone's work on this.

After enabling 'Convert URLs into links' for Basic HTML on 9.1, I have created a basic page and added both the links.
Its showing text as a link if there is no domain suffix.
Can we have a patch fix for 9.1?

d8-require-tld-for-mailto-links-2016739-73.patch in #75 works for us, thank you!

#75 works for me too, thank you!

Attached is the screenshot:

Noticed that this is tagged 'Needs tests' but it also RTBC, it can't be both. I looked at the patch and indeed there are no tests. The latest patch is for 8.8.x. It needs to be against 9.1.x.

Setting NW for tests and to have a patch for 9.1.x.

Rerolled for 9.1. Please review

Setting back to NW for tests.

+++ b/core/modules/filter/filter.module
@@ -503,7 +503,11 @@ function _filter_url($text, $filter) {
-  $url_pattern = "[\p{L}\p{M}\p{N}._+-]{1,254}@(?:$domain)";
+  // Mail domain pattern differs from the general domain pattern by requiring
+  // a TLD match. This allows patterns like foo@bar in text without
+  // being converted to a mailto link.
+  $email_domain = '(?:[A-Za-z0-9._+-]+\.)+[A-Za-z]{2,64}\b';
+  $url_pattern = "[A-Za-z0-9._+-]{1,254}@(?:$email_domain)";

This change is a regression. #1657886: Filter "Convert URLs into links" doesn't support multilingual web addresses changed this to allow multilingual characters. See https://en.wikipedia.org/wiki/International_email

Added a patch that keeps the current format of the domain pattern (multilingual support) and make a change of the regex, so if no dot is added after the @, text will not be transformed to mailto link

Issue history has many patches in the past where test cases have been added.
I've clubbed together test cases and created a patch.
Test cases are passing on local.

The patch in #92 works as designed, and tests pass, and still cleanly applies to the 9.3.x-dev branch. Marking this as RTBC, accordingly, with the desire that this is next reviewed by the core maintainers.

+1 for the RTBC (and hopefully getting it reviewed/committed). We've been using this for months now with no issue.

The change to the regex looks good in my opinion. I might assign both $domain and $email_domain at the same point in the code so if you change one you'll consider the other.

+++ b/core/modules/filter/tests/filter.url-input.txt
@@ -29,11 +30,12 @@ The old URL filter has problems with <a title="kind of link www.example.com with
 <!-- <p>This url http://www.test.com is
- inside a comment containing newlines and 
+ inside a comment containing newlines and
 <em>html</em> tags.</p> -->
 
-This is the end!
\ No newline at end of file
+This is the end!

+++ b/core/modules/filter/tests/filter.url-output.txt
@@ -29,11 +30,12 @@ The old URL filter has problems with <a title="kind of link www.example.com with
 <!-- <p>This url http://www.test.com is
- inside a comment containing newlines and 
+ inside a comment containing newlines and
 <em>html</em> tags.</p> -->
 
-This is the end!
\ No newline at end of file
+This is the end!

These changes might be automatically occurring due to IDE settings but we should not be making them here. It's out-of-scope and I'm not sure they are correct.

  // Mail domain pattern differs from the general domain pattern by requiring,
  // a TLD match. 

Also not sure about this text. Firstly the use of the acronym without it being defined earlier and also the comma is incorrect.

Thanks for the review, alexpott!

The attached patch addresses comments in 95 & 96:
1. The definition of the email domain is now adjacent to the generic domain pattern.
2. The comment text clarifies how the email domain differs.
3. The newlines errroneously added to .txt files in 92 are excised.

Comments from #95 and #96 seem to be addressed. Setting back to RTBC.

Committed 8ff4d48 and pushed to 9.3.x. Thanks!
Committed f7ccf32 and pushed to 9.2.x. Thanks!

Backported to 9.2.x because this is a bug and the implementation only affects mailto links so the scope is small. The use something@something to mean things like ladygaga@oscars feels way more commonplace than it was when this issue was opened.

In order for this issue to be backported to Drupal 7 the current policy is to open a new issue.

@Fabianx now that this is in D9, can we back port to D7 please. There's a long history here. While the patch in #49 works, attached is a new D7 re-roll with all the changes that made it into D9.

#104 @douggreen, as per, "In order for this issue to be backported to Drupal 7 the current policy is to open a new issue" in #99 and because you have a proposed patch, can you open a new issue to backport and reference this as related issue. Cheers.