Constructor NamedRecipientResolver

Namespace

MailFathom.Application.Mail.Delivery.Addressing

Assembly

MailFathom.Application.dll

NamedRecipientResolver(IContactDirectory)

Turns the people an author named into the addresses a message is composed and offered to.

public NamedRecipientResolver(IContactDirectory contacts)

Parameters

contacts IContactDirectory

Reads the book a named contact is resolved against.

Remarks

This is the single place a contact becomes a recipient, and it sits between authoring and composition on the way to the outgoing record — which is what makes naming a person a convenience rather than a second route out of the deployment. Everything the record creation point applies to a recipient applies to a resolved one: the address it produces is an ordinary address from that moment on, indistinguishable from one an author wrote down, so whatever bounds, policy, and ceilings hold for a literal address hold for this one without being restated here.

A lookup either finds exactly one contact or it does not. Nothing ranks candidates, nothing prefers the most recently written down, and nothing falls back to a near match: a recipient chosen that way is a message delivered to somebody nobody named, which is a worse outcome than the send being refused.

It reads the book and writes nothing. Addressing somebody is not a fact about them, so no contact is created, amended, or promoted by being written to.

It asks for no permission of its own, and that is deliberate rather than an omission. Every use case above it is reached under a principal — a caller holding a grant, or the process running work nobody requested — and only the first of those can hold one at all, so a grant demanded here would refuse a rule addressing a contact rather than authorize anything. Whether a caller may name people out of the book is therefore the boundary's question, asked where the caller is known and beside the grant that lets it send at all.