Re: Wish. . .

[Jason L Tibbitts III <tibbs @ hpc . uh . edu>]

>>>>> "MTA" == Mordechai T Abzug <morty@sled.gsfc.nasa.gov> writes:

MTA> The second problem is relatively trivial to solve, but the first is
MTA> much more tricky.  I was thinking hacking around with 1.94.4, but
MTA> before i do: is some facility to handle this sort of issue going to
MTA> appear in 2.0?

Well, exactly how do you want to handle it?  If you're content to send a
nice message back to the users telling them that they can't unzubscribe
from the list directly, you'll be able to handle the first problem with
something like the following (one of you folks with a test list on my
server should try this kind of thing):

configset access_rules <<END
unsubscribe
deny, replyfile=no_unsubscribes
ALL
END

Of course, you'll have to make a suitable reply file, like:

put GLOBAL /no_unsubscribes Unsubscribing is not allowed <<END
Our lists are built from databases nightly and thus
unsubscribing will only remove you until the list is
rebuilt.  To truly unsubscribe yourself, contact
soandso@wherever.blah.
END

2.0 also has the ability to lock out actions (and thus do the above kind of
denials) _even when they have password approval_.  All you have to do is
set access_password_override to 'no'; then the validity of the password is
just another variable you can examine in the access_rules routines.  This
is reasonably dangerous, though, because you can screw up easily.

If you want something stranger, you'll have to spell it out.  It would
probably be difficult to have Majordomo feed directly from your database,
as it expects to be able to store information in that database, but I could
be persuaded to make a "no-modify" class of lists.

BTW, in any case you won't be able to just scp your lists in any more,
because the list file is no longer simple.  You can, however, just call the
shell interface to wipe your list and incorporate a new address list
quickly.

 - J<