Internet Draft S. Taylor Document: draft-taylor-exmp-01.txt Sublime Solutions Expires: October 2005 March 2005 Extensible Mail Protocol (ExMP) Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" This Internet-Draft will expire in April 2005. Abstract This document describes the Extensible Mail Protocol (ExMP); a protocol designed to deliver XML formatted mail messages between post office nodes using Simple Object Access Protocol (SOAP) via HTTPS. The purpose of this ExMP is to become a total end-to-end mail delivery and retrieval system that is both scalable and secure. Taylor [Page 1] Extensible Mail Protocol (ExMP) October, 2004 Conventions used in this document "Node" refers to a Post Office. "Post Office" refers to an ExMP node that handles all the messages for a set of customers as well as routing messages for other ExMP post offices. "Message" refers to a well formed XML message, capable of being delivered via the ExMP network. "Mail Bag" refers to a collection of messages, bundled as a bag, destined for a remote post office node. "Post Master" refers to the process residing at a post office, responsible for the processing/authenticating of messages and mail bags. It also refers to the person or people which manage the post office. "Dispatcher" refers to the process residing at a post office, responsible for the bundling of messages into mail bags and transferring them to remote post offices. "Gateway" refers to the process responsible for transferring messages between the existing mail network and the ExMP network. "Spoofing" refers to a process in which one person effectively masquerades or hijacks another person's identity. "NULL" refers to a state of an object that has not yet been initialized or is at default state. Other languages such as Visual Basic may refer to this object as being "Nothing". In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements Taylor Expires - October 2005 [Page 2] Extensible Mail Protocol (ExMP) October, 2004 but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant." Table of Contents 1. Introduction..................................................7 2. Scope.........................................................7 3. Basic Model...................................................8 3.1. Client to Post Office.......................................8 3.2. Post Office to Post Office..................................8 4. Detailed Model................................................8 4.1. Requirements................................................8 4.1.1. HTTPS.....................................................8 4.1.2. Server Certificates.......................................9 4.1.3. Client Certificates.......................................9 4.1.3.1. Client to Post Office..................................10 4.1.3.2. Post Office to Post Office.............................10 4.2. Client to Server...........................................11 4.2.1. Message Delivery.........................................11 4.2.2. Limitations..............................................11 4.2.3. Semantics................................................11 4.2.3.1. Delivery...............................................11 4.2.3.2. Retrieval..............................................11 4.2.4. Guarantees...............................................12 4.3. Post office to Post office.................................12 4.3.1. Mail Bag Delivery........................................12 4.3.2. Limitations..............................................12 4.3.3. Semantics................................................13 4.3.3.1. Delivery...............................................13 4.3.4. Guarantees...............................................13 4.4. Addressing.................................................13 4.4.1. Semantics................................................14 4.4.2. Reserved Accounts........................................14 4.4.2.1. Post Master............................................14 4.4.2.2. Return To Sender.......................................15 4.4.3. Virtual Mailboxes........................................15 4.4.3.1. Everyone...............................................15 4.5. Messages...................................................16 4.5.1. Maximum Size.............................................16 4.5.2. Message Segmenting.......................................16 4.6. Mail Bags..................................................19 4.6.1. Maximum Size.............................................19 4.6.2. Messages.................................................19 4.6.3. Filling..................................................20 4.7. Firewalls..................................................20 4.7.1. Incoming.................................................20 4.7.2. Outgoing.................................................20 4.8. Proxy Servers..............................................20 5. Public Interfaces............................................20 Taylor Expires - October 2005 [Page 3] Extensible Mail Protocol (ExMP) October, 2004 5.1. Documentation..............................................20 5.2. DNS........................................................21 5.2.1. MX Records...............................................21 5.3. Service Determination......................................21 5.3.1. Versioning...............................................22 5.4. Standard Bind Points.......................................22 5.4.1. Web Service Extension....................................22 5.4.2. Service Points...........................................22 5.4.2.1. Service.soap...........................................22 5.4.2.1.1. Methods..............................................23 5.4.2.1.1.1. Information........................................23 5.4.2.2. Postoffice.soap........................................23 5.4.2.2.1. Methods..............................................24 5.4.2.2.1.1. Post...............................................24 5.4.2.2.1.2. Deliver............................................25 5.4.2.3. Mailbox.soap...........................................25 5.4.2.3.1. Methods..............................................26 5.4.2.3.1.1. Open...............................................26 5.4.2.3.1.2. ChangePassword.....................................26 5.4.2.3.1.3. GetInformation.....................................27 5.4.2.3.1.4. GetMessageIds......................................28 5.4.2.3.1.5. GetMessageSize.....................................28 5.4.2.3.1.6. GetMessage.........................................29 5.4.2.3.1.7. DeleteMessage......................................30 5.4.2.3.1.8. Close..............................................31 5.4.2.4. Account................................................31 5.4.2.4.1. Methods..............................................32 5.4.2.4.1.1. Create.............................................32 5.4.2.4.1.2. RequestCertificate.................................33 5.4.2.4.1.3. Close..............................................33 6. Routing......................................................34 6.1. Store and Forward..........................................34 6.2. Semantics..................................................35 6.2.1. Hop Confirmations........................................35 6.2.2. End point Confirmations..................................35 6.2.3. Delivery Confirmations...................................37 6.2.4. Collected Confirmation...................................38 6.2.5. Read Confirmations.......................................39 6.2.6. Duplicate detection......................................40 6.3. Mail Bags..................................................40 6.3.1. Destination..............................................41 6.3.2. Transit..................................................41 7. SMTP Gateways................................................42 7.1. Authentication.............................................42 7.1.1. Client Certificates......................................43 7.2. Translating RFC 2822 and MIME Fields.......................43 7.2.1. Mappings.................................................43 Taylor Expires - October 2005 [Page 4] Extensible Mail Protocol (ExMP) October, 2004 7.2.1.1. RFC 2822 Header........................................43 7.2.1.2. MIME Body..............................................44 7.2.1.2.1. Unicode..............................................44 7.2.1.2.2. HTML.................................................45 7.2.1.2.3. Text.................................................45 7.2.1.3. MIME Attachments.......................................46 8. Error Handling...............................................47 8.1. Receipts...................................................47 8.1.1. Informational Codes......................................47 8.1.1.1. 200-279 - Reserved.....................................47 8.1.1.2. 280-299 - Implementation Specific......................47 8.1.2. Warning Codes............................................47 8.1.2.1. 400 - Insufficient Randomness in Message Id............48 8.1.2.2. 401 - Insufficient Randomness in Mailbag Id............48 8.1.2.3. 410 - Duplicate Message Detected.......................48 8.1.2.4. 411 - Duplicate Mailbag Detected.......................48 8.1.2.5. 420 - Incorrectly Bagged Messages Detected.............48 8.1.2.6. 480-499 - Implementation Specific......................48 8.1.3. Error Codes..............................................48 8.1.3.1. 500 - General Server Error.............................48 8.1.3.2. 520 - Missing Message Id...............................49 8.1.3.3. 521 - Missing Subject..................................49 8.1.3.4. 522 - Missing Date.....................................49 8.1.3.5. 530 - Missing Mailbag Id...............................49 8.1.3.6. 531 - Missing Mailbag Destination......................49 8.1.3.7. 540 - Missing Mailbox..................................49 8.1.3.8. 541 - Missing Post Office..............................49 8.1.3.9. 542 - Missing From Address.............................49 8.1.3.10. 543 - Missing Recipient...............................50 8.1.3.11. 544 - Invalid Sender Address..........................50 8.1.3.12. 545 - Invalid From Address............................50 8.1.3.13. 546 - Invalid Post Office.............................50 8.1.3.14. 547 - Invalid Destination Post Office.................50 8.1.3.15. 580-599 - Implementation Specific.....................50 8.2. SOAP Exceptions............................................50 8.2.1. Error Codes..............................................51 8.2.1.1. 500 - General Server Error.............................51 8.2.1.2. 550 - Invalid or missing client certificate............51 8.2.1.3. 551 - Certificate error................................51 8.2.1.4. 570 - Invalid user name or identifier..................51 8.2.1.5. 571 - Invalid password.................................51 8.2.1.6. 610 - Invalid client information.......................52 8.2.1.7. 640 - Session not established..........................52 8.2.1.8. 650 - Account Exists...................................52 9. ExMP Objects Specifications..................................52 9.1. Message....................................................52 9.2. Header.....................................................53 9.3. Address (abstract).........................................54 9.3.1. From.....................................................55 Taylor Expires - October 2005 [Page 5] Extensible Mail Protocol (ExMP) October, 2004 9.3.1.1. Sender.................................................56 9.3.2. To.......................................................56 9.3.2.1. ReplyTo................................................56 9.3.2.2. Cc.....................................................56 9.3.2.2.1. Bcc..................................................56 9.4. MetaTag....................................................57 9.5. PostOffice.................................................57 9.6. Segment....................................................57 9.7. Attachment.................................................58 9.8. Block (abstract)...........................................59 9.8.1. Body.....................................................60 9.8.1.1. TextBody...............................................60 9.8.1.2. HtmlBody...............................................60 9.8.2. Confirmation.............................................60 9.8.2.1. EndPointAcceptance.....................................61 9.8.2.2. EndPointRejection......................................61 9.8.2.3. DeliveryConfirmation...................................61 9.8.2.4. CollectedConfirmation..................................62 9.8.2.5. ReadConfirmation.......................................62 9.9. Mailbag....................................................62 9.10. Result....................................................64 9.11. MessageReceipt............................................64 9.12. MailbagReceipt............................................64 9.13. ServiceRequest............................................65 9.14. MailboxInfo...............................................65 9.15. SysInfo...................................................66 10. Extending Meta Tags.........................................66 10.1. Adding Pictures...........................................67 10.2. Adding Contact Details....................................68 11. ExMP Standards..............................................68 11.1. Message Checks............................................68 11.2. Mail Bag Checks...........................................69 11.3. Message Delivery..........................................70 11.3.1. Maximum Retry Time......................................70 12. Security Considerations.....................................70 12.1. Account Creation..........................................70 12.2. Message Persistence.......................................70 12.3. X.509 Certificates........................................70 12.3.1. Client Certificates.....................................71 12.3.1.1. Issuing Authorities...................................71 12.3.1.2. Issuing from Server...................................71 12.4. DNS.......................................................71 12.5. Messages..................................................71 13. Formal Syntax...............................................72 14. Reference...................................................72 15. Acknowledgments.............................................74 16. Author's Addresses..........................................74 Appendix A. WSDL................................................74 A.1. Account.soap...............................................75 Taylor Expires - October 2005 [Page 6] Extensible Mail Protocol (ExMP) October, 2004 A.2. Postoffice.soap............................................78 A.3. Mailbox.soap...............................................86 A.4. Service.soap...............................................97 Appendix B. Sample Messages.....................................99 B.1. ExMP Message...............................................99 B.2. Mail Bag..................................................100 1. Introduction Extensible Mail Protocol is a protocol that has been designed as an end to end mail solution, replacing the current routing protocol Simple Mail Transport Protocol (SMTP) [2] and suite of mailbox protocols such as Post Office Protocol (POP3) [3] and Internet Message Access Protocol (IMAP) [4]. Gateways between ExMP networks and existing networks allow current email infrastructures to operate seamlessly as well as current client programs to function correctly. SOAP [5] via HTTPS [6] is used to transmit messages/mail bags between ExMP nodes and clients. Client and Server X.509 [7] certificates are used throughout the system to ensure communicating parties are correctly identified, preventing identity "spoofing". Delivery is essentially point-to-point but relaying nodes may be introduced with mail bags being passed from node to node. Termination or destination nodes will confirm the receipt of both the mail bag and each message, allowing the transmitting stations to remove the messages from the outgoing queues. Mail Messages consist of four separate parts; - The Header which defines what the message is about and who it is destined to go to. - Attachments which are any type of octet streams with an associated name/filename. - The Blocks which are a collection of data, destined for the recipient. - The Chain Message is a message to which this one can refer to. In email domains this is commonly referred to as "Re:" in subjects. 2. Scope This document is primarily targeted at parties wishing to develop their own implementation of ExMP. Taylor Expires - October 2005 [Page 7] Extensible Mail Protocol (ExMP) October, 2004 3. Basic Model The two basic models that ExMP will provide are client to post office and post office to post office. Both of the models use the same idea with a slightly different implementation concerning methods called and certificates passed. 3.1. Client to Post Office This model allows the client to communicate directly with the server by posting and retrieving messages from it. Ideally, the client to server model will be where a client implementation program interacts directly with the post office, using the native web methods supplied. Alternatively, a gateway could perform the translation tasks required to convert a proprietary mail program with the post office. 3.2. Post Office to Post Office This model allows two ExMP post office nodes to communicate directly with each other, sending mail bags between the nodes. Once again an ideal solution would be to have ExMP nodes communicate directly with each other. However, to facilitate existing networks, translation using gateways may be required to interoperate between incompatible systems. Note: While one could effectively gateway from ExMP to SMTP it is not an ideal solution as it would bypass most of the security precautions taken in the ExMP network. An option may arise with the introduction of SMTP over TLS [8]. 4. Detailed Model 4.1. Requirements 4.1.1. HTTPS HTTPS is the primary protocol that MUST be used whenever a message or mail bag is transmitted through the ExMP network. When exposing the service to the outside world, enabling of HTTPS and disabling HTTP is recommended, failing that firewall rules should prevent HTTP traffic from passing to-from that node. Servers MUST be set up to accept client certificates and reject all other HTTPS non-client certificate connections, the notable Taylor Expires - October 2005 [Page 8] Extensible Mail Protocol (ExMP) October, 2004 exception being the "Service" and "Account" web services which are used to setup clients and query service capabilities. Implementations SHOULD also check client certificates at the method level as to prevent any vulnerabilities left open via the incorrect setup of a web server. This document makes no reference to the strength of the cipher that is used but the higher the cipher the more secure the connection will be. Note: Implementations MUST make sure that no insecure services are left open as this may introduce security vulnerabilities. 4.1.2. Server Certificates Each and every post office node MUST have an X.509 server certificate installed. These certificates MUST be from one of the standard issuing authorities and MUST contain; - Valid company or provider details. - Valid and up-to-date contact details. - Validity for a period of no less than 2 years. - Linked to the current DNS entry (section 5.2) Note: A new certificate is required for each version of the protocol and MUST be issued to the current DNS entry of that version. 4.1.3. Client Certificates X.509 client certificates are the primary way in which both a post office and a client identify itself with another foreign post office. The use of client certificates is crucial in the prevention of anonymous mailing and spoofing of accounts. Whenever a client certificate is presented from a post office it must only be accepted if it is from a reputable issuing authority. Client certificates issued from non-standard sources MUST not be accepted. A list of reputable sources can usually be obtained from most standard web browser root certificate lists. AT NO TIME SHOULD A POST OFFICE ACCEPT A CLIENT CERTIFICATE FROM ANOTHER POST OFFICE. Whenever a client certificate is presented from a client then that post office MUST validate the fingerprint of the certificate against its own certificate. If there is a Taylor Expires - October 2005 [Page 9] Extensible Mail Protocol (ExMP) October, 2004 discrepancy, then the post office MUST reject all transactions from that client. When a client certificate has been issued from a valid issuing authority, post offices MUST check all aspects of this certificate, including but not limited to the valid from and to dates and fingerprint. AT NO TIME SHOULD A POST OFFICE ACCEPT A CLIENT CERTIFICATE WHICH IS CONSIDERED INVALID. 4.1.3.1. Client to Post Office To prevent "spoofing" of email addresses, post offices with connecting ExMP capable clients MUST ensure that they present a valid client certificate. These certificates MUST be generated by the post office and sent to the client when the account is created. This certificate MUST contain; - Valid email address which matches the post office's domain and client account. For example, if client John Smith has an account 'jsmith' at the post office example.net then the client certificate email address MUST read jsmith@example.net. - Valid name of the account holder (i.e. John Smith) - Validity of the certificate is up to the discretion of the issuing post office but it would be advisable to have the certificate valid for a minimum of 6 months. - Fingerprint of the issuing post office which will be matched against the connecting post office when the client attempts to deliver messages. 4.1.3.2. Post Office to Post Office Whenever a delivering post office connects to a remote post office it MUST present a valid client certificate to that node. Client certificates enable the remote node to validate that the connecting node is in fact a real ExMP post office node and is allowed to send mail bags. Client certificates MUST be issued from one of the standard issuing authorities and MUST contain; - Valid company or provider details. - Valid and up-to-date contact details. - Valid for a period of no less than 2 years. - Common name or Subject of certificate MUST point to the sending post office's current DNS entry for its most current version of the protocol (section 5.2). This is to ensure that client certificates generated for other purposes are not used. Taylor Expires - October 2005 [Page 10] Extensible Mail Protocol (ExMP) October, 2004 4.2. Client to Server 4.2.1. Message Delivery When delivering messages to a post office client, implementations are required to complete a message check according to a set of predefined checks (section 11.1), bundle them into a collection of messages and post them to the server. The post office will then check each of the messages and return a receipt for each one sent. If a message is rejected the receipt will contain a code identifying the problem. 4.2.2. Limitations When delivering collections of messages to the post office, client implementations are required to consider HTTP post sizes and link transmission speeds before sending large numbers of messages. A simple rule to follow would be to bundle many small messages and only a couple of larger messages into a collection. For a description of message size limitations refer to section 4.5.1. 4.2.3. Semantics 4.2.3.1. Delivery Once a message has been posted to the post office the client MUST assume the correct delivery of the message. The server MUST make sure that the message meets all the requirements of a valid ExMP message detailed in section 11.1. Failing any of these requirements the message MUST be rejected by the server and the client will be notified in a MessageReceipt object (section 9.11). 4.2.3.2. Retrieval When retrieving messages from the post office via the Mailbox.soap service, the post office MUST check all of the supplied user credentials, validating them as necessary. Any feedback concerning the validation or steps required to retrieve messages will be relayed back to the client by the use of SOAP exception handling techniques. The expected order of steps to be taken is listed below; 1. Open 2. GetInformation 3. GetMessageIds 4. GetMessageSize Taylor Expires - October 2005 [Page 11] Extensible Mail Protocol (ExMP) October, 2004 5. GetMessage 6. DeleteMessage 7. Close Once the client has successfully opened his/her post box, the post office SHOULD hold some type of session state, such as cookies, allowing the client to access his/her messages. Once the client has completed his/her work then he/she can either close the mailbox or the server will timeout and close the mailbox for him/her. Session timeouts SHOULD be sufficient to allow a client to retrieve his/her messages without having to re-login every time. A suggested timeout formula is listed below; Timeout = Number of Messages * 120 seconds 4.2.4. Guarantees Once a message has been accepted by the post office, the client can assume that the message will be delivered to the remote post office or be returned with a detailed reason for the failure. See Routing Semantics (section 6.2) for a detailed explanation of this process. 4.3. Post office to Post office 4.3.1. Mail Bag Delivery Mail bags are delivered using one of two models; - Direct - Transit With the direct model, post offices determine who the remote post office is via a DNS MX record lookup and send mail bags directly to the node. With the Transit model, post offices send mail bags to a routing post office which will then either deliver directly or transit the mail bag to another node. Transiting may be necessary in large organizations with one mail post office used for the delivery of all mail to the outside network. 4.3.2. Limitations When delivering a mail bag to a remote post office implementations are required to consider the maximum HTTP post sizes. On larger messages it is advisable that the post office Taylor Expires - October 2005 [Page 12] Extensible Mail Protocol (ExMP) October, 2004 send mail bags with segmented messages (section 4.5.2) as to prevent buffer overflow situations occurring and exception conditions being generated. 4.3.3. Semantics 4.3.3.1. Delivery There are two types of responsibilities a post office accepting messages or mail bags can take. The first type of responsibility concerns the post office receiving a message from a client. Once the client has delivered the message the post office MUST guarantee that this message will be sent, failing that, the client MUST be notified of the reason of failure. The second type of responsibility concerns the post office receiving a mail bag from a remote post office. If the mail bag is marked as a TRANSIT mail bag (section 6.3.2), the receiving post office only needs to check the mail bag, accept it or reject it. If the mail bag is marked as a DESTINATION mail bag (section 6.3.1), the receiving post office MUST take responsibility for the mail bag and all of its content. All of the messages must be checked, delivered or rejected. All messages MUST be acknowledged by an end point confirmation (section 6.2.2). 4.3.4. Guarantees Once a mail bag has been accepted by a remote post office, the sending post office MUST assume that it will arrive at its final destination. If not, a detailed reason for "each message" MUST be generated and sent to the originating mailbox. This is also true if the mail bag is rejected by any routing post office and there are no other routes available for the mail bag to be sent via. 4.4. Addressing In order to keep in line with current email infrastructures, no change will occur in the naming of email addresses from a client's perspective. Clients will retain their existing RFC 2822 formatted email address but will have them translated into a valid ExMP Address object (section 9.3). ExMP has the ability to receive messages using individual accounts, aliased accounts and virtual mailboxes (distribution lists). Taylor Expires - October 2005 [Page 13] Extensible Mail Protocol (ExMP) October, 2004 4.4.1. Semantics Addressing in ExMP closely follows that of traditional email systems. When sending a message the following applies; a.) You may specify as many "From" addresses as you wish but each message MUST contain at least one valid "From" address. If you do specify more than one "From" address then you MUST nominate an address as the "Sender" of the message. The "Sender" may be one of the "From" addresses or may be a completely separate address. b.) If a "Sender" is nominated then there can be only one "Sender" present. c.) If you wish to add a "ReplyTo" address then you may specify as many "ReplyTo" addresses as you wish. d.) You MUST have at least one valid recipient present. A recipient address can be any of the types "To", "Cc" or "Bcc". e.) If you specify a "Bcc" address then this address MUST NOT be delivered to any destination post offices other than the one where the mailbox resides. This protects the identity of the "Bcc" recipient. On replying the following applies; a.) If "ReplyTo" addresses exist then these become the "To" addresses in the new message. b.) If there are no "ReplyTo" addresses then the "From" addresses become the "To" addresses in the new message. c.) Any "Cc" addresses MUST appear in the new messages "Cc" addresses if a reply all is used. 4.4.2. Reserved Accounts There are several accounts which MUST be reserved for the post office and MUST NOT be used by public accounts. 4.4.2.1. Post Master Taylor Expires - October 2005 [Page 14] Extensible Mail Protocol (ExMP) October, 2004 This account is reserved for the administrator(s) of a post office. It is defined as an incoming and outgoing account and may be configured as a virtual mailbox. When sending a message as the post master, the sending person MUST have their address present in the "Senders" address, post master being sent in the "From" address. The following MUST be defined on ALL post offices; Display Name - "Post Master" Mailbox - postmaster 4.4.2.2. Return To Sender This account is reserved for undeliverable or erroneous messages which need to be returned to the original sender of the message. It is defined as an outgoing system account only and MUST NOT accept messages. The following MUST be defined on ALL post offices; Display Name - "Return to Sender" Mailbox - rts 4.4.3. Virtual Mailboxes Virtual mailboxes allow a sender to send to one mailbox and have it delivered to a group of mailboxes. Every post office MUST be able to accept virtual mailboxes. These virtual mailboxes can be used to send outgoing messages but can only be used in the "From" address. The original sender MUST be identified in the "Sender" address. The following virtual mailboxes MUST be defined on all post offices. 4.4.3.1. Everyone This virtual mailbox allows a person to send a message to all mailboxes on a post office. It is an incoming only mailbox and under no circumstances should a message have this in the "From" or "Sender" addresses. Post offices may choose to disable or restrict this mailbox for obvious security reasons. Display Name - "" Mailbox - everyone Taylor Expires - October 2005 [Page 15] Extensible Mail Protocol (ExMP) October, 2004 4.5. Messages Due to the limitation of HTTP post buffers, messages need to be limited to a maximum size. This restriction is in place to allow post offices to handle large volumes of messages in a reasonable amount of memory. If a message is larger than the maximum size it MUST be segmented into smaller messages. These smaller segments are then sent to the remote post office where they are re-assembled into the original message. This maximum size must also be considered when a client delivers a collection of messages to a post office. The combined size of the collection MUST NOT exceed the maximum size. If the combined collection size does exceed the maximum size multiple postings with single messages will be required. 4.5.1. Maximum Size In order to successfully cross the ExMP network, a maximum message size of 2 megabytes is enforced. Post offices and client implementations MUST make sure that ALL messages do not exceed this size, else segmentation of the message is required. 4.5.2. Message Segmenting In order to successfully transmit a larger message across the ExMP network, it must be broken into smaller manageable segments. These segments do not have to be complete entities in themselves and can be segmented further, if a post office's transmission path requires it. Once ALL of the segments have been received at the remote post office, they must be reassembled in the correct order and then processed as one message. If a message has been segmented by a client before posting, re- assembly occurs at the destination post office. This ensures that the destination mailbox receives a complete message. When segmenting messages the segmenting process is required to perform the following steps; 1.) Persist the original message in standard plain XML format according to the format specified in the WSDL (Appendix A). For an example of the format expected, refer to Appendix B.1. 2.) Split the message into segments that will not exceed the maximum message size defined in section 4.5.1. Taylor Expires - October 2005 [Page 16] Extensible Mail Protocol (ExMP) October, 2004 3.) Duplicate the original header Addresses, Subject and Date. 4.) Complete a Segment object for each of the new Messages. 5.) Insert the segmented message into the Bodies collection. On reception of a segmented message the receiving post office is required to perform the following steps; 1.) Save each segment of the message pending reception of ALL segments of the message. 2.) Remove the original segments of the message from the body. 3.) Merge each of the segments together, load the file and process as a normal message. If the message is for any reason rejected by the remote post office then the segmenting process may need to be reversed back to the sending office. If any of the segments do not arrive at the remote post office within the acceptable time frames for a delivered message (section 11.3.1), the remote office MUST discard the segments and await the sending office to re-transmit the original message. Example ------- If the following message was sent from a client and the maximum message size was reached, it would be segmented into smaller messages, containing the original message in the body. Once each segment of the message reached the remote post office, it will be re-assembled into the original message. Original Message ----------------
0f10095f-a655-407a-a419-6c43fb95adf1
Taylor Expires - October 2005 [Page 17] Extensible Mail Protocol (ExMP) October, 2004
This is a test 2004-09-12T09:42:22+10:00
QSBCb2R5IG9mIFRleHQNCg==
Segment 1 ---------
c8239767-57b4-4843-ac83-14e1bf7ff2d9
This is a test 2004-09-12T09:42:22+10:00 0f10095f-a655-407a-a419- 6c43fb95adf1 remote.mail.com
st "1 Segment of Data"
Segment 2 --------- Taylor Expires - October 2005 [Page 18] Extensible Mail Protocol (ExMP) October, 2004
8ae949c4-dc70-4004-a5ee-6b840886ea2f
This is a test 2004-09-12T09:42:22+10:00 0f10095f-a655-407a-a419- 6c43fb95adf1 remote.mail.com
nd "2 Segment of Data"
4.6. Mail Bags Due to the limitation of HTTP post buffers, mail bags need to be limited to a maximum size. If a mail bag is larger than the maximum size, its contained messages MUST be extracted and new mail bags created. If the mail bag only contains one large message, then this message MUST be extracted and segmented. The segments will then be sent in separate mail bags. 4.6.1. Maximum Size In order to successfully cross the ExMP network, a maximum mail bag size of 9 megabytes is enforced. This allows for a total of 4 maximum sized messages with 1 megabyte remaining for the mail bag header. With a 2 gigabyte buffer on the receiving post office, this value allows for approximately 220 simultaneous mail bags to be received. 4.6.2. Messages There are no restrictions on how many messages can be stored in a single mail bag as long as the mail bag size does not exceed the maximum size stated in section 4.6.1. Taylor Expires - October 2005 [Page 19] Extensible Mail Protocol (ExMP) October, 2004 4.6.3. Filling When filling a mail bag with messages the sending post office the following rules apply; - If a post office cannot deliver direct, it MUST mark the mail bag as "TRANSIT" and deliver to a routing post office. - If a post office can deliver directly it MUST mark the bag as "DESTINATION" and deliver directly to the post office defined in the header. - If a mail bag is marked as a DESTINATION mail bag it MUST contain messages destined to only ONE post office. If the mail bag contains messages destined to a post office other than the one defined in the header, the mailbag MUST be failed by the receiving post office. - If a mail bag is marked as a TRANSIT mail bag it may contain messages destined for other post offices. In this case the post office defined in the header MUST NOT be defined. 4.7. Firewalls The use of firewalls should be transparent to the ExMP network as HTTPS is used as the primary protocol. All firewalls are usually pre-configured for HTTP and HTTPS traversal. If not, the following firewall rules SHOULD be applied: 4.7.1. Incoming Incoming firewall rules SHOULD be set to examine the incoming defined IP address and port 443. Forwarding rules SHOULD be applied, allowing this traffic to pass to the correct post office server transparently. 4.7.2. Outgoing Outgoing rules MUST allow port 443 to pass transparently to the sending post office server. 4.8. Proxy Servers The use of proxy servers should be transparent to SOAP and ExMP. 5. Public Interfaces 5.1. Documentation Each and every post office MUST offer a documentation area where any potential customizations MUST be documented. Taylor Expires - October 2005 [Page 20] Extensible Mail Protocol (ExMP) October, 2004 Documentation may include; - Non Standard MetaTag field descriptions. - Informational, Warning and Error Codes descriptions. - Service status information. - Administrator notifications. - Service Requests. - Technical Support. The documentation MUST exist in the following location; https://exmp.../documentation/ 5.2. DNS ExMP makes use of the DNS system [9] to determine both the end post office of a mail domain and the end version of the protocol; ensuring that all post offices adhere to the use of DNS and verification of valid MX [10] records prevents obfuscation of identity. 5.2.1. MX Records All ExMP MUST have a valid Mail Exchange (MX) record in DNS. This tightens up the relaxed standards of SMTP which use the domain name failing the resolution of the MX record. Since the MX record contains no way of determining the end port or protocol that is to be used in the transport of the message, ExMP post offices are distinguished simply by the DNS entry itself. An example of this; nslookup > example.net example.net MX preference = 0, mail exchanger = exmp.1.0.example.net 5.3. Service Determination Once the MX records have been successfully retrieved from DNS, one determines whether the remote post office is running ExMP or SMTP by looking at the returned DNS host entry. ExMP nodes are identified by prefixing the host name with "exmp" whereas SMTP nodes are not. This is not to say that the end machine is not running SMTP, but if the host name is prefixed with "exmp" then it MUST be running the required service points. Failing an ExMP binding on a node that has declared itself as ExMP Taylor Expires - October 2005 [Page 21] Extensible Mail Protocol (ExMP) October, 2004 compatible, all implementations MAY revert to SMTP as a fallback system and report the error to the post master on the sending node. 5.3.1. Versioning Examining the resulting DNS record of the MX lookup allows the sending post office to bind to the correct version of the protocol. This allows a post office to support newer versions of the protocol while still being able to support legacy versions. The format of the record MUST be in the following format; exmp... An example of this; exmp.1.0.example.net or on subsequent revisions of the protocol. exmp.1.5.example.net Note: Each post office MUST support legacy versions of the protocol allowing older post offices to correctly route. 5.4. Standard Bind Points In order for a remote post office to be able to bind via SOAP to a destination it MUST know where to bind to. For this reason several required and optional SOAP bind points need to be defined. These are defined as services on the remote post office and can be used as entry points in the terminating offices load balancing systems. 5.4.1. Web Service Extension Each of the defined services MUST use ".soap" as the service extension to clearly show the underlying protocol. 5.4.2. Service Points The following service points are required by ExMP and any implementation MUST provide them. 5.4.2.1. Service.soap This service allows a remote post office to query a post office's capabilities. Remote post offices may choose to query Taylor Expires - October 2005 [Page 22] Extensible Mail Protocol (ExMP) October, 2004 a series of post offices to try and find the most efficient route to send a message if a direct one is not available. This service allows the post office to determine how many messages could be sent through it. Below is an example of this; https://exmp.1.0.example.net/exmp/system.soap 5.4.2.1.1. Methods 5.4.2.1.1.1. Information This method allows a client or post office to query the information about a post office. The caller SHOULD cache this information for an acceptable amount of time before calling again as the states may not change. Prototype --------- SysInfo Information() Requires Client Certificate --------------------------- No Requires Session ---------------- No Returns ------- SysInfo - A SysInfo object (section 9.15) describes the information about a post office. Soap Exceptions --------------- . General server error. 5.4.2.2. Postoffice.soap This is the main routing service that is used to process delivered mail messages and mail bags from both client as well as remote post office nodes. Below is an example of this; https://exmp.1.0.example.net/exmp/postoffice.soap Taylor Expires - October 2005 [Page 23] Extensible Mail Protocol (ExMP) October, 2004 5.4.2.2.1. Methods 5.4.2.2.1.1. Post This method allows a client to post a collection of messages to the server, have them verified and delivered if correct. Once the collection of messages have been delivered to the server, it will scan each one of the messages to make sure that it completely complies with all the defined requirements of an ExMP message (see section 11.1). As each one of the messages are processed the server will build a collection of message receipts, containing a receipt code as well as a message containing any human readable text. Once ALL the messages have been scanned and either processed or discarded, the collection of receipts will be returned to the client . The client SHOULD then correlate all receipts to sent messages and display any error messages to the sending person. Prototype --------- MessageReceipt[] Post( Message[] messages ) Requires Client Certificate --------------------------- Yes Requires Session ---------------- No Parameters ---------- messages - A collection of ExMP messages (section 9.1) MUST be verified by the receiving post office according to the checks defined in section 11.1. If any of the messages do not conform to these rules, they MUST be discarded and the receipt MUST contain the reason code and message. Returns ------- MessageReceipt[] - One MessageReceipt (section 9.11) for each message that was posted. The client code can then correlate this to the original messages, checking for rejected messages. Soap Exceptions --------------- . Invalid or missing client certificate. . General server error. Taylor Expires - October 2005 [Page 24] Extensible Mail Protocol (ExMP) October, 2004 5.4.2.2.1.2. Deliver This method allows a remote post office to deliver a mail bag to a destination post office. When a client posts a collection of messages, the post office bundles messages with the same destination in a single mail bag. The mailbag is then delivered to the destination post office where it is unpacked and each of the messages are delivered to the end destination mailboxes. This process is a little different when a mailbag is sent from a source post office to a relay post office. The mail bag in this case is marked as a transit mailbag and is NOT unpacked by the intermediate post office, it is simply forwarded to the destination or passed on to the next relay. Prototype --------- MailbagReceipt Deliver( Mailbag mailbag ) Requires Client Certificate --------------------------- Yes Requires Session ---------------- No Parameters ---------- mailbag - A Mailbag object (section 9.9) contains a collection of messages and a destination post office. This bag MUST be verified by the receiving post office and rejected if it does not conform to the checks defined in section 11.2. Returns ------- MailbagReceipt - Once the mailbag has been delivered to the post office and processed, the post office will return a mailbag receipt containing a result code. This result code will indicate the state of the mail bag, being accepted or rejected. Soap Exceptions --------------- . Invalid or missing client certificate. . General server error. 5.4.2.3. Mailbox.soap This service allows a client access to his/her stored messages in a post office. It gives the client the ability to logon to Taylor Expires - October 2005 [Page 25] Extensible Mail Protocol (ExMP) October, 2004 the post office, retrieve a list of messages, download new messages and delete old stored messages. https://exmp.../exmp/mailbox.soap 5.4.2.3.1. Methods 5.4.2.3.1.1. Open The method is used for opening a user's mailbox on the server. When initiating a session with the post office, the client code MUST call this method before any other can be called. This allows the post office to correctly identify the user's name and password combination, as well as validating the client certificate sent. Once the person has been verified the state of this mailbox SHOULD remain valid for the duration of the session. Prototype --------- String Open( String userName, String password ) Requires Client Certificate --------------------------- Yes Requires Session ---------------- No Parameters ---------- userName - Unique name or identifier for the user's mailbox. password - Corresponding password of the above user name. Returns ------- String - Once the method has validated the user's information the returning string is the user's physical mailbox name in the post office. Soap Exceptions --------------- . Invalid or missing client certificate. . Invalid user name or identifier. . Invalid password. . General server error. 5.4.2.3.1.2. ChangePassword Taylor Expires - October 2005 [Page 26] Extensible Mail Protocol (ExMP) October, 2004 This method allows the user to change his/her password currently stored in the post office. Once this password has been changed the user session MUST reflect this change and all subsequent password operations will require the new password. Prototype --------- void ChangePassword(String userName, String oldPassword, String newPassword) Requires Client Certificate --------------------------- Yes Requires Session ---------------- Yes Parameters ---------- userName - Unique name or identifier for the user's mailbox. oldPassword - Corresponding password of the above user name. newPassword - New Password which will be stored on the post office. Soap Exceptions --------------- . Invalid or missing client certificate. . Invalid user name or identifier. . Invalid password. . Session not established. . General server error. 5.4.2.3.1.3. GetInformation This method is used to retrieve information about a user's currently opened mailbox. Client implementations can use this method to retrieve information such as number of messages and current mailbox size. Prototype --------- MailboxInfo GetInformation() Requires Client Certificate --------------------------- No Taylor Expires - October 2005 [Page 27] Extensible Mail Protocol (ExMP) October, 2004 Requires Session ---------------- Yes Returns ------- MailboxInfo - Returns a MailboxInfo (section 9.14) object containing information about the user's mailbox. Soap Exceptions --------------- . Session not established. . General server error. 5.4.2.3.1.4. GetMessageIds This method is used to retrieve a list of message identifiers currently stored in the user's mailbox. Client implementations use this list as a comparison against a locally cached set of messages, determining if any new messages have been received. Prototype --------- Guid[] GetMessageIds() Requires Client Certificate --------------------------- No Requires Session ---------------- Yes Returns ------- Guid[] - Returns a collection of Guid objects representing the messages identifiers stored in the ExMP message header (section 9.1). Soap Exceptions --------------- . Session not established. . General server error. 5.4.2.3.1.5. GetMessageSize This method is used to retrieve the size of a specified message held in the user's mailbox. Before downloading a message the client implementation may choose to invoke this method and Taylor Expires - October 2005 [Page 28] Extensible Mail Protocol (ExMP) October, 2004 determine if the message to be downloaded will be a large one. When using high speed networks this method is superfluous but with a slower speed link it can be used to predict a long download time. Note: This value will not be 100% accurate as the SOAP wrapping and transmission over HTTPS may increase this size. It is simply useful for clients to determine how long the download may take. Prototype --------- long GetMessageSize( Guid messageId ) Requires Client Certificate --------------------------- No Requires Session ---------------- Yes Parameters ---------- messageId - A Guid object representing the messages identifier stored in the ExMP message header (section 9.1) of the requested message. Returns ------- Long - a long value representing the calculated size of the message in octets (see formula in section 4.5.1). Soap Exceptions --------------- . Session not established. . General server error. 5.4.2.3.1.6. GetMessage This method is used to retrieve a message from the server. After determining whether or not a new message has been retrieved by the server, client implementations invoke this method, passing the requested message identifier. Once retrieved, the message may be removed from the server using the DeleteMessage method (section 5.4.2.3.1.7). Prototype --------- Taylor Expires - October 2005 [Page 29] Extensible Mail Protocol (ExMP) October, 2004 Message GetMessage( Guid messageId ) Requires Client Certificate --------------------------- No Requires Session ---------------- Yes Parameters ---------- messageId - A Guid object representing the messages identifier stored in the ExMP message header (section 9.1). Returns ------- Message - Returns a Message object (section 9.1) containing the full ExMP message that was sent from the remote post office. Soap Exceptions --------------- . Session not established. . General server error. 5.4.2.3.1.7. DeleteMessage This method is used to delete a message from the server. Once a message has been retrieved from the server by the client, he/she may choose to delete the message from the server, freeing space from his/her mailbox. Once the message has been deleted it MUST be deleted permanently from the server and MUST not be stored. Note: There may be an exception to this rule regarding corporate mail, but for public implementations NO copies should be stored. Prototype --------- void DeleteMessage( Guid messageId ) Requires Client Certificate --------------------------- No Requires Session ---------------- Yes Taylor Expires - October 2005 [Page 30] Extensible Mail Protocol (ExMP) October, 2004 Parameters ---------- messageId - A Guid object representing the messages identifier stored in the ExMP message header (section 9.1) of the requested message. Soap Exceptions --------------- . Session not established. . General server error. 5.4.2.3.1.8. Close This method is used to close an opened mailbox. Once the client has completed all of his/her tasks in the mailbox, he/she SHOULD close the mailbox. Closing the mailbox prevents misuse and potential security risks of an open mailbox. If this method is not invoked, server implementations SHOULD time out a client's session and automatically close the mailbox for them. Note: Failure to properly close a user's mailbox could lead to a potential security risk. Prototype --------- void Close () Requires Client Certificate --------------------------- No Requires Session ---------------- Yes Soap Exceptions --------------- . Session not established. . General server error. 5.4.2.4. Account This service allows an ExMP provider to offer dynamic account creation. It is not required to offer this service if accounts are intended to be manually created or the implementation is destined to be a router. https://exmp.../exmp/account.soap Taylor Expires - October 2005 [Page 31] Extensible Mail Protocol (ExMP) October, 2004 5.4.2.4.1. Methods 5.4.2.4.1.1. Create This method is used to create an account in the post office, generate a client certificate and return the certificate in byte format. Implementations may choose to offer a dynamic account generation service, where a client supplies his/her details via a pre-defined template and requests the account be created on the post office. The post office MUST take care of all of the directory creation, access rights, generation of certificates and authorizing potential payment details. Once the account has been created and authorized, the post office MUST return an X.509 client certificate in DER binary encoded CER format, stored in a byte array. If the post office requires a manual approval of an account before the client certificate is issued, post offices MUST still return a valid client certificate. This certificate can easily be revoked at a later time if the account is rejected. Prototype --------- byte[] Create( ServiceRequest request ) Requires Client Certificate --------------------------- No Requires Session ---------------- No Parameters ---------- request - A ServiceRequest (section 9.13) object containing all the information required to create a client certificate and account. Returns ------- byte[] - An array of bytes representing the X.509 client certificate in DER binary encoded CER format. Soap Exceptions --------------- . Invalid client information. . Account exists. . Certificate error. Taylor Expires - October 2005 [Page 32] Extensible Mail Protocol (ExMP) October, 2004 . General server error. 5.4.2.4.1.2. RequestCertificate This method is used to re-create a current user's client certificate. If for any reason the user loses his/her client certificate, a new client certificate request will need to be generated and submitted to the server. This process MUST invalidate any previous client certificates, removing any trace from storage. This method SHOULD only generate a client certificate if the client has a valid account on the server. If the client's account is invalid or does not exist then the post office MUST throw an invalid client information exception. Prototype --------- byte[] RequestCertificate( ServiceRequest request ) Requires Client Certificate --------------------------- No Requires Session ---------------- No Parameters ---------- request - A ServiceRequest (section 9.13) object containing all the information required to re-create the client certificate. Returns ------- byte[] - An array of bytes representing the X.509 client certificate in DER binary encoded CER format. Soap Exceptions --------------- . Invalid client information. . Invalid user name or identifier. . Invalid password. . General server error. 5.4.2.4.1.3. Close This method is used for closing a client's account. When a user no longer requires his/her account then he/she will request to have his/her account closed. This method MUST delete all information concerning the client, remove any storage Taylor Expires - October 2005 [Page 33] Extensible Mail Protocol (ExMP) October, 2004 directories created and delete any remaining messages. The server MUST also invalidate the client certificate issued to the client, deleting it from the post office. This prevents any misuse of the certificate. Prototype --------- void Close( String userName, String password ) Requires Client Certificate --------------------------- No Requires Session ---------------- No Parameters ---------- userName - Unique name or identifier for the user's mailbox. password - Corresponding password of the above user name. Soap Exceptions --------------- . Invalid user name or identifier. . Invalid password. . General server error. 6. Routing Routing in the ExMP network closely follows the model offered by SMTP where messages are directly delivered to remote nodes or delivered to an intermediate routing node. Direct delivery involves the determination of; a.) Type of service offered (ExMP or SMTP) b.) Version of ExMP For this DNS MX records are used. For intermediate routing nodes, mail bags are simply delivered and it is up to that node to deliver from there. 6.1. Store and Forward Each post office node MUST have the ability to store and forward messages when the destination node is down. On reception of a message the intermediate node SHOULD store the message in a persistent message store and attempt transmission Taylor Expires - October 2005 [Page 34] Extensible Mail Protocol (ExMP) October, 2004 to the destination at regular intervals. Once the maximum retry time has been reached (section 11.3.1), a message MUST be returned to the sending party notifying them of the failure and containing the original sent message. At no point should a message be discarded from the system without notifying the sending party of the reason. 6.2. Semantics Once a message has been sent it MUST be guaranteed that the message will be delivered to the remote mailbox. If for any reason the message needs to be failed then the sending party MUST be notified of the exact reason for the failure. Mail bags and messages MUST be acknowledged by intermediate nodes and final destinations MUST acknowledge the reception of the message before it is removed from the sending post offices dispatch area. 6.2.1. Hop Confirmations Hop confirmations allow client and post offices to guarantee that a message or mail bag has been successfully received by a destination or transit post office. Error conditions can be passed back to a transmitting client or post office allowing the transmitter to take the appropriate action. When a message is posted to the post office, the post office makes an initial check of the message for content and conformity. Once satisfied with a correct format the post office returns a message receipt to the client, acknowledging the message and allowing the client to mark the message as sent. When a mail bag passes from one post office to another, the destination node will check the mail bag for conformity, duplication and validity. Once the destination post office is satisfied with the mail bag, it will acknowledge the reception of the bag by returning a bag receipt with a return code of 0. This enables the sending post office to clear the mailbag from its dispatch area, marking the mail bag as delivered. 6.2.2. End point Confirmations End point confirmations allow a sending post office to guarantee that a message it has sent has been correctly received and acknowledged at the destination post office. An end point confirmation can come in two distinct variations; Taylor Expires - October 2005 [Page 35] Extensible Mail Protocol (ExMP) October, 2004 a.) Acceptance - Acknowledges the message at the remote node. In order for it to be accepted it MUST pass all of the outlined requirements of a message (section 11.1). Failing this, the message MUST be rejected and the sending post office notified by the use of an EndPointAcceptance object (section 9.8.2.1). b.) Rejection - Rejects the message before it lands in a destination mailbox. If the message fails any of the requirements of the destination post office, or the destination mailbox refuses the message, it MUST be rejected and the sending post office notified of the reason for the failure by using an EndPointRejection object (section 9.8.2.2). Once the final confirmation has been received by the sending post office, it may clear the message from its dispatch area. Creating the conformation is performed by sending a message back to the originating post office. The source address MUST be from the post master (section 4.4.2.1) and MUST contain the following attributes; From Address - Destination Post Master (section 4.4.2.1) To Address - Sending post office Subject - "Confirmation" These confirmations are not a optional and MUST be generated by the receiving office. Note: There is no need to send back the original message in the header as the source post office will have a copy of it. Acceptance Example ------------------
72c0ba73-b8a7-416b-babb-74944af04a63
Confirmation Taylor Expires - October 2005 [Page 36] Extensible Mail Protocol (ExMP) October, 2004 2004-09-19T15:37:34+10:00
0f10095f-a655-407a-a419- 6c43fb95adf1
Rejection Example -----------------
83f9adc2-d70b-42dc-9586-76f5ee37a3ef
Confirmation 2004-09-19T15:37:34+10:00
0f10095f-a655-407a-a419- 6c43fb95adf1 The users mailbox has rejected the message because of content.
6.2.3. Delivery Confirmations Delivery confirmations are a way in which the sending post office notifies the client that his/her send message was received, lost, accepted or rejected by any step in the routing of the message. As the sending post office is reliably able to maintain a status of the sent message, the sending post office is able to generate a confirmation and store it in the sending person's mailbox once an end point confirmation has been received. These confirmations are not a optional and MUST be generated by the sending post office. Taylor Expires - October 2005 [Page 37] Extensible Mail Protocol (ExMP) October, 2004 From Address - Source Post Master (section 4.4.2.1) To Address - Sender Subject - "Confirmation" Example -------
d7d0df02-914c-4395-8e35-67404d3a025f
Confirmation 2004-09-19T16:53:40+10:00
3ae8cb2e-619d-41c4-a8a4- 284d47d93f88 2004-09-19T16:53:40+10:00 V2l0aCBhIFRleHQgTWVzc2FnZQ==
6.2.4. Collected Confirmation Collected confirmations are optional confirmations which SHOULD be implemented but may be disabled by the client's post office for privacy reasons. When a message is delivered and has been accepted by the destination post office and mailbox it awaits collection by the mailboxes owner. When the owner collects the message the post office will generate a collected confirmation and send this receipt back to the originator of the message. This confirmation notifies the sender that the recipient has collected the message and at a later time may or may not read the message. From Address - Recipient Taylor Expires - October 2005 [Page 38] Extensible Mail Protocol (ExMP) October, 2004 To Address - Sender Subject - "Confirmation" Example -------
121a2d0b-f24f-4654-ab1e-74ff263fc9a9
Confirmation 2004-09-19T16:53:40+10:00
3ae8cb2e-619d-41c4-a8a4- 284d47d93f88 2004-09-19T16:53:40+10:00 V2l0aCBhIFRleHQgTWVzc2FnZQ==
6.2.5. Read Confirmations Read confirmations are optional confirmations which SHOULD be implemented but may be disabled for privacy reasons. Once a message has been read the client's preferred mail program may generate a read confirmation and send it back to the originator of the message. On reception of this read confirmation the client's post office may chose to discard it or forward it on to the original sender of the message. From Address - Recipient To Address - Sender Subject - "Confirmation" Example ------- Taylor Expires - October 2005 [Page 39] Extensible Mail Protocol (ExMP) October, 2004
ce5cd3d8-d472-4c6c-9008-26e4d7536a7d
Confirmation 2004-09-19T16:53:40+10:00
3ae8cb2e-619d-41c4-a8a4- 284d47d93f88 2004-09-19T16:53:40+10:00 V2l0aCBhIFRleHQgTWVzc2FnZQ==
6.2.6. Duplicate detection It is very likely that a message or mail bag will most probably end up being transmitted more than once across the network at any given point in time. Factors that attribute to this may be delays in processing of an intermediate node or simply delays in the network. In order to prevent the reception and processing of duplicate messages, terminating post offices are required to keep a cache of received message and mail bag identifiers for a period of 2x the maximum retry time (section 11.3.1). If a duplicate message or mail bag is detected it MUST be immediately discarded and not processed or forwarded. For a message sent from the client, he/she MUST be notified with a warning code 410 (section 8.1.2.3) and in the case of a duplicate mail bag the sending post office MUST be notified with a warning code 411 (section 8.1.2.4). 6.3. Mail Bags When routing mail bags, post offices SHOULD take note of the type of mail bag they are receiving, the destination post Taylor Expires - October 2005 [Page 40] Extensible Mail Protocol (ExMP) October, 2004 office defined and the messages contained within. There are two types of routing which can occur with a mail bag; - Destination - Transit. Each of these types have distinct differences of which a post office MUST be aware when receiving delivered mail bags. 6.3.1. Destination If a post office is able or willing to deliver to a remote post office directly, it is said to be using "Destination Routing". In this mode the mail bags contain messages destined for the remote office which is declared in the mail bag header (section 9.9). On reception of the mail bag the destination post office MUST perform the following; 1.) Check that the type is "DESTINATION". 2.) Check that the mail bag has NOT been received before. If it has, then the mail bag MUST be discarded and the sending post office sent a warning code 411. 3.) Check that the post office contained in the header is the same as the processing post office. If it is not, then the mail bag MUST be rejected with error code 547. The sending post office MUST correct this error and resend the mail bag. 4.) Check that each message has at least one recipient at the processing post office. If any messages do not contain a recipient at the processing post office then they MUST be discarded and the sending post office returned a warning code 420. On reception of this warning code the sending post office MUST check the outgoing mail bag, remove the incorrect messages, re-create a new mail bag and deliver these messages to the correct post office. Since the original messages were accepted by the first post office, they can be safely discarded by the sending post office. 5.) Store the ExMP messages in the user's mailbox. 6.3.2. Transit If a post office needs to, or wants to deliver through a transit post office, it is said to be using "Transit Routing". Taylor Expires - October 2005 [Page 41] Extensible Mail Protocol (ExMP) October, 2004 In this mode the mail bags contain either messages destined for a remote office, declared in the mail bag header (section 9.9), or messages for multiple offices with no post office declared in the header. On reception of the mail bag the transit post office MUST perform the following; 1.) Check that the type is "TRANSIT". 2.) Check that the mail bag has NOT been received before. If it has then the mail bag MUST be discarded and the sending post office sent a warning code 411. The sending post office can safely ignore this warning. 3.) If the post office in the header is NULL, then either of the following options MUST be performed; a. Remove each message from the mail bag and create new mail bags for each unique destination. Each mail bag MUST contain messages destined for only one post office and the header MUST be correctly defined for the destination post office. b. Forward the mail bag in its entirety to another transit post office for it to process. 4.) If the post office in the header is NOT NULL. a. The Post office MUST perform the checks outlined in section 6.3.1, 4. b. Change the type to "DESTINATION" and forward the mail bag in its entirety to the destination post office. 7. SMTP Gateways In order to allow interoperability with the existing SMTP network, gateways to and from SMTP allow messages to pass seamlessly between the networks, retaining most of the information contained in an ExMP message. For a complete reference of requirements for an SMTP gateway refer to "Mail Gatewaying" in RFC 2822, section 3.8. 7.1. Authentication In order to maintain the integrity of ExMP messages, SMTP authentication [11] for client to post office MUST be enabled. Taylor Expires - October 2005 [Page 42] Extensible Mail Protocol (ExMP) October, 2004 This prevents unknown clients from accessing the SMTP server and "spoofing" someone else's email address. 7.1.1. Client Certificates Once the client has been authenticated, the use of client certificates will be superfluous since the client has already been authenticated. Implementations are free to include mapped client certificates if their gateway is on a separate or random machine and all processes accessing the web service requires a client certificate. 7.2. Translating RFC 2822 and MIME Fields RFC 2822 and MIME formatted messages [12] are the backbone of email today and MUST be seamlessly translated into any ExMP formatted message. While translating from a RFC 2822/MIME formatted message into an ExMP yields no information loss, translation from ExMP into RFC 2822/MIME does. The following sections describe which fields map from an RFC 2822/MIME formatted email to and ExMP message object. 7.2.1. Mappings 7.2.1.1. RFC 2822 Header Below is a table of directly translatable fields from a RFC 2822 email message header [13]; Subject - Header.Subject Date - Header.Date Sender - Header.Address.Sender From - Header.Address.From Reply-To - Header.Address.ReplyTo To - Header.Address.To Cc - Header.Address.Cc Bcc - Header.Address.Bcc The inverse is also true when mapping from an ExMP message to a RFC 2822 formatted message header. Any other fields that do not map directly to a pre-defined ExMP object attribute SHOULD be added as Meta Tag information in the Header. Examples of these types of fields include; - MIME-Version - Content-Type - Content-Transfer-Encoding - Content-Disposition Taylor Expires - October 2005 [Page 43] Extensible Mail Protocol (ExMP) October, 2004 - Return-Path - Message-ID - Any X field Original RFC 2822 Header ------------------------ Message-Id: <200409112323.i8BNNx702421> From: "John Smith" To: Subject: This is a test Date: Sun, 12 Sep 2004 09:42:22 +1000 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C498AC.CEA78B20" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSYWPu7b6knGLkURVGTWu8u+dv2pA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Translated ExMP Header ----------------------
0f10095f-a655-407a-a419-6c43fb95adf1
This is a test 2004-09-12T09:42:22+10:00
7.2.1.2. MIME Body 7.2.1.2.1. Unicode Taylor Expires - October 2005 [Page 44] Extensible Mail Protocol (ExMP) October, 2004 All implementations of ExMP MUST support Unicode strings and all text MUST be converted into the Unicode character set utf-8 before storing. 7.2.1.2.2. HTML When translating MIME HTML to an ExMP body, implementations MUST use the HtmlBody (section 9.8.1.2) object to store the data. Once the HTML data has been parsed from the MIME message implementations need only append this HTML body to the collection of block objects. Below are the mappings required for the MIME text to HTML body; - HtmlBody.data Original MIME Data ------------------ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Line of Text

Translated ExMP HTML Body ------------------------- QSBCb2R5IG9mIFRleHQNCg== 7.2.1.2.3. Text When translating MIME text to an ExMP body, implementations MUST use the TextBody (section 9.8.1.1) object to store the data. Once the text data has been parsed from the MIME message implementations need only append this text body to the collection of block objects. Below are the mappings required for the MIME text to text body; - TextBody.data Original MIME Data ------------------ Content-Type: text/plain; charset="utf-8" Taylor Expires - October 2005 [Page 45] Extensible Mail Protocol (ExMP) October, 2004 Content-Transfer-Encoding: 8bit Line of Text Translated ExMP Text Body ------------------------- QSBCb2R5IG9mIFRleHQNCg== 7.2.1.3. MIME Attachments When translating a MIME attachment to an ExMP attachment (section 9.7), the following fields can be directly mapped from the MIME block header to the ExMP attachment object; Content-Type - NewAttachment.Type Content-Type/name - NewAttachment.Source - NewAttachment.Data Any other information that is present in the MIME block header MUST be stored in meta tags. When storing the original attachment data, the data MUST be translated into its original binary format and stored in the ExMP attachment data attribute as SOAP will handle the encoding of the binary data during transportation. Original MIME Attachment ------------------------ Content-Type: text/plain; name="A file.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="A file.txt" This is a Line of Text Translated ExMP Attachment -------------------------- VGhpcyBpcyBhIExpbmUgb2YgVGV4dA== Taylor Expires - October 2005 [Page 46] Extensible Mail Protocol (ExMP) October, 2004 8. Error Handling The following sections define the two types of response mechanisms used in the ExMP network. The first are receipts, returned whenever a message or mail bag is delivered. The second are exceptions, thrown whenever a condition, outside of normal, is met. Implementations MUST handle all of the defined conditions and respond accordingly. 8.1. Receipts Receipt codes are separated into three categories; - Informational Codes - Warning Codes - Error Codes Each one has its own separate range of values. 8.1.1. Informational Codes Informational codes are generally for the benefit of the sending post office or client. The defined range of values for informational codes are 200- 299. 8.1.1.1. 200-279 - Reserved These codes have been reserved. 8.1.1.2. 280-299 - Implementation specific These codes have been reserved for implementations to use at their discretion. If any of these codes are to be used in the public ExMP network then they MUST be documented and be made available for public consumption. 8.1.2. Warning Codes Warning codes generally are conditions which can be recovered from but are considered "abnormal". Generally, receiving these codes does not warrant resubmitting but logs should note the code and reason for it. The defined range of values for warning codes are 400-499. Taylor Expires - October 2005 [Page 47] Extensible Mail Protocol (ExMP) October, 2004 8.1.2.1. 400 - Insufficient randomness in message identifier This code is specified when the post office determines that the identifier in the message header (section 9.2) is not random enough and the chance of a duplicate message is high. 8.1.2.2. 401 - Insufficient randomness in mailbag identifier This code is specified when the post office determines that the identifier in the mail bag header (section 9.9) is not random enough and the chance of a duplicate mail bag is high. 8.1.2.3. 410 - Duplicate message detected This code is specified when a duplicate message has been detected from a client. Any message sent from a client MUST have a new message identifier (including resent messages). 8.1.2.4. 411 - Duplicate mailbag detected This code is specified when a duplicate mail bag has been detected. If a duplicate mail bag has been detected then the receiving post office MUST return this code to the sending post office, notifying them of the detection. 8.1.2.5. 420 - Incorrectly bagged messages detected This code is specified when a message, destined for another post office is sent in a mail bag to another post office. An example of this would be if a message destined for mailbox "user" at post office "foo.com" is bagged with messages sent to "bar.com". The post office "bar.com" returns this warning code to the sender informing them that the message was discarded and MUST be resent to "foo.com". 8.1.2.6. 480-499 - Implementation specific These codes have been reserved for implementations to use at their discretion. If any of these codes are to be used in the public ExMP network then they MUST be documented and made available for public consumption. 8.1.3. Error Codes The defined range of values for error codes are 500-599. 8.1.3.1. 500 - General server error Taylor Expires - October 2005 [Page 48] Extensible Mail Protocol (ExMP) October, 2004 This code is specified when a general server error occurs. A general error could be one where a server catches an internal error and cannot proceed with the current transaction. 8.1.3.2. 520 - Missing message identifier This code is specified when a message is posted to a post office without having defined a valid message identifier. 8.1.3.3. 521 - Missing subject This code is specified when a message is posted to a post office without a subject. 8.1.3.4. 522 - Missing date This code is specified when a message is posted to a post office without a valid date defined (section 13). 8.1.3.5. 530 - Missing mailbag identifier This code is specified when a mail bag is delivered to a post office without a valid mail bag identifier defined. 8.1.3.6. 531 - Missing mailbag destination This code is specified when a destination mail bag is missing a post office destination. If a post office is delivered a mail bag, marked as a "destination" mail bag and there is no post office specified, it MUST return this error code. For an explanation of the different types of mail bags refer to section 6.3. 8.1.3.7. 540 - Missing mailbox The code is specified when an "Address" object does not contain a valid mailbox attribute (section 9.3). 8.1.3.8. 541 - Missing post office The code is specified when an "Address" object does not contain a valid post office attribute (section 9.3). 8.1.3.9. 542 - Missing "from" address This code is specified when a message does not contain a valid "From" address. One of the message checks requires that at least one valid "From" address be specified. Taylor Expires - October 2005 [Page 49] Extensible Mail Protocol (ExMP) October, 2004 8.1.3.10. 543 - Missing recipient This code is specified when a message does not contain a valid address. One of the message checks requires that at least one valid recipient address be specified (section 11.1). 8.1.3.11. 544 - Invalid "sender" address This code is specified if a client attempts to send a message using one of the reserved mailbox accounts (section 4.4.2) as the "Sender". 8.1.3.12. 545 - Invalid "from" address This code is specified if a client attempts to send a message using one of the reserved mailbox accounts (section 4.4.2) as a "From" address. 8.1.3.13. 546 - Invalid post office This code is specified if an address post office of one of the "From" addresses or the "Sender" address does not match up to the post office holding the account. 8.1.3.14. 547 - Invalid destination post office This code is specified when a mail bag, marked as a destination, is sent to the wrong post office. An example of this would be if the mail bag's header contained a destination called "foo.com" and the mailbag is delivered to "bar.com". The receiving post office "bar.com" would return this error code to the post office which delivered the mail bag. 8.1.3.15. 580-599 - Implementation specific These codes have been reserved for implementations to be used at their discretion. If any of these codes are to be used in the public ExMP network then they MUST be fully documented and be made available for public consumption. 8.2. SOAP Exceptions The use of SOAP exceptions provides a common framework for delivering error conditions to clients. If the client attempts to perform a task which is considered "incorrect" or "out of context" then post offices MUST throw an exception. This also builds on the idea of the SOAP layer passing back exceptions in the case of system error states being encountered. Below are Taylor Expires - October 2005 [Page 50] Extensible Mail Protocol (ExMP) October, 2004 the set of post office generated exceptions which MUST be generated, if the situation arises. 8.2.1. Error Codes Error codes for exceptions are broken up into categories which allow for expansion with future protocol versions. 8.2.1.1. 500 - General server error This exception is thrown by a post office if it encounters an internal server error during processing. If the post office is processing and catches an internal error which it cannot recover from, it MUST return this exception, letting the client know that the last transaction has failed and SHOULD be re- tried. 8.2.1.2. 550 - Invalid or missing client certificate This exception is thrown whenever a client attempts to execute a method without a valid client certificate. Implementations MUST check the client certificate according to section 4.1.3.1 and failing any of the criteria specified, throw an exception containing this error code. If this error persists, clients may need to request a new certificate or contact the post master. 8.2.1.3. 551 - Certificate error This exception is thrown if a post office has an error while generating a client certificate. When a client requests either a new account or a new certificate, a client certificate needs to be generated. During this certificate generation the post office may encounter an error, preventing the creation of the certificate. This exception MUST be thrown by the post office, informing the client that the request needs to be re-generated. 8.2.1.4. 570 - Invalid user name or identifier This exception is thrown whenever a client attempts to access the post office with an invalid user name. Implementations MUST throw this exception if the client's user name or identifier cannot be matched against an internal list of known clients. 8.2.1.5. 571 - Invalid password This exception is thrown whenever a client enters an incorrect password against a valid user name or identifier. Implementations MUST throw this exception if the client's Taylor Expires - October 2005 [Page 51] Extensible Mail Protocol (ExMP) October, 2004 password does not match up against his/her internally stored password. 8.2.1.6. 610 - Invalid client information This exception is thrown during an account creation or certificate request. A client MUST generate his/her own request for a client certificate, this makes him/her responsible for the content that is added to the request. When a malformed or invalid request is sent to the post office, the post office MUST throw this exception back to the client, informing him/her of the failure reason. 8.2.1.7. 640 - Session not established This exception is thrown whenever a client tries to access a post office method without establishing his/her credentials. A client MUST open a mailbox before he/she is allowed access to the messages stored in that mailbox. If the client attempts to access a method outside a session, the server MUST throw this exception to inform the client that his/her state is invalid. 8.2.1.8. 650 - Account exists This exception is thrown when a client requests a new account from a post office and the account already exists. Before a post office creates an account it MUST check to see that the account does not already exist. If the account exists the post office MUST throw this exception, informing the requestor that the account already exists and he/she must select an alternative. 9. ExMP Objects Specifications This section will describe each of the ExMP objects and attributes in detail. Many languages are able to create a complete object hierarchy directly from the WSDL specification (Appendix A) and their relevant documentation SHOULD be consulted. 9.1. Message This object represents a complete ExMP message object which is essentially the glue binding all the other parts of the ExMP message together. If for any reason this object is incomplete or incorrect, the message MUST be rejected and the sending party notified. Attributes Taylor Expires - October 2005 [Page 52] Extensible Mail Protocol (ExMP) October, 2004 ---------- Header[] Header - This attribute defines the source, destination and meta information for the message. This is not an optional attribute and must be a valid object containing valid addresses and meta information before being sent. Attachment[] Attachments - This attribute defines a collection of binary objects that can be sent with the message. This is an optional attribute and may be left NULL when sending the message. Block[] Blocks - This attribute defines a collection of block objects which contain the messages being sent to the end post office or person. These blocks may contain confirmations, text, html, voice or video. This is not an optional attribute and must be a valid object containing at least one block of information before being sent. Message ResponseTo - This attribute defines the message to which this one is referring to. For example, if a person replies to a message, this attribute MAY contain the original message. This is an optional attribute and may be left NULL when sending the message. 9.2. Header This object contains all of the source, destination and meta information associated with the ExMP message it is contained within. Whenever a message is constructed the "Header" object MUST contain all of the information a post office would need to process and send that message. If for any reason this object is incomplete or incorrect, the message MUST be rejected and the sending party notified. Attributes ---------- Guid MessageId - This attribute defines the globally unique identifier of the message. This identifier MUST be machine generated and MUST be as unique as possible. If an implementation is lazy in the generation of this value, the chance exists of a duplicate message being detected and deleted (see section 6.2.6). This is not an optional attribute and must be automatically generated whenever a header is created. Address[] Addresses - This attribute defines a collection of addresses that relate the message being sent. Each and every message MUST have at least one "From" (section 9.3.1) address Taylor Expires - October 2005 [Page 53] Extensible Mail Protocol (ExMP) October, 2004 and one recipient (section 9.3.2) defined. This is not an optional attribute and must have at least 2 entries added before the message is sent. string Subject - This attribute defines the subject of the message being sent. This is not an optional attribute and must be specified before the message is sent. string Date - This attribute defines the date/time stamp when the message was sent from the client. This date MUST conform to the date/time format specified in section 13. MetaTag[] MetaTags - This attribute defines a collection of meta information pertaining to the current message. This is an optional attribute and may be left NULL when creating the header. Segment Segment - This attribute defines a segment in a multi- segmented message. For information of how to use this attribute, refer to message segmenting (section 4.5.2). This is an optional attribute and may be left NULL when creating the header. 9.3. Address (abstract) This object defines an abstract address which is used in the routing of the message as well as the identification of the sending person(s). ExMP makes use of the current email address standard (RFC 2822), breaking up the components into 3 distinct parts; - Display Name - Mailbox - Post Office Each one of these parts contains the information necessary to rebuild a standard RFC 2822 email address in the format; "Name" @ For interoperability with the existing mail network. Note: This is an abstract object and cannot be instantiate on its own. Attributes ---------- Taylor Expires - October 2005 [Page 54] Extensible Mail Protocol (ExMP) October, 2004 string DisplayName - This attribute defines the "human readable" name of the address. This value usually appears in client programs as it is easier to read than a mailbox name. An example of a valid display name might be "John Smith". This is an optional attribute and may be left NULL when creating the address. string Mailbox - This attribute defines the actual physical mailbox on the post office. Unlike the display name, this value may or may not be in a format that is easily read by a person. It could be a unique identifier that is generated when the client's account is created. An example for a valid mailbox name might be "jsmith0043". This is not an optional attribute and must be a valid value that points to a real or virtual mailbox on a post office. string PostOffice - This attribute defines the physical post office where the above mailbox resides. When a post office determines the node for this message, it will look at this value and perform a lookup of the physical address of the node. An example for a valid post office might by "example.net". This is not an optional attribute and must be a valid post office name. MetaTag[] MetaTags - This attribute defines a collection of meta information pertaining to the above address. Extra information that could be included in this collection might be objects such as address information or pictures. This is an optional attribute and may be left NULL when creating the Address. 9.3.1. From This class overrides an Address object and defines a "From" address. This address defines the actual person or people from which the message is. This is not to say that the message was actually sent by them, but it was authorized by them. In any message you may wish to have multiple "From" addresses denoting that the message is from multiple people. A common situation for this could arise when a group of managers send a common message to all employees. All of the managers' email addresses would appear in the "From" field but the sender may be another person (e.g. an assistant) with the Reply address yet someone else again. For a complete description of sending address variations refer to section 4.4.1. Attributes ---------- Taylor Expires - October 2005 [Page 55] Extensible Mail Protocol (ExMP) October, 2004 bool Replyable - This attribute defines whether or not the address contained in the message can be replied to or not. This flag MUST be set to false if the mailbox indicated in the address cannot accept incoming messages. 9.3.1.1. Sender This class overrides a "From" address and defines a "Sender" address. There can only be one actual sender of a message but as the above case states there could be multiple "From" addresses. Post office nodes MUST make sure that if a Sender address is present, then there MUST ONLY be only one. For a complete description of sending address variations refer to section 4.4.1. 9.3.2. To This class overrides an address object and defines a direct address. When sending a message to a remote mailbox, the sending party defines "To" addresses to which the message will be delivered directly. Each person on the "To" address list is visible to each receiver of the message and care must be taken if privacy is required. 9.3.2.1. ReplyTo This class overrides a "To" address and defines a "ReplyTo" address. Under certain circumstances one may want to have all replies sent to an automated mailbox and not the original sender's address. An example of this might be when the manager of a department sends a message to all department employees asking for some information; if the "ReplyTo" field is set to his/her secretary, then he/she will receive all the replies and not the manager. For a complete description of sending address variations refer to section 4.4.1. 9.3.2.2. Cc This class overrides a "To" address and defines a Carbon Copy or "Cc" address. When sending a message to a remote mailbox, the sending party defines "Cc" addresses to which the message will be delivered indirectly. Each person on the "Cc" address list is visible to each receiver of the message and care must be taken if privacy is required. 9.3.2.2.1. Bcc This class overrides a "Cc" address object and defines a Blind Carbon Copy or "Bcc" address. When sending a message to a Taylor Expires - October 2005 [Page 56] Extensible Mail Protocol (ExMP) October, 2004 remote mailbox, the sending party defines "Bcc" addresses where the message will be delivered indirectly and without any other receiving party seeing the "Bcc" addresses. This effectively allows a person to receive an email and not have his/her email address disclosed. 9.4. MetaTag This object defines a Meta Tag object which allows many of the objects in a message to better describe their internal content. Meta tags allow messages to include information in a logical clear manner, where it otherwise might not be. For an explanation on meta tags use, refer to section 10. Attributes ---------- string Name - This attribute defines the name of the meta tag data which is contained. This is not an optional attribute and must be a completed for all meta tag objects. string Value - This attribute defines the data in which the above name refers to. This data can be any string or encoded data. This is not an optional attribute and must be completed for all meta tag objects. 9.5. PostOffice This object defines a post office which participates in the ExMP network. This object is primarily associated with a mail bag which is passed from post office to post office. Attributes ---------- Guid Id - This attribute defines a globally unique identifier of a post office node. Each node on the network MUST have a unique identifier, generated locally at the time of installation. This identifier can be used in fast hash table lookups for routing purposes. This is an optional attribute but SHOULD be completed on all outgoing transactions. string Name - This attribute defines a physical post office name. This name MUST be the same name that is present in the DNS MX record lookup. This is not an optional attribute and must be completed for all transactions. 9.6. Segment Taylor Expires - October 2005 [Page 57] Extensible Mail Protocol (ExMP) October, 2004 This object defines a segment in a segmented message. If a message exceeds the maximum message size defined in section 4.5.1 and needs to be segmented, this object defined which portion of the message is contained in the body. For an in- depth explanation of message segmenting refer to section 4.5.2. Attributes ---------- Guid MessageId - This attribute defines which message, contained in the body, this segment refers to. When the message segments arrive at the remote post office or client, this value is used to determine which message to apply the segment to. This is not an optional attribute and must be completed for all segments. string SegmentedBy - This attribute defines who segmented the message and who SHOULD be notified if any of the segments are missing. Possible values for this attribute can include the post office (example.net) or a mailbox (jsmith@example.net). This is not an optional attribute and must be completed for all segments. int Part - This attribute defines which part of the segmented message is contained in this message. This value MUST start from the value 1 and reach a maximum defined in the "Total" attribute. This is not an optional attribute and must be completed for all segments. int Total - This attribute defines the total segments in which the original message has been split. This value is 1 based and MUST be exactly the number of parts. For example, if the message was split into 8 parts then this value must be equal to 8. This is not an optional attribute and must be completed for all segments. 9.7. Attachment This object defines an attachment which can be sent with a message. Attachments are a way of delivering binary content to a remote mailbox. Attachments can be an assortment of objects, ranging from files to video or voice. Attributes ---------- string Source - This attribute defines the original name which the attribute was called. For a file this may be the filename, for voice this might be the date and time of the recording. Taylor Expires - October 2005 [Page 58] Extensible Mail Protocol (ExMP) October, 2004 Care must be taken when sending original filenames, making sure that the preceding path has been stripped off the name before it is sent. An example of this might be when sending a PNG format binary image. This attribute could show the filename or name of the picture, "me.png" or just "my picture". This is an optional attribute and may be left NULL when creating the attachment. string Type - This attribute defines the MIME type identifying the use of the attachment. An example of this might be with the above PNG format picture, this value would be "image/png". This is not an optional attribute and must be completed for all attachments. long Size - This attribute defines the size of the attachment and aids in the determination of the size of attachment without checking the binary data buffer. This size MUST be the exact size of the attachment in octets, after the buffer is filled. This is not an optional attribute and must be completed for all attachments. Byte[] Data - This attribute defines the actual binary data which is associated with the attachment. On reception, this data may be streamed to an external device and MUST be an exact, unmodified copy of what was read. This is not an optional attribute and must be completed for all attachments. MetaTag[] MetaTags - This attribute defines a collection of meta information pertaining to the above attachment. This may be extra information about the encoding of data, format of the data or even what it is to be used for. This is an optional attribute and may be left NULL when creating the attachment. 9.8. Block (abstract) This object defines an abstract block which is used as a base information object in an ExMP message. Attributes ---------- MetaTag[] MetaTags - This attribute defines a collection of meta information pertaining to the deriving object. An example of this would be if the data buffer contained an audio message recorded from a telephone answering machine. The meta tags could detail the exact specifics of the message including the format of the audio being sent over. This is an optional attribute and may be left NULL when creating the block. Taylor Expires - October 2005 [Page 59] Extensible Mail Protocol (ExMP) October, 2004 9.8.1. Body This object overrides a block object and defines a body of information that will be sent to remote mailboxes. A body of information could be conceived as anything that sends a message or informs a person. This could include things like text, html, voice or video. The specifics of what is sent, is not bound to this object. This means , theoretically, anything could be sent. There are, however, two derived objects which are specific implementations of a technology, TextBody and HtmlBody. Each respectively handles a slightly different type of text data. Attributes ---------- Byte[] Data - This attribute defines a buffer of data which contains a message of some description. Using the meta tags, the data sent in this buffer could be anything. This is not an optional attribute and must be completed for all bodies. 9.8.1.1. TextBody This object extends a body object, adding a description of the type of text that is being sent in the body. Implementations MUST use this object whenever sending text messages as this object could be expanded for future versions of the protocol. 9.8.1.2. HtmlBody This object extends a TextBody object, allowing for simple object identification between a Text and Html Body. Implementations MUST use this object whenever sending HTML messages as this object could be expanded for future versions of the protocol. 9.8.2. Confirmation This object overrides a block object and defines a confirmation object. This object is used primarily by post offices confirming the reception of messages to the sending post office. Attributes ---------- Guid MessageId - This attribute defines the globally unique identifier of the message which the confirmation represents. Taylor Expires - October 2005 [Page 60] Extensible Mail Protocol (ExMP) October, 2004 This is not an optional attribute and MUST be the same identifier of the message which it represents. 9.8.2.1. EndPointAcceptance This object extends a Confirmation object, defining an EndPointConfirmation object. When a message arrives at its final destination and is accepted by the remote post office and mailbox, the receiving post office generates an end point confirmation (section 6.2.2), sending is back to the sending post office. Once the sending post office receives this confirmation it can clear the message out of its dispatch area. 9.8.2.2. EndPointRejection This object extends a "Confirmation" object, defining an EndPointRejection object. When a message arrives at its final destination, it may be rejected by the post office or by the mailbox. The receiving post office generates an end point rejection (section 6.2.2) with a reason which is returned to the sending post office. Once the sending post office receives this rejection it can clear the message out of its dispatch area and notify the sender of the rejection. Attributes ---------- String Reason - This attribute defines the reason for the message rejection. This message MUST be in clear "English" text as it will be passed to the originator of the message. The reason for the rejection MUST be as detailed as possible as to allow the sender to understand why the message was rejected. This is not an optional attribute and must be defined for any end point rejection that is sent back. 9.8.2.3. DeliveryConfirmation This object extends a "Confirmation" object, defining a DeliverConfirmation object. When a message has been delivered successfully or unsuccessfully to the remote post office, a message with this confirmation is sent to the sender of the message. For an explanation of this process refer to section 6.2.3. Attributes ---------- String DateDelivered - This attribute defines the timestamp of when the message was delivered to the post office. This is not Taylor Expires - October 2005 [Page 61] Extensible Mail Protocol (ExMP) October, 2004 an optional attribute and MUST be defined according to the format in section 13. 9.8.2.4. CollectedConfirmation This object extends a "Confirmation" object, defining a CollectedConfirmation object. When a message has been collected by the intended recipient, a collected timestamp is generated by the post office. This confirmation may or may not be returned to the originator of the message by the post office. For an explanation of this process refer to section 6.2.4. Attributes ---------- String DateCollected - This attribute defines the timestamp of when the message is collected from the post office. This is not an optional attribute and MUST be defined according to the format in section 13. 9.8.2.5. ReadConfirmation This object extends a "Confirmation" object, defining a ReadConfirmation object. When a message has been read by the intended recipient, a read timestamp is generated by the client's mail program. This confirmation may or may not be returned to the originator of the message by the client's program or the post office. For an explanation of this process refer to section 6.2.5. Attributes ---------- String DateRead - This attribute defines the timestamp of when the message was read by the recipient. This is not an optional attribute and MUST be defined according to the format in section 13. 9.9. Mailbag This object defines a mail bag which is in essence a collection of messages all traveling to (or via) a post office. Constants --------- BagType.DESTINATION - This constant indicates that the post office to which this mail bag will be traveling will be the Taylor Expires - October 2005 [Page 62] Extensible Mail Protocol (ExMP) October, 2004 final destination. Once the mailbag has been posted, none of the messages contained will travel any further. BagType.TRANSIT - This constant indicates that next post office in which this mail bag arrives will be a transit office. Each one of the messages will be forwarded to either another transit post office or a destination post office. Attributes ---------- Guid MailbagId - This attribute defines the globally unique identifier of the mail bag. This identifier MUST be machine generated and MUST be as unique as possible. If an implementation is lazy in the generation of this value a duplicate mailbag may be detected and deleted (see section 6.2.6). This is not an optional attribute and must be automatically generated whenever a mail bag is created. PostOffice Destination - This attribute defines the final destination of the mail bag. This attribute MUST NOT indicate the next hop in the routing of the mail bag but the destination where it will finally arrive. This is not an optional attribute when delivering a DESTINATION mail bag and must be defined before a mail bag is delivered. In the case of a TRANSIT mail bag this attribute can be left NULL. PostOffice[] PostOffices - The attribute defines a collection of post offices through which this mail bag has traveled, aiding in the detection of routing loops. Before a mail bag is delivered, the sending post office MUST append itself to this collection. For a detailed explanation of routing refer to section 6. This is not an optional attribute and must be appended to before a mail bag is delivered. BagType Type - The attribute defines the type of mail bag routing that is to be used. Refer to the above constants for an explanation of possible values. This is not an optional attribute and must be set before a mail bag is delivered. Message[] Messages - This attribute defines the collection of ExMP messages which need to be delivered to the remote post office. These messages might all be destined for a single post office, in the case of a DESTINATION mail bag, or might be a collection of TRANSIT messages being routed through a routing post office. Each of these messages MUST be complete and checked according to section 11.1 before the mailbag is sent. This is not an optional attribute and must contain at least one message before a mail bag is delivered. Taylor Expires - October 2005 [Page 63] Extensible Mail Protocol (ExMP) October, 2004 MetaTag[] MetaTags - This attribute defines a collection of meta information pertaining to the above mail bag. Meta information that might be deemed pertinent could be details about the sending post office, statistics on the mailbag size or even security information, preventing mail bag content modification. This is an optional attribute and may be left NULL when creating the mail bag. 9.10. Result This object defines a result object, used to return result codes and descriptions to remote post offices after a server operation. While this object is usually not used directly, two derivatives, MessageReceipt and MailbagReceipt are. Attributes ---------- int Code - This attribute defines a numerical code which will denote a response from the post office. This code can be correlated against the table of know responses in section 8.1. This is not an optional attribute and must be completed for all result objects (including derivate objects). string Description - This attribute defines a detailed description of the above error code which may be locale specific. Due to locale issues this is an optional attribute and may be left NULL when creating result objects (including derivate objects). 9.11. MessageReceipt This object extends a "Result" object and defines a receipt that is received by a client whenever he/she posts a message to the sever via the post method (section 5.4.2.2.1.1). Attributes ---------- Guid MessageId - The attribute defines the message identifier (section 9.2) to which this receipt refers to. 9.12. MailbagReceipt This object extends a "Result" object and defines a receipt that is received by a post office whenever it delivers a mailbag to another post office via the deliver method (section 5.4.2.2.1.2). Taylor Expires - October 2005 [Page 64] Extensible Mail Protocol (ExMP) October, 2004 Attributes ---------- Guid MailbagId - The attribute defines the mailbag identifier (section 9.9) which this receipt refers to. 9.13. ServiceRequest This object defines a service request object, used in the request for a new account or in the generation of a new client certificate. This object MUST be fully completed and sent to the server. Attributes ---------- string Name - This attribute defines the name which will be associated with the account, appearing in the "Display Name" attribute of the address object. Implementations may choose to use this name as the unique identifier. string EmailAddress - This attribute defines the email address that MUST be created by the post office. This address is the real world email address from which messages will be sent. This email address MUST match that contained in the returned client certificate. string Password - This attribute defines the password which the mailbox will be bound to. This password will be used in all credential checks on the post office. string PKCS10 - This attribute defines a PKCS10 format request for a client certificate. This request MUST be generated on the client's machine and will be bound to that machine. While generation of this request is outside the scope of this document, the request MUST contain the data outline in section 4.1.3.1. MetaTag[] MetaTags - This attribute defines a collection of meta information pertinent to the request. Meta information sent with the request could be some type of billing information, in the case of a signup service, or might just be extra information about the requesting client. This is an optional attribute and may be left NULL when creating the attachment. 9.14. MailboxInfo Taylor Expires - October 2005 [Page 65] Extensible Mail Protocol (ExMP) October, 2004 9.15. SysInfo This object defines a system information object, used when a client or post office requests information about a post office. Attributes ---------- PostOffice PostOffice - This attribute defines the current post office's name and unique identifier (section 9.5). bool WillTransit - This attribute defines a flag indicating whether or not the post office is willing to transit mail bags or not. If this flag is true, the post office will accept a mail bag and forward the contained messages to their respective destinations. If this flag is false, the post office will reject transit mail bags with an error. long MaxMessageSize - This attribute defines the maximum message size which it is willing to handle. A post office may choose to handle smaller messages than the defined standard (section 4.5.1). This attribute allows the sending post office to segment messages based on this value. Note: This value normally should not be smaller than the standard. long MaxSpeed - This attribute defines the maximum speed of the public network link in bits per second. This value allows a remote post office to determine the fastest link for a list of known routes. MetaTag[] MetaTags - This attribute defines a collection of meta information pertinent to the system information. This collection might contain custom information which concerns only this post office. All data here MUST be fully documented in the post office documentation (section 5.1). This is an optional attribute and may be left NULL when creating the object. 10. Extending Meta Tags Meta tags are designed to allow extensibility when sending messages from one user to another. Below are some examples of extra meta information which could be sent with a message. When sending meta information it is vitally important that the information be presented in a way that it is easily identifiable and decodable. The "Name" field MUST depict exactly what is being stored in the meta tag and the "Value" must be a specific comma separated format. Taylor Expires - October 2005 [Page 66] Extensible Mail Protocol (ExMP) October, 2004 Format ------ Value= /> type = Type of meta information which is being sent. attribute = Attribute helping in the decoding of the data. data = Encoded data which is being sent. 10.1. Adding Pictures Pictures can be added to address meta tags, allowing a company to send a logo along with an informational message. In order for the picture to be sent correctly and decoded, the following attributes MUST be included in the meta tag value field; MetaTag Name ------------ picture Attributes ---------- 1. This is the format of the binary data being sent. This can be of any type but SHOULD be an easily identifiable standard (bmp, png, jpeg, etc). 2. Encoding technique in which the binary data is converted into a string representation. The encoding can be of any type but SHOULD be an easily identifiable standard (Base64, Hex, Uuencode, etc). 3. This is the binary picture encoded in the above format. Example -------
Taylor Expires - October 2005 [Page 67] Extensible Mail Protocol (ExMP) October, 2004 10.2. Adding Contact Details Contact details can be added to address meta tags, allowing a person to send his/her contact details embedded in the address. This allows the receiving program to simply retrieve the contact details from the address object and import them directly into a contacts database. Below is an example; Example -------
11. ExMP Standards 11.1. Message Checks Before a message is sent in the ExMP network, post offices MUST perform a series of sanity checks on the message to make sure that it conforms to below standards. If ANY of the checks fail, the message MUST be rejected. Failing to reject an invalid message circumvents the purpose of securing the network. Below are the minimum checks that each and every post office accepting messages directly from a client MUST perform; 1.) The header MUST contain a suitably random Message Id, subject and date. 2.) Every address MUST contain both a complete mailbox and post office attribute. The noticeable exception to this rule is when end point confirmations are sent (section 6.2.2) and the destination address is the post office only. 3.) The message MUST contain at least one valid "From" address. 4.) There can only be one "Sender" address defined (if at all). 5.) Both the "Sender" or "From" addresses MUST match up to the sending post office's name and ALL MUST have a valid account in the post office. Taylor Expires - October 2005 [Page 68] Extensible Mail Protocol (ExMP) October, 2004 6.) The above user MUST match the name on the client certificate. The obvious exception to this rule is if a gateway is used and no client certificate has been passed. Then this rule can be ignored. 7.) The "Sender" cannot be a reserved mailbox (section 4.4.2) or a virtual mailbox (section 4.4.3). 8.) There MUST be at least one recipient (To,Cc,Bcc) defined. 9.) At least one body object MUST be defined. 11.2. Mail Bag Checks Before a mail bag is accepted the receiving post office MUST perform a series of sanity checks on both the mail bag and the contained messages. If ANY of the checks fail, the mail bag MUST be rejected. This allows the sending post office to check the contents of the mail bag and resend it once the error has been corrected. AT NO STAGE SHOULD THE RECEIVING POST OFFICE ACCEPT A MAIL BAG AND REMOVE ANY MESSAGES FAILING CHECK 6. 1.) The header MUST contain a suitably random Mailbag Id. 2.) If this is a destination mail bag then the destination post office MUST be defined in the header. If it is a transit mail bag then the destination may be NULL according to section 6.3.2. 3.) The sending post office MUST have a valid DNS MX record. The obvious exception to this rule is if a gateway is used and the process is on a "known" machine. The IP address should be configured in the post office and this check can be bypassed. 4.) The mail bag has not been seen by this post office before. This check can concern both the mail bag identifier or the collection of post offices in the PostOffices attribute in the header. 5.) The mail bag contains at least one message. 6.) Each contained message MUST conform to check 1, 2, 3, 4, 7 and 8 of section 11.1. Taylor Expires - October 2005 [Page 69] Extensible Mail Protocol (ExMP) October, 2004 11.3. Message Delivery 11.3.1. Maximum Retry Time Implementations are free to decide on how regular a message send retry is performed, but the maximum retry attempt time is 7 days. After this period the post office holding the message MUST notify the sender of the failure. 12. Security Considerations In any public system one needs to consider security and just how secure a system is. This can be as simple as the inspection of a message on a post office to as complex as hijacking a person's identity and using it for malicious purposes. The following section discusses some of the identified areas in the ExMP design where security could be considered an issue. 12.1. Account Creation If a post office provides the ability for clients to create accounts dynamically then the post office may need to consider the possibility of a "denial of service" attack. The possibility exists of a remote attacker flooding the post office with fictitious account requests, overflowing the client certificate generation and storage resources. One possible solution is to populate the service request object meta tags (sction 9.13) with security credentials. These security credentials may need to exist in another service method not defined in this version of the protocol. 12.2. Message Persistence While it is possible to encrypt transmission via a public link, somewhere along the line the data must be converted into a plain text representation for processing. In this state the messages could be considered to be vunerable to both inspection and modification. Possible solutions to this may be with the introduction of an encrypted body object (section 9.8.1) or the WS-Security [14] and encrypted data blocks. 12.3. X.509 Certificates The security considerations of X.509 certificates themselves are outside the scope of this document. For any information concerning X.509 certificates refer to RFC 2459, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile". Taylor Expires - October 2005 [Page 70] Extensible Mail Protocol (ExMP) October, 2004 12.3.1. Client Certificates The theft of a client's certificate must also be considered when the client stores his/her certificate on a remote machine. While binding of this certificate to a single machine does prevent the theft of the actual certificate, regeneration of the certificate from another machine does not. The post office has no real way of determining whether the user of the certificate is actually the person whose account it is. Once a certificate has been issued, the post office must assume that the person using it is the actual account holder. 12.3.1.1. Issuing Authorities A standard list of reputable issuing authorities exists but it is entirely possible for an attacker to coerce a post office administrator to add him to their root server's list. This provides a potential security hole as that person may then issue client certificates to non-trusted nodes. These nodes, using the modified post office as a relay could inject "valid" messages into the network. 12.3.1.2. Issuing from Server Whenever a client certificate is issued from the server, there exists a potential security issue. Access to the client certificate generation routines MUST be kept private and away from any possibility for public access. All data MUST be completely verified before the client certificate is generated. If a client certificate is revoked, then it MUST be removed from any storage device and invalidated on the issuing post office. 12.4. DNS The openness of DNS makes it the most vulnerable to modification. DNS MX records could easily be modified, redirecting valid mail to another IP address. Before a client or post office attempts to send a message or mail bag, he MUST make sure that the server certificate is valid in every respect. Securing MX records is beyond the scope of this document. 12.5. Messages It is entirely possible for a post office to ignore all of the checks outlined in section 11.1. For this reason a potential loophole in the security could be found. Without every post office checking the validity of every message against the Taylor Expires - October 2005 [Page 71] Extensible Mail Protocol (ExMP) October, 2004 sending post office, this is a problem that exists. The onus will be on the post office accepting client messages to ensure that any messages that it accepts are true and valid. If for any reason a post office is found to be injecting spam in invalid messages, it runs the risk of having its certificates revoked, effectively removing it from the network. 13. Formal Syntax All date and time formats MUST be presented in ISO 8601 [15] format, as shown below; YYYY-MM-DDThh:mm:ssTZD Where ----- YYYY - four-digit year MM - two-digit month (01=January, etc.) DD - two-digit day of month (01 through 31) hh - two digits of hour (00 through 23) (am/pm NOT allowed) mm - two digits of minute (00 through 59) ss - two digits of second (00 through 59) TZD - time zone designator (+hh:mm or -hh:mm) Example ------- 2004-09-19T15:15:34+10:00 14. Reference 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Klensin, J.(Editor), "Simple Mail Transfer Protocol", RFC 2821, AT&T Laboratories, April 2001 3 Myers, J. and Rose, M., "Post Office Protocol - Version 3", RFC 1939, Carnegie Mellon and Dover Beach Consulting, Inc., May 1996 4 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 2060, University of Washington, December 1996 Taylor Expires - October 2005 [Page 72] Extensible Mail Protocol (ExMP) October, 2004 5 Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J. and Nielsen, H., "SOAP Version 1.2", http://www.w3.org/TR/soap/, Microsoft, Sun Microsystems, IBM and Canon, June 2003 6 Rescorla, E., "HTTP Over TLS", RFC 2818,RTFM Inc., May 2000 7 ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997 Housley, R., Ford, W., Polk, W. and Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, SPYRUS, VeriSign, NIST and Citicorp, January 1999 8 Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, Internet Mail Consortium, February 2002 9 Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, ISI, November 1987 Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC 1035, ISI, November 1987 10 Partridge, C., "MAIL ROUTING AND THE DOMAIN SYSTEM", RFC 974, CSNET CIC BBN Laboratories Inc, January 1986 11 Myers, J. "SMTP Service Extension for Authentication", RFC 2554, Netscape Communications, March 1999 12 Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft and First Virtual, November 1996 Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and First Virtual, November 1996 Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RCF 2047, University of Tennessee, November 1996 Freed, N., Klensin, J. and Postel, J., "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, Innosoft, MCI and ISI, November 1996 Taylor Expires - October 2005 [Page 73] Extensible Mail Protocol (ExMP) October, 2004 Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, Innosoft and First Virtual, November 1996 13 Resnick, P. (Editor), "Internet Message Format", RFC 2822, QUALCOMM Incorporated, April 2001 14 Kaler, C. (Editor), Atkinson, B., Della-Libera, G., Hada, S., Hondo, M., Hallam-Baker, P., Klein, J., LaMacchia, B., Leach, P., Manferdelli, J., Maruyama, H., Nadalin, A., Nagaratnam, N., Prafullchandra, H., Shewchuk, J., Simon, D., "Specification: Web Services Security (WS-Security)", http://www- 106.ibm.com/developerworks/webservices/library/ws-secure/, Microsoft, IBM and VeriSign, April 2002 15 "ISO 8601 Date/Time format", http://www.w3.org/TR/NOTE- datetime 15. Acknowledgments Firstly, I would like to thank my family, especially my wife Elizabeth, who has had to put up with the long hours of research and development required to complete this document. Secondly, I would like to thank Dr Paul Watters of Macquarie University in Sydney for all of his help and support while writing this document and lastly, James Bourne, of Sublime Solutions for all of his support and input during the development cycle of this document. 16. Author's Addresses Steven Taylor Sublime Solutions Pty Ltd PO Box N660 Grosvenor Place NSW 1220 Australia Email: steven@sublime.com.au Appendix A. WSDL Taylor Expires - October 2005 [Page 74] Extensible Mail Protocol March 2005 A.1. Account.soap Taylor Expires - October 2005 [Page 75] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 76] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 77] Extensible Mail Protocol March 2005 A.2. Postoffice.soap Taylor Expires - October 2005 [Page 78] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 79] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 80] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 81] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 82] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 83] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 84] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 85] Extensible Mail Protocol March 2005 A.3. Mailbox.soap Taylor Expires - October 2005 [Page 86] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 87] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 88] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 89] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 90] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 91] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 92] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 93] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 94] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 95] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 96] Extensible Mail Protocol March 2005 A.4. Service.soap Taylor Expires - October 2005 [Page 97] Extensible Mail Protocol March 2005 Taylor Expires - October 2005 [Page 98] Extensible Mail Protocol March 2005 Appendix B. Sample Messages B.1. ExMP Message
0f10095f-a655-407a-a419-6c43fb95adf1
This is a test 2004-09-12T09:42:22+10:00
Taylor Expires - October 2005 [Page 99] Extensible Mail Protocol March 2005 VGhpcyBpcyBhIExpbmUgb2YgVGV4dA== QSBCb2R5IG9mIFRleHQNCg==
B.2. Mail Bag 425e5a32-a462-403b-9560-fcdc0a67db22 1d0107bf-68ab-4394-a5f1-2c1d337a65e7 exmp.net 20c7f67e-e96f-49d2-ae3e-97513e5c27c8 foo.com e69e9c3b-bf85-4d96-8ac7-1d903d775654 bar.com
0f10095f-a655-407a-a419- 6c43fb95adf1
This is a test 2004-09-12T09:42:22+10:00 Taylor Expires - October 2005 [Page 100] Extensible Mail Protocol March 2005
VGhpcyBpcyBhIExpbmUgb2YgVGV4dA== QSBCb2R5IG9mIFRleHQNCg==
DESTINATION
Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Taylor Expires - October 2005 [Page 101] Extensible Mail Protocol March 2005 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.