ezmlm sublists require that the message envelope sender is the main list, and that the message has a ‘Mailing-List:’ header. Both are easy to fake, allowing an attacker to inject messages at the sublist level. Other than the possible ramifications of only a subset of subscribers seeing the message, this is of no concern for open lists. For a ‘subscriber-only’ list based on SENDER checks, it is no harder to set SENDER to the address of a subscriber than to fake the headers required by the sublist. However, for a moderated list the mainlist to sublist communication becomes the weakest link. Sublists using a SQL database also use better authentication in this step (see ezmlm support for SQL databases).
A sublist user can unsubscribe a normal ezmlm sublist from the main list. To guard against this, you need to prevent propagation of unsubscribe confirm requests by the sublist. Easiest is to add a line to DIR/editor before the ezmlm-send(1) line:
|grep -i '^Subject: CONFIRM' >/dev/null 2>&1 && exit 99; exit 0
Another option would be to take advantage of the fact that DIR/headeradd headers at the main list are added to normal messages, but not to administrative messages. Thus, one could discard messages that lack the default ‘Precedence: bulk’ header:
|grep -i '^Precedence: bulk' >/dev/null 2>&1 || exit 99; exit 0
For lists with SQL-support, users cannot unsubscribe sublists (see ezmlm support for SQL databases).
Break-in at a sublist host for normal ezmlm lists leads to loss/compromise of the addresses handled by the sublist. For MySQL-enabled lists, the sublist access credentials give DELETE and SELECT access to all addresses serviced by the list. Thus, a successful sublist attacker can completely disable the list. The MySQL log (if used) will reveal from which host the attack was done. Although the potential damage to a SQL-enabled list is greater, the results are of the same order of magnitude. The risk in minimized by keeping control over all sublist hosts. A successful sublist attacker cannot normally add addresses, since the sublist users by default are set up without INSERT privileges to the address database.