https://bugzilla.wikimedia.org/show_bug.cgi?id=39676
--- Comment #9 from Seb35 <[email protected]> --- Some days ago I tried to census the automatic emails with links in MediaWiki (which are concerned by this bug): 1. email confirmation emails: links to confirm or invalidate the email address (User::sendConfirmationMail with messages 'confirmemail_body*', uses Title::getCanonicalURL), 2. password reminder: general link to the wiki (SpecialPasswordReset::onSubmit with messages 'passwordreset-emailtext-*', uses Title::getCanonicalURL; previously LoginForm::mailPasswordInternal with message 'passwordremindertext', uses $wgCanonicalServer), 3. initial password email: general link to the wiki (LoginForm::mailPasswordInternal with message 'createaccount-text', uses $wgCanonicalServer) 4. new message email: link to talk page (EmailNotification::composeCommonMailtext, uses Title::getCanonicalURL, this function is designed to make the message as most as possible recipient-neutral for performance reasons), 5. watchlist emails: links to pages and diffs (idem to the new message email), 6. user to user email: but no link in the current messages. The classical function to create the full non-relative URLs in these functions is Title::getCanonicalURL, which uses by default a protocol PROTO_CANONICAL, id est (i.e.) the protocol defined by wgCanonicalServer. All public Wikimedia wikis have for now http as canonical protocol (and probably a lot of MediaWiki wikis also). One non-satisfactory solution would be to simply switch the canonical protocol to HTTPS, but this would make emails received by Chinese users non-functionnal for them (this choice is currently discussed on wikimedia-l for the Wikimedia projects, but given this bug is related to MediaWiki, the solution should be a bit more general). It could be added for #1 #2 #3 an other argument in Title::getCanonicalURL to give the mailer functions an opportunity to have their own decision logic, based on the recipient; for instance to take into account $user->getBooleanPreference('prefershttps') [note: current discussion about this bug on wikitech-l highlights the fact that this preference is on for https-blocked users in China; it’s just hidden to the user]. For #4 #5 it is more difficult (if possible) to include any recipient-based logic since the messages are designed to be recipient-neutral to permit bulk mailing (and it is very important to speed as much as possible the sending for bulk mails because the volumes are high -- I administer a ML server). I don’t see a solution apart a rewrite of the function EmailNotification::composeCommonMailtext to create two versions of a same message (HTTP and HTTPS), although this would imply performance issues on major wikis. For #3 the initial password email (user account created by an administrator) and the initial email confirmation (email registrated in the new account form), I have doubts if the user preference should be taken into account since the user never logged in, so probably the better solution is to follow the canonical protocol. To conclude: A) resolve this bug for #1 and #2 could be easily done, but it could block/make more difficult the reception of emails for https-blocked users (they will have to change the protocol); B) I find not really justified the implementation of this bug for any message sent to the user before his/her first connection (e.g. #3); C) the resolution of this bug is quite challenging (although possible) for watchlist emails and any other impersonal bulk email (#4 and #5). -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
