Table of Contents

Method Answering

Namespace
MailFathom.Domain.Delivery
Assembly
MailFathom.Domain.dll

Answering(EmailThreadReferences)

Places a message as the answer to one this deployment already holds.

public static OutgoingThreadPlacement Answering(EmailThreadReferences original)

Parameters

original EmailThreadReferences

The threading headers the answered message carried.

Returns

OutgoingThreadPlacement

The placement a composed answer writes, which is None when nothing usable can be written.

Remarks

In-Reply-To is the answered message's own identity and References is its path with that identity appended, which is what RFC 5322 § 3.6.4 asks for and what every client implements. The answered identifier is last because that is where a client looks for the immediate parent.

A message that carried no Message-ID can be answered but cannot be pointed at, so the answer inherits the path it carried and names no parent. That is the honest reading rather than a degraded one: naming an ancestor as the parent would attach the reply to the wrong message in the same conversation.

An identifier that cannot be written into a header is dropped rather than repaired or written through. What arrives here has already been normalized as a parse publishes it, so this drops what remains — an angle bracket, a comma, or whitespace inside the value — which no mail server mints and which would end the header early or split one identifier into two.

Exceptions

ArgumentNullException

Thrown when original is null.