According to Jason L Tibbitts III:
> full addr
> strip addr
> password (probably encrypted somehow)
> bounce data (?)
> a list of lists the user is a member of
> PER LIST:
> full addr (for doing 'who' quickly)
> strip addr
> zub. class + args
> flags (need to be per list)
> Really, this is not difficult to split up but I want to split it once and
> leave it that way. I can see places where you might want a global default
> and a per-list override but I'd really, really like to try to get away
> without doing that.
Why not design it so even the global values have a key that could
be different per-list or not? Then if you end up being wrong you
just use a different identifier for the lists that turn out to be
> Now, the global list doesn't even have to be Majordomo-maintained; it could
> be on an LDAP server somewhere assuming that the fields it needs can be
> created. The per-list stuff should be probably be internal, though.
LDAP might be the best long-term choice, especially if you teach it to
automatically make the list addresses available and let sendmail use
it directly for the expansions, but I expect it to be several years
before many sites are prepared for that.
Right now you could use DBI with the base distribution set up for
DBD::CSV which uses a flat file storage instead of needing a backend
database. Places that outgrow that scheme or want access from
multiple machines could drop in their choice of server and DBD backends
without changing the base code.