Feature request: domains blacklist

[ldidry]

Some people migrating lists from <whatever, I don't know> to our Sympa registers people with some well-known abandoned addresses. In France, we got voila.fr that is still registered but without mail server (and it will not change, it's owned by a big ISP that shut down the mail server a few years ago).

I suggest a domains blacklist setting that will prevents addresses using those domains to subscribe to list (a message saying "Sorry, that domain is blacklisted" to the subscribing action instigator could be cool)

[dverdin]

I arrive a bit late but did you know that Sympa can do this already?
for each list, you can set a blacklist. If your blacklist entry looks like "*@domain.tld", you blacklist the whole domain.
This blacklist is automatically used by any Sympa list.
It can be defined at the server or virtual host level, as it is a scenario.
You could also have used implicit scenarios inclusion.
In other words: you already had solutions in Sympa without the hasle of writing new code.

Remember: most of the time, any problem in Sympa can be solved by a scenario.

Consequently, I think that PR #478 is irrelevant and should be removed. I think it is counter-productive to use a different mechanism than the one already existing. It adds only confusion.

As it is obviously aimed at being used by listmaster, there is no immediate reason to make it available from the web interface.

[ikedas]

@dverdin, I don't agree to remove PR #478. That is, I think we'd be better to discuss on pros and cons of both solutions (scenario-based blacklist and this domain blacklist) so that we can find better way to improve Sympa.

How about opening a new issue? (Thus, I refrain from objecting your arguments by now.)

[dverdin]

I thought it was the right place to do so as this issue is where the problem arose.
But if you want, I can do this someplace else.

[dverdin]

OK, I posted a more elaborated issue here: #523.
I must admit that scenario are not immediately usable in that case, but I maintain that we should adapt Luc's solution to make a better usage of existing code.