Noch etwas von IBM
Technote 1088172
Using a Notes client, you receive either visual or audible new mail notification. When you open your mail file, however, there are no new documents.
New mail notices are generated when an internal sequence number in the server mail file is compared to the NewMailSeqNum in the client's NOTES.INI file. The internal sequence number is incremented when new mail is delivered by the router. If it is found to be different, then a new mail notice is displayed. In Notes R5, separate NewMailSeqNum values are kept for each mail file replica bookmarked in the Workspace.
Note that the notice appears when the numbers are DIFFERENT. Although specific values are kept for each database replica ID as they are accessed, there have been circumstances where the newmailseqnum value for the database in use is updated with the wrong number. This is discussed below.
During replication, if either copy of the database (local or server) has a sequence number, the sequence numbers will be maximized in both databases at the end of replication. This makes the sequence number for a particular user's mail file universal across all Notes replicas of the mail file.
The delivery sequence number is obtained (or the NewMailSeqNum variable is updated) by:
Polling: If users specify a polling interval, the client checks to see if there is any new mail in their current mail file.
Broadcast: The router will broadcast the delivery sequence number of a user's mail file as it delivers mail if the user has a current session open to the server.
Replication: When Notes replicates a user's mail file, Notes also learns its delivery sequence number. If it is indicative of new mail, the user will be notified.
New mail notifications are initiated in 2 ways:
1. Notification is sent by the server with a "You have new mail" message in the toolbar broadcast when new mail arrives in the mail file. This is known as "asynchronous notification".
While a user session is opened with the server, the server broadcasts a mail sequence number when new mail is delivered to the mail file. This is independent of the polling performed by the client according to the parameter in User Preferences. This broadcast number is compared to the NewMailSeqNum number in the client's NOTES.INI file. If it is different than the NewMailSeqNum, a "You have new mail" message is generated by the client in the Toolbar.
Refer to the document titled "'You Have New Mail' Notification Received Even Though User Preferences Has it Disabled in Notes 4.x" (#167835) for more information.
2. Via an audible or visible pop-up notification when polling is initiated by the Notes client.
If, when the Notes client polls for new mail against any replica of the user's mail file, the sequence number returned is different than the NewMailSeqNum variable (or NewMailSeqNum specific to the replica in Domino 5 and 6), the user receives a notification.
The delivery sequence number is a universal number across all replicas of a user's mail file. If the number is greater than the number last recorded, the user has new mail. This is incremented by one with each new message. However, it is not indicative of the number of documents in the mailfile.
Solution
NOTE: There is a known issue (reported to Quality Engineering as SPR# JHOD5M3RF9) where the server broadcasts the delivery sequence number from a centralized mailfile to all open sessions. This mailfile is incorrectly referred to via a Person document that does not have a User Name indicated. In this case, the Mail-In Database document should be used, and implementing this resolves the problem.
It has been found that in most cases, the false new mail notifications are a result of seeing the message in the view before the polling has had a chance to update the NewMailSeqNum variable in the client's NOTES.INI. When trying to reproduce the problem, it is important to make sure that the mail file is not left open. Refreshing the mail file via the F9 key or clicking on the Refresh arrow displays new mail before the client polls the mail file.
The original intent of polling for new mail was for situations when the client does not have an open session on the server. If the mail file is left open, new mail notifications are delivered via a broadcast from the server in the toolbar, when the refresh arrow appears. In this case, since the user is actually monitoring the mail file for new mail, polling is not necessary. If suspecting false new mail notices, it is recommended to turn polling off to rule out this scenario.
Use the following steps to troubleshoot false new mail notifications:
1. First, verify that you are using the correct Location document. Then, within the Location document, verify that the 'Mail file' field specifies your mail file. (The Mail file field specifies which database your Notes client should poll for new mail.)
2. When a new mail message arrives AFTER the visible or audible notification is received, then that message will trigger a notification the next time the mail file is polled. If the user opens the mail file and sees the message during this interval, the message may not be perceived by the user as new, and the next notification may be interpreted as false.
Verify that this is not the reason by closing the mailfile and only opening when the new mail notice appears.
An enhancement request to update the NewMailSeqNum with the current database sequence number when the message is displayed in the view is pending.
3. Check the All Documents view at this point to determine if new mail is actually received, but does not appear in the Inbox due to Mail Rules.
4. Set debugnewmail=1 in the client NOTES.INI file. This parameter, along with the debug_outfile parameter (capturing output to a text file as in, debug_outfile=c:\newmail.txt) captures the following information: Time of polling, server polled, mailfile polled, and the previous and new value of the NewMailSeqNum.
If the NewMailSeqNum increases normally, focus on user perception (#2).
When polling for new mail, the Notes client compares the NewMailSeqNum variable in the NOTES.INI file against the delivery sequence number in the mail file. If the number is different, a new mail indication is received. Refreshing your mail view after receiving new mail but before the mail file is polled does not update the NewMailSeqNum NOTES.INI variable. When the mail file is next polled on schedule, you receive a new mail notice because the number kept in the mail file is still different than the NewMailSeqNum at polling time. This can be seen in the captured outfile when debugnewmail=1 is in place.
5. As stated above, there is a known issue when mail is delivered to a database using a Person document with no User Name listed. The debugnewmail setting will log the delivery sequence number being used to update the local NewMailSeqNum value. The key symptom is that the local number is updated with a seemingly bogus number from time to time. The false new mail notice occurs when this number is initially updated, and then occurs again (if there is no new mail) during the next poll as the number is reset to its original, correct value.
The hidden $Users view in the Server's Domino Directory lists the User Name. Search the ListName & FullName column for blank values. If these are Person documents being used to route mail to a centralized database, create Mail-In Database documents instead to resolve this issue.
6. Re-synchronize the value stored in your NOTES.INI with the value stored in your mail file. Do this by completely removing the NewMailSeqNum parameters from your NOTES.INI file. When you restart Notes, a plain NewMailSeqNum parameter (without Replica ID) is added back to your NOTES.INI file.
When Notes is first set up, the NewMailSeqNum does not exist. When you access your mail file for the first time, this variable is added to your NOTES.INI file. If switching to Location documents pointing to different mailfiles, separate NewMailSeqNum variables are added that include the database replica ID.
7. If your workstation is shared by multiple users (who switch Location documents but share the same NOTES.INI file), false mail notifications may occur because the NewMailSeqNum is updated with the current mail file's number. In Domino R5 and Domino 6, separate INI variables are kept specific to each replica and should prevent this from occurring.
8. Check for multiple NOTES.INI files. (Check both your local C: drive and mapped drives.) The NewMailSeqNum in the NOTES.INI in use is compared against the internal number in the mail file and is updated by the polling function.
9. In the NOTES.INI file look for an entry that begins either:
AltMailApp=
or
$MailStEd=
If either entry exists, comment it out - by inserting either a REM or a semi-colon at the front of the line. (In one case, this resolved the problem for a client that was getting mail notifications every two minutes.)
10. Check to see if a Readers field prevents the user from seeing the message. In this case, a new mail message has been received, but cannot be viewed by the user. You can try to access the user's mail file from the server's workstation with the server's ID. If the server is reader, the documents will be displayed. If this cannot be done, another troubleshooting method is to add a "Log_Mailrouting=30" line on the mail server's NOTES.INI, and when a "false" mail notification arrives, check the log or server console to determine if the message has arrived undetected by the recipient, and the identity of the sender.
