A list exit facility will be introduced with version 1.8a to answer the concerns expressed about the removal of the .DO mailform command. While we expect this facility to be extended to all list management commands with version 1.8b, only the commands implemented in PASCAL will make use of the exit facility in version 1.8a, as appropriate. For now this means only the ADD and SUBSCRIBE commands, although the SET command might be included before final release. It is unlikely that SIGNOFF and DELETE will be included, because internals for the X-REQ synchronization mechanism are presently available only in REXX. In version 1.8b we plan to have all the list management commands in PASCAL, with the possible exception of EXPLODE. An exit is enabled by adding "Exit= filename" to the list header. For security reasons, all exits must be explicitly declared in the new LIST_EXITS configuration variable. This prevents list owners from causing the invocation of arbitrary executable files through the use of the "Exit=" keyword. However, once a particular program has been identified as a list exit, any list may refer to it. If you write exits which could compromise confidential data if executed on behalf of the wrong list, it is your responsibility to test the 'listname' parameter in the exit program and take appropriate action. Note that the exit name itself is available to anyone who can review the list; make sure to program the exit to test the list name, and not to rely on the confidentiality of the exit name. List exits are regular REXX programs under VM, which must be prepared to handle calls from an arbitrary number of exit points. The parameter string always include the exit point name, followed by a blank, the name of the list, another blank, and parameters that depend on the exit point. In other words: Parse arg ep listname more The exit returns a numeric return code, which may or may not be checked, depending on the exit point. The value 0 always has the meaning "do the same thing as if there had not been any exit for this list". Always return the value 0 for exit point names your program does not handle or recognize. At the moment, the following exit points are available: SUB_FILTER, one parameter: originator's e-mail address. This exit point gives you a chance to reject a subscription by returning a nonzero value. This adds to rather than replaces the "Filter=" keyword. SUB_FAIL, one parameter: originator's e-mail address. This exit point is called whenever a subscription is rejected (in particular, it is called if you return a nonzero value from SUB_FILTER). You may send additional messages to the user, log the event, and so on. LISTSERV ignores the return value. SUB_REQ, one parameter: originator's e-mail address. The user's request for subscription is being forwarded to the list owners. You may send additional messages to the user, log the event, and so on. LISTSERV ignores the return value. To implement custom subscription/rejection, use the SUB_FILTER exit with "Subscription= Open". When SUB_REQ is called, it is too late to let the user through. SUB_NEW, one parameter: originator's e-mail address. This exit point notifies you that the user has been successfully subscribed to the list. You can send additional messages, log the event, and so on. LISTSERV ignores the return value. ADD_NEW, one parameter: subscriber's e-mail address. Same as SUB_NEW, but for the ADD command. The return values from xxx_NEW and SUB_REQ may be checked in future versions to override the delivery of standard mail templates, so be sure to return zero for now. IMPORTANT: List exits may not make any change to the list file, because the command processor may have changes of its own to make to the file, or may have kept the file open for further processing. If you really have to change the file, use CP MSG * CMS EXEC to call yourself after processing completes. The new template processor can be called from list exits. The syntax is: Call LSVTMAIL recipients,template_name,listname,keywords keywords = 'KWD1 value of first keyword'||'15'x'KWD2 second keyword'||... Note the change in calling sequence, even when no keyword is defined. Do not use LSVIMAIL as it will be removed in version 1.8b. Version 1.8a no longer uses LSVIMAIL, but it will be kept around for one version to facilitate the migration to new versions of optional packages such as the line monitor, which call LSVIMAIL. Eric