I work for a local government agency where we manage our own mailing list for pushing out news and information for our citizens. I try to stay proactive on removing email addresses that no longer exist and dealing with any spam blacklistings. However, there is one non-delivery report that is baffling me. Here is a screen shot:
The blurred out areas indicate our email server.
As you can see, there isn't any email address in there that tells me where the issue resides. I get several of these every time time we send out another news release everything is the same, but the date, thread index, and message id. I have been unable to find any of this in the email server's logs. How do I figure out what email address this relates to so I can remove it?
For context, the emails are generated on our web server using another email server software. Our primary email server is running Exchange. I have talked to our email server admin about this problem, and they don't see anything in their logs.
Update: Here is another type I get with the same problem. I understand what the error means, but how do I know what that domain is?
Maintaining a big mailing list can involve a fair amount of detective work. Much of this is caused by MS Exchange, and other mail servers who think it's a great idea not to use 5xx SMTP codes to indicate unknown users, but to accept email for everyone, then generate new emails to inform senders that some users don't exist. To make life even more fun, the format of these "replies" can be configured, so you can't rely on a standard-format response.
When those go back to mailing lists, some list software doesn't recognise the cute, custom "No such user" email, and generates a new "I don't know what you're talking about" email, which goes back to the system account from which the original "No such user" email came.
These can bounce back and forward for a while, until finally an automated reply (to an automated reply)^
n
to a no-such-user automated email (for largen
) reaches a human being, who then has to start working out which invalid subscribed user caused the original email.Congratulations, this is you, and it's your job. Techniques I've used successfully include:
making a shrewd guess about the domain of the sending user (which in this case might be
lotuslive.com
), asking the list server which users are in that domain (which undermailman
involvessudo -u mailman list_members -f LISTNAME | grep lotuslive.com
), and sending each of them a personal test email to look for bounces;repeating the above, but for each subscribed user, doing a
dig mx DOMAINNAME
and seeing if any of the reciipents' domains is MX-delegated tolotuslive.com
, then for each of those, sending a personal test email to look for bounces;slowing the delivery rate of the list engine to a crawl (like, one email sent out per minute) and trying to correlate the replies (see mail server logs) with the recipient;
accepting that I'm never going to find out who it is, and involving procmail or some similar filter to suppress the final error, so I don't have to read it each time a legitimate mail is sent to the list.
In short, there's no single answer; patient detective work is called for, and that's just part of the boulot of a list admin. Good luck.
To finish up this question. I did find the cause. The email server we were using wasn't quite configured right. One of the settings referred to the bad domain. I updated that to use the right domain and now I no longer get those messages.