Block all mails targeting specified users #9926

New Issue

GiteaMirror · 2025-11-02T08:53:15-06:00

GiteaMirror commented

2025-11-02 08:53:15 -06:00

Originally created by @theAkito on GitHub (Dec 3, 2022).

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

Originally created by @theAkito on GitHub (Dec 3, 2022). ### 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 * https://github.com/go-gitea/gitea/issues/17238 * https://github.com/go-gitea/gitea/issues/18054 * https://github.com/go-gitea/gitea/issues/21975 * https://github.com/go-gitea/gitea/issues/21704

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:53:15 -06:00

GiteaMirror closed this issue

2025-11-02 08:53:15 -06:00

GiteaMirror commented

2025-11-02 08:53:15 -06:00

@fnetX commented on GitHub (Jan 3, 2023):

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.

@fnetX commented on GitHub (Jan 3, 2023): 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.

GiteaMirror commented

2025-11-02 08:53:16 -06:00

@lafriks commented on GitHub (Jan 10, 2023):

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

@lafriks commented on GitHub (Jan 10, 2023): I think this could be solved by implementing bot users (I think there was issue for that already)

GiteaMirror commented

2025-11-02 08:53:16 -06:00

@lafriks commented on GitHub (Jan 10, 2023):

Closing as duplicate of #13044

@lafriks commented on GitHub (Jan 10, 2023): Closing as duplicate of #13044

GiteaMirror commented

2025-11-02 08:53:16 -06:00

@theAkito commented on GitHub (Jan 10, 2023):

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.....

@theAkito commented on GitHub (Jan 10, 2023): > 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.....

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9926