Next: How moderator email addresses are stored, Previous: Testing SENDER to allow posts only from list subscribers, Up: Overview of ezmlm function
Each ezmlm list has it's own “key” created by ezmlm-make at setup time. This key is stored in DIR/key, and you can improve it by adding random data of your own to it. However, changing the key will make all outstanding subscription and moderation requests invalid, so this should be done only when the list is established.
When ezmlm receives an action request, such as ‘subscribe’, it constructs a cookie as a function of:
The cookie and these items are then assembled into a address that is sent out as the ‘Reply-To:’ address in the confirmation request sent to the subscriber. When the subscriber replies, ezmlm first checks if the timestamp is more than 1,000,000 seconds old (approx 11.6 days) and rejects the request if it is. Next, ezmlm recalculates the cookie from the items. If the cookies match, the request is valid and will be completed. Depending on the circumstances, ezmlm generates an error message or a new cookie based on the current time and sends the target a new confirmation request.
Dan has based these cookies on cryptographic functions that make it very unlikely that a change in any part of the cookie or the items will result in a valid combination. Thus, it is virtually impossible to forge a request even for someone who has a number of valid requests to analyze. Since the algorithm ezmlm uses is available, the security rests on the key (and the correctness of the algorithm). Anyone who knows the key for your lists can easily construct valid requests.
As ezmlm-make(1) doesn't use a truly random process to generate the key, it is theoretically possible that someone with sufficient knowledge about your system can guess your key. In practice, this is very unlikely, and the safety of the system is orders of magnitude higher than that of other mechanisms that you may rely on in your list management and mail transport (exclusive of strong encryption, such as PGP).