Documenting security mailing list (and restarting it to avoid spam filters?)

A [recent blog post](https://blog.jupyter.org/cve-2021-32797-and-cve-2021-32798-remote-code-execution-in-jupyterlab-and-jupyter-notebook-a70fae0d3239) described two mailing lists relating to security:

> We have 2 mailing list for security-related discussion. The first one – security@ipython.org – has only a couple of members all core contributors and can receive email from the outside, it is used for triage. It receive a high number of spam as this is public email. As it has only a few members and we are all busy, mail can slip through. The second mailing list is slightly larger, and used for internal announcement for stakeholder. It has a fairly open membership model, (ask a Jupyter developer if you can be on it, and the reason why and we’ll likely add you), though it’s content seem to be ignored (it even lands on my spam folder, not sure why).

It could help to clarify how to sign up for the second (more open) mailing list and what are the vetting criteria for the membership. As for signing up, the number of Jupyter contributors across all the projects is not small and not everyone will be already on the list/have rights to add others (and the term _Jupyter developer_ is not well defined for me either) so clarifying who can add new members and which communication channel to use (gitter? discourse? email?) would help a lot. I imagine that the new security page, or the README of this repo (or both) would be a good place to host this information.

The documentation should mention that once added the new members will receive a message from "Jupyter Security" confirming their subscription (and they can unsubscribe at any time), which may land in spam (but no confirmation is required). We could also note that the membership is visible to other members.

Speaking of spam, would it make sense to re-start the mailing list from scratch using a different address so that the emails are not flagged as spam? I think it currently uses an `ipython`-based address and we could probably have one with `jupyter` instead.