Fixing a problem: When one person is not getting SOME mail

Anthony Holmes  5 January 2010 01:08:00 PM

Here's a problem two of my customers have seen: A single person is getting all email except message sent to them by people on one other server. Those emails vanish. They don't appear in any mail.boxes and they aren't returned to the senders.

In both cases I was impressed that my customers managed to track down that much information about the problem. It's potentially very elusive. Imagine what happens when the (non)recipient phones up the Help Desk:

"I'm not getting some of my emails."
"Yes, most of them arrive."
"Fred told me he sent an email, but I can't see it."
"No, Fred didn't get a non-delivery report."
"Yes, I got the test email you just sent me" (from the Help Desk).
"Mary has also just told me that she sent me an email that I didn't get."

You'd be tempted to decide that the problem was caused by people covering their backsides and pretending to have sent emails, or getting forgetful, or messages going to someone else with a similar name. It would take you a while to discover that the messages had a) truly been sent b) completely vanished and c) bear only one common factor: the senders are all on a single mail server, and their server is not the destination server.

(And, by they way, anybody on the Senders' server can successfully send to other people on the Recipient's mail server. So it's not a server to server routing problem.)

If I've seen this problem twice, there must be many others out there with the same problem. Here's the solution:


Imagine this environment:

People are sending emails to Fred Flintstone from SendingServer1.
Fred's Person document shows that his mail file is on Receiving Server1.
The mail routing between SendingServer1 and ReceivingServer1 is working correctly for other messages. The problem is recipient specific.

Mail sent from anywhere in the world (except SendingServer1) is routed by a lookup of where Fred's Mail File is in his person document.

But SendingServer1 notices (and uses) a hidden field in Fred's Person document with this value:

NewMailServer:    SendingServer1

There is also a value in the person document for NewMailFile.

These values are (properly) added to person documents as part of a user move initiated by Adminp. They are needed to ensure that mail isn't lost in the middle of a mail move. The values are normally automatically cleaned up at the end of a move.

In these cases the following happened:

• The Administrators didn't think that Fred's mail file was in the middle of a user move when they encountered this problem. But there may have been a move in the past.
  
• In both customers' case, there was likely to be some strangeness around a user move for Fred Flintstone.
  In one case a person was moved to another server and then back to the original server, but Adminp was prevented from deleting the mail file on the temporary server.
  In the other case, the customer simply fixed the problem and didn't track down the root cause, but it was likely to be similar.
  
• No matter what happened to confuse the Adminp move, the critical point was to discover that there was an additional mail file for Fred Flintstone sitting on SendingServer1.

When SendingServer1 saw that the NewMailServer value was SendingServer1, and when it also discovered that it had the mail file named in NewMailFile, it used those values in preference to Fred's "proper" mail server and mail file values.

Removing the NewMailServer and NewMailFile values and deleting the rogue mail file on SendingServer1 fixes the problem. (Before you delete the mail file, make sure the 'missing' messages are copied/replicated to Fred's proper mail file.

For background information on the two fields, see this document:

AdminP Move MailFile Request Adds Two New Fields to Person Document (NewMailFile and NewMailServer)
http://www-01.ibm.com/support/docview.wss?uid=swg21087214

• Comments [3]