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
originalEmailThreadReferencesThe 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
originalis null.