Block all mails targeting specified users

[theAkito]

Feature Description

It would help a lot of use cases, if there were a way to block e-mail traffic to specific users, altogether.

I imagine this as an extension to the "restricted" user property.

For example, if there are users with invalid e-mails on purpose, it would already save resources, if no e-mail sending attempts would even be made to these users.

Another use case is having system users with valid e-mail addresses, but one doesn't want to send e-mails to them, because it is unnecessary, since it's a system user.

An additional use case is about being able to cut off a user from e-mail notifications manually, without having to change anything about the user's profile or status. All you would need to do is check a checkbox. That's it. No changing e-mail address or otherwise changing the profile. This would be the least invasive way.

There are plenty more use cases.

It's probably simplest to just have an app.ini configuration option, which enables this feature & a checkbox in each user's profile.

Nicer, but more elaborate would be to re-vamp the "restricted" property & make it more configurable & extended.

Screenshots

No response

Somewhat a bit related issues

• email notifications depending on action #17238
• [Feature Request] Add e-mail domain blocklist #18054
• Need a setting to disable sending parts of the code by mail #21975
• allow blank email #21704

[fnetX]

If you have an instance large enough that this matters, I recommend solving this at the infrastructure level. E.g. postfix has a transport config where you can add a list of domains to drop from receiving any traffic, before any dns lookup etc happens.

This was a stable solution for Codeberg for quite a while.

[lafriks]

I think this could be solved by implementing bot users (I think there was issue for that already)

[lafriks]

Closing as duplicate of #13044

[theAkito]

If you have an instance large enough that this matters

Not sure, how the size of the instance matters. My proposal is especially suited for smaller sized instances with important core members, only.

I recommend solving this at the infrastructure level. E.g. postfix has a transport config where you can add a list of domains to drop from receiving any traffic, before any dns lookup etc happens.

This sounds like a lot of low level UNIX hell fiddling, which has become a huge anti-pattern over the years.
Now, even if it would be solvable on an Infrastructure as Code level, I don't think it would make much sense in the infrastructural design.

I think this could be solved by implementing bot users (I think there was issue for that already)

No. It wouldn't be. I am talking about manipulating the system's behaviour toward an existing account, rather than the actual account itself, which shall not be changed in any way. The changes should be external & not associated with the account.

For example, if an account user passed away, I do not want to change the account, I want to change how the system reacts to the account & how it works with it - i.e. it shouldn't work with it, otherwise the account should stay exactly the same.

Therefore.......

Closing as duplicate of #13044

.......this is not the case! 🙂

P.S.:

Reading this comment again, I realised one could also determine an account "frozen", as in everything stays the same & the account won't be touched. However, the account shall stay and seem "normal" in all issues, comments, pull requests, etc.....