Protocol-relative urls break Drupal-generated password reset links in some mail clients

Problem/Motivation

Gross summary: MandrillMailSystem-generated password reset emails incorrectly form the reset links, making it almost impossible for some users to reset their account passwords.

More detail: If Mandrill is used as the default MailSystemInterface class, user-generated password reset emails contain a protocol-relative URL (href="//mysite.com/user/reset/HASH-STUFF") for the link in the html part of the email, which some mail clients cannot interpret correctly, thus breaking the links. In addition, the anchor-wrapped link text includes the correct protocol but only a trunctated version of the reset token, so users cannot copy and paste the link text as a workaround.

For example, when the password reset email is viewed in Apple (Yosemite) Mail, the the protocol-relative URL in the anchor tag's href attribute ends up rendered as x-webdoc://mysite.com/user/reset/HASH-STUFF, (if you right-click and choose 'copy link location') which doesn't do anything at all either when clicked or when copied and pasted into a browser. The same email, when viewed in Gmail's web interface, is formatted correctly and works as expected when clicked.

When the default mail system is set to Drupal's normal defaults, then the password reset email is sent as purely plain text, with the complete URL, including the protocol, i.e., https://mysite/etc.

Using Drupal 7.38. Mailsystem 7.x-2.34, Mandrill 7.x-2.1+4-dev (2015-Jan-30)

Steps to reproduce

Configure Mandrill with your API, and leave the default blacklist entry as-is
Visit admin/config/system/mailsystem and set the default MailSystemInterface to "MandrillMailSystem"
Using another browser, visit mysite.com/user/password and request a new password for your account
Using a mail client of your choice, view the raw source of the resulting email

You will see that you have received a multipart email. In the plain text part, you will see a link that resembles the following (#s represent account-specific id's or hash code):

http://mandrillapp.com/track/click/######/mysite.com?p=###########=
############################################=
############################################=
############################################

In the html part of the message, the link will be formed like this:

<a href="//mysite.com/user/reset/#/######/##################">https://mysite.com/user/reset/#/######/#############&#8230;</a>

Note that the wrapped link description text shows the correct protocol, but it uses a truncated version of the hash link, followed by an ellipsis (… = "..."), so the user cannot even copy and past the text into a browser.

If I view the above multipart email in (for example) a web-based email client like Gmail, since I'm viewing a secured site (https://mail.google.com/etc), the protocol-relative href works. But not in at least some desktop clients.

Proposed resolution

It turns out that all of this was due to the application of an Input Filter to Mandrill emails, selected at admin/config/services/mandrill. Core 'convert URLs to links' has a configurable link description max-length, which defaults to 72 characters. The Pathologic module allows urls to be converted to either full urls, protocol-relative urls, or site-relative urls.

When configuring an Input Filter for use with outgoing Mandrill-delivered emails, be aware of the filters being applied, and consider creating a separate input filter altogether, just for emails.