Interface IMailboxWriteSession
- Namespace
- MailFathom.Application.Mail.Mutations
- Assembly
- MailFathom.Application.dll
Changes one folder of a remote mailbox, on behalf of an act the mailbox owner authored.
public interface IMailboxWriteSession : IAsyncDisposable- Inherited Members
Remarks
This is the only type in MailFathom able to change a mailbox, and it is deliberately a different type from IMailboxSession rather than a mode of it. Synchronization, reconciliation, content retrieval, and every MCP tool reach the server through that one, which exposes no operation capable of writing; a refactor therefore cannot give a read path the ability to write, because a read path never holds something that has it.
The surface is closed to exactly the four mutations MailFathom is permitted to perform. There is no method that
sends, replies, or forwards, none that creates, renames, deletes, or subscribes to a folder, and none that writes
any flag other than the \Seen one operation exists for and the \Deleted that removing a message is
made of. Permitting one of those later is a decision to reopen rather than a method to append.
Every operation names what the caller asked for and never how the server was made to do it. Which protocol
extension carried a relocation is a property of the server rather than of the change, so it reaches no caller and no
record above debug detail; a server without RFC 6851 MOVE behaves identically to one with it, from here up.
A relocation and a delete are not atomic on a server that lacks MOVE, and nothing here makes them so. A crash
between the commands leaves the mailbox in a state this session cannot describe, which is why every operation takes
an IMailboxMutationJournal: the caller has written the change down before calling, the session
announces each stage of the sequence as it passes it, and a resumed attempt reads
Stage and continues from there instead of starting over.
Resuming is decided here rather than by the caller because it depends on what the connection advertises, which is this adapter's business and deliberately reaches no layer above. What the caller decides is the one thing the protocol cannot: a mutation whose placement command was issued and never acknowledged never reaches this session at all, because issuing it again would put a second message in the destination folder.
One session is used by one caller at a time and is not safe for concurrent use. It is short-lived by design: it holds the account's single write connection for as long as it is open, so a second caller waits.
Methods
- CopyAsync(EmailOccurrenceId, RemoteFolderPath, IMailboxMutationJournal, CancellationToken)
Puts a second live occurrence of one email into another folder of the same account.
- DeleteAsync(EmailOccurrenceId, IMailboxMutationJournal, CancellationToken)
Removes one email from this session's folder on the server.
- RelocateAsync(EmailOccurrenceId, RemoteFolderPath, IMailboxMutationJournal, CancellationToken)
Moves one email out of this session's folder and into another folder of the same account.
- SetSeenAsync(EmailOccurrenceId, bool, IMailboxMutationJournal, CancellationToken)
Sets or clears the remote
\Seenflag of one email in this session's folder.