This is a case study of Bill sending a message to Ben using a hypothetical originator MUA, im2000send, that has a "glass TTY" interface much like that of the Unix mailx program. It illustrates the processes involved in originators writing IM2000 mail. (Of course: A more useful, real, MUA would combine the functions of originator MUA and recipient MUA, cache message store connections, automatically check the delivery status of previously submitted messages, provide a better message composition interface, and so forth.)
To write his mail, Bill starts up his originator MUA. It displays a prompt and waits for a command.
$ im200send Welcome to the IM2000 originator MUA. Please enter a command. > verbose on [Verbose mode is now on.] >
Bill has previously bought originator service from a message store hosting company, which provided him with
Notice that Bill does not obtain a mailbox name from the message store hosting company. His mailbox name is where he wants mail to him to be addressed, and so is provided to him by the company that hosts his recipient notification agent. He uses it in the author headers of the message. Furthermore, IM2000 has no concept of "returning a message to its sender" (In IM2000, messages stay with their senders.) and the message location information (that will always be present because otherwise recipients would not know where to download a message from) contained in a message notification provides the "source" information of the message envelope, so IM2000 has no requirement for an actual mailbox name as an envelope sender.
Bill has already told his originator MUA about his message store hosting service account, by adding to his originator MUA's list of "originator accounts" an account with the MSOAP service location and login account information. His originator MUA allows him to refer to originator accounts by arbitrary names (that are invisible, and of no concern, to the rest of the world). He has named this account bill-at-flowerpot1.
To compose a message, Bill first selects an originator account with the account command.
> account bill-at-flowerpot1 [Account "bill-at-flowerpot1" selected. MSOAP server is msoap.flowerpot1.org.:7530.] >
Bill's originator MUA allows him to explicitly set the envelope recipients, before composing the message itself. Bill's message is going to his friend Ben, whose recipient notification mailbox name is ben@flowerpot2.org., so he uses the personalto command to specify that mailbox.
> personalto ben@flowerpot2.org. [Recipient 1 is <ben@flowerpot2.org>.] >
To, similarly, address the message to a mailing list Bill would use a listto command, specifying the name of one of the mailing lists to which his originator MUA has a "write subscription". Bill doesn't want his message sent to a mailing list. But he does want to add more recipients, so he uses the personalto command again.
> personalto weed@graden.org [Recipient 2 is <weed@graden.org>.] > personalto weeed@garden.org [Recipient 3 is <weeed@garden.org>.] > personalto weed@garden.org [Recipient 4 is <weed@garden.org>.] > personalto lucy@example.org [Recipient 5 is <lucy@example.org>.] >
Bill now composes the body of the message. As a convenience, Bill's originator MUA allows other, extra, information to be held for each originator account. One such piece of information is the default From: mailbox, which Bill has previously configured to be bill@flowerpot1.org.. When Bill uses the edit command to enter the actual message text, his MUA helpfully has already created a From: header from the originator account information and a To: header from the recipient list. Bill chooses to accept these defaults without change, and enters a Subject: header and the message body.
> verbose off > edit From: Bill <bill@flowerpot1.org> To: <ben@flowerpot2.org>, <weed@graden.org>, <weeed@garden.org>, <weed@garden.org>, <lucy@example.org> Subject: Weed Flobbadobbadob ? . >
All that remains is for Bill to actually submit the message to the message store, which he does with the submit command. Behind the scenes, his MUA makes an MSOAP connection to his message store, logs on using the configured authentication information, submits the message, and closes the connection.
> verbose on [Verbose mode is now on.] > submit [Connecting to msoap.example.net. port 7530 ...] [Logging in as user bill37 ...] [Sending envelope ...] [Sending message ...] [Remembering ID ...] [Disconnecting ...] Message saved as message 15 and submitted with ID 4378a523c76d0e38b5a4d7e932faf638. >
The ID returned from the message store can be used by Bill to cancel his message or to track its delivery status. Bill has configured his originator MUA to save local copies of the messages that he sends in a outbox. Along with the message, it saves the tracking/cancellation ID returned from the message store, so that when tracking or cancelling this message he can simply refer to that message number rather than have to remember the ID himself.
The message store begins to send regular message notifications to all of the recipients. Lucy sees the notification and decides to refuse the message. Ben sees the notification and reads the message, leaving it in his list of "current" messages and not transferring it to his recipient MUA's own mail folders. Unfortunately, Bill has been a bit slapdash, and has mis-spelled Weed's mailbox name two out of three times. The domain graden.org. doesn't have an RNASP server for receiving notifications (because it simply doesn't host mailboxes), and the garden.org RNASP server is replying that it has no mailbox with the local part weeed.
To track the delivery status of a message, Bill uses the status command. Behind the scenes, his MUA makes an MSOAP connection to his message store, logs on using the configured authentication information, queries the message delivery status, and closes the connection.
> status 15 [Connecting to msoap.example.net. port 7530 ...] [Logging in as user bill37 ...] [Querying status of 4378a523c76d0e38b5a4d7e932faf638 ...] [Disconnecting ...] Message 15 status: Recipient 1 <ben@flowerpot2.org>: current (silenced, read, pinned) Recipient 2 <weed@graden.org>: undeliverable (no RNASP server, unread, pinned) Recipient 3 <weeed@garden.org>: undeliverable (no such name, unread, pinned) Recipient 4 <weed@garden.org>: new (notifying, unread, pinned) Recipient 5 <lucy@example.org>: refused (silenced, unread, unpinned) >