Domain blacklist

[dverdin]

See Issue #295 for the origin of this discussion. Here is a summary: On May last year, @ldidry asked about how to prevent owners from adding email addresses using abandoned email domains. The solution he found was to submit PR #478. Basically, this PR adds a list and global config parameter, named 'domains_blacklist'. It is a comma-separated list of domains. If somebody tries to add a user to the list, and the user's email address uses one of the domains listed in the parameter, this addition is rejected and the addition originator is warned that the domain is black-listed.

It's cool but there is already a blacklist in Sympa. Is is even available in the web interface to list owners. In the black list, you put an address per line and the addresse is blacklisted from sending message, subscribing, or both, depending on configuration. If the address has the form "*@domain.tld", the whole domain is blacklisted.

However, this blacklist is not applied to "add" operation. Only to subscribe and send.

I think we should rather extend blacklist, and the usage of lists, the way Steve shipway did for modlists/whitelists plugins (see https://sympa-community.github.io/manual/customize/template-plugins-modwhitelist.html) rather than creating such an exception mechanism.

I know it feels useful right now, but I think this the kind of exceptional behaviour we should avoid. In this case, we create a list parameter for only one case.

Using scenarios instead of this would allow to work on domains in a wider way. An example that pops up in my head is limiting addition / subscriptions to a set of domains (if you want to restrict a list to a set of institutions for example). Another one would be, to give a set of domains which would not be moderated when posting to the list or putting a shared document, when anyone else would be.

There is a lot of applications to the usage of list of domains in scenarios. I don't think what Luc wrote is the best way to handle such exceptions. If no mechanism existed in Sympa, I would not have noticed, but knowing that we already have blacklists, I think we should extend it.

OK, Up to you now!

[ldidry]

The point is

Is is even available in the web interface to list owners.

I don't want to let list owner changing my blacklist.

I'm blacklisting gmail.fr since it doesn't handle mails (real domain is gmail.com), but list owners could not knowing that and misunderstand my blacklisting.

To my case, he blacklisting feature needs to fulfill those requirements:

• works on add and subscribe
• is applied to all lists
• is not overridable by list owners

If you can do that with your method, I have no objection to #478 revert.

[dverdin]

Actually, blacklists can be used for all actions. But they are based on who originates the action. Not the user we want to add. Damn. It's only this variable that we are missing... I'm searching...

[dverdin]

...And did not find. There is no easy way to check another variable than the sender in the scenario.

We would need a rule like: search('file.txt', 'variable').

For now, we have only: search('file') and the variable is implicitely the action originator.

We could easily change 'search() but then there is a real problem: how to name the variable and how to make sure it is relevant to the context? I mean: the way the email to add is named takes sens only in the add action. So it appears in add only.

We could certainly use a variable looking like 'args[n]' where 'n' would be the nth argument to a Sympa command. But this order is relevant in mail commands context only. It does not make sense in web or command line context.

Considering you actually solve the problem with your solution and there are other issues at hand, it would be counter-productive to me to keep working on this.

So I give up; It was a bad idea after all. ;-) Sorry for bothering you. I clearly underestimated the work to be done. Thanks for your quick answers to my concerns!

[dverdin]

As far as I'm concerned, we can close the issue.

[ldidry]

Sorry for bothering you.

No pb :wink:

Closing the issue.