A message on Exim's spool consists of two files, whose names are the message id followed by -D and -H, respectively. The data portion of the message is kept in the -D file on its own. The message's `envelope', status, and headers are all kept in the -H file, whose format is described in this chapter. Each of these two files contains the final component of its own name as its first line. This is insurance against disc crashes where the directory is lost but the files themselves are recoverable.
Files whose names end with -J may also be seen in the spool directory. These are journal files, used to record addresses to which the message has been delivered during the course of a delivery run. At the end of the run, the -H file is updated, and the -J file is deleted.
The second line of the header file contains the login id of the process that called Exim to create the file, followed by the numerical uid and gid. For a locally generated message, this is normally the user who sent the message. For an external message, the user is either root or exim.
The third line of the file contains the address of the message's sender as transmitted in the `envelope', contained in angle brackets. In the case of incoming SMTP mail, this is the address given in the MAIL command. For locally generated mail, the sender address is created by Exim from the login of the current user and the configured qualify_domain, except when Exim is called by a trusted user that supplied a sender address via the -f option, or a leading `From' line. The sender address is null if the message is a delivery failure report.
The fourth line contains two numbers. The first is the time that the message was received, in the form supplied by the Unix time() function -- a number of seconds since the start of the epoch. The second number is a count of the number of messages warning of delayed delivery that have been sent to the sender.
There follow a number of lines starting with a hyphen. These can appear in any order, and are omitted when not relevant.
Following the options are those addresses to which the message is not to be delivered. This set of addresses is initialized from the command line when the -t option is used and extract_addresses_remove_arguments is set; otherwise it starts out empty. Whenever a successful delivery is made, the address is added to this set. The addresses are kept internally as a balanced binary tree, and it is a representation of that tree which is written to the spool file. If an address is expanded via an alias or forward file, the original address is added to the tree when deliveries to all its child addresses are completed.
If the tree is empty, there is a single line in the spool file containing just the text `XX'. Otherwise, each line consists of two letters, which are either Y or N, followed by an address. The address is the value for the node of the tree, and the letters indicate whether the node has a left branch and/or a right branch attached to it, respectively. If branches exist, they immediately follow. Here is an example of a three-node tree:
YY darcy@austen.fict.book NN alice@wonderland.fict.book NN editor@thesaurus.ref.book
After the non-recipients tree, there is a list of the message's recipients. This is a simple list, preceded by a count. It includes all the original recipients of the message, including those to whom the message has already been delivered. In the simplest case, the list contains one address per line. For example:
4 editor@thesaurus.ref.book darcy@austen.fict.book rdo@foundation alice@wonderland.fict.book
However, when a child address has been added to the top-level addresses as a result of the use of the one_time option on an aliasfile or forwardfile director, each line is of the following form:
<top-level address> <flags number>,<parent number>,0
The flags at present contain only one bit, which is set for one_time addresses. It indicates that <parent number> is the offset in the recipients list of the original parent of the address. The third number of the trio is for future expansion and is currently always zero. A blank line separates the envelope and status information from the headers which follow. A header may occupy several lines of the file, and to save effort when reading it in, each header is preceded by a number and an identifying character. The number is the number of characters in the header, including any embedded newlines and the terminating newline. The character is one of the following:
<blank> header in which Exim has no special interest B Bcc: header C Cc: header F From: header I Message-id: header P Received: header -- P for `postmark' R Reply-To: header S Sender: header T To: header * replaced or deleted header
Deleted or replaced (rewritten) headers remain in the spool file for debugging purposes. They are not transmitted when the message is delivered. When `Resent-' headers are present, it is those headers that have the appropriate flags. Here is a typical set of headers:
111P Received: by hobbit.fict.book with local (Exim 0.17 #8) id E0tHplY-0000mG-00; Tue, 21 Nov 1995 10:17:32 +0000 049 Message-Id: <E0tHplY-0000mG-00@hobbit.fict.book> 038* X-rewrote-sender: bb@hobbit.fict.book 042* From: Bilbo Baggins <bb@hobbit.fict.book> 049F From: Bilbo Baggins <B.Baggins@hobbit.fict.book> 099* To: alice@wonderland.fict.book, rdo@foundation, darcy@austen.fict.book, editor@thesaurus.ref.book 109T To: alice@wonderland.fict.book, rdo@foundation.fict.book, darcy@austen.fict.book, editor@thesaurus.ref.book 038 Date: Tue, 21 Nov 1995 10:17:32 +0000
The asterisked headers indicate that the envelope sender, From: header, and To: header have been rewritten, the last one because routing expanded the unqualified domain foundation.
Go to the first, previous, next, last section, table of contents.