> I've tripped myself up a few times with the list name vs. list ID thing.
> Output of "lists" command:
> 
>  * LSTAFF-L -LISTSERV Maintenance Staff
>  * TEST     -List for testing MAILER
>  *           Alias: LSTESTLS
>  *
>  * (-) Lists marked with a minus sign only support RFC822 mail.
> 
> 
> Here, the list name (i.e. the VM file name) is LSTESTLS. The list ID is
> "test" and that's the address to which I'm sending mail. That works fine
> when the VM userid is in place and LMail is not (I had the alias defined
> in my SMTP NAMES file so the mail would get to the right userid). I tried
> sending to lstestls also, same result.

You need:

1. No VM userid (unless you really want to have one).

2. TELL MAILER SET LIST FOR LSTESTLS

3. TELL MAILER SET FORWARD [log in to unmask] FOR TEST

4. No SMTP NAMES entry or anything like that.

> tell mailer for lstaff-l set list
> Ready; T=0.01/0.01 10:26:48

This is not the correct syntax. 'FOR user command' will execute 'command' as if it had come from 'user' and with the privileges of 'user'. You will get a copy of the response, but it will go primarily to 'user'. This is a common way to test how a given command will behave when coming from a non-privileged user. 'command' can be anything but you cannot have a wildcard in 'user'.

'SET ... FOR user' on the other hand changes options for the user in question. The command is executed under your authority and 'user' can contain wildcards. The response is not automatically sent to 'user' (some commands may send a separate notification that an administrator changed the account). Only a handful of commands support a FOR option.

I'll look into the CLASS= message, but you have to use the 'SET ... FOR' syntax anyway.

> Ok, I blew away the original test list and recreated with list-id the same
> as the list name. Now LISTTEST recognizes the list but delays the mail for
> 10 minutes because MAILER (?) isn't a subscriber.

This suggests that the MAILER variable in LISTTEST's LOCAL SYSVARS is not set correctly.

  Eric