Update README

README.md

@@ -53,10 +53,12 @@ In addition to the required POP3 commands ([RFC1939](https://tools.ietf.org/html
   * **SASL PLAIN**
   * **PIPELINING**
 
-Notably missing is the **TOP** extension.
+Notably missing is the **TOP** extension as for now there is no mechanism for retrieving first *n* lines of the message.
 
 #### POP3 command behaviors
 
+All changes to messages like deleting messages or marking messages as seen are stored in storage only in the UPDATE stage (eg. after calling QUIT). Until then the changes are preserved in memory only. This also means that if a message is downloaded but QUIT is not issued then the message does not get marked as *Seen*.
+
 ##### LIST
 
 POP3 listing displays the newest 250 messages in INBOX (configurable)
@@ -67,7 +69,7 @@ Wild Duck uses message `_id` value (24 byte hex) as the unique ID. If a message
 
 ##### RETR
 
-If a messages is downloaded by a client this message gets marked as Seen
+If a messages is downloaded by a client this message gets marked as *Seen*
 
 ##### DELE
 
@@ -106,9 +108,9 @@ Somewhat yes. Even though on some parts Wild Duck is already fast (Wild Duck is
 
 ### How does it work?
 
-Whenever a message is received Wild Duck parses it into a tree-like structure based on the MIME tree and stores this tree to MongoDB. Larger attachments (anything above 50kB) are removed from the tree and stored separately in GridStore. If a message needs to be loaded then Wild Duck fetches the tree structure first, if needed loads attachments from GridStore and then compiles it back into the original RFC822 message. The result should be identical to the original messages unless the original message used unix newlines, these might be partially replaced with windows newlines.
+Whenever a message is received Wild Duck parses it into a tree-like structure based on the MIME tree and stores this tree to MongoDB. Attachments are removed from the tree and stored separately in GridStore. If a message needs to be loaded then Wild Duck fetches the tree structure first and, if needed, loads attachments from GridStore and then compiles it back into the original RFC822 message. The result should be identical to the original messages unless the original message used unix newlines, these might be partially replaced with windows newlines.
 
-Wild Duck tries to keep minimal state for sessions to be able to distribute sessions between different hosts. Whenever a mailbox is opened the entire message list is loaded as an array of UID values. The first UID in the array element points to the message #1 in IMAP, second one points to message #2 etc.
+Wild Duck tries to keep minimal state for sessions (basically just a list of currently known UIDs and latest MODSEQ value) to be able to distribute sessions between different hosts. Whenever a mailbox is opened the entire message list is loaded as an array of UID values. The first UID in the array element points to the message #1 in IMAP, second one points to message #2 etc.
 
 Actual update data (information about new and deleted messages, flag updates and such) is stored to a journal log and an update beacon is propagated through Redis pub/sub whenever something happens. If a session detects that there have been some changes in the current mailbox and it is possible to notify the user about it (eg. a NOOP call was made), journaled log is loaded from the database and applied to the UID array one action at a time. Once all journaled updates have applied then the result should match the latest state. If it is not possible to notify the user (eg a FETCH call was made), then journal log is not loaded and the user continues to see the old state.