The LISTSERV® list owner's Support FAQ
Last updated 2016/09/06
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:
· Your local LISTSERV maintainer
· Your local list owner help list (if one exists; it's usually a good idea to have one)
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.
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).
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.
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
QUIET ADD MYLIST firstname.lastname@example.org His Name
your mail client or mail server will probably wrap that line, and LISTSERV will probably respond
> QUIET ADD MYLIST email@example.com
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,
// QUIET ADD MYLIST firstname.lastname@example.org ,
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.
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.
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.
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.
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.
How do I edit the archive notebooks for my list, for instance, to remove a virus attachment or a spam?
See http://www.lsoft.com/manuals/1.8d/qs/editlogs.html for instructions.
Issue the command: REVIEW listname SHORT NOHEADER
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.
Issue the command: REVIEW listname SHORT NOHEADER BY COUNTRY
(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.
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.
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
GET listname CHANGELOG
to LISTSERV. (People running lists on VM need to send the command
GET listname CHANGELG
To delete the changelog you simply store a blank copy of the file, ie, send
PUT listname CHANGELOG
(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.
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 <email@example.com>
is perfectly OK, but
> From: Joe User <firstname.lastname@example.org>
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.
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.
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.
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
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 (ie 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.
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 suggests 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.
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.
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.
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.
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 <email@example.com>
From: John Doe <firstname.lastname@example.org>
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
in the list header, and LISTSERV will not generate a Sender: field.
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.
Unfortunately this is due to a Gmail policy which is found here: http://support.google.com/mail/bin/answer.py?hl=en&answer=6588 .
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.
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:
Action: REJECT Please don't send replies to the &LISTNAME; mailing list.
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:
Subject:: Re: *
That way, if there were any false matches, the moderators would have the opportunity to approve them.
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
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 email@example.com. 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.