LISTSERV Tech Tip: Can you help me understand the daily error monitoring reports that LISTSERV sends out?

Q: Can you help me understand the daily error monitoring reports that LISTSERV sends out?

Most list owners have at some point received the daily error monitoring reports that are automatically generated and sent out whenever certain delivery errors occur. These error reports are part of the auto-deletion feature, which can be configured in many ways depending on the level of automatic error handling wanted by the list owner. But what do all of these delivery errors really mean, and are they something that list owners should be concerned about? Let's take a look at some examples.

To learn more about the Auto-Delete list configuration setting specifically, see this previous Tech Tip.

This example of the daily error monitoring report shows which addresses are currently bouncing and are being actively monitored by LISTSERV for further bounces.

Date: Thu, 18 Aug 2016 00:05:14 -0400
From: <LISTSERV@LISTERV.EXAMPLE.COM>
Subject: LISTNAME: Daily error monitoring report

The following 1 subscriber was deleted from the LISTNAME list today:

  peter@COMCAST.NET
  Last error was: 5.1.1 Mailer gateway-s.COMCAST.NET said: "551 not our
                  customer"

The following 4 subscribers are currently being monitored:

Err First Last  Address
--- ----- ----- -------
 15 08/16 08/17 PAUL@EXAMPLE.COM
                Last error: 5.0.0 X-Postfix; unknown user: 
                "paul@example.com"

  8 08/17 08/17 "Max Shelby" <MAX@EXAMPLE.EDU>
                Last error: 5.1.1 Mailer mailrelay.EXAMPLE.EDU said:  
                "550 5.1.1 <max@EXAMPLE.EDU>... User unknown"

  7 08/16 08/16 David Armstrong <DAVID@EXAMPLE.ORG>
                Last error: 5.1.1 Mailer 
                inbound.example.org
                said: "550 RCPT TO:<david@EXAMPLE.ORG> Relaying
                not allowed"

  1 08/15 08/15 Bob Johnson <BJOHNSON@EXAMPLE.NET>
                Last error: 5.1.1 X-Unix; 67

Err=   Number of delivery errors received thus far
First= Date first delivery error was received (mm/dd)
Last=  Date of most current delivery error (mm/dd)

With the Auto-Delete= Yes,Full-Auto,Delay(4),Max(50) list configuration setting, subscribers will be automatically deleted from the list when delivery errors have been reported for a period of three days or more, or when 50 delivery errors have been received, whichever occurs first. Monitoring will cease after four days if no further errors have been reported.

The top portion lists any addresses that have been auto-deleted from your list. The reasons are usually clearly stated. See the References section at the end of this tech tip for more information on the numerical error codes.

The next section lists addresses being "monitored". These are addresses for which one or more bounces have been received but have not yet reached the threshold for auto-deletion. To properly interpret these, you first need to look at the error count. A count of one or another small number (three to five) can usually be ignored (but see later examples for cases where even one error may be important). The next column is "First", which is the date when the first error was received, followed by "Last", which is the date that the most recent error was received.

Looking at the example above, BJOHNSON@EXAMPLE.NET had only one error reported, and it was three days ago. This address has produced zero errors since then and will drop off the report if no more errors occur tomorrow. DAVID@EXAMPLE.ORG had seven errors, but they occurred two days ago and none since. If no more errors occur, this address will drop off the report in two more days. Neither of these is of any concern. MAX@EXAMPLE.EDU had eight errors yesterday. We'll need to see what happens to it in tomorrow's report. Finally, the address PAUL@EXAMPLE.COM has a total of 15 errors over the last two days. As it happens, there was a total of 15 messages posted to the list over the last two days, so for this recipient, every message bounced. If this address produces any bounces tomorrow, it will have made bounces for three consecutive days and will, thus, be auto-deleted when the report is produced tomorrow night. It won't reach the cutoff of 50 total errors, but it will reach the cutoff point of errors for three or more consecutive days.

The following 2 addresses are currently being monitored: (Remember, some
addresses may not be subscribers.)

Err First Last  Address
--- ----- ----- -------
  1 11/09 11/09 HANS@EXAMPLE.DE
                Last error: 5.4.7 554 5.4.7 [internal] exceeded max retries
                            without delivery

  1 11/08 11/08 Nate Miller <NATE.MILLER@EXAMPLE.GOV>
                Last error: 5.2.2 Unspecified; usually "Mailbox full"

The second error here is readily understandable, but the first one may not be. Typically this means that the domain of the recipient no longer exists (or its mail server is off-line). LISTSERV's sending mail server tried to deliver the message for its maximum configured timeout (typically three to five days) but never succeeded in connecting to the receiving domain, so it has given up and bounced the message.

The following 106 addresses are currently being monitored: (Remember,
some addresses may not be subscribers.)

Err First Last  Address
--- ----- ----- -------
  3 11/20 11/22 Jim Joyce <JIM@MSN.COM>
                Last error: 5.0.0 550 Requested action not taken: mailbox
                            unavailable

  1 11/22 11/22 Andy Adams <ANDY.ADAMS@EXAMPLE.UK>
                Last error: 5.7.1 554 5.7.1 Rejected 209.119.5.127 by             
                            security policy

  1 11/22 11/22 EXAMPLE1@AOL.COM
                Last error: 5.2.1 521 5.2.1 : AOL will not accept delivery of
                            this message.

  1 11/22 11/22 Jonathan Taylor <EXAMPLE2@AOL.COM>
                Last error: 5.2.1 521 5.2.1 : AOL will not accept delivery of
                            this message.

  1 11/22 11/22 Kate Walker <EXAMPLE3@AOL.COM>
                Last error: 5.2.1 521 5.2.1 : AOL will not accept delivery of
                            this message.

The above error report is only a small portion of the total report. The first error is easily understood. All of the AOL.COM errors (there were 95 more) are the same. Unfortunately, AOL doesn't give any more information, but the second error gives a clue that there might have been some kind of objectionable content in one message sent to the list that day. For example, this could have been a certain URL included in the message that was deemed suspicious, so the entire email was blocked. Simply wait for the next day's report to see if any further errors occur.

The following 5 addresses are currently being monitored: (Remember, some
addresses may not be subscribers.)

Err First Last  Address
--- ----- ----- -------
  2 11/08 11/10 SCOTT@EXAMPLE.CA
                Last error: 5.7.1 550 5.7.1 message content rejected

  2 11/08 11/10 Patrick Brown <PATRICK.BROWN@EXAMPLE.COM>
                Last error: 5.0.0 550-ATLAS(2503): Your email was detected as
                            spam. SA (RCPTs:

  2 11/08 11/10 Peter Singh <PETER@EXAMPLE.EDU>
                Last error: 5.7.1 550-5.7.1 Vulgar/Inappropriate words

  2 11/08 11/10 Chris <CHRIS@EXAMPLE.ORG>
                Last error: 5.0.0 554 rejecting banned content

  12 11/08 11/10 WILLIAM@EXAMPLE.NET
                Last error: 5.1.10 550 5.1.10 RESOLVER.ADR.RecipientNotFound;
                            Recipient not found by SMTP address lookup

Again, we have two messages sent over two days that had some kind of objectionable content, in this case something considered by several different sites as "bad language". This can be a common problem if your list acts as a support group for people with certain medical conditions. While certain words may be necessary to use in this context, some sites think otherwise. The only solution is to suggest that list members change to another email provider with less stringent rules. The final error above is a variation on "no such user", and the person will be auto-deleted when the next report is produced the following day.

Hopefully this gives you a little insight into how to interpret these reports so that you can better manage your lists. Many list owners get unnecessarily concerned (in the AOL.com example above) that all of their AOL.COM subscribers are in danger of being auto-deleted immediately. This was not the case here. There was only one such error for the whole week, so the AOL.COM subscribers didn't come anywhere near the cutoff values and were in no danger of being auto-deleted.

As a list owner, if you have questions about any messages that you don't understand on your error reports, you may have a helpdesk that you can contact, or you should be able to contact your server administrator for help in interpreting unfamiliar messages.