Automatically encode all email links using as hex HTML entities

[apfelbox]

It currently only encodes the href, not any content of the node.

So something like

[mail@example.org](mailto:mail@example.org) will only encode the link.
The same goes for <mail@example.org>.

Although in the latter case one could actually argue to also encode the text.
Thoughts?

Fixes #193

[ghost]

This should be definitly an optional feature if accepted by @erusev. There are people out there that use other methods to obfuscate email addresses or a cms ist handling this automatically.

[cebe]

The encoding of emails is part of the markdown description by John Gruber so it should be enabled by default imo.

[hkdobrev]

It is part of markdown, but I don't think it is still relevant. Anti-spam detection have become better and some people do not want obfuscation.

[ghost]

@hkdobrev 👍

[apfelbox]

CommonMark doesn't mention anything about it, too.

The patch is simple enough - should I submit a PR against parsedown-extra. Maybe you could choose your encoding mechanism, something like Smarty does (encode parameter).

[aidantwoods]

I think this is out of scope for now since it isn't part of CommonMark or the GitHub Flavoured extension.

Just to comment about email obfuscation in general: IMO it is better to display the email in plaintext without obfuscation so that users can see that the email is given out in plaintext. It's trivial to write a decoder for email addresses obfuscated in this way, and I think the worst thing of all would be for a user to believe that they somehow had not given their email address out publicly because of obfuscation.

If you give out your email address, encoded or not, you've still given out your email address. I think we shouldn't hide this fact.

The appearance of safety or security where there is none is likely to be worse than none on its own, because it will likely encourage the user to behave as if there were some in place.