This is a case study of Lucy reading her mail using a hypothetical recipient MUA, im2000read, that has a "glass TTY" interface much like that of the Unix mailx program. It illustrates the processes involved in recipients reading IM2000 mail. (Of course: A more useful, real, MUA would combine the functions of recipient MUA and originator MUA, allow new mail to be read from multiple recipient accounts concurrently, cache message store connections, and so forth.)
To read her mail, Lucy starts up her recipient MUA. It displays a prompt and waits for a command.
$ im200read Welcome to the IM2000 recipient MUA. Please enter a command. > verbose on [Verbose mode is now on.] >
Lucy has previously bought recipient service from a recipient notification agent hosting company, which provided her with
She has already told her recipient MUA about this, by adding lucy@example.org to its list of "recipient accounts", accompanied by the RNAQP service location and login account information. (Her particular MUA names "recipient accounts" by the mailbox name that the rest of the world uses to send mail notifications to her.)
She now wants to know what new mail people have sent to her. To do this she runs the newmail command against her lucy@example.org recipient account. Behind the scenes, her MUA creates a RNAQP connection to the RNAQP server associated with that recipient account, logs in with the configured authentication information, queries the server for its list of new notifications, and then closes the connection. It then reports the list of new notifications, received from the server, to her.
> newmail lucy@example.org [Connecting to rnaqp.example.org. port 3182 ...] [Logging in as user 32869 ...] [Retrieving notifications ...] [Disconnecting ...] New mail for lucy@example.org is available for retrieval: 0: At 2004-03-26 13:45:16 +0000 from toby on example.net. says 192.0.2.2 1: At 2004-03-29 07:30:18 +0000 from nick on example.net. says 192.0.2.2 2: At 2004-04-01 15:17:01 +0900 from salesman on junkmail.com. says 64.81.204.225 3: At 2004-04-01 19:12:38 +0500 from scamartist on illegal.com. says 64.202.167.129 >
Three message stores (Toby and Nick share a message store.) have notified her notification agent about new messages that they have for her. The dates given in the list are the dates that her recipient notification agent received the notifications, which are not necessarily the dates of the messages themselves.
At this point, she has not yet retrieved any actual messages, and the message stores will continue to remind her notification agent if nothing further is done.
Lucy chooses to read the message from Toby. To do this, she runs the readnew command. She refers to the message by its number in the list of message notifications that her MUA has just downloaded. (Her MUA is a simplistic one, and only reads messages from one recipient account at a time.) Behind the scenes, her MUA creates an MSRAP connection to the example.net. message store, instructs the message store to send no more notifications about the message from Toby, attempts to obtain the message from Toby, and disconnects. (The message store location information and the message identifier used when querying the server were in the notification that her recipient notification agent passed along.) It also adds the notification information for the message to a list of "current" messages that it keeps internally.
> readnew 0 [Connecting to msrap.example.net. port 4753 ...] [Silencing notifications for message with ID 25a8d7f450687235b6c740e96d58ce7e ...] [Reading message with ID 25a8d7f450687235b6c740e96d58ce7e ...] [Disconnecting ...] From: Your mate Toby <toby@example.net> To: My mate Lucy <lucy@example.org> Date: 2004-03-26 13:44:57 +0000 Subject: Yo, Luce! Are you off on your holidays again next week? >
Toby's message store now knows that she has retrieved (and possibly read) the message. If Toby cares to monitor the delivery status of his message to Lucy, he will discover when he next checks that it has been delivered. Lucy's MUA hasn't saved a copy of the message, though, which is why Toby's message store has not been informed that the message need not be retained any longer. Lucy's MUA does, however, remember that this message has not yet been downloaded or discarded. The message is no longer a "new" message and is a "current" message.
Lucy then chooses to save a copy of Nick's message for later (possibly offline) reading. To do this, she runs the savenew command, referring to the message by its number in the list of message notifications (as before) and providing the name of a local mail folder in which she wants the MUA to save the message. Behind the scenes, her MUA creates an MSRAP connection to the example.net. message store once again, cancels notifications about the message from Nick, attempts to obtain the message, signals the message store that the message need no longer be retained, and disconnects.
> savenew 1 nickmail [Connecting to msrap.example.net. port 4753 ...] [Silencing notifications for message with ID 039d7098b708e7547da058c3e984af0a ...] [Reading message with ID 039d7098b708e7547da058c3e984af0a ...] [Unpinning message with ID 039d7098b708e7547da058c3e984af0a ...] [Disconnecting ...] New message 1 saved to folder "nickmail" as message 14. >
Nick's message store now knows that she has retrieved (and possibly read) the message. Since Lucy's MUA has saved the message, it has instructed the message store that it need retain it no longer. Nick's message store is free to delete its copy of the message at any time from this point on.
Lucy isn't interested in the message from the salesman. She decides to refuse it, using the refuse command. Behind the scenes, her MUA makes an MSRAP connection to the junkmail.com. message store, cancels notifications about the message from the salesman, signals the message store that the message need no longer be retained, and disconnects.
> refuse 2 [Connecting to msrap.junkmail.net. port 9797 ...] [Silencing notifications for message with ID 7689a765f37e954f1fd40bc124e08a12 ..] [Unpinning message with ID 7689a765f37e954f1fd40bc124e08a12 ...] [Disconnecting ...] New message 2 refused. >
The salesman's message store has been instructed that Lucy isn't interested in it retaining the message for her, and doesn't want to receive further notifications about it. It also knows that she hasn't retrieved it. A well behaved message store will stop sending notifications and will delete the message.
Of course, the message store is free to ignore her wishes instead. After all, the salesman is paying it, not her. However, Lucy has further weapons at her disposal for such eventualities.
What Lucy does with the fourth message, from the scam artist, exemplifies one of those weapons. He simply won't go away. So Lucy instructs her recipient notification agent to simply discard all further notifications. She could instruct it to ignore notifications about this specific message, which would be appropriate if she believed that the continual pestering were not done at the sender's behest; or instruct it to ignore notifications from this specific sender, which would be appropriate if she believed that the message store were not complicit in annoying her. But she's tried to refuse messages from this message store before, and it has simply ignored her wishes. Obviously the message store owner is in collusion with the scam artist, and in all likelyhood will soon be playing games such as sending notifications about multiple messages or switching sender names. So she instructs her recipient notification agent to simply ignore any further (and current) notifications from this entire message store. (This penalises other users of that message store, of course. But the facts that this weapon exists, is readily available, and will cause users of the message store to leave in droves when they find that everyone ignores their mail, are incentives for message stores to not indulge in such complicity in the first place.)
To do this, she uses the ignore command, providing it with her recipient account and the location of the message store that is to be ignored. Behind the scenes, her MUA creates a RNAQP connection to the RNAQP server associated with her recipient account, logs in with the configured authentication information, tells the server to ignore all notificiations to her from that message store, and then closes the connection.
> ignore to lucy@example.org on illegal.com. [Connecting to rnaqp.example.org. port 3182 ...] [Logging in as user 32869 ...] [Setting filter for message store illegal.com. ...] [Disconnecting ...] >
Lucy has not interacted with the abusive message store. The scam artist's message store will continue to send notifications to her recipient notification agent. However, her recipient notification agent will apply her filtering rule, see that they provide the location of the message store as msrap.illegal.com. (irrespective of where they themselves are actually sent from), and simply discard them. The scam artist's messages will not be read. Lucy won't even know that the scam artist was trying to send mail to her.
The effect of the block is immediate. So, too, were the effects of the instructions to Toby's, Nick's, and (since he turns out to be polite) the salesman's message stores to stop sending notifications. When Lucy looks for new mail again, there are no stored notifications.
> newmail lucy@example.org [Connecting to rnaqp.example.org. port 3182 ...] [Logging in as user 32869 ...] [Retrieving notifications ...] [Disconnecting ...] No new mail for lucy@example.org is available for retrieval. >
Lucy still has mail, though. She has mail that she read, but didn't either discard or save locally, from previous sessions. She also has Toby's message. She sees this when she runs the curmail command. Behind the scenes, her MUA doesn't contact any servers. The list of "current" mail is maintained by her MUA itself (persistently, across sessions), and is added to whenever she silences notifications for but does not "un-pin" a new message.
> curmail lucy@example.org Current mail for lucy@example.org is available for retrieval: 0: At 2004-02-29 09:13:56 +0100 from <jen@example.net> on example.net. said 192.0.2.2 1: At 2004-03-26 13:45:16 +0000 from <toby@example.net> on example.net. said 192.0.2.2 >
To re-read Toby's message, Lucy can issue the readcur command, whose only difference from the readnew command is that it reads messages on the list of "current" mail rather than on the list of "new" mail. Behind the scenes, her MUA repeats exactly what it did with the readnew command.
> readcur 1 [Connecting to msrap.example.net. port 4753 ...] [Silencing notifications for message with ID 25a8d7f450687235b6c740e96d58ce7e ...] [Reading message with ID 25a8d7f450687235b6c740e96d58ce7e ...] [Disconnecting ...] From: Your mate Toby <toby@example.net> To: My mate Lucy <lucy@example.org> Date: 2004-03-26 13:44:57 +0000 Subject: Yo, Luce! Are you off on your holidays again next week? >
Lucy could choose to save Toby's message with the savecur command (analogous to the savenew command). But instead she decides that she doesn't want to keep the message, but wants to discard it. She does this with the discard command. Behind the scenes, her MUA creates an MSRAP connection to the example.net. message store once again, signals the message store that the message from Toby need no longer be retained, and disconnects. It then removes the notification information for the message from its own list of "current" messages.
> discard 1 [Connecting to msrap.example.net. port 4753 ...] [Unpinning message with ID 25a8d7f450687235b6c740e96d58ce7e ...] [Disconnecting ...] Current message 1 discarded. >
Finally, Lucy decides to leave Jen's message on the "current" list and to read the message from Nick that she saved earlier. The former requires no action. To do the latter she uses the readfolder to read the message, which was saved as message 14 in the nickmail folder. Behind the scenes, her MUA doesn't contact any servers, as it is dealing with a message that it has taken sole responsibility for storing.
> readfolder nickmail 14 Recieved: from msrap.example.net by localhost via TCP with MSRAP id 039d7098b708e7547da058c3e984af0a ; 2004-04-01 21:47:19 +0000 From: Nick le Taxi <nick@example.net> To: Lucy <lucy@example.org> Date: 2004-03-29 07:15:37 +0000 Subject: Next month I still have a few tickets left. Do you still want one? >
As part of the process of transferring the message to a local folder, Lucy's MUA has added a trace header. Since IM2000 is a "pull" system, the addition of trace headers during message delivery is the responsibility of the recipient MUAs.
Nick's message store could also have added a trace header recording its reception of the message from Nick's originator MUA when he submitted it. However, it did not, for privacy reasons.