Class MailOutboxDelivery

Namespace

MailFathom.Application.Mail.Delivery.Outbox

Assembly

MailFathom.Application.dll

Carries one claimed send from the record that describes it to the ending that settles it.

public sealed class MailOutboxDelivery

Inheritance

object

MailOutboxDelivery

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

The whole sequence is arranged around one instant: the moment the message body may begin to reach a submission server. Everything before it is repeatable at no cost, because nothing has left the deployment; everything after it is not, because a message transmitted twice is a second copy in somebody's mailbox and cannot be withdrawn. So the record is moved to TransmissionBegun and committed before the envelope is offered, and a process that dies anywhere past that point leaves a statement that says the outcome is unknown.

Being pessimistic there would strand every send whose server was briefly unreachable, so the attempt earns the record back where it can prove it. A submission server is offered the body only once it has accepted at least one address, so an envelope that accepted nobody is proof that nothing was transmitted — and that is the one case in which the record is taken back to Recorded and attempted again.

A server that answered settles the question by itself, whatever it said: an acceptance means the message was taken and either refusal means it was not, so neither needs the ledger. The ledger decides only where the server said nothing at all.

A transmission the server acknowledged does not always finish the send. An address it refused for now is one the next attempt offers again, and that attempt transmits to the outstanding addresses alone, so nobody receives the message twice and nobody is quietly dropped from it. The send is Sent only once nothing is outstanding, which is what that stage has always meant.

Nothing here retries. One attempt reaches the server once, the delivery dependency's own pipeline repeats what is safe to repeat inside that attempt, and when the next attempt happens is a jittered backoff written onto the record. A loop here would be a second retry layer around the same submission, which is the storm both of those are shaped to avoid.

Constructors

MailOutboxDelivery(IMailDeliverySessionFactory, IOutgoingEmailStore, IEmailContentStore, IOutgoingSenderIdentityReader, OptimisticConcurrencyRetryPolicy, MailOutboxSettings, TimeProvider)

Initializes the attempt from the session it submits through and the record it settles.

Methods

DeliverAsync(ClaimedOutgoingEmail, MailTransportSecurityPolicy, CancellationToken)

Attempts one claimed send and records what became of it.