Internet DRAFT - draft-taylor-exmp
draft-taylor-exmp
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
----------------
<?xml version="1.0"?>
<Message xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<MessageId>0f10095f-a655-407a-a419-6c43fb95adf1</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com" Replyable="true"
/>
Taylor Expires - October 2005 [Page 17]
Extensible Mail Protocol (ExMP) October, 2004
<Address xsi:type="To" DisplayName=""
Mailbox="draft.editor" PostOffice="exmp.net" />
</Addresses>
<Subject>This is a test</Subject>
<Date>2004-09-12T09:42:22+10:00</Date>
</Header>
<Blocks>
<Block xsi:type="TextBody">
<Data>QSBCb2R5IG9mIFRleHQNCg==</Data>
</Block>
</Blocks>
</Message>
Segment 1
---------
<?xml version="1.0"?>
<Message xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<MessageId>c8239767-57b4-4843-ac83-14e1bf7ff2d9</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com" Replyable="true"
/>
<Address xsi:type="To" DisplayName=""
Mailbox="draft.editor" PostOffice="exmp.net" />
</Addresses>
<Subject>This is a test</Subject>
<Date>2004-09-12T09:42:22+10:00</Date>
<Segment Part="1" Total="2">
<MessageId>0f10095f-a655-407a-a419-
6c43fb95adf1</MessageId>
<SegmentedBy>remote.mail.com</SegmentedBy>
</Segment>
</Header>
<Blocks>
<Block xsi:type="TextBody"> st<Data> "1 Segment of Data" </Data>
</Block>
</Blocks>
</Message>
Segment 2
---------
<?xml version="1.0"?>
<Message xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
Taylor Expires - October 2005 [Page 18]
Extensible Mail Protocol (ExMP) October, 2004
<Header>
<MessageId>8ae949c4-dc70-4004-a5ee-6b840886ea2f</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com" Replyable="true"
/>
<Address xsi:type="To" DisplayName=""
Mailbox="draft.editor" PostOffice="exmp.net" />
</Addresses>
<Subject>This is a test</Subject>
<Date>2004-09-12T09:42:22+10:00</Date>
<Segment Part="1" Total="2">
<MessageId>0f10095f-a655-407a-a419-
6c43fb95adf1</MessageId>
<SegmentedBy>remote.mail.com</SegmentedBy>
</Segment>
</Header>
<Blocks>
<Block xsi:type="TextBody"> nd<Data> "2 Segment of Data" </Data>
</Block>
</Blocks>
</Message>
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.<major>.<minor>.<domain>/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.<major>.<minor>.<domain>
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.<mj>.<mn>.<domain>/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.<mj>.<mn>.<domain>/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
------------------
<?xml version="1.0"?>
<Message xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<MessageId>72c0ba73-b8a7-416b-babb-74944af04a63</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName="Post Master"
Mailbox="postmaster" PostOffice="example.net" Replyable="true"
/>
<Address xsi:type="To" DisplayName="" Mailbox=""
PostOffice="exmp.net" />
</Addresses>
<Subject>Confirmation</Subject>
Taylor Expires - October 2005 [Page 36]
Extensible Mail Protocol (ExMP) October, 2004
<Date>2004-09-19T15:37:34+10:00</Date>
</Header>
<Blocks>
<Block xsi:type="EndPointAcceptance">
<MessageId>0f10095f-a655-407a-a419-
6c43fb95adf1</MessageId>
</Block>
</Blocks>
</Message>
Rejection Example
-----------------
<?xml version="1.0"?>
<Message xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<MessageId>83f9adc2-d70b-42dc-9586-76f5ee37a3ef</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName="Post Master"
Mailbox="postmaster" PostOffice="example.net" Replyable="true"
/>
<Address xsi:type="To" DisplayName="" Mailbox=""
PostOffice="exmp.net" />
</Addresses>
<Subject>Confirmation</Subject>
<Date>2004-09-19T15:37:34+10:00</Date>
</Header>
<Blocks>
<Block xsi:type="EndPointRejection">
<MessageId>0f10095f-a655-407a-a419-
6c43fb95adf1</MessageId>
<Reason>The users mailbox has rejected the message
because of content.</Reason>
</Block>
</Blocks>
</Message>
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
-------
<?xml version="1.0"?>
<Message xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<MessageId>d7d0df02-914c-4395-8e35-67404d3a025f</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName=""
Mailbox="draft.editor" PostOffice="exmp.net" Replyable="true"
/>
<Address xsi:type="To" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com" />
</Addresses>
<Subject>Confirmation</Subject>
<Date>2004-09-19T16:53:40+10:00</Date>
</Header>
<Blocks>
<Block xsi:type="DeliveryConfirmation">
<MessageId>3ae8cb2e-619d-41c4-a8a4-
284d47d93f88</MessageId>
<DateDelivered>2004-09-19T16:53:40+10:00</DateDelivered>
</Block>
<Block xsi:type="TextBody">
<Data>V2l0aCBhIFRleHQgTWVzc2FnZQ==</Data>
</Block>
</Blocks>
</Message>
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
-------
<?xml version="1.0"?>
<Message xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<MessageId>121a2d0b-f24f-4654-ab1e-74ff263fc9a9</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName=""
Mailbox="draft.editor" PostOffice="exmp.net" Replyable="true"
/>
<Address xsi:type="To" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com" />
</Addresses>
<Subject>Confirmation</Subject>
<Date>2004-09-19T16:53:40+10:00</Date>
</Header>
<Blocks>
<Block xsi:type="CollectedConfirmation">
<MessageId>3ae8cb2e-619d-41c4-a8a4-
284d47d93f88</MessageId>
<DateCollected>2004-09-19T16:53:40+10:00</DateCollected>
</Block>
<Block xsi:type="TextBody">
<Data>V2l0aCBhIFRleHQgTWVzc2FnZQ==</Data>
</Block>
</Blocks>
</Message>
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
<?xml version="1.0"?>
<Message xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<MessageId>ce5cd3d8-d472-4c6c-9008-26e4d7536a7d</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName=""
Mailbox="draft.editor" PostOffice="exmp.net" Replyable="true"
/>
<Address xsi:type="To" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com" />
</Addresses>
<Subject>Confirmation</Subject>
<Date>2004-09-19T16:53:40+10:00</Date>
</Header>
<Blocks>
<Block xsi:type="ReadConfirmation">
<MessageId>3ae8cb2e-619d-41c4-a8a4-
284d47d93f88</MessageId>
<DateRead>2004-09-19T16:53:40+10:00</DateRead>
</Block>
<Block xsi:type="TextBody">
<Data>V2l0aCBhIFRleHQgTWVzc2FnZQ==</Data>
</Block>
</Blocks>
</Message>
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" <jsmith@remote.mail.com>
To: <draft.editor@exmp.net>
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
----------------------
<Header>
<MessageId>0f10095f-a655-407a-a419-6c43fb95adf1</MessageId>
<Addresses>
<Address xsi:type="From" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com" Replyable="true"
/>
<Address xsi:type="To" DisplayName=""
Mailbox="draft.editor" PostOffice="exmp.net" />
</Addresses>
<Subject>This is a test</Subject>
<Date>2004-09-12T09:42:22+10:00</Date>
<MetaTags>
<MetaTag Name="Message-Id"
Value="<200409112323.i8BNNx702421>" />
<MetaTag Name="X-Mailer" Value="Microsoft Office Outlook,
Build 11.0.6353" />
<MetaTag Name="Thread-Index"
Value="AcSYWPu7b6knGLkURVGTWu8u+dv2pA==" />
<MetaTag Name="X-MimeOLE" Value="Produced By Microsoft
MimeOLE V6.00.2900.2180" />
</MetaTags>
</Header>
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;
<HTML Data> - HtmlBody.data
Original MIME Data
------------------
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html><body>
<H1>Line of Text</H1>
</body></html>
Translated ExMP HTML Body
-------------------------
<Block xsi:type="HtmlBody">
<Data>QSBCb2R5IG9mIFRleHQNCg==</Data>
</Block>
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;
<Text Data> - 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
-------------------------
<Block xsi:type="TextBody">
<Data>QSBCb2R5IG9mIFRleHQNCg==</Data>
</Block>
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
<Decoded Data> - 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
--------------------------
<Attachments>
<Attachment Source="A file.txt" Type="text/plain" Size="22">
<MetaTags>
<MetaTag Name="DisplayName" Value="A file.txt" />
</MetaTags>
<Data>VGhpcyBpcyBhIExpbmUgb2YgVGV4dA==</Data>
Taylor Expires - October 2005 [Page 46]
Extensible Mail Protocol (ExMP) October, 2004
</Attachment>
</Attachments>
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" <mailbox>@<post office>
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]
