Remember I was badgering you to create a replacement spec for
the FTS specs?  Well I've already done the job.  The file is
available for FREQ as FTS-0501.002, and here it is...

Document: FTS-0501
Version:  002
Date:     1996-02-10
Title:    Mail packet format
Current Author: Paul Edwards
Current Addresses: 3:711/934{at}fidonet
Authors: Paul Edwards 3:711/934{at}fidonet
         Leonard Erickson 1:105/51{at}fidonet
Copyright: This document is released to the public domain


NOTE
----

If you intend to follow this proposal you must implement all of
it.  If you have any questions as to how certain sentences are
to be interpreted, do not hesitate to contact the author of this
document, whose address is at the top of this document.


BODY
----

This file documents the format of files that are received by
a mailer as described by the FTSCD specs.

Terms:

byte - a binary number from 0 to 255 stored in 8 bits.

integer - a 2-byte numeric data type, stored in little-endian format, 
ie low byte then high byte.  The values specified are to be treated
as unsigned integers, so there are no complications as to whether
negative numbers are represented as 2's complement, sign-magnitude
etc.  These are straight binary values.

bytes - a sequence of bytes


A file will start off with a packet header, which is 58 bytes 
long.  The format of the packet header is:


Offset
Dec  Hex  Length   Data Type   Contents
 0    0    2       integer     originating node
 2    2    2       integer     destination node
 4    4    2       integer     4-digit year of packet creation date
 6    6    2       integer     month component of packet creation date (0-11)
 8    8    2       integer     day component of packet creation date (1-31)
10    A    2       integer     hour (0-23)
12    B    2       integer     minutes (0-59)
14    D    2       integer     seconds (0-59)
16   10    2       integer     baud (useless)
18   12    2       integer     constant value of 2, the packet type
20   14    2       integer     originating net
22   16    2       integer     destination net
24   18    1       byte        product code (optional)
25   19    1       byte        serial number (optional)
26   1A    8       bytes       password (optional)
34   22    2       integer     originating zone
36   24    2       integer     destination zone

Then comes one of the following...

Type 2...

38   26   20       bytes       filler (must be set to NULs if *generating*,
                               could be anything on *reading*)

Extend Type 2+ (optional)...

40   28    2       integer     inverted capability word
42   2A    2       integer     expanded product code?
44   2C    2       integer     capability word
46   2E    2       integer     originating zone (optional)
48   30    2       integer     destination zone (optional)
50   32    2       integer     originating point (optional)
52   34    2       integer     destination point (optional)
54   36    4       bytes       product-specific field


Notes:

Any unused bytes in the password field must be NUL-filled.  The
password is normally completely NUL, and is there mainly for use
by non-mailprocessors.

Any optional fields must be set to NULs when generating (if not
used), but should not be expected to be NULs when reading.

The defined range of zone, net, node and point are 0-32767.  In
addition, net and node may have the value 0xFFFF, which represents
"-1".

The 1-byte product code is used as follows:
0x00 should be used by new programs.  For historical reasons,
most existing programs use codes from 0x00-0xFE.  0xFF is 
strictly reserved.


After the packet header comes 0 or more messages, followed by two
NUL characters, which signifies the end of the packet.  A message
will never start with two NUL characters.

The messages are stored as follows:

First there is a 14-byte message header, then there are some
variable-length NUL-terminated strings, then there is a text
block, which is also NUL-terminated.

In general, messages look like this:

1. message header
2. area line (if echomail)
3. optional ctrl-a control lines
4. user text, optionally interspersed with intra-text control lines
5. optional ctrl-a control lines
6. tear line (if echomail)
7. origin line (if echomail)
8. seen-by lines (if echomail)
9. optional ctrl-a control lines

The format of the fixed message header is as follows:

Offset
Dec  Hex  Length   Data Type   Contents
 0    0   2        integer     constant value of 2, the message type
 2    2   2        integer     originating node
 4    4   2        integer     destination node
 6    6   2        integer     originating net
 8    8   2        integer     destination net
10    A   2        integer     attributes
12    C   2        integer     cost (useless)

The attributes are a set of 16 bits, which have the following
meaning when set:

0x0001 - message is private
0x0002 - message to be crashed directly to destination
0x0004 - message has been read by recipient
0x0008 - message has been sent
0x0010 - subject specifies a file that accompanies message
0x0020 - message is in-transit
0x0040 - message destination is unknown (orphaned)
0x0080 - delete message after sending it
0x0100 - message was written locally
0x0200 - message is to be placed on hold to be picked up
0x0400 - officially unused, but has several unofficial uses
0x0800 - subject specifies name of file to file-request
0x1000 - return receipt requested
0x2000 - message is a return receipt
0x4000 - an audit trail is requested
0x8000 - subject specifies a file update request

Then comes a date string, which is always 20-bytes in length,
including the NUL terminator.  It is suggested you treat this
as a variable length string, for historical reasons.

The date string can take two formats, as examples

1. "01 Oct 95  20:31:59"
2. "Sun  1 Oct 95 20:31"

It is suggested that new programs always generate the first format,
but accept either format.

Note:

1. The day in the first format has values from "01" to
"31" with a
leading zero.
2. The day in the second format has values from " 1" to
"31", with
no leading zero.
3. In both formats, the hours, minutes, seconds and year are zero
filled.
4. The range of days-of-weeks for the second format is "Mon",
"Tue",
"Wed" "Thu", "Fri", "Sat",
"Sun".  No language translations are
allowed.
5. The range of month for both formats is "Jan", "Feb",
"Mar", "Apr",
"May", "Jun", "Jul", "Aug",
"Sep", "Oct", "Nov", "Dec".  No
language
translations are allowed.
6. All the characters in the date are the corresponding hex values
from ISO 646 (same as ASCII).
7. Only 19 bytes are shown in the above formats, the NUL terminator
makes it 20 bytes total.

Following the date comes the "To name", which is a maximum of 36
characters including a terminating NUL.  There is no restriction
on the content of this field, although it is suggested that
implementations not put any ISO-646 defined control characters in
this field, or the following 2 fields.

After the "To name" field comes the "From name" field,
which follows
the same rules as the "To name".

The next field is the "Subject" field, which follows the same rules
as stated above, except that it is a maximum of 72 characters, not
36.

After the "Subject" comes a text block, which has a mixture of
control information and message text in it.  A NUL character
terminates the text block, thus NULs may not be imbedded in the
text block. 

A lot of control information is present in this text block, via
control lines.  Control lines in general follow the following
format: 

^AKEYWORD:data

Where ^A is x'01', KEYWORD is any number of keywords, some defined
in this document, some not, and the data is a keyword-dependent
field, which may be nothing.  The data may or may not contain a
leading space.  It is highly recommended that if data follows the
keyword, a leading space is inserted, otherwise no leading space
is inserted.   can be either one of  or
.  The
use of  for  is an obsolescent feature that may
be removed in a future version of this document.  For x'01' to
introduce a control line, it must be the very first character in
the text block, or else follow a .  The KEYWORD is 
always comprised of printable ISO-646 characters.

The following control lines have meanings as follows:


o INTL  

This control line is an exception in that it does not have a ":" 
after the keyword.  INTL is used to send inter-zone messages,
although it may also be used in intra-zone messages, although it
is not required to be present.


o FMPT 

This control line is an exception in that it does not have a ":"
after the keyword.  It is used to specify the point number of
the originating node.  It is only to be used for messages that
are from points.


o TOPT 

This control line is an exception in that it does not have a ":"
after the keyword.  It is used to specify the point number of
the originating node.


o MSGID:  

The MSGID is an optional control line which is used to uniquely
define a message.  The  field is the originating address
of the sender, not necessarly an address in the current network.
The  is a sequence of exactly 8 hex digits.  A node that
generates MSGID's guarantees that no two messages leaving his
node will contain a  that is the same as the  on
another message that was sent from this node in the last 3 years.


o REPLY:  

The REPLY is an optional control line which is used to uniquely
define which message is being replied to.  The  and
 are both copied from the original message's MSGID
control line.


o AREA:

If the very first line of the text block starts with
"AREA:", the message is an echomail message, in the
conference with name .  On receipt of an echomail message,
a node will normally export this message to 0 or more destinations,
by sending multiple "netmail" messages to these destinations, with
the same "AREA" information.  This control line is an exception in
that it does not start with a ctrl-A.


o --- 

This control line, known as the "tear line" appears in echomail messages.
 is normally the name of the program which wrote the echomail
control lines.  A tearline may be empty, in which case it is just
"---".  It is unknown whether this line is required in echomail or
not.  It is suggested that new programs always generate a tearline,
but accept a message with or without one.  This control line is an 
exception in that it does not start with a ctrl-A.


 
This control line, known as the "origin line" appears in echomail messages.
The address should be the address of the originating system in the 
current network.  It should be a 4D address, although new programs 
should accept 2D and 3D addresses also.  This control line is required 
for all echomail messages, although it is suggested that new programs 
allow a message to be processed that doesn't have one, or doesn't 
have an address in it.  This control line is an exception in that it 
does not start with a ctrl-A.


o SEEN-BY: 

The SEEN-BY control lines are used in echomail to tell which systems within 
the current zone, this particular message has been sent to.  They are
an exception in that they do not start with a ctrl-A.  An inter-zone
message may have the SEEN-BYs stripped before crossing the boundary,
except for both it's own address and the recipient's address.  The
inter-zone recipient may then strip all SEEN-BYs except for it's
own address, in case the sender failed to do so, plus this way it
picks up the one extra address.  The SEEN-BYs should be sorted in
numerical order.  The SEEN-BYs should always start off with
a net/node pair, although new programs should accept data starting
with a node, so long as it is not the very first line.  An example
set of SEEN-BY lines would be:

o SEEN-BY: 711/444 555 666 712/111
o SEEN-BY: 712/222 333

The SEEN-BY line from the first S to the last number before the newline,
inclusive, should not exceed 69 characters in length when generating
them (at least for new applications), but new implementations should 
accept at least 79 characters for this, although it is suggested that 
the SEEN-BY block be treated as a single buffer avoiding any line length 
limitations.  The SEEN-BYs must be in a single block.  Applications must 
be able to handle a minimum of 450 addresses in total.


o PATH: 

The PATH lines are used in echomail to tell which net/nodes a message
travelled through to arrive at your node.  The addresses are in the
same format as the SEEN-BY.  However, the addresses are not stripped
at a zone boundary.  The length of the PATH line, follows the same
rules as the SEEN-BY, with 'P' substituted for 'S'.
@EOT:

---