Has everyone gotten 1.5n up? Are we ready to start thinking about where to go next? Here are some items I wish for: - An exit to be invoked with at every ADD/SUBSCRIBE. Actually there probably should be two exits for ADD/SUBSCRIBE. The first should be before the user has been added to the listname LIST file, but after all the other checks, such as service area, etc. This exit would allow a finer rejection method. The second exit(the one I want the most) would be invoked after the user was added to the listname LIST. I have modifications into LSVSUBSC and LSVADD now to handle this. It allows me to implement a keyword I call Auto-AFD. Whenever I add a user to this list, they also automatically get an AFD to a particular file/package. There can be multiple AFDs. I haven't implemented FUI, but it is trivial. - Similar exits to DELETE and UNSUBSCRIBE. - Make the PEERS NAMES a searchable database. - Make (at least parts) of PEERS NAMES dynamically maintained. We have seen with the Network-wide list of lists that dynamic reconfiguring of the listserv netowrk is possible, and even feasible. Allow me to maintain a file(eg LOCAL NAMES) which would have my entry for PEERS NAMES. I could change things in it, and at some remote time, it would distribute an update to the other servers. Somethings would not be possible to be trusted to the postmaster, but some items definitely could be. Fields such as :emergency are such canditates. :version is not, and should be dynamic. :lists is obsolete. - A reduction in the returned output from a network-wide delete. There are too many messages returned. - Others that I haven't thought of. Harry PS None of the above should be taken as thinking that I don't like 1.5n. I do. But where do we go from here? Is it my imagination, or does mail arriving for a list that is held go out in the reverse order(LIFO) when it is freed?