The LISTSERV® list owner's Support FAQ

Last updated 2017/04/18


Here we have tried to compile a list of the most frequently-asked questions that list owners ask about LISTSERV.

Please note carefully that if your question is not answered here, you should try one of the following avenues for support:

·         The LISTSERV manuals for list owners:

o   List Owner's Quick Start Manual for LISTSERV

o   List Owner's Manual for LISTSERV

·         Your local LISTSERV maintainer

·         Your local list owner help list (if one exists; it's usually a good idea to have one)

·         The LSTOWN-L mailing list

L-Soft's regular support addresses are reserved for LISTSERV maintainers' use only. List owners should use one of the three avenues listed above and may not write directly to L- Soft for help.


1.         Distribution postponed because list is held. 2

2.         Difference between HELD and LOCKED lists. 3

3.         ADD command with really long address fails. 4

4.         Subscriber is "served out". 5

5.         List owner can't post to list 5

6.         "Send= Private" and subscriber can't post; or "Send= Editor,..." and editor/moderator can't post 6

7.         How to get rid of generic "welcome" message when using WELCOME file. 6

8.         How to edit list archive notebooks (i.e., to remove spam, virus, etc.) 7

9.         How do I find out how many subscribers are on my list?. 7

10.      How do I break down the subscriber count by country?. 8

11.      How can I find out the date people subscribed to the list?. 8

12.      The STATS listname command doesn't work! 9

13.      Mail posted to a list rejected because "Sender:, From:, or Reply-To: header pointing to the list has been found in mail body". 10

14.      Postings to lists using Japanese two-byte character sets are mangled. 11

15.      Can I send attachments to my lists?. 11

16.      Can I strip attachments from list postings, or reject messages with attachments?. 12

17.      Out of office autoresponses from list mail are driving me and my subscribers nuts! 12

18.      List is held with "incomplete copy of message might be present in archive file" error 13

19.      Can I stop people from unsubscribing from my list?. 13

20.      Can I send HTML messages through my list?. 14

21.      Topics limit questions. 14

22.      "On behalf of" in the From: field. 14

23.      How to put an unsubscribe link at the bottom of all postings?. 15

24.      Gmail subscribers report that they cannot receive copies of their own posts, even if they are set to REPRO. 15

25.      Can I prevent recipients from replying to list postings?. 16

26.      On a moderated list, can I disable automated messages informing the sender that their message has been submitted to the moderator?. 17

1.  Distribution postponed because list is held

I sent a message to my list but got the following response back from LISTSERV:

The distribution of your message dated Thu, 02 Apr 2015 08:44:51 -0500 with

subject "Test" has been postponed because  the TEST list is held. No action

is required from  you; your message will be  reprocessed automatically once

the list owner releases the list.

A list can become held under a couple of different scenarios:

·         An error has occurred during the processing of a message that has caused LISTSERV to automatically hold the list pending the correction of the error condition.


·         The list owner or server manager placed the list on hold manually, with the HOLD listname command.

In the first scenario, both the list owner and the LISTSERV maintainer(s) are notified of the error. For instance, the list may have been made but the directory for its archives may not have been created before someone posted to the list, or a typo may have been made in the "where" parameter of the Notebook= keyword. In that case you would get a message like this:

An error occurred  while  logging mail to  the archives of the TEST list. An

incomplete copy  of the message  might be present  in the archive  file. The

list is being held to prevent further occurrences of this error. Please take

corrective  action  and  issue  a "FREE  TEST"  command  when  you want  the

message to be reprocessed.


Serious error occurred - traceback follows


>>> Error X'00000011' opening file C:\LISTSERV\ARCHIVES\TEST\TEST.LOG1504


 -> Severity: Warning

 -> Facility: Generic error codes

 -> Abstract: File/major entity not found

-> I/O mode: Record write

which is simply LISTSERV-ese for "the directory referred to doesn't exist". When this kind of error occurs, your LISTSERV maintainer usually has to fix it, and you should contact him or her to do that.

In the second scenario, if you did not place the list on hold yourself, you may want to communicate with the server manager to find out why the list was placed on hold. This may have been done to stop a loop or for some other good reason. When the error is fixed or the reason for holding the list is no longer valid, you can take the list out of HOLD status by issuing a FREE listname command to LISTSERV (where listname is of course the name of your list).

2.  Difference between HELD and LOCKED lists

What is the difference between a list that is on HOLD and a list that is LOCKED?

It is a common error to confuse the HOLD and LOCKED states. They are completely different and it is important to make the distinction when asking for help.

HOLD means only that mail posted to the list will be held until the list is freed. All other operations can be performed on the list, for instance, users can still subscribe and unsubscribe and set personal options freely, the list archives can be searched, and so forth. You free a list that is in HOLD state with the FREE listname command. (Note carefully that if an error condition forced the list into HOLD state, and if the error hasn't been fixed when you issue the FREE command, the list will promptly go back on HOLD and you will be notified.)

A list becomes LOCKED only when you use the GET listname command without the (NOLOCK option and can be unlocked with the UNLOCK listname command or by a list header PUT operation. When a list is LOCKED, users cannot subscribe or unsubscribe or set personal options. However a LOCKED list will still process mail and allow archive searches and so forth.

Please note carefully that it is impossible for a list to become LOCKED as a result of an error condition; a list can become locked ONLY due to a GET without (NOLOCK.

3.  ADD command with really long address fails

When I send an ADD command with a really long address, LISTSERV treats the command as two separate lines and it fails. How do I fix this?

This happens because your command has wrapped to a second line. LISTSERV treats each separate physical line of the message as a separate command line. For instance if you send


your mail client or mail server will probably wrap that line, and LISTSERV will probably respond


someone.with.a.real.long.userid.that.wraps@HISHOST.COM  is not  yet in  the

signup file. Please specify the full name of that person, as in "ADD MYLIST

JOE@XYZ.EDU Joe H. Smith".


> His Name

Unknown command - "HIS". Try HELP.

In order to send commands that span multiple lines, you have to use special formatting called a "continuation card".

Continuation cards can be used to split any long command into two or more 80-character cards. In that case you must insert a "//<space>" string before the first line of the command text and a space followed by a comma at the end of all but the last line of the command text so that LISTSERV considers the multiple lines to be a control card followed by continuation cards, and performs the required concatenation. For instance,


His Name

is read by LISTSERV as one single line and the command will succeed. Note that the spaces are mandatory after the "//" and before the comma; if they are omitted the command will still fail.

4.  Subscriber is "served out"

One of my subscribers just got a message that said they were "served out". How does that happen and how do I fix it so she can post to the list?

If a user sends more than 50 consecutive invalid commands to LISTSERV, LISTSERV automatically serves that user off so that further commands from that user will be ignored. This normally happens by accident, for instance, if a user's "vacation" program keeps sending messages back to LISTSERV every time a posting from the list is received, rather than by someone actually sending 50 consecutive invalid commands manually.

It's also possible for a LISTSERV site maintainer to manually serve users off. Generally this is done to stop mailing loops or because a user's online behaviour is considered unacceptable. Some LISTSERV site maintainers serve out addresses used by spammers, for instance.

While served off, the user will be unable to set personal options and will be unable to subscribe or unsubscribe to lists on that server. Note that a user will likely be served off of one particular LISTSERV site but not others, and also that the user may not even realize that he has been served off (when this happens by accident, LISTSERV always sends notification to the user to that effect, but not all users know what they are looking at when they receive the message).

Should a user become served off accidentally, it is possible for the list owner or any other user to issue a SERVE address command (where address is the user's e-mail address) to restore that user's access. As with all other LISTSERV commands, the SERVE command is sent to the LISTSERV address.

Note that the SERVE command will not restore service to users who have been manually served off by the LISTSERV maintainer. Restoration of service in this case requires that a LISTSERV maintainer intervene.

5.  List owner can't post to list

Note:  In older versions of LISTSERV, list owners and other administrative "role" accounts (such as the LISTSERV maintainer) could not post to lists coded "Send= Private" unless their email address was subscribed to the list.  Current versions of LISTSERV allow these administrative "role" accounts to post even without a subscription, although of course the email address used must be the one associated with the administrative account.

I'm the list owner but I can't post to the list! Why not?

Ensure that the address from which you are posting is either listed in the list header as an Owner=, or that the address is subscribed to the list with posting privileges (e.g., the subscription is not set to NOPOST or REVIEW).  Note that your mail client or your outbound server may be changing your From: address slightly, which would prevent LISTSERV from identifying your mail as coming from the Owner= or subscribed address.  The best thing to do in a case like this is to ask the LISTSERV maintainer to check the LISTSERV system logs to see what happened when your posting arrived.

On my non-public list, I use (for instance) a Hotmail account as my Owner= address, and the Hotmail address is subscribed to the list and I get mail and can post just fine from that address. But I don't want to post from my list owner address, I want to post from my school address so that people don't think I'm the list owner. But I can't post from that address! Why can't I post? I'm the list owner!

(Yes, we really do get this question.) LISTSERV has no way to know that your Hotmail account and your school account belong to the same person (you) and therefore LISTSERV treats your school account just like anyone else's. You need either to subscribe your school address to the list or to make it an editor, depending on how you have the list set up.

6.  "Send= Private" and subscriber can't post; or "Send= Editor,..." and editor/moderator can't post

I have a list that is set to Send= Private (or in any case, it is not set Send= Public) and I can't post to it even though I am subscribed (or am set as an Editor= or Moderator= for a moderated/edited list). Why is this happening?

It's probably because either:

·         You are trying to post from a slightly-different address than the one you have subscribed or listed as an Editor=; or

·         You have "Default-Options= NOPOST" coded in the list header. If you added yourself to the list after adding that keyword setting, your personal options include NOPOST, which overrides any other posting-related option or keyword setting. In order to be able to post you need to set yourself to POST.

7.  How to get rid of generic "welcome" message when using WELCOME file

I want to create a listname.WELCOME file instead of using the generic message LISTSERV sends to new subscribers. But I can't figure out how to get rid of the generic message and I don't want both messages to go out. How do I do that?

There are actually two different ways to do this.

·         Change the generic template for your list so that it says what you want it to say. This involves changing the ADD1, SIGNUP1, and $SIGNUP mail template forms, which is most easily done via the web interface but which can also be done by mail. $SIGNUP is probably the most important form because it is the one that contains all of the information you probably are trying to change. $SIGNUP is included by the ADD1 and SIGNUP1 template forms when you manually ADD a user or when a user SUBSCRIBEs himself, respectively. The upside to this method is that you don't have a separate WELCOME file that you have to deal with, and you can use variable substitutions which can't be used in the WELCOME file (like &LISTNAME). This makes it simpler to just cut and paste templates from list to list.

·         Disable the generic templates and just use the WELCOME file, as you've already indicated you want to do. Note carefully that WELCOME files can't use variable substitutions, so everything you want to say in the WELCOME file has to be coded right into the file. In order to disable the generic templates you simply replace the text in the ADD1 and SIGNUP1 template forms with the text ".QQ", ie,

>>> ADD1 Not needed



>>> SIGNUP1 Not needed


As with the other solution, this is most easily done via the web interface.

8.  How to edit list archive notebooks (i.e., to remove spam, virus, etc.)

How do I edit the archive notebooks for my list, for instance, to remove a virus attachment or a spam?

See for instructions.

9.  How do I find out how many subscribers are on my list?

Issue the command:


You should get a response something like this:

Date:         Thu, 02 Apr 2015 14:30:32 -0400

From:         "LISTSERV.EXAMPLE.COM LISTSERV Server (16.0)"


Subject:      File: "MYLIST-L LIST"

To:           Joe ListOwner <JOE@EXAMPLE.COM>



* Total number of "concealed" subscribers:         227

* Total number of users subscribed to the list:   4623  (non-"concealed" only)

* Total number of local host users on the list:      0  (non-"concealed" only)


The first number represents the number of subscribers who have set the "CONCEAL" personal option. You add the first number to the second number to get the total number of subscribers. In this case the list has 227 + 4623 = 4850 subscribers.

The third number represents only the number of subscribers who are subscribed from accounts on the LISTSERV server. In the "old" BITNET days when LISTSERV ran only on VM mainframes, this number could be significant. Today, when most LISTSERV servers run on dedicated workstation-type machines that do not have mail accounts on them, this number is usually zero.  If it happens to be non-zero, it can (and should) be ignored in the total count, because it represents a subset of the total number of subscribers indicated by the other two numbers.

10.     How do I break down the subscriber count by country?

Issue the command:


(be sure that there is a space between "BY" and "COUNTRY").

Note the following:

·         Country is determined by the top-level domain found in the subscriber's address. Thus (for instance) German AOL users who have AOL.COM addresses will be counted as USA users. Some Canadian universities still have .EDU domains instead of .EDU.CA domains, and will also be counted as USA users. There is no way for LISTSERV to determine that a user whose address is in a given top-level domain is actually living in a country other than the one pointed to by that top-level domain.

·         Users set to the "CONCEAL" option are not counted in the by-country user count.

·         If the output shows a "???" count at the bottom, this indicates that your server's COUNTRY FILE is not up to date and that new top-level domains have been added that LISTSERV is not aware of. Contact your LISTSERV administrator if this is a major issue.

·         If you omit the "SHORT" option from the command, LISTSERV will send you a list showing all users who are not set to the "CONCEAL" option grouped by country.

11.     How can I find out the date people subscribed to the list?

There are two ways to do this. If you are interested only in a particular person's subscription date, issue a QUERY listname FOR userid@host command for that user.

If you want a complete list of people on the list with their subscription dates, issue a REVIEW listname NOHEADER BY DATE command. This returns a columnar list of users and subscription dates. Note that this command (like all of the REVIEW commands we have mentioned above) does not return data for users who are set to the CONCEAL option. Also, if a person subscribed to the list when it was running under a (much) earlier version of LISTSERV, the subscription date field will contain "[UNKNOWN]", as LISTSERV did not log that data prior to version 1.8d.

12.     The STATS listname command doesn't work!

I sent a STATS MYLIST-L command to LISTSERV but it came back saying that the STATS command has not yet been ported to this environment.

The STATS command is (as documented) available only for lists running on the VM mainframe version of LISTSERV. It is very unlikely that it will ever be ported to non-VM servers.

However, under current versions of LISTSERV, you can add

* Change-Log= Yes

to your list header and a special log file will be generated for your list that will monitor all ADD, AUTODEL, BOUNCE, CHANGE, DELETE, POST, RESUBSCRIBE, SET, SIGNOFF, and SUBSCRIBE commands. All abbreviations and synonyms are translated to their "official" forms, i.e., SUB, JOIN, and SIGNON are all translated to SUBSCRIBE for the purposes of the changelog. This makes it easy to write scripts to come up with statistics for a given list--you don't have to take variations of the commands into account.

IMPORTANT NOTE: Before adding "Change-Log= Yes" to your list header, consult your local LISTSERV administrator to make sure LISTSERV has plenty of disk space available. Changelogs can get quite large very quickly if a given list is high-volume or has a lot of subscription activity.

Changelogs can be retrieved and deleted like any other LISTSERV file. To retrieve your change-log, send the command


to LISTSERV. (People running lists on VM need to send the command



To delete the changelog you simply store a blank copy of the file, ie, send


(or "PUT listname CHANGELG" for lists on VM) without any other text following it in the body of an e-mail message addressed to LISTSERV.

Sample changelog entries are:

20150324100330 ADD xxxxxxx@JPS.NET Lxxxx Pxxxxxxxx

20150329120049 AUTODEL xxxxxxxx@EISA.NET.AU

20150329131221 BOUNCE xxxxxxxx@NONEXIST.COM

20150331214433 CHANGE xxxx@MCS.COM txxx@MCS.NET

20150331214434 DELETE xxxxx@SINGNET.COM.SG

20150331232441 POST xxxxxxxx@M4.SPRYNET.COM Printer Drivers

20150401000400 RESUBSCRIBE xxxx@MAIL.MECHWART.MUMSZKI.HU Mxxxxx Zxxxxx

20150426113947 SET xxxxxx.xxxxxxx@WDC.COM REPRO

20150511082712 SIGNOFF xxxxxxxx@STARNET.NET.AR

20150511085642 SUBSCRIBE xxxxxxxx@LYCOSMAIL.COM Kxx Wxxxxxx

As you see, the SET entry tells you what options were set, and the POST entry tells you what the subject of the posting was. RESUBSCRIBE is a SUBSCRIBE operation that takes place when the user is already subscribed to the list, e.g., to change the real name field in the user's subscription. BOUNCE is a special operation that takes place when using the "no-list" bounce-processing mechanism (described in the Developer's Guide to LISTSERV; most list owners will never need or see this operation). Otherwise these entries are fairly self-explanatory.

LISTSERV’s web interface includes a report generator that uses the contents of the changelog files to produce statistical and historical reports.  Or the file may be parsed manually via third-party methods.

13.     Mail posted to a list rejected because "Sender:, From:, or Reply-To: header pointing to the list has been found in mail body"

A user replied to a message on the list and instead of the reply being posted, I received the following error in my mailbox.

The enclosed  message, found in  the MYLIST-L  mailbox and shown  under the

spool  ID 92888  in  the system  log,  has been  identified  as a  possible

delivery  error notice  for  the following  reason:  "Sender:", "From:"  or

"Reply-To:"  field pointing  to  the  list has  been  found  in mail  body.

This error seems to indicate that LISTSERV is incorrectly diagnosing a perfectly good post as a delivery error. Why?

This error is normally generated on an otherwise good reply to a list because the poster (or the poster's mail client) has quoted the entire text of the message he or she is replying to in the body of the reply. Normally this would not be an issue, but if the quoted text includes the RFC822 headers from the original message and if the quoting character (for instance, ">") has a space between it and the lines of the original message, LISTSERV will reject the message as a possible delivery error notice. For instance, quoting like this:

>From: Joe User <>

is perfectly OK, but

> From: Joe User <>

is not. In the first example, LISTSERV ignores ">From" because the complete word it is looking for is "From:". If there is a space as in the second example, LISTSERV finds the word "From:" and rejects the message. (LISTSERV evaluates words as whole units, ie, it looks at message lines as space-delimited character strings and anything between two consecutive spaces is evaluated as a word. Thus the word ">From:" is not strictly equal to the word "From:".)

The question as to why LISTSERV does this can be answered fairly simply. There are mail transfer agents (MTAs) in use today that consistently bounce errors back to the list address (the RFC822 From: line) instead of back to the mail envelope return address (the RFC821 MAIL FROM: line, which you may or may not ever see--often this line is added by sendmail and other MTAs as the RFC822 "Return-Path:" header). This is a violation of standards long in use on the Internet, but unfortunately not everyone pays attention to the standards when writing software for the Internet (L-Soft does, religiously, and always requests interpretations from the standard author when considering implementing something that may or may not be strictly to standard).

One of the ways LISTSERV tries to avoid mailing loops is to look for evidence in the body of the message to the effect that the message is a delivery error. If it finds a From:, Sender:, or Reply-To: line in the body of the message that points back to the list, it rejects the message as a "possible" delivery error. This is because the loop-checking heuristic has no way to tell between a legitimate post and a mail delivery error masquerading as a post; it just has to assume that if certain rules are met, the post is probably a delivery error.

It is not reasonable to relax the loop-checking heuristic in this case as it would then be completely possible for your list to get into a nasty loop situation. The best solution to the problem is to educate your users to remove non-germane text from the body of their replies (the headers are rarely useful anyway), and/or to change the quoting setup in their mail client to remove the space between the quoting character and the text being quoted. If there is no quoting character at all, then one should be added or, again, the quoted headers should be removed in replies to the list.

14.     Postings to lists using Japanese two-byte character sets are mangled

Postings to lists using Japanese (or other Asian) two-byte character sets are mangled when they go through LISTSERV.

This should not be happening in modern versions of LISTSERV.  Your LISTSERV administrator should contact L-Soft support if this issue arises.

15.     Can I send attachments to my lists?

Short answer: Yes.

Long answer: LISTSERV will happily pass just about any kind of attachment through the list that you can think of without comment. The problem you will undoubtedly run into is more along the lines of whether or not your users all have mail clients that can deal with the attachments, either from the aspect of being able to read and decode them (some attachment formats are proprietary) or from the aspect of how large they are (some ISPs limit the size of an individual piece of incoming mail). You also need to keep in mind whether or not your subscribers really want to receive attachments; many do not.

It is usually best to place large files on an FTP or Web server somewhere and simply provide a link to them when you post to the list. Most users on POP dialup accounts will thank you for this, since they won't have to unexpectedly download a large file that they may or may not really want.

LISTSERV does have an "Attachments=" list header keyword that can be set to allow or disallow either all attachments or a subset of certain MIME attachments.  Please see the documentation for "Attachments=" for more information.

16.     Can I strip attachments from list postings, or reject messages with attachments?

Modern versions of LISTSERV contain a configurable MIME attachment filter that will let you bounce or strip MIME attachments. The filter is configured on a list-by-list basis by using the "Attachments=" list header keyword. (There is no site-wide override.) See the LISTSERV documentation for information on how to configure "Attachments=".

You can also strip HTML attachments from multipart/alternative messages (assuming that there is a plain text alternative in the message) by setting "Misc-Options= DISCARD_HTML" in the list header.  (Note that older lists may have "Language= NoHTML", which is deprecated and should be replaced with the "Misc-Options" setting whenever possible.)  The "Attachments=" keyword setting cannot be used for this purpose, nor can it be used to strip or reject messages of MIME type text/plain (which are always accepted since they are plain text).

A list of registered MIME media types for attachments is kept by IANA and can be found at

17.     Out of office autoresponses from list mail are driving me and my subscribers nuts!

Is there a way to stop them?

Since there are no standards for out-of-office (OOO) messages, how they are handled depends entirely on how the remote mail server decides to handle the OOO reply. LISTSERV can recognize some (but NOT all!) OOO messages and deal with them (i.e., ignore them). Other OOO messages get sent to the error-handling address for the list, and this can potentially cause LISTSERV to eventually auto-delete the user whose mail server is throwing back the autoresponse. Other OOO messages get sent back to the list address and can cause loops, which are easy enough to fix--you just delete the user or set him to NOMAIL. Still other OOO messages get sent back to the person who made the original posting (since his address is in the From: line), and LISTSERV never sees them at all. These last are the confusing ones because they sometimes make users think that their messages aren't being accepted by the list, when in fact their messages are being accepted but are being bounced by some other subscriber's OOO setup after LISTSERV sends them out.

Many list owners don't even mess with people who set OOO messages and go on vacation. They delete or NOMAIL the user as soon as they start seeing the messages or start getting complaints from other subscribers.  How to handle this, of course, is a decision that should be made locally.


18.     List is held with "incomplete copy of message might be present in archive file" error

We are getting the following error when we try to send mail to the list:

An error occurred  while logging mail to the archives  of the MYLIST-L list.

An incomplete copy of the message might  be present in the archive file. The

list is  being held  to prevent  further occurrences  of this  error. Please

take corrective action and issue a "FREE MYLIST-L" command when you want the

message to be reprocessed.

We keep freeing the list but this error keeps re-occuring and nothing gets processed.

This situation is usually caused by someone attempting to edit the current message log file. The message log gets out of sync with the digest, and this causes a cycle where the accumulated digest cannot be issued and will continue to build up, the list continues to be held, you free it, it holds again, etc.

The solution is to delete the digest (by setting "Digest= No" in the list header, put the header, then reset "Digest=" to what it was set to before). This means that digest subscribers miss that particular issue of the digest, but it is the only way to re-sync the message log and the digest and solve the problem.

L-Soft strongly recommends that list owners do not edit the current message log file, since this situation can be the result. It's always best to wait until after a particular period's message log has been closed out before attempting any edits on it.

19.     Can I stop people from unsubscribing from my list?

Usually this question is asked by people running lists to which people are subscribed as a condition of their employment (corporate announcement lists, for instance). Sometimes it is asked by people who just don't want people to unsubscribe from their lists (typically spammers).

LISTSERV's design does not take this sort of thing into account, at least not by default. LISTSERV was designed as an "open" system (for lack of a better term) where subscribers had the ability to opt in and out of lists at their own discretion. So the answer is that there really is no simple way to stop people from signing off of lists, and the fact of the matter is that even if you did have such a feature available, if someone really didn't want to read your mail it would be simple enough for them to set up a filter rule in their mail client to automatically and silently dump the mail from your list into the trash.

Site admins who don't mind doing a little programming on their own can take advantage of LISTSERV's "list exit" extensibility to write an exit program to reject the SIGNOFF/UNSUB/LEAVE commands, but list owners who are not also site admins can't do this, since exit implementation is something that can only be done by a LISTSERV postmaster. (Note: List exits are only supported under LISTSERV Classic; they are disabled in LISTSERV Lite.)

LISTSERV sites integrated with LISTSERV Maestro can accomplish this much more easily by using a LISTSERV Maestro Hosted Recipient List and setting it up so that only the admin can modify subscriptions.

The bottom line is that it is probably not worth the time and trouble to keep people from being able to sign off of any list, even if the list serves up highly-important data, given that it's always possible for an individual user to delete the mail unread either automatically or by simply dumping it in the trash after downloading it and reading the subject line.

It should also be noted that current law, for instance the CAN-SPAM act in the United States, may require you to provide an unsubscription path for subscribers who wish to leave the list, particularly if subscription to the list is not required as a condition of employment/enrollment or similar, and/or if the list was not obtained through a double opt-in procedure.

20.     Can I send HTML messages through my list?

Assuming that HTML messages are not explicitly disabled for the list, yes. LISTSERV is essentially a pass-through: unless it is specifically configured *not* to do so, it will distribute whatever it is sent.

The only issues for HTML messages are ability of the sender's e-mail program to send true HTML, and the ability of the recipient's e-mail program to interpret and display it.

21.     Topics limit questions

Is the limit of 23 list topics a "hard" limit, and what are the alternatives if I need more topics?

Yes, it is a hard limit and can't be raised.

If you need more topics, the only alternatives are:

·         Use multiple lists and/or better categorize your topics

·         Switch from using topics on a single list to using a combination of a super-lists and sub-lists

The fact is that if you need more than 23 topics, you probably need to rethink your topic strategy.

22.     "On behalf of" in the From: field

Why does the From: line on mail received from LISTSERV say something like

From: My Test List on behalf of John Doe  

The actual mail was sent by John Doe.

This happens primarily when Outlook is being used to read the mail, but it may happen with other mail user agents (MUAs) as well.  It is due to the way the MUA processes RFC822 "Sender:" headers in received mail.  The actual headers of the message you received were probably more like

Sender: My Test List <>

From: John Doe <>

The intent of the Sender: field as used by LISTSERV is to show that the mail passed through an agent, which is perfectly legal according to the standard.  However, Outlook interprets this according to a different part of the standard, which implies that the Sender: field can also be used to indicate that some other person sent the mail on behalf of the person in the From: line (for instance, a secretary sending mail on behalf of an executive; it should be noted that RFC822 was written in the days when most executives didn't read or respond to their own email, if they even had email).

There is nothing wrong with either approach to the problem, but it can be confusing.  If it is desired to suppress this behavior, simply set

Sender= None

in the list header, and LISTSERV will not generate a Sender: field.

23.     How to put an unsubscribe link at the bottom of all postings?

How do I put an "unsubscribe" link at the bottom of all postings that go through my list?

In current versions of LISTSERV, the default is to insert such a link in the BOTTOM_BANNER templates.

24.     Gmail subscribers report that they cannot receive copies of their own posts, even if they are set to REPRO.

Unfortunately this is due to a Gmail policy which is found here:

Not receiving email from groups

When you send mail to any group or mailing list you subscribe to, Gmail automatically skips your inbox and archives the message to save you time and prevent clutter. The message will appear in your inbox if someone responds to it or if there is an error delivering the message. If you'd like to view your message, you can find it in Sent Mail or All Mail.

There does not seem to be any willingness on Gmail's part to change this policy.  The only workaround for Gmail users is to receive an acknowledgement that their mail was posted, by setting their personal subscription options to ACK NOREPRO.

25.     Can I prevent recipients from replying to list postings?

Not as such.  While LISTSERV can (and usually does) add a Reply-To: header to messages it processes (see the Reply-To= list header keyword for how this is done), the RFCx822 Reply-To: header is handled inconsistently by the major email clients in use today.  Since LISTSERV does not control the recipient's client software, there is no way to prevent any recipient from replying to a list message, other than either to moderate the list and actively reject replies from non-authorized posters, or to set the list up as a one-way announcement list and simply bounce any attempt to reply from a non-authorized poster.  Even setting Reply-To= to point to a "black-hole" mailbox that just throws the mail away unread won't solve this problem, because that still doesn't prevent people from hitting "reply all".

Essentially, RFCx822 "Reply-To:" is added to messages in the hope that a) the recipient's client software will get it right, and b) the recipient won't simply hit "reply all".

It may also be possible to use LISTSERV's CONTENT_FILTER template to block messages that are identified by different types of specialized headers as being replies.  Many modern email programs insert a 'References: ' header which points to the message IDs of previous messages in the conversation, and some also use a 'In-Reply-To:' header that contains the message ID of the message to which the current message is a reply.  Additionally, of course, many email programs put 'Re:' at the beginning of the subjects of replies.

If you want these types of messages to be rejected outright, you'd edit the CONTENT_FILTER mail template and use something like:

References: <*>

Action: REJECT Please don't send replies to the &LISTNAME; mailing list.

In-Reply-To: <*>

Action: REJECT Please don't send replies to the &LISTNAME; mailing list.

Subject:: Re: *

Action: REJECT Please don't send replies to the &LISTNAME; mailing list.

Note that the 'Subject::' line has two colons after 'Subject' – this signifies that it should be an exact match, and that syntax is used in order to match only messages with 'Re:' at the beginning of the message, and ignore messages that have 're:' elsewhere in the subject.   (The comparisons aren't case sensitive, and you wouldn't want a message with a subject like 'Health Care: An Investigation' to be blocked, just because it contains the letters 're' followed by a colon.)

A less stringent measure would be to have such messages be forwarded to the moderators.  In this case you'd use:

References: <*>


In-Reply-To: <*>


Subject:: Re: *


That way, if there were any false matches, the moderators would have the opportunity to approve them.

26.     On a moderated list, can I disable automated messages informing the sender that their message has been submitted to the moderator?

This is the message we wish to disable:

Your message  dated Sun,  31 Aug  2014 17:00:14  -0400 with  subject "Re:

I have a response for that"  has been submitted  to the moderator  of the

MYLIST-L list: moderator@EXAMPLE.COM.

This can be done by editing the list's mail templates.  Using the web administration interface, go to

List Management > Customization > Mail Templates


·         Click save/update.  (Note that LISTSERV may automatically insert another line ".CS xxxxxxx".  You can and should ignore this; it's normal under certain circumstances.)

If it is preferred to make this change for all lists on the server, it can be done at the site level (requires Postmaster-level privileges).  Go to

Server Administration > Customization > Mail Templates

and follow the same instructions as above.

Please note carefully:  The site-wide change will affect ONLY lists that do not already have a customized MSG_POSTING_FORWARD_EDITOR template.  If the change is made at the site level and a list continues to send out moderation notifications, be sure to check if the list-level template has been customized before contacting support.

Comments on this FAQ should be sent to Please do not send support or sales inquiries to this address--it is for comments on the manuals only. If you need to ask a question that is not covered by this FAQ, see the support options outlined at the top of the page.