URLs wrapped in <> parsed as HTML when wp_mail_content_type set to text/html
|Reported by:||iandunn||Owned by:|
 wrapped the password-reset URL in the e-mail sent from retrieve_password() in greater-than/less-than signs in order to prevent it from breaking when line wrapped (see #14140). That has the side-effect of causing the URL to be parsed as HTML by the mail client when the message's content-type is set to text/html via the wp_mail_content_type filter. I don't see any other places in Core where this happens.
Using wp_mail_content_type to enable HTML e-mails is a common technique documented on the Codex and across the Web. Is it considered a bad practice to enable it globally -- as opposed to adding it before calling wp_mail(), then removing it after; or just setting the content type in the $headers param of wp_mail()? If so, we should document that on the Codex and possibly in wp_mail() where the filter is applied.
Even if it is, I don't think it'd hurt to have retrieve_password() check the content-type and behave accordingly. If it's "text/html", then create a proper link; otherwise wrap the URL in greater-than/less-than signs.
If everyone agrees on that approach, I'll submit a patch.