2.1.3 Processing Rules

In this specification, attributes using the original syntax described in section 1.5 are referred to as "attributes" and the rich set of properties described in section 1.5 will be referred to as "properties".

The TNEF stream starts with a signature, a legacy key value, an attribute containing a legacy version number, and an attribute containing the code page used by the encoder for ANSI attributes and properties. After that, the stream is a series of attributes laid out, one after the other – message attributes followed by attachment attributes. The special attributes attMsgProps, attRecipTable, and attAttachment contain the various message and attachment properties. attMsgProps and attAttachment are counted lists; attRecipTable is a counted list of counted lists.

Each attribute is laid out as follows: the level at which it applies (message or attachment), ID, length of the contained data, the data itself, and a simple 16-bit checksum of the bytes comprising the data.

The attMsgProps attribute SHOULD be encoded after all other message attributes, and the attAttachment attribute SHOULD be encoded after all other attachment attributes. Values of encapsulated properties SHOULD be used instead of any conflicting mapped attribute values. Message attributes and properties SHOULD be encoded before attachment attributes and properties.

Each set of attachment attributes MUST begin with the attAttachRendData attribute, as specified in section, followed by any other attributes; attachment properties encoded in the attAttachment attribute, as specified in section, SHOULD be last.