MTA is able to process all mailboxes except one, the error is: MAPI_E_LOGON_FAILED (4349088)

Mail Target Agent fails with an error:

"CSession::Logon Error -2147221231 The information store could not be opened. - MAPI_E_LOGON_FAILED (MAPI 1.0) Low level error: 0x0 File: 'aeWrapHelpers.h' Line: '279'"

When using Outlook and when using MFCMAPI the mailbox can be opened, even when using the LEDN - /O=ABC/OU=XYZ/cn=Recipients/cn=Bob

The entries in the log file are:
8/12/2008 7:17:02 AM CMBMConn::GetMailboxInfoEx TraceMsg 4808 Retrieving mailbox information (Mailbox: '/O=ABC/OU=XYZ/cn=Recipients/cn=Bob ', Infostore: 'E7C6CFCDC0595A429E6C9792926AFBC2').
8/12/2008 7:17:02 AM PSTFile::InfoBackup TraceMsg 1614 Backing up the auxiliary information for current PST file container 'C:\WINDOWS\system32\Aelita Exchange Migration Wizard\Mail Source Agent\PST\6FE7B016425AD646A72C80A19C610246.PRV'.
8/12/2008 7:17:02 AM CSession::Logon TraceMsg 4800 Logging on to the mailbox '/O=ABC/OU=XYZ/cn=Recipients/cn=Bob ' (Server: 'SERVERNAME', user: 'Domain\serviceaccount').
8/12/2008 7:17:02 AM CSession::Logon Error -2147221231 The information store could not be opened. - MAPI_E_LOGON_FAILED (MAPI 1.0) Low level error: 0x0 File: 'aeWrapHelpers.h' Line: '279'
8/12/2008 7:17:02 AM MailKernel::Connect Informational 2079 Synchronization status: Object '/O=ABC/OU=XYZ/cn=Recipients/cn=Bob ' synchronization was not started due to connection errors.
8/12/2008 7:17:02 AM MailKernel::Disconnect TraceMsg 2042 Total errors occured during processing 1; internal errors 0; warnings 0.
8/12/2008 7:17:02 AM MailKernel::Work TraceMsg 2061 Synchronization has been completed. (RetCode: -2147221502).
8/12/2008 7:17:02 AM PSTFile::Delete TraceMsg 1613 Deleting the file 'C:\WINDOWS\system32\Aelita Exchange Migration Wizard\Mail Source Agent\PST\6FE7B016425AD646A72C80A19C610246.PRV'.

During a close examination of the LEDN in the log file a space at the end of the user name is noticeable:

Retrieving mailbox information (Mailbox: '/O=ABC/OU=XYZ/cn=Recipients/cn=Bob '

There should be no space after Bob, it should be '/O=ABC/OU=XYZ/cn=Recipients/cn=Bob'

Stop dirsync, use ADSI Edit, look up the source LEDN and remove the trailing space. In ADSI to confirm click on Edit, put the cursor at the end of the LEDN and you will see the space. Correct it, delete the space and wait until AD/Exch replication occurs.

Also look up the target object and correct the x500 attribute, it has the same value and MTA is retrieving the information from this attribute.

If you use LDIFDE or lookup target users attributes you will notice - ProxyAddresses=x500:/O=ABC/OU=XYZ/cn=Recipients/cn=Bob ;

You will see that x500 has this trailing space too, it has been copied by DSA from the source LEDN.  This can be either corrected manually or DSA can do it properly. Recommended way is fixing the LEDN in the source and then letting DSA to sync it to the target, it should then populate the x500 properly. Or deleting the x500 on the target and waiting until DSA creates it again with a proper syntax, without a space. Some admins prefer to get rid of all Exchange attributes and let dirsync to populate them again. Modifying any attribute for the source user object should trigger a resync for this object so a full resync is not required.

When this was done proceed with the following steps:
1. Stop all mail agents
2. Remove the mailbox from any collection
3. Expand the source org, find the server, right mouse click - refresh
(alternatively: right mouse - add recipients to the database - find the mailbox and add it manually)
4. Add the mailbox to the mailbox collection
5. Commit changes
6. Find all old PRV in the queue which belong to this user/mailbox and delete them
7. Perform full resync for the mailbox
8. Only then start the agents

MTA should be able to logon to the mailbox successfully.

Note: When using Outlook and MFCMAPI and using the LEDN people usually copy the LEDN from the log but the trailing space is not being copied and/or does not affect the test so it looks like the mailbox can be opened using the same LEDN without a problem, which is not true.