6.1 INTERNET MESSAGE FORMAT (IMF)
Messages are exchanged using Internet message format. As aforementioned, a message body is comprised of multiple parts. There can be a HTML part, a text part and each attachment is a part. Preceeding the body is a set of meta data headers. The headers of interest are as follows:-
| Message-ID: | According to accepted internet standards, the message id should be "globally unique" and contain "a component of the sender's address". To this end, message ids are commonly of the form "XXX@domain_name", where the domain is that of the sender adress and XXX is a unique identifier generated by the "source machine" on the basis of IP address, time and date and often a sequence number for good measure. Note that message ids are always enclosed in angle brackets which are not part of the id. Note also that message ids are not compulsoty (see note 1 below). |
| From: | This is the address of the sender and is always enclosed in angle brackets e.g. <john.doe@mydomain.com>. Often this address is preceeded by a string, taken to be the real name of the sender e.g. "John Doe <john.doe@mydomain.com>". The real name is usually that announced in the mail client. |
| Sender: | This is rarely used (see note 2). |
| Return-Path: | This states where non-delivery and other such notices should be sent, so it is not treated as the de-facto sender address (see note 2). |
| Reply-To: | A reply-to address is added when the message originator wants any replies to go to that particular email address rather than the one in the From: address (see note 2). |
| Subject: | Message subject, can be blank |
| To: | Primary recipients |
| Cc: | Carbon copy |
| Bcc: | Blind carbon copy |
| Date: | Date and time according to originator (date and and time when message first enters the system) |
Notes
Note 1: Running a server carries legal responsibilities and administrators are strongly advised to avail themselves the ability locate messages by the message-id. In the event of a complaint, the formal ids of offending messages can then be quoted. Internet message format has other related message headers. In a reply there will be an "In-reply-to:" header and in a reply to a reply there will be a "References:" header. As replies go back and forth, more refereces headers are added, with each containing the id of the message it is a reply to. It is important that mail servers adhere to this convention as it is often necessary to retrieve the entire conversation. Epistula ensures all outgoing messages are supplied with a message-id.
Note 2: According to www.iana.org, The From, Sender and Reply-To headers are in accordance with RFC 5322, which states the following:-
From: is a list of one or more mailboxes.
Sender: is only used to state which mailbox applies if multiple mailboxes appear in From:
Reply-To: is an address list.
In practice, the Sender header almost never appears and the From, Reply-To and Return-Path headers always contain a single email address. By convention, the From address is assumed to be the proper sender address and is shown as such in the mail client, while any replies are sent to the Reply-To address. If the From and Reply-To addresses differ, the question of which is best arises. Users may see the From address in the mail client and use that to originate a new message to the sender, rather than simply replying to any of the sender's messages. With Epistula, the From and Reply-To addresses in outgoing messages will only differ when the user is acting as a group or department member. Otherwise the two addresses will always be the same.
Short Form Messages
Epistula stores a single copy of each incoming and outgoing message in a central repository, which assigns 32-bit ids to them. For each there is a FROM, TO, SUBJECT, SIZE, DATE and TIME of recipt Epistula, plus boolean flags which indicate priority and the presence of attachments - so basically what fields are shown in the folder listings in the webmail pages and the typical email client. These records are known as 'Short Form' messages. The 'whole form' (IMF) messages are stored as binaries in a separate binary datum repository. 32-bit ids are assined to these and are stored in the short form messages.
Whole form messages are retrieved only when messages are opened in webmail or when they are sent to a POP3 client. These operations will only involve a single whole form message in respect of any given user's actions. By contrast, multiple short form message are retrieved when users select folders as they browse messages in their mailbox. Efficient operation depends on the short form messages being stored in order.
Correspondents
To this end and to aid operation of automatic folders, short form messages are ordered by correspondent which depends on message direction. For incoming messages, the correspondent will be the sender. For outgoing messages the correspondent will be the principle recipient.