Duplicate/ambiguous addresses in iMS 6.3
I've just migrated from iMS 5.2 to iMS 6.3-1.04. Our old iMS used dirsync, so direct comparisons are difficult, but when email addresses which used to be considered unique are used in the new system, I'm getting the "duplicate/ambiguous" error.
Here's the sample LDAP from one of the affected users, who married, and carried two LDAP entries (serial numbers filed off):
dn: uid=abcde, ou=nsPeople, o=company.com, c=US
mailalternateaddress: georgia.burdell@company.com
mail: gburdell@company.com
maildeliveryoption: forward
mailforwardingaddress: Georgia.Burdell@exchange.company.com
objectclass: mailrecipient
mailhost: mailhub.company.com
inetmail: yes
dn: uid=12345,ou=nsPeople,o=company.com,c=US
mailalternateaddress: georgia.burdell@company.com
mail: gburdell@company.com
mailforwardingaddress: gburdell@memo.company.com
objectclass: mailrecipient
Our old iMS 5.2 system keyed only on "objectclass: mailrecipient" for valid entries, but when you send to "gburdell@company.com" it had no problem forwarding to the Exchange address.
The new iMS 6.3 system views both as valid. Is there some way to set an LDAP filter on an attribute which will let iMS 6.3 pick out valid email? iMS 5.2 had the "local.imta.ugfilter", but iMS 6.3 has nothing like that I can find.
Any help is appreciated!
Chris
# 1
Hi,
> dn: uid=abcde, ou=nsPeople, o=company.com, c=US
> mailalternateaddress: georgia.burdell@company.com
> mail: gburdell@company.com
> maildeliveryoption: forward
> mailforwardingaddress:
> Georgia.Burdell@exchange.company.com
> objectclass: mailrecipient
> mailhost: mailhub.company.com
> inetmail: yes
>
> dn: uid=12345,ou=nsPeople,o=company.com,c=US
> mailalternateaddress: georgia.burdell@company.com
> mail: gburdell@company.com
> mailforwardingaddress: gburdell@memo.company.com
> objectclass: mailrecipient
>
> Our old iMS 5.2 system keyed only on "objectclass:
> mailrecipient" for valid entries, but when you send
> to "gburdell@company.com" it had no problem
> forwarding to the Exchange address.
Do you mean "objectclass: mailrecipient" or "inetmail: yes"? Both accounts have the former so wouldn't this have caused confusion with dirsync?
> The new iMS 6.3 system views both as valid. Is there
> some way to set an LDAP filter on an attribute which
> will let iMS 6.3 pick out valid email? iMS 5.2 had
> the "local.imta.ugfilter", but iMS 6.3 has nothing
> like that I can find.
Ideally you should be looking at cleaning up the duplicate addresses -- so having a one-to-one model (one email address per account). Anything else is bound to lead to problems in the future.
One thing you may want to try is to add the following to the inactive account:
"mailuserstatus: deleted"
From the Messaging Server Admin Guide:
"Sanity Checks on the LDAP Result: After the LDAP search has returned a result, it is checked to verify that there is only one entry in it. If there are more than one, each entry is checked to see if it has the right object class for a user or a group, a non-deleted status, and for users, a UID. Entries that do not pass this check are ignored. If the list of multiple entries is reduced to one by this check, processing proceeds. If not, a duplicate or ambiguous directory error is returned."
The one downside I can see with this is that if you run a commadmin purge or similar it could remove the entry (since its marked deleted) - this is something you would need to test.
Regards,
Shane.
# 2
Thanks for the speedy answer!
> Do you mean "objectclass: mailrecipient" or
> "inetmail: yes"? Both accounts have the former so
> wouldn't this have caused confusion with dirsync?
The "inetmail" attribute is left over from an even older installation of Netscape Messaging Server, but our LDAP provisioning tool has never been updated to quit inserting it.
So far as I can tell, the iMS 5.2 system pays that parameter no attention at all, but relies solely on the "objectclass: mailrecipient" to identify mailusers.
Now that we've discovered this problem, it turns out that iMS 5.2 was simply choosing one of the two entries. I've found at least one pair of LDAP entries so far which were equally valid. The iMS 6.3 barfs at that, but iMS 5.2 just picks one.
> The new iMS 6.3 system views both as valid. Is
> there
> some way to set an LDAP filter on an attribute
> which
> will let iMS 6.3 pick out valid email? iMS 5.2 had
> the "local.imta.ugfilter", but iMS 6.3 has nothing
> like that I can find.
>
> Ideally you should be looking at cleaning up the
> duplicate addresses -- so having a one-to-one model
> (one email address per account). Anything else is
> bound to lead to problems in the future.
Thanks, I'm already hard at work on this. Fortunately, despite the many thousands of email recipients in LDAP, only a few hundred have duplicate entries.
I'm still interested in any means of filtering the LDAP query, if anyone knows of a way.
> One thing you may want to try is to add the following
> to the inactive account:
>
> "mailuserstatus: deleted"
I won't be able to add new attributes. Even if our corporate culture weren't super conservative, it'd be a vast production evolution to get those added quickly.
That passage from the Admin Guide looks interesting. I'll check that out to see if it leads to any clues on how to modify the user checks.
Thanks!
Chris
# 3
One of the many bugs that will never be fixed in dirsync is that it did not enforce non-ambiguous mail addresses.Direct LDAP does enforce that, and is one reason we encouraged all 5.2 users to move to Direct LDAP.
6.3 does enforce unique mail addresses, and the provided provisioning tools to, too. However, if you have rolled your own provisioning tool, you may want to add checks for uniqueness of mail, mailAlternateAddress, and mailEquivalentAddress
