Currently, mailing lists have to be configured manually and statically in the configuration file. This is suitable for the small, relatively static use cases common in the early days of mailing lists, but that was 30 years ago now. We can do better with dynamic mailing lists (think LISTSERV), by storing list membership in a database table. We should, however, keep the current arrangement as an option as it's simple, it works, and it may be all that some sysops need. Larger systems however may need richer functionality.
For example, send a message to [email protected]
to subscribe to that mailing list. If sent from the local mail server, no confirmation is needed since the mail server knows that it was sent by that user. In general, however, confirmations may be required, and this could be done in memory (no need to persist confirmation codes between restarts).
A robust implementation of Sender Rewriting Scheme should also accompany this feature.
At the same time, we should be careful not replicate existing functionality here. For example, newsgroups already serve well the use case of mailing-list-like things that people can self-subscribe to, with a good mechanism for discovering groups that are available. Indeed, newsgroups reduce duplicated content stored on the server, and for this reason are far preferable to mailing lists in most cases when they make sense. However, mailing lists support a variety of use cases that newsgroups do not. If an implementation of dynamic mailing list is to be done, it must support at least some of these, or there would be no reason to use such functionality over relying on newsgroups.
You must be