Improve Email Social Icon with automatic "mailto:" and obfuscation

[mrwweb]

This is an offshoot of #21733

Is your feature request related to a problem? Please describe.
At present, the default placeholder for all social icons is the same: "Enter Address". This is a unique problem for the email icon:

Someone who reads that as "enter email address", would enter just their email address. Doing so results in appending an email with "http://".

This would result in an invalid link going to "http://info@example.com". I suspect there are now many links like this due to this problem. (See also: #21699)

Describe the solution you'd like
Similar to #19425, the icon should handle automatically appending "mailto:" if the user does not enter it.

Going further, it would be ideal to obfuscate the emails via an antispambot()-like method to offer at least some level of spam protection. There's no reason that couldn't be done automatically.

[karmatosed]

Feels like a great little enhancement to me. I can't see you would add anything that isn't a mailto there, or at least that doesn't seem to be as common.

[mrwweb]

@karmatosed makes a good point that it would be worth testing for the presence of an @ in case folks are linking to a contact form or something.

something like this pseudo code logic for testing the submitted "email"

if( contains '@' && doesn't contain 'mailto:' && doesn't start with 'http'  ) {
    prepend 'mailto:'
} else if( doesn't contain '@' && doesn't start with 'http' {
   prepend 'http://'
} else {
   don't do anything
}

[derweili]

Feels like a great little enhancement to me. I can't see you would add anything that isn't a mailto there, or at least that doesn't seem to be as common.

Linking a page with a contact form could be a use case for the mail icon with a http:// link.

[Mamaduka]

Hi, @mrwweb

Created PR to handle the mailto prefixes. The obfuscation probably should be handled by anti-spam plugins.

[mrwweb]

Created PR to handle the mailto prefixes.

Awesome! Thanks, @Mamaduka

The obfuscation probably should be handled by anti-spam plugins.

Given that antispambot() is a core function, it feels like it would be well within the scope of core to handle this and avoid forcing people to opt in to it. Are there specific concerns you had about implementing that behavior?

[Mamaduka]

That's a good point, @mrwweb.

I will re-open this issue since obfuscation is still missing from the Social block.