id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc
23578,URLs wrapped in <> parsed as HTML when wp_mail_content_type set to text/html,iandunn,,"[16285] 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.",defect (bug),new,normal,Awaiting Review,Mail,3.1,normal,,,