Q: How can I investigate why a subscriber didn't receive a certain message from my list?

By Jacob Haller
Senior Support Engineer, L-Soft

List owners will sometimes hear from subscribers who complain that they didn't receive a certain message that was posted to a mailing list. Perhaps they saw replies to it or someone else mentioned the message, but they don't remember getting it. This tech tip outlines a step-by-step approach on how to investigate the situation.

Problems with the Subscription

To start, check the basic facts of the story. Is the missing message actually in the user's spam folder? Was the user subscribed to the mailing list at the time the message was distributed? Was the missing message actually distributed to the list?

1. Was the person subscribed to the list when the missing message was distributed and what are their subscription options?

To check this, go to "Subscriber Management" under the List Management section and search for the person's email address. If the person is subscribed, then the subscription information should come up like this:

Here are some details to examine:

• Was the address subscribed at the time the message was posted? The "Subscribed Since" date gives this information. If you aren't sure when the message was posted, see below.
• Is the subscription in Digest or Index mode? If so, then the subscriber wouldn't get individual messages immediately when they are posted.
• Is the subscription set to NOMAIL mode ("Mail Delivery Disabled Temporarily")? If so, then LISTSERV wouldn't send copies of messages posted to the list.

2. Was the message actually distributed to the list?

There are a few different ways to check this:

• If the mailing list has archives enabled ("Notebook= Yes"), then you can look there to see if the message in question is there. If it is, then note that the date and time found in the archives are taken from the "Date" header that was present in the original message at the time it arrived to LISTSERV and may not match the time LISTSERV processed or distributed it. In particular, for moderated mailing lists, the message may have been approved some days after the message was originally submitted.
• If the mailing list has changelogs enabled ("Change-Log= Yes"), then you can get a report on "Post" activity for the list by going to "List Activity Reports" under the List Management section. Select "Post" under "Report Events", choose the desired start and end dates under "Report Period", and click on "Update".

You can also include other events if you're interested in other list activity. For instance, if a subscriber is currently set to "NOMAIL" and you want to find out when that option was set, you can look at "Set" activity.

The date and times given are the exact date and time that the message or command was processed by LISTSERV, so this method is more reliable than looking at the archives if you need that information.

Note that if a mailing list has rotating changelogs (for instance, "Change-Log= Yes,Monthly"), then the report will only include activity from the current changelog. If you need information from before the time that the current changelog was started, then you will need to manually view the earlier changelogs in the listserv\main\ or ~listserv/home/ directory. Information about the format of changelogs can be found in the LISTSERV Site Manager's Manual

• Finally, if the mailing list doesn't have archives or changelogs enabled, then you can look in the main LISTSERV log file, which is normally stored in files with names like listserv-yyyymmdd.log. When a message is distributed to a mailing list, a series of entries are made to the LISTSERV log file.

The email address user@EXAMPLE.COM is the person who sent the message originally, and TEST-L is the name of the mailing list. If you know the date the message was distributed, then you can open the LISTSERV log file for that day and search for the email address of the sender, or the name of the mailing list, and see if an entry shows up.

Problems with Mail Servers

For the rest of this tech tip, let's assume that neither of the above is a problem. The user is subscribed to the mailing list with the appropriate subscription options, and the message was in fact distributed to the list. So, the question is, why didn't the subscriber receive it?

The basic possibilities are that LISTSERV couldn't deliver the message to its outgoing mail server; or the outgoing mail server couldn't deliver it onward to the subscriber's mail server; or the message made it to the subscriber's mail server but went astray after that. Let's go over each scenario in order:

1. Did LISTSERV encounter any problems delivering mail to its outgoing mail server?

Normally, LISTSERV is configured to use subprocesses called "SMTP workers" to deliver its mail to its outgoing mail server or servers. This is controlled by the SMTP_FORWARD_n setting. If any errors are encountered, then, under Windows, the errors are recorded in files with names like SMTPS#1-yyyymmdd.LOG, SMTPS#2-yyyymmdd.LOG in the listserv\log directory, with each SMTPS#n log file for a different SMTP worker. Under Unix, all SMTP workers use the main LISTSERV log file for this purpose.

If an SMTP worker is unable to deliver mail to its outgoing mail server, then you may see an entry like this:

The first line, with the -> after the time, is the command the SMTP worker sent to the outgoing mail server. The second line contains the error returned by that mail server, "550 5.7.1 Unable to relay" in this case.

An error code starting with "5" indicates a permanent error, which means that the SMTP worker would not have attempted to deliver the message again. An error code starting with "4" is a temporary error, so the SMTP worker would continue to attempt delivery.

If you see an error like this, then you would need to investigate what caused it. The administrator of the outgoing mail server may need to get involved.

If there is no such error in any of the SMTPS#n log files (under Windows) or the main LISTSERV log file (under Unix), then that normally indicates that the message was successfully delivered to the outgoing mail server.

2. What happened to the message after that? If it was delivered to another mail server, which server? If an error occurred, what was the error?

If an error occurred, then the hope is that the text of the error will indicate what went wrong, and why the message went astray. If the LISTSERV outgoing mail server received the message, and the mail administrator can see that it was delivered onward to another mail server, then the next step is to have the administrator of that mail server verify that the message arrived there and to see what happened to it after that. By repeating this process, you should be able to eventually find the point at which the message went astray and determine the reason this occurred.

Often, if the mail server in question isn't under the control of your organization, then its mail administrators may not be very interested in talking to you. The users affected by the problem may have better luck talking to their mail administrators to get an answer at this point, so you may find it most effective to write up what you've found so far, provide it to the affected user, and have them contact their mail administrators to analyze the problem and hopefully fix it.

Subscribe to LISTSERV at Work.