When you add an email address in preferences, MediaWiki sends you an email asking you to confirm it. The email contains two links, one to Special:ConfirmEmail/<token> and the other to Special:InvalidateEmail/<token>. Following one of these links instantly (on GET request) either confirms or removes the email, and invalidates the token so the links can't be used again.

This is a problem when the user's email provider itself follows the links, due to some sort of email scanning. In T411799 we received a report from a user of Yandex that the links don't work, likely for this reason. I couldn't find online documentation about this, but apparently Office365 will do that as well, some other Microsoft software will even run JS on the target page, and it's something commercial providers of auth systems are aware of.

So, single-use or magic links in emails are going to be unusable for some users. Can we do something about this?

1. We could try to magically detect browsers versus automated tools, and only allow using the links in browsers. This will be unreliable as well.
2. We could require the user to click through a confirmation form at the target page. This should be reliable but worsens user experience.
3. We could make the confirmation link only work when logged in. We'd still have to do something about the invalidation link, and it would worsen the user experience (e.g. the user may be signing up on desktop but access their email on their phone).
4. We could replace the links with one-time codes and a form that requires you to input them (like in the new EmailAuth extension). This would be a slightly worse user experience, and would require us to make the tokens shorter and simpler, but it would be completely reliable. Maybe we could have both links and codes to get the best of both worlds.
5. We could make the links multi-use (which would require not invalidating the tokens, and keeping the email stashed somewhere when the "invalidate" link is clicked). This should be reliable and won't make the experience any worse, but it's a security trade-off. It would probably be fine if we also reduce the lifetime of the token (currently 7 days, $wgUserEmailConfirmationTokenExpiry).

Also worth noting that if the automated scanner clicks the confirmation link, but not the invalidation link, then the user will have their email confirmed without ever proving that they can access the email. I don't know if that's a practical concern.

Thoughts?

(Bonus relevant tasks: T62434, T387460)