Exchange Server 2003 goes into Extended Support on 4/14/2009.
Details on our lifecycle policy for Exchange 2003 can be found at https://support.microsoft.com/lifecycle/?LN=en-us&p1=1773&x=11&y=9

Outlook 2003 goes into Extended Support on 4/14/2009.
https://support.microsoft.com/lifecycle/?p1=2520

The Rule.ExecutionOrder property could be used to assign priority to rules. Rules.Item(1) represents a rule with ExecutionOrder being 1, Rules.Item(2) represents a rule with ExecutionOrder being 2, and Rules.Item(Rules.Count) represents the rule with ExecutionOrder being Rules.Count.
https://msdn.microsoft.com/en-us/library/bb176165.aspx

The below VBA script changes the Execution order of the 2nd rule whose execution order is 2nd to last.
Whenever the order for the rule x changed to x+n, all the rules from x+1 till x+n is shifted up.

E.g. If there are 5 rules and the 2nd rule whose Execution order is 2nd is changed to 5:
Rule 3 execution order is changed to 2
Rule 4 execution order is changed to 3
Rule 5 execution order is changed to 4
Rule 2 execution order is changed to 5

Sub CreateRule()
    Dim colRules As Outlook.Rules
    Dim oRule As Outlook.Rule
    Dim colRuleActions As Outlook.RuleActions
    Dim oMoveRuleAction As Outlook.MoveOrCopyRuleAction
    Dim oFromCondition As Outlook.ToOrFromRuleCondition
    Dim oExceptSubject As Outlook.TextRuleCondition
    Dim oInbox As Outlook.Folder
    Dim oMoveTarget As Outlook.Folder
    Dim intCounter As Integer
    Dim oRuleCount As Integer 

    Set oInbox = Application.Session.GetDefaultFolder(olFolderInbox)
    'Get Rules from Session.DefaultStore object
    Set colRules = Application.Session.DefaultStore.GetRules()
    oRuleCount = colRules.Count
    Debug.Print oRuleCount
    intCounter = 1
    Do While intCounter < (colRules.Count + 1)
        Set oRule = colRules.Item(intCounter)
        Debug.Print oRule.Name
        Debug.Print oRule.ExecutionOrder
        intCounter = intCounter + 1
    Loop
    Set oRule = colRules.Item(2)
    oRule.ExecutionOrder = oRuleCount
    'Update the server and display progress dialog
    colRules.Save
End Sub

If a rule is created using the Outlook Rules Wizard, its value is least and has highest priority. The existing rules gets pushed down by 1 i.e. PR_RULE_SEQUENCE gets increased by 1 for all the existing rules.
Conversely, a new rule gets higher priority when created using Outlook wizard or using Outlook Object model programmatically.

When we use Named properties, MAPI picks up an available property identifier. This way it avoids conflict with the properties that are being used by MAPI clients like Outlook.

Transmittable/Non-transmittable properties
Non-transmittable properties usually contain information that is of value only to clients and service providers operating with the current session. These properties would not necessarily be useful to another messaging system and another set of service providers.

A non-transmittable message property exposed at both the sending and receiving ends of a transmission, with different values depending upon the client application or store provider involved. This property is initialized by the client or message store provider when a message is created and saved for the first time and then updated periodically by the message store provider, a transport provider, and the MAPI spooler as the message is processed and its state changes.

Transmittable properties are transferred with a message; non-transmittable properties are not transferred with a message. The concept of transmittable properties applies primarily to transport providers.

REQUEST
<?xml version="1.0"?>
  <GetAttachmentType xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema">
    <AttachmentShape xmlns="https://schemas.microsoft.com/exchange/services/2006/messages">
      <AdditionalProperties xmlns="https://schemas.microsoft.com/exchange/services/2006/types">
        <ExtendedFieldURI PropertyTag="0x0E20" PropertyType="Long" />
      </AdditionalProperties>
    </AttachmentShape>
    <AttachmentIds xmlns="https://schemas.microsoft.com/exchange/services/2006/messages">
    <AttachmentId Id="AAAaAEFkbWluaXN0cmF0b3JAZGMxMjkw...</AttachmentIds>
</GetAttachmentType>

RESPONSE
<?xml version="1.0"?>
  <GetAttachmentResponseType xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="https://www.w3.org/2001/XMLSchema">
    <ResponseMessages xmlns="https://schemas.microsoft.com/exchange/services/2006/messages">
      <GetAttachmentResponseMessage ResponseClass="Success">
        <ResponseCode>NoError</ResponseCode>
          <Attachments>
           <FileAttachment xmlns="https://schemas.microsoft.com/exchange/services/2006/types">
             <AttachmentId Id="AAAaAEFkbWluaXN0cmF0b3JAZG...<Name>smime.p7m</Name>
                 <ContentType>multipart/signed</ContentType>
                   <Content>TUlNRS1WZXJza.....
                   </Content>
           </FileAttachment>
          </Attachments>
      </GetAttachmentResponseMessage>
    </ResponseMessages>
</GetAttachmentResponseType>

There we go. The response doesn't yield the Extended Field type property.
Hence, the theorem.