Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Domain blacklist #523

Closed
dverdin opened this issue Jan 10, 2019 · 5 comments
Closed

Domain blacklist #523

dverdin opened this issue Jan 10, 2019 · 5 comments
Assignees
Labels
Milestone

Comments

@dverdin
Copy link
Contributor

dverdin commented Jan 10, 2019

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!

@dverdin dverdin self-assigned this Jan 10, 2019
@dverdin dverdin added the design label Jan 10, 2019
@dverdin dverdin added this to the 6.2.40 milestone Jan 10, 2019
@ldidry
Copy link
Contributor

ldidry commented Jan 10, 2019

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
Copy link
Contributor Author

dverdin commented Jan 10, 2019

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
Copy link
Contributor Author

dverdin commented Jan 10, 2019

...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
Copy link
Contributor Author

dverdin commented Jan 10, 2019

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

@ldidry
Copy link
Contributor

ldidry commented Jan 10, 2019

Sorry for bothering you.

No pb 😉

Closing the issue.

@ldidry ldidry closed this as completed Jan 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants