Battletech Live

Online, Turn-Based Battletech – Development Logs

How should a mail server work?

I spent 20+ hours this weekend working on the email system.  While I got quite a bit accomplished, I ended the weekend with more questions than I had to begin with.  At least for testing purposes, I have the system set up able to compose and send mail, deliver the message and put a message in the outbox or sent items of the sender although the process that I have in place seems way too complicated.  I want to take a step back, analyze things and put together a sequence that makes sense.  The following is my logic, which may or may not be flawed, about how a mail server should work.

  1. When a user composes an email, they supply a title and body and designate who that message is going to be sent to.  If the message is sent, one copy of the message will exist for each intended recipient.  Another copy of the message also exists in the senders mailbox, residing in one of several possible folders such as Outbox, Sent Items or Deleted Items, depending on how the user treats the message.
  2. When each recipient receives the email, it appears in their inbox.  At this point, the user is free to move the message to the folder of their choosing.

The above notes are a somewhat simplified representation of what happens when sending email.  In reality, what takes place is far more complicated:

  1. The composer supplies the title and body of the message and at least one recipient.  Recipient options are To, Cc and Bcc.  For the most part, To and CC are handled the same, the differences existing in the header of the message.  Bcc also receives the message but does not appear in the header of the message and is thereby invisible to other recipients.
    1. A successful email message must have all three components, subject, body and recipient.  The send button should be disabled until all three components are satisfied.  The send button should also be disabled if the only recipient is a Bcc, discouraging anonymous email.
    2. If the sender decides not to send the message, they should be asked if they wish to store it in Drafts, to be sent at a later time.
      1. If the sender says yes, the message is pushed to the server and stored in such a way as to prevent it’s immediate delivery, perhaps a field named Draft that contains a record of who the message is to be sent to.
      2. If the user says no, the form is reset and the user is returned to their previous screen.
    3. If the user is satisfied with the composition of the message and selects to send it, the message specific information is pushed to the server.  If the message is sent to multiple people, the message is essentially replicated and stored once for each recipient, plus once for the sender.
      1. For the outbound message, a number of fields are needed:
        1. The name, id or address of the sender.
        2. The name, id or address of the recipient.
        3. The message subject.
        4. The message body.
        5. A generated timestamp for when the message was sent.
        6. A field to store a value for the messages present location, initially set as inbox.
        7. A field to indicate the timestamp for when the message appeared in the recipients inbox.
        8. A flag to indicate whether or not it should be displayed as bold for unread or plain for read.
        9. Indicate whether the message was sent as To, Cc or Bcc.
      2. The message that appears in the sender’s outbox is similar, but has some differences.
        1. The server should again indicate who sent the message.
        2. The message recipient.
        3. The message subject.
        4. The message body.
        5. Timestamp for when the message was sent.
        6. A text field that holds a collection for who it was sent to, or possibly three fields, one for each possible state.
        7. The folder in which the message currently exists.
    4. Upon sending, all copies of this message should be stamped with the same message ID so that information from one can be referenced through the others.  For example, if a message is sent to four people, each of those four people gets a copy of the message and each copy contains a field to indicate when it was delivered and whether or not it has been read.  Because there are four recipients and only one sender, and because the total number of recipients is indeterminate, the copy that appears in the senders sent items cannot immediately reflect whether or not a message has been delivered.  Instead, there should be a way that the sender can select to view more information about the message, at which point, the server goes out and collects information related to the current message id.  It finds five items with the id, cross-references the information and displays it in a form easy to understand.  For example, three have been delivered and when, and of those three, two have been read and one is still unread.
    5. So, when a message is delivered, the message on the server is updated to list a timestamp for when it was delivered and on the host machine, appears in bold.  When the message is read, the server copy is updated again and the host machine now displays as plain text.  If the message is moved to a saved folder, the server updates the message to indicate the change, as does delete.  The process works similarly for the sender’s copy.

I don’t know if I’ve overlooked anything or not.


April 13, 2009 - Posted by | Project Development

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: