Stumped by Recipient user name not unique issue

HCL Domino Domino Forum
1

I’ve got a mail-in database, with the internet address of info@.co.ukMessages are delivered to it fine internally, if addressed to the full name, however messages sent via the internet are bounced to the sender.

The bounce is:

"Your message

Subject: Test from an external source

was not delivered to:

info.ppl@.co.nz

because:

Recipient user name info (info@.co.uk) not unique. Several matches found in Domino Directory.

Final-Recipient: rfc822;info.ppl@.co.nz

Action: failed

Status: 5.0.0

Diagnostic-Code: X-Notes; Recipient user name info (info@.co.uk) not unique. Several matches found in Domino Directory."

It appears that the info.ppl@.co.nz is a Person Document which has a forwarder on it. The name for that ‘Person’ is “info ppl” (My quote marks).

Not sure why they’ve done this, but I’m not in a position at the moment to get hold of our affliates in New Zealand to get them to fix this entry.

When I make the change on our SMTP gateway and Mailserver where the Mail-in database is located for the Address Lookup to be Fullname only, it changed subtlely to be:

"Your message

Subject: Test from an external source

was not delivered to:

info@.co.uk <-----Address changes here from earlier one

because:

Recipient user name info (info@.co.uk) not unique. Several matches found in Domino Directory.

Final-Recipient: rfc822;info.ppl@.co.nz

Action: failed

Status: 5.0.0

Diagnostic-Code: X-Notes; Recipient user name info (info@.co.uk) not unique. Several matches found in Domino Directory."

I’ve had to roll back the changes to both servers at the moment, as by having the Fullname only option on the router, means that only the internet address specified on the Person Document works. i.e. Paul.Dakers-Black@.co.uk works fine, but paul_dakers-black@.co.uk fails, saying they’re not listed in the Domino Directory. As we’ve got users who use both the underscore and the period as a separator, this bit is a show stopper.

I can’t seem to understand why the Router is having such an issue delivering to an explicit address, and why it’s picking this Person Doc over my mail-in db entry.

Does anyone have any ideas?

2

Subject: Stumped by Recipient user name not unique issue

keep in mind, that any ‘info’ entry in your nab might be a info@.co.uk if its not explicite defined in the nab (as you found: the fullname option)

So are you sure there is only one ‘info’ document in the nab? And aren’t there any other cascaded adress books?

There MUST be a user like ‘Info PPL’ which does not have a unique internet address specified

3

Subject: RE: Stumped by Recipient user name not unique issue

Hi Daniel,

There certainly is a number of other mail-in dbs with the name Info in them. They have their internet address of info@.com or whatever.

There is also a couple of other Person documents with the Lastname of Info, and the Internet Address of info@.com etc.

As I’ve said, there is a Person Document for this Info PPL, with the Firstname of Info and Lastname of PPL. It does have an Internet Address specified in the Mail section of the Person document.

I’m not quite sure what you’re getting at? Let me know if I’m missing a trick :slight_smile:

4

Subject: RE: Stumped by Recipient user name not unique issue

as I understand you don’t have the fullname-feature enabled but localpart only and is it correct that the problem only appeared after adding an entry (mailin) with only ‘info’?

without the new mail-in entry i persume the other mails addressed to ‘info@.co.uk’ were revoced too.

you cannot use a part of a name if it already exists within another entry with ‘localpart’ enabled.

read the help for the address lookup field in the config document:

“Determines how recipients are found in the directory. Fullname requires a unique case insensitive exact match of the complete address in the $Users view. LocalPart requires a unique case insensitive match of the part of the address before the @. LocalPart matching matches periods and underscores in the address with spaces in the directory.”

the $users-view uses different variations (Fullname,Firstname,Lastname,internetaddress…) and looks them up with the ‘localpart’ (which is without the domain)

did you also tried ‘fullname then local part’? usually if it finds an exact match it does not search further.

is ‘exhaustive check’ disabled?

if that doesn’t work, you have to change info@.co.uk to something like global.info@.co.uk.

if needed adjust the names that need additional or other internet addresses (add desired additional internetadresses to the username field)

5

Subject: RE: Stumped by Recipient user name not unique issue

Thanks for your response Daniel.

We did already have ‘Fullname then LocalPart’. The mail-in DB entry had existed for quite a while, and no changes had been made recently to either those particular servers or the Mail-in DB entry, so I’ve no idea what it was that stopped it working.

I have fixed it however. All I did was to change the name of the Mail-in DB to be ‘Info <ourcompanyname’, from it being just ‘Info’

Immediately that started working. What confuses me is that there about 5 or 6 more Mail-in DB entries, also having the name of ‘Info’ for our other affliates in the same Domino Directory. I’m not sure if they are working or not.

What confuses me is that the info@.co.uk is absolutely unique in the $users view, and we already had ‘Fullname then LocalPart’ set on our servers, so I’ve no idea why it was missing that and going looking for another match.

At least it’s working now though. Just need to fix a shared mailbox with multiple (1400+) private folders that I need to unpick somehow!

6

Subject: Stumped by Recipient user name not unique issue

If the names.nsf is full text searched- do a search for info@.co.uk -you will find, that in fact, there is more than one entry- happened w/ us. I had to modify the others.Tom

7

Subject: RE: Stumped by Recipient user name not unique issue

Hi Thomas,

Many thanks for the response. I’m afraid that if I search the $users view on a fully indexed Address book it’s the only match. It seems to be this co.nz address causing the issue somehow.