I think there already exists a notes.ini for this, called DPABRemoveRule. This in combination with DPABRemoveRuleSetting=1 should make it possible to exclude internal names.

See Wiki for more information under the Recent Contacts Faq:
{ Link }

Interesting read... Especialy as that seems to be the only webpage that mentions this settings :-/

Anyway, after reading it, I think this won't work because my groupnames have no common substring (groups are "group" not "group/domain") and even if, this substring might remove too much.

I see the problem but I'd rather see a fix that updates local recent contacts when they originate from the Domino Directory.
Especially because IBM itself promotes adding those contacts to the PAB at various times, e.g. to have them available on Traveler devices.

The notes.ini setting does not fully solve the problem. I had a user at one of our customers that addressed a mail wrongly in the copy to field (used to spaces in the name). All receivers then got a wrong address in their recent contacts, that have made a lot of trouble to us because the address looks correct. Also this is not possible to solve with the above rule, since the policy document removes double spaces I enter in the address.

The recent contacts is a good function, but should be improved to make it easier to remove wrong addresses via policy and also update local contacts with those from the domino directory.

Why make it a Notes.ini setting? It's easier if it could be se in the Contact profile document (where you presently can deselect recent contacts)

In Notes 8.5.3, you now have much more capability in Recent Contacts.

Fred's problem with the CC field can be avoided by choosing in the Contacs preferences to not add recipients in the CC field (or in the ini with DisableDPABCCProcessing=1) or it can be pumped up to only allow senders to be added to recent contacts (a choice in preferences or set in ini as DisableDPABCCandToProcessing=1).

My client site uses 8.5.2, so we can only get DisableDPABCCProcessing. I think that 852FP3 might allow the tighter restriction, but as our deployment is already underway, we won't be going there.