Frequently Asked Questions about ListProc
- I created a Listproc mail list. Now what?
- I sent a TEST message to my list, but it was rejected.
- How can I tell whether or not I have been dropped from a list?
- Subscription confirmation sometimes doesn't work.
- How do digest readers know their posts are successful?
- How does auto-delete work?
- Does a listowner get list mail by being an owner?
- Is there a way to set a list to be digest *only*?
- I have a lot of subscribers to add and/or modify. How do I do this?
- When I subscribe an individual under an email address the system sometimes does not recognize that address.
- Can you address aliases a bit more?
- How can I fix the mistake of mistyping email addresses in the alias command?
- How can I fix email addresses for subscribers?
- I own several lists and want to put the subscribers of one onto another.
- Can you tell me the responsibility of a sponsor (Faculty/Staff member) of a mailing list?
- Sometimes people complain that all they receive is the digest headers.
- I am having a problem doing moderated-edit list control on my PC.
- How do I restrict my list to USC addresses only?
- How do I subscribe to Listproc?
- What can I do about viruses in list mail?
- Listproc seems to be ignoring commands from my hotmail/MSN mail account.
- Please explain the list FILTER option.
Warning! Being a listowner or moderator can SUBSTANTIALLY increase the amount of email you receive. Get into the habit of checking your mail account daily for busy lists. Remember to remove old mail from your personal (owner's) mail account so you don't run out of room for new mail.
Check out the list configuration right now, and think about some of the options you have. You may:
- Send to firstname.lastname@example.org the message CONFIG listname password
where listname is your list's name and password is the list's password
Use the online documentation on the website, or print a copy for reference.
If you have a list of email addresses that you want to add as subscribers, then compose an email message to send to email@example.com with the proper ADD command syntax, as shown in the Owners Intro and full documentation. (See below first).
Compose a welcome message that will be sent to new subscribers (unless you do a QUIET ADD, that is). Decide whether you want the text of your welcome to appear at the end of the default system welcome, at the beginning, or instead of the system welcome. If you choose either of the last two, you need to tell firstname.lastname@example.org (and cc: email@example.com). Note: if you choose to substitute the welcome, you lose the ability to insert the users name in the message, and to show the user their personal list password. Only the system welcome can do that.
If you want your list mailings to always be a digest rather than individual messages, set the lists default mail mode to be DIGEST before you add any subscribers. If you don't want to deal with MIME encoding use DIGEST-NOMIME. Your subscribers can always set their personal settings differently later unless you disable this feature.
You might also consider configuring a size option for digests. This forces the creation of a new digest whenever the digest meets or exceeds the size you specify. This can be useful if you have subscribers with mail accounts that limit the maximum size of a piece of mail to some small value. Subscribers limited in this way will often complain that they have not seen any mail from the list in a while, if they are set to digest mode and your digests are large enough.
If your digest is set to go out at 60 Kbytes, for example, a message can push the digest past the limit. Messages won't be truncated or split by this function. So if your digest is currently at 46 Kbytes, for instance, and a message of 60 Kbytes comes in, the digest will be 105 Kbytes when it goes out. The size limit is only a trigger, not an absolute value.
ListProc looks at the Subject line of messages to any list and compares it to a list of "suspicious" subjects. It rejects any message with a match and sends an error message. The word TEST is one such subject, since most lists don't appreciate a flurry of test messages at random times. Use subject TRY or SAMPLE or EXAM, depending on the context.
Other Subject line contents that can trigger a rejection are:
ADD ME or ADD MY
DELETE ME or DELETE MY
If you plan to resend a message that has the same text in the body, you'll first have to make a change to that text. Otherwise it will be rejected as a duplicate message.
A quick way to check if you are on a list or not and get
your current settings is to send an email to: firstname.lastname@example.org
and as the text of the message put:
Where listname is the name of the list you want. You will get back a message showing your current settings for that list, or saying you are not subscribed. If the latter, then just re-subscribe.
To re-subscribe, send an email to: email@example.com
In the text of the message body, put:
SUBSCRIBE listname yourname
substitute the lists name and your own name as indicated.
If the list is not hosted at USC.EDU, this might not work.
If a list is set up to send the subscriber a confirmation
cookie in a confirmation message, one must reply to it to actually
get on the list. In addition, the text is case sensitive, so be sure
to send back; Conf-Cookie:######
(The ##### would be the number actually in the message)
If you simply reply to the message, the subject line should contain the cookie info, and for insurance, you can cut and paste a copy into the first line of the message body. Don't embellish the message with your own words.
ListProc doesn't currently provide a mechanism for digest subscribers to receive immediate confirmation that their message went through. The four subscriber mail methods (ack, noack, digest, and postpone) are mutually exclusive.
You can make sure that subscribers receive bounced messages by setting DONT-FORWARD-REJECTS. If you would also like the owners to be notified when messages are rejected, you should include CCIGNORE in their preferences.
ListProc will auto-delete and auto-postpone subscribers as long as the AUTO-DELETE option is set for the list. The decisions as to which action to take are based on error mail (usually sent to "owner-listname", since this is automatically placed in the Sender field of outgoing list mail) account by the MTA (Mail Transport Agent, i.e... mail server program).
Most likely, your local MTA is set up to send warning messages back to the sender if a message was not able to go out for a specified amount of time. (5 hours is a common number.) ListProc then sees this warning message, interprets it as an intermittent error, and sets the subscriber's mail method to "postpone."
User unknown or host unknown type errors usually result in deletion. If a number of people end up being deleted/postponed as a result of this, you might want to turn off auto-deletion for the list. For large lists, however, this is probably not a good idea, as it creates a lot of extra work for the owner to remove bad addresses.
No. Owners must be subscribed in order to receive list messages.
Is there a way to set a list to be digest *only*? I found lots of digest-related commands, but nothing that looks like it would inhibit a user from changing his mail status to ACK or NOACK. Can it be done?
You can do:
config <list> <pw> set-disable mail ack mail noack mail postpone default mail digest
and it should work. You could leave out the "mail postpone" to allow users to postpone. The example above should be on one line.
No, not directly. Send an email to firstname.lastname@example.org (CC:email@example.com) to work out these details. This is not meant for casual, minor updates, say under 200 subscribers. Use ADD/DELETE for such updates.
You can send an email to firstname.lastname@example.org (cc:listmgr) containing the email addresses
(and optional names) of the subscribers. The format must be plain text. One subscriber address per line. If the name is included, it can be before or after the address. Keep the order the same throughout the listing, don't mix formats.
It must be separated by a comma.
You can work on a copy of the subscriber file for the list, rather than use add/delete/set commands. But if you do, you MUST NOT put it back. Rather, send it in email to email@example.com (and cc: firstname.lastname@example.org).
You can get a copy of the file to edit by using the edit command:
EDIT listname passwd SUBSCRIBERS -nolock
This is sent to ListProc. You will get a copy of the subscriber file by return mail. You would then save that message as a file, remove any headers and make changes as necessary. You must be sure not to introduce any errors. Don't leave any blank lines, or run any lines together. The file has a fixed format. You are NOT free to alter that format.
Once you are done, end the updated file as plain-text back to ACTION@USC.EDU (CC:LISTMGR@USC.EDU). DO NOT SEND TO LISTPROC.
Do not send it as an attachment. Send it as plain text inline in the message body.
Be sure you send from a valid owner's email account.
The message body should look like this:
PUT listname passwd SUBSCRIBERS
<subscriber file data follows here>
The subscriber file data follows starting on the line right below the PUT command.
This is a multi-part message in MIME format.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
This results from your email program making the message mime-encoded, or html-encoded. Make sure that your email program is set to only send plain-text. Otherwise, if you use the EDIT/PUT method, you will BREAK LISTPROC. Send yourself a copy of your edited file before sending it to LisProc, and save it as a file and look at it to be sure it has nothing but the normal original data in it.
The subscriber file should have nothing in it but lines like:
email@example.com ACK 812838183 NO Joe User
The 5 fields are:
<ADDRESS> <MAILMODE> <PASSWD> <HIDE> <NAME>
These fields are always one subscriber per line, with each field separated by a single space
You can ask firstname.lastname@example.org (cc:listmgr) for help. Use ADD/DELETE/SET commands. You can put multiple commands into one message.
When I subscribe an individual under an email address, the system
sometimes does not recognize that address. Which of the following
formats should I use not to receive such an error message:
If it's a known scf or rcf account, it's correct to say @usc.edu. But you need to see email from the person to be sure.Seeing an email and looking at the FROM: field will usually give you the right address to use. Subscribe users with their real address. Don't guess. This problem usually arises when they try to post to a list and are told that they are not on the list.
If you get back a USER UNKNOWN message, it is usually because you have misspelled the name, the mail alias is broken, or the username really does not exist. You can't fix that last one. Email email@example.com (CC:listmgr) about it, if in doubt.
Once you have added someone to a list, you may see an error message about the person's address. This may happen the first time she or he tries to post email to the list. This happens whenever that person tries to post to the list using an address other than the exact address you entered.
You could simply remove the bad address and add the new, correct address. However, there are circumstances where a person's address could change, depending on how and/or where she or he logged onto a USC host.
The alternative is to leave the subscribed address in place and instead add an alias that will allow one or more variations of the person's address to be accepted. For example. You have added firstname.lastname@example.org to a list. It may have worked when the user used it, but now you get an error message and a complaint from the person, stating "email@example.com, you are not subscribed."
Due to the way mail works at USC, the person's address actually showed up as firstname.lastname@example.org, and so now you need to add an alias to allow both forms of her or his address to work. You can create a specific alias, using the new address and the original address. Send it in an email to ListProc:
alias listname passwd email@example.com firstname.lastname@example.org
The above will now let both addresses work for that user on that list. This is fine if there are only the two choices. However, if the user can log into some other host at USC, that now turns her or his address into: email@example.com, and things are broken again. A small change to the alias format will catch this and other similar morphs of the user address. The changed alias is:
alias listname passwd user@.*.usc.edu firstname.lastname@example.org
The (.*) after user@ is a wildcard match for any characters that show up between the user@ and the .usc.edu. This alias example assumes the person is subscribed as email@example.com.
If the original address had been entered as: firstname.lastname@example.org and you wanted to be able to accept all 3 formats still, use this form:
alias listname passwd user@.*usc.edu email@example.com
Notice that there is no (.) just before the usc.edu in
You could use this form in both cases, but it's less correct for the first example.
If all of your USC address are SCF and/or RCF addresses, and you add the subscribers, rather than have them add themselves, you can use a single broad alias to catch all usc address variations. This assumes you add everyone as firstname.lastname@example.org.
alias listname password (.+)@.*\.usc.edu \email@example.com
Note that this is a VERY broad alias and can end up causing problems for some USC subscribers that have addresses that are not supposed to be converted to @usc.edu. An example might be firstname.lastname@example.org. Converting that private domain to be email@example.com would either fail with "user unknown" or direct mail to the wrong "fred". So a variation on the broad alias can be used:
alias listname passwd ^(.*)@([brs]cf)\.usc.edu$ \firstname.lastname@example.org
then add another alias (for each host like skat) containing:
These two aliases would replace the single broad one above. The upper one catches bcf/rcf/scf.usc.edu and the lower one can catch specific hosts (skat, sol, almaak, mizar). These can be expanded, and others that don't duplicate them can be added.
When you have such aliases in place, they affect your ADD
commands. If you try to add email@example.com, it would be
converted to firstname.lastname@example.org.
Also, only one alias per address. Do not define two aliases for the same addresses, with one set reversed. This creates an alias loop....bad.
You will have to do an EDIT/PUT of the alias file, or send to ListProc:
edit LISTNAME PASSWORD aliases
You'll get back the alias file, and the list will be locked until you do:
put LISTNAME PASSWORD aliases
text of alias file starts here
To look at the alias file, you can send:
edit LISTNAME PASSWORD aliases -nolock
You have to be sure to send only plain text, or you could break your aliases altogether.
You can use the SET command to alter or update subscriber
addresses. The syntax is;
SET listname ADDRESS password new_address FOR old_address
For example, to change email@example.com to be Fredf@bar.org for list OOPS-L
set oops-l address password firstname.lastname@example.org for email@example.com
You could do this by emailing firstname.lastname@example.org (cc:email@example.com) and explaining that you want to replace or merge the subscribers of your lists. Be sure to send your request from an account that is listed as an owner for all lists affected. Otherwise the request will not be honored.
This is the person who would take ultimate responsibility for the list and those that actually manage it. While the sponsor does not have to function as a list owner, he/she has final say about who does fulfill that function and how the list will be run. This person must be a full-time faculty or staff member. The sponsor is really only required when students -- a "group" or "club" or individual -- want a list. Individuals do not normally get a list just to have one. Lists should have some purpose, such as serving a class, or department or special interest group.
The digest is mailed as one file. It is all simply text. The headers are part of that file but separated by keywords that MIME-enabled mail readers can act on to display and/or store them in various ways. If you got the headers, you got the digest. It's just a case of where your mailer put it. Your mail reader configuration may have been altered so that digest messages are not displayed with the headers. They may be being saved as attachments, requiring you to open them separately.
Whether or not you have changed or updated the email reader you are using, you should go over the settings carefully. Look for settings that relate to digest/mime/quoted-printable/attachment actions and directory/file areas where attachments may be going. Try to set these to as close to NO encoding at all as possible. Also, when composing email, DO NOT USE ATTACHMENTS. Include any external file in the body of the message by inserting it, not attaching it. Otherwise, it's unlikely anyone will see the data in the attachment, or the attachment itself.
In summary: When you receive a digest that appears to contain only
the headers (or table of contents), the culprit will almost always
be your mail reader. You should recheck the settings as mentioned
above. To eliminate this problem, Listproc 8.1a and later allow settings
for a non-mime digest mode. Subscribers can set this mode by sending
an email request to firstname.lastname@example.org with the message text:
set LISTNAME mail digest-nomime
The digest will now be simple plain text.
There is another event that can cause attachment problems. Your own mail provider can be running mail through mime filters to "sanitize" the headers. They may have some reference that explains exactly what that means and how to get around it.
It may require that you save the entire message, edit out each attachment piece and save them as separate files, then run them through a decoder such as Stuffit Expander (on Macs or Windows systems).
I am having a problem doing moderated-edit list control on my PC. When I forward the message back, as the heading says, I just get it again, or it goes to the list with the moderator message still in it. Or it may look like I sent it, instead of the real sender
This is a problem with most email programs that run on PC's (Mac's too). It's due to the way it treats a message when you tell the program to forward it back to the list, as required by moderated-edit mode.
For Eudora, the way to do it is to copy everything below
the message headers, starting with the blank line above the one that says:
This message was submitted by
Then create a new blank message addressed to the list name and paste the text into it.
For Pine, use the BOUNCE (B) command on the moderator message, instead of
forward. When a moderated message is forwarded to the list using
Pine, Pine puts the moderator's address as the sender. When the Bounce command is enabled and used it, the digest table of contents lists the actual sender.
If you don't already have bounce enabled, go to
under the Feature Name selections should be one called:
Put an X next to it.
Use moderated-no-edit if possible. All these problems disappear. Think about whether you need to edit a message. Most of the time the answer is no. The few times it may be desirable, simply disapproving the post and telling the sender to resubmit with your changes is easier all around.
Note that if your list is moderated AND set to send-by-subscriber and a non-subscriber posts, the moderator will still get the moderation message. However, the message will not go out, even if the moderator does approve it. If you want to allow non-subscribers to post, you will either have to have the moderator copy and send the message from his account, or set the list to send-by-all, or subscribe the person to the list. Send-by-all is not a good solution unless the list is moderated.
You can restrict your list to USC only by adding this string to the list ignore file:
Thus you would send to email@example.com this email:
ignore listname password ~<.*[\.@]usc\.edu|^catmail$>
This will ignore email to the list unless the person has an email address like firstname.lastname@example.org or email@example.com.
If you plan on doing this, don't forget ISI.EDU. If you want to include ISI as well as USC then use:
The example in the documentation was not quite correct. It
only worked for host.usc.edu addresses. The above is more correct.
The "|^catmail$" part is needed if your list is moderated, and allows moderator messages through. If you use restrictions, you should also tell potential subscribers.
You cannot subscribe to ListProc. You must subscribe to a specific list. Thus you must know the name of the list you want to subscribe to. Then you would send the subscription request to: firstname.lastname@example.org and not to action(or listmgr). The request would go in the body of the message and would look like: SUBSCRIBE listname yourname.
You would substitute the actual list's name for listname and your own first and last name for yourname.
You can limit the spread of an email-borne virus by having your list run as moderated. Then the moderators can block mail with suspicious attachments. Be wary of tricks in how files are named that try to fool you into thinking they are just images or other documents. Attachments with names ending in ".exe" or ".scr" or ".vbs" are all executables for Windows-based systems. There are likely others.
You can inform a subscriber by direct mail if you suspect
she or he is infected with some sort of email-carried virus.
Then also send a warning to the list. Most viruses require an action by the recipient (opening a file, etc), but some are able to execute code by simply being read. That action is dependent on which operating system is used and which applications are installed. Let email@example.com (cc:firstname.lastname@example.org) know, so we can check for and remove any virus from the list archives. Each individual is responsible for protecting her or his own equipment.
If commands in email to ListProc are not in plain clear text, ListProc will not understand them. It is unclear whether this mail is coming from a web-based mail application or a special program provided for mail, but it encloses the text in the message in HTML (and adds an advertisement). To try to get around this, format any message this way: Start the message with a blank line and end the message with a blank line. This should make the text in the message appear on a line by itself. Simply hit the Return key as the first line entered, then enter the command, then hit the Return key twice at the end of the line. If that fails, you are forced to address your requests to the owners of the list by sending email to listname-REQUEST@listproc.usc.edu. So to send mail to owners of list OOPS-L@usc.edu, address it to: email@example.com.
Obviously, if you are a list owner, you don't want to be using such a mail service to try to manage your list. In such cases, contact the email provider to say that you want a simple method to send plain-text email.
If you choose the HTML/ATTACHMENT FILTER option, all mail to your list will pass through the filter.
The filter enforces plain text emails by truncating the email at the first non-plain text attachment.When it does so, it inserts a warning message that becomes part of the email that is delivered to the list.
Since mail clients can vary in how the mail is composed, there are variations in what might be seen. If the message contained a plain-text portion followed by the HTML version of that text, the plain text would appear, along with the warning message. For instance, if you send a message from Outlook and apply BOLD formatting to some text, Outlook sends two copies of the text in the message. The plain 7-bit text, followed by an HTML attachment that allows the "bold" text to be seen. However, the filter will strip that attachment and insert the warning.
If the message did not have the plain text portion, as some don't then there would be nothing to read but the warning message. And even then, some may not see that warning, depending on client.
If the message has HTML in the body, that should go through, as the attachment is not present. In fact, the headers that trigger the filter don't even exist in that type of message (unless, of course the sender does attach something).
Now, on the viewers' end, they may or may not see the message correctly, depending on how their client handles the fact that the attachment was removed. Their program may not display the plain text portion. That may be the case if you get some complaints that some people see a message while others do not. However, everyone does get the very same message, so any difference is due to their client.
For example, a 1-line message sent from Outlook Express with BOLD applied to the text was seen as just a single line of text with NO warning message displayed in Outlook. However, the warning message was there. Using "View Source" showed it. Some may see it that way. Some may see both the text and the warning. Some may see only the warning. Some may see only an empty message. It depends on the mail client they use.
List owners: The point of the filter is to discourage attachments and HTML. If it does not work as you would like then do not use it.