The LISTSERV® list owner's Support FAQ
Last updated 2007/06/13
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, 08 Jul 1999 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.LOG9907
-> 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.
With that in mind, we are leaving this FAQ otherwise unchanged for those list owners running lists on older versions of LISTSERV, or for list owners trying to post from non-subscribed addresses that are not administratively associated with the list.
I'm the list owner but I can't post to the list! Why not?
List owners do not have any special posting privileges per se. If the list is Send= Public, then anyone can send to the list, of course, including the list owner, regardless of whether or not they are subscribed to it.
On the other hand, if a list is set to Send= Private (or Send= Editor when the list owner is not defined as an Editor= or Moderator=), the list owner is treated just like anyone else. On a Send= Private list, he has to subscribe in order to post; on a moderated or edited list, he has to be defined as an editor or moderator in order to post.
On my non-Send= 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.) This is pretty much the same answer as above. 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 either need to subscribe your school address to the list or 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.
If you have to change the template forms by mail, see chapter 9 of the list owner's manual for instructions.
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, 16 Sep 1999 14:30:32 -0400
From: "L-Soft list server at LISTSERV.EXAMPLE.COM (1.8d)"
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 CompuServe users who have COMPUSERVE.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.
(Both of these solutions require LISTSERV 1.8d or later. If you have an earlier version, there is no way to determine the subscription date.)
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 an 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 LISTSERV 1.8d and later, 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:
19980324100330 ADD xxxxxxx@JPS.NET Lxxxx Pxxxxxxxx
19980329120049 AUTODEL xxxxxxxx@EISA.NET.AU
19980329131221 BOUNCE xxxxxxxx@NONEXIST.COM
19980331214433 CHANGE xxxx@MCS.COM txxx@MCS.NET
19980331214434 DELETE xxxxx@SINGNET.COM.SG
19980331232441 POST xxxxxxxx@M4.SPRYNET.COM Printer Drivers
19980401000400 RESUBSCRIBE xxxx@MAIL.MECHWART.MUMSZKI.HU Mxxxxx Zxxxxx
19980426113947 SET xxxxxx.xxxxxxx@WDC.COM REPRO
19980511082712 SIGNOFF xxxxxxxx@STARNET.NET.AR
19980511085642 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.
A non-supported REXX script that generates a report based on the contents of a changelog file can be downloaded from ftp://ftp.lsoft.com/listserv/windows/contrib/STATS.REXX. STATS.REXX is NT-specific but could probably be ported easily enough to unix, or could be used as an outline for a Perl script. The output of this script is similar to that of the old VM STATS command, but with more bells and whistles.
As of 14 Feb 2000 a unix-specific port of this script (still unsupported) is available at ftp://ftp.lsoft.com/listserv/unix/contrib/stats-unix.rexx.
A non-supported Windows NT/98 GUI that will also process changelogs can be found at ftp://ftp.lsoft.com/contrib/changelog_check.exe.
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.
By default, LISTSERV translates control characters in postings. The solution to this problem is to set
* Translate= No
in the list header to stop LISTSERV from doing this.
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.
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.
The version 1.8d 2000a "level set" release of LISTSERV, announced and made available on 5 May 2000, and later 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 level set release notes or the LISTSERV 1.8e documentation for information on how to configure Attachments=, and check with your site manager if you are unsure if your site has installed the 1.8d-2000a level set or later.
You can also strip HTML attachments from multipart/alternative messages (assuming that there is a plain text alternative in the message) by setting Language= NoHTML in the list header. 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
Special note for LISTSERV 1.8d and inline uuencoded (non-MIME) attachments
Note carefully that prior to 1.8e, Attachments= works only for properly-configured MIME attachments. It will not strip or filter (for instance) uuencoded files that are simply cut and pasted into the body of a posting. The only way to reject such postings would be to use the pre-1.8d-2000a workaround of setting the Sizelim= list header keyword to reject mail more than a specified number of lines in length, which can have the side effect of rejecting mail containing binary attachments (assuming the attachments push the length of the mail over the number of lines you specify; it won't catch all attachments). To limit the number of lines you code
* Sizelim= xxx
in the list header (where "xxx" is the number of lines). This has to be done on a list-by-list basis; there is no global setting. Generally a setting of 200-250 lines is sufficient to allow legitimate mail through but reject most large attachments. Note carefully that setting Sizelim= for a given list is not a guarantee that your list will remain virus-free, since it is entirely possible that a virus propagated by a non-MIME method (and thus being able to slip through regardless of any Attachments= setting you might have) might be smaller than your Sizelim= setting. Sizelim= is just one more tool that you can use to help keep the larger virii off your lists.
LISTSERV 1.8e can and does recognize mail that contains this sort of attachment. Please see the documentation for details.
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.
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?
The simplest solution (and please note that this works only in LISTSERV Classic, since LISTSERV Lite does not allow you to customize list-level templates) is to put a mailto: link in the BOTTOM_BANNER template form for the list in question. If you have nothing else in that template form, the code for the link might look like this:
Unsubscribe link: mailto:&LISTNAME-SIGNOFF-REQUEST&MYHOST
This creates a bottom banner that might look like this when the user receives it in his mailbox:
Unsubscribe link: mailto:MYLIST-L-SIGNOFF-REQUEST@LISTSERV.EXAMPLE.COM
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.