@dmaza and I decided to make this an 8. We can re-evaluate when there's a UI plan.

👍

We'll work on the UI on Monday. I predict a liberal use of the <marquee> tag.

The muting should still work even if the muted user changes their username. See T173475.

Now we've finally reached a level where treating this as an security bug becomes laughable…

Change 374361 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Allow users to restrict who can send them direct emails via Special:EmailUser

https://gerrit.wikimedia.org/r/374361

Ugh.. I tried to do a squash merge and that didn't work. :(

Some points regarding this change. I think it is a very good improvement however... Special:EmailUser was also used as an indicator by experienced users who tried to help users who lost their passwd to check if the user in question had a verified email configured and would thus be able to receive password reset emails.

1. I don't think that this is going to be problematic and I guess with the acceptance criteria as defined, you could still figure that out from going to Special:EmailUser/Name directly.
2. Maybe we should have that specific information discoverable somewhere else ?
3. "This user has chosen not to receive email from other users" is a level of information disclosure about who you have blocked and can easily be bypassed by having a (disclosed or not) alternative account. It might be wiser, to just present the form to send an email and only upon submit, have it bounce. That makes it harder for the sender to figure out if they have been muted, which might be safer for the receiver.

Another feature idea:
Make it possible to block mail from entire usergroups.

In T138166#3541919, @Thryduulf wrote:

More as a reminder for when the documentation page gets written for this after implementation than anything more urguent, but it might be worthwhile to note that there are ways a restricted user can find out they are specifically restricted, including (but not necessarily limited to):

• sockpuppet accounts
• {{you've got mail}} and similar messages on user talk pages
• the restricting user asking third parties to email them

• Just look at the output of API

In T138166#3562062, @Anomie wrote:

• Just look at the output of API

Example:
https://meta.wikimedia.org/w/api.php?action=query&list=users&usprop=emailable&ususers=DBarratt%20(WMF)

I thought the response was broken, but that's apparently the format per T29881: the 'emailable' property (from API) should be true or false (currently empty string or undefined)

In T138166#3561281, @TheDJ wrote:

"This user has chosen not to receive email from other users" is a level of information disclosure about who you have blocked and can easily be bypassed by having a (disclosed or not) alternative account. It might be wiser, to just present the form to send an email and only upon submit, have it bounce. That makes it harder for the sender to figure out if they have been muted, which might be safer for the receiver.

Another feature idea:
Make it possible to block mail from entire usergroups.

True, it would be possible for a malicious user to use a sock to circumvent this Mute list. T138165: Allow users to restrict which user groups that can send them direct emails via Special:EmailUser will prevent some sock email harassment. We've also considered a whitelist, but don't yet have a tracking ticket.

As for the question of showing the email form at Sp:EmailUser or not — there are valid arguments for both designs. I have a slight preference to not show the form at all — the error message already exists and is common for users who do not want any email at all. This also will also help users from posting the "you've got mail" template on the other's talk page and situations of "hy didn't you respond to my email?"

Happy to hear other opinions on the "show the form + bounce the email" vs "hide the form".

In T138166#3562122, @dbarratt wrote:

I thought the response was broken, but that's apparently the format per T29881: the 'emailable' property (from API) should be true or false (currently empty string or undefined)

Side note, [[https://meta.wikimedia.org/w/api.php?action=query&list=users&usprop=emailable&ususers=DBarratt%20(WMF)&formatversion=2|use ]] to get actual booleans in JSON format. That's not the default for historical reasons.

@TBolliger Just to confirm, we are making a new tab for this field correct?

@dbarratt — yes, a new tab. I will create another ticket for the next sprint to polish up the UI.

Edit: I updated T174606: Move Echo Notification Mute & Special:EmailUser Prohibit to new Prohibit/Mute tab, update copy, add links on other tabs to reflect these desired changes

I should probably add a config variable for this like echo.

@Anomie How do you feel about just adding a new method to since what we are doing here is almost exactly the same as T173475?
Something like

$nameToId = array_fill_keys( array_flip( $names ), false );
$ids = array_filter( $this->lookupUserNames( $nameToId, $audience ), function ( $id ) {
 return $id !== false;
} );

return array_values( array_unique( $ids ) );

?

You'd probably want two methods, one for names to IDs and one for IDs to names.

I don't have any really compelling reason to object, but I do note that you'd need to come up with distinctive names for the new methods so it doesn't wind up confusing to others looking at the class in the future.

@kaldari Your code review would be much appreciated. :)

Based on the conversation with @kaldari and @Samwilson we'll add the blacklist to the existing email section. If we want to move it to a new tab, we can have that discussion in T174606: Move Echo Notification Mute & Special:EmailUser Prohibit to new Prohibit/Mute tab, update copy, add links on other tabs.

@TBolliger Only question left is whether to show the field all the time or only show it if email is enabled. It is possible to do this right now, but it doesn't change the form until you click "Save". T174606 would make it happen immediately, but @kaldari mentioned that most people will not be enabling email and then immediately looking for how to block people.

@kaldari should be good now!

In T138166#3587172, @dbarratt wrote:

Based on the conversation with @kaldari and @Samwilson we'll add the blacklist to the existing email section. If we want to move it to a new tab, we can have that discussion in T174606: Move Echo Notification Mute & Special:EmailUser Prohibit to new Prohibit/Mute tab, update copy, add links on other tabs.

@TBolliger Only question left is whether to show the field all the time or only show it if email is enabled. It is possible to do this right now, but it doesn't change the form until you click "Save". T174606 would make it happen immediately, but @kaldari mentioned that most people will not be enabling email and then immediately looking for how to block people.

OK, I agree with this. Let's get it out and examine if we should move them to another tab. I'll update T174606 to reflect this.

I agree with @kaldari — Safe to assume that 99.99% of the time this will be a reactive preference, not proactive. Let's have the list appear only if the allowemail preference is enabled. The list can display when a page refresh occurs.

Can you please send a screenshot of what the UI looks like, just to make sure all the copy works well together?

Change 374361 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Allow users to restrict who can send them direct emails via Special:EmailUser

https://gerrit.wikimedia.org/r/374361

Change 374361 merged by jenkins-bot:
[mediawiki/core@master] Allow users to restrict who can send them direct emails via Special:EmailUser

https://gerrit.wikimedia.org/r/374361

@TBolliger This is done and it looks like will be in the September 19th deploy. After that we can enable it on Meta.

@dbarratt hooray! 🙌🏼

We're not aware of any reason (social or technical) that we shouldn't enable this on all Wikimedia wikis, once T173475: Echo Notification Mute (Block List) can be bypassed by changing username and T176365: Update Email Mute copy have been resolved.

Any concerns?

In T138166#3654726, @TBolliger wrote:

We're not aware of any reason (social or technical) that we shouldn't enable this on all Wikimedia wikis, once T173475: Echo Notification Mute (Block List) can be bypassed by changing username and T176365: Update Email Mute copy have been resolved.

Any concerns?

@TBolliger enabling this feature on all wikis is not blocked by T173475: Echo Notification Mute (Block List) can be bypassed by changing username since that is not a bug of this feature, only Echo notifications.