One document matched: draft-taylor-exmp-00.txt
Internet Draft S. Taylor
Document: draft-taylor-exmp-00.txt Sublime Solutions
Expires: April 2005 October 2004
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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 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 - April 2005 [Page 55]
Extensible Mail Protocol (ExMP) October, 2004
bool Replyable - This attribute defines whether or not the
address contained in the message can be replied to or not. This
flag MUST be set to false if the mailbox indicated in the
address cannot accept incoming messages.
9.3.1.1. Sender
This class overrides a "From" address and defines a "Sender"
address. There can only be one actual sender of a message but
as the above case states there could be multiple "From"
addresses. Post office nodes MUST make sure that if a Sender
address is present, then there MUST ONLY be only one. For a
complete description of sending address variations refer to
section 4.4.1.
9.3.2. To
This class overrides an address object and defines a direct
address. When sending a message to a remote mailbox, the
sending party defines "To" addresses to which the message will
be delivered directly. Each person on the "To" address list is
visible to each receiver of the message and care must be taken
if privacy is required.
9.3.2.1. ReplyTo
This class overrides a "To" address and defines a "ReplyTo"
address. Under certain circumstances one may want to have all
replies sent to an automated mailbox and not the original
sender's address. An example of this might be when the manager
of a department sends a message to all department employees
asking for some information; if the "ReplyTo" field is set to
his/her secretary, then he/she will receive all the replies and
not the manager. For a complete description of sending address
variations refer to section 4.4.1.
9.3.2.2. Cc
This class overrides a "To" address and defines a Carbon Copy
or "Cc" address. When sending a message to a remote mailbox,
the sending party defines "Cc" addresses to which the message
will be delivered indirectly. Each person on the "Cc" address
list is visible to each receiver of the message and care must
be taken if privacy is required.
9.3.2.2.1. Bcc
This class overrides a "Cc" address object and defines a Blind
Carbon Copy or "Bcc" address. When sending a message to a
Taylor Expires - April 2005 [Page 56]
Extensible Mail Protocol (ExMP) October, 2004
remote mailbox, the sending party defines "Bcc" addresses where
the message will be delivered indirectly and without any other
receiving party seeing the "Bcc" addresses. This effectively
allows a person to receive an email and not have his/her email
address disclosed.
9.4. MetaTag
This object defines a Meta Tag object which allows many of the
objects in a message to better describe their internal content.
Meta tags allow messages to include information in a logical
clear manner, where it otherwise might not be. For an
explanation on meta tags use, refer to section 10.
Attributes
----------
string Name - This attribute defines the name of the meta tag
data which is contained. This is not an optional attribute and
must be a completed for all meta tag objects.
string Value - This attribute defines the data in which the
above name refers to. This data can be any string or encoded
data. This is not an optional attribute and must be completed
for all meta tag objects.
9.5. PostOffice
This object defines a post office which participates in the
ExMP network. This object is primarily associated with a mail
bag which is passed from post office to post office.
Attributes
----------
Guid Id - This attribute defines a globally unique identifier
of a post office node. Each node on the network MUST have a
unique identifier, generated locally at the time of
installation. This identifier can be used in fast hash table
lookups for routing purposes. This is an optional attribute but
SHOULD be completed on all outgoing transactions.
string Name - This attribute defines a physical post office
name. This name MUST be the same name that is present in the
DNS MX record lookup. This is not an optional attribute and
must be completed for all transactions.
9.6. Segment
Taylor Expires - April 2005 [Page 57]
Extensible Mail Protocol (ExMP) October, 2004
This object defines a segment in a segmented message. If a
message exceeds the maximum message size defined in section
4.5.1 and needs to be segmented, this object defined which
portion of the message is contained in the body. For an in-
depth explanation of message segmenting refer to section 4.5.2.
Attributes
----------
Guid MessageId - This attribute defines which message,
contained in the body, this segment refers to. When the message
segments arrive at the remote post office or client, this value
is used to determine which message to apply the segment to.
This is not an optional attribute and must be completed for all
segments.
string SegmentedBy - This attribute defines who segmented the
message and who SHOULD be notified if any of the segments are
missing. Possible values for this attribute can include the
post office (example.net) or a mailbox (jsmith@example.net).
This is not an optional attribute and must be completed for all
segments.
int Part - This attribute defines which part of the segmented
message is contained in this message. This value MUST start
from the value 1 and reach a maximum defined in the "Total"
attribute. This is not an optional attribute and must be
completed for all segments.
int Total - This attribute defines the total segments in which
the original message has been split. This value is 1 based and
MUST be exactly the number of parts. For example, if the
message was split into 8 parts then this value must be equal to
8. This is not an optional attribute and must be completed for
all segments.
9.7. Attachment
This object defines an attachment which can be sent with a
message. Attachments are a way of delivering binary content to
a remote mailbox. Attachments can be an assortment of objects,
ranging from files to video or voice.
Attributes
----------
string Source - This attribute defines the original name which
the attribute was called. For a file this may be the filename,
for voice this might be the date and time of the recording.
Taylor Expires - April 2005 [Page 58]
Extensible Mail Protocol (ExMP) October, 2004
Care must be taken when sending original filenames, making sure
that the preceding path has been stripped off the name before
it is sent. An example of this might be when sending a PNG
format binary image. This attribute could show the filename or
name of the picture, "me.png" or just "my picture". This is an
optional attribute and may be left NULL when creating the
attachment.
string Type - This attribute defines the MIME type identifying
the use of the attachment. An example of this might be with the
above PNG format picture, this value would be "image/png". This
is not an optional attribute and must be completed for all
attachments.
long Size - This attribute defines the size of the attachment
and aids in the determination of the size of attachment without
checking the binary data buffer. This size MUST be the exact
size of the attachment in octets, after the buffer is filled.
This is not an optional attribute and must be completed for all
attachments.
Byte[] Data - This attribute defines the actual binary data
which is associated with the attachment. On reception, this
data may be streamed to an external device and MUST be an
exact, unmodified copy of what was read. This is not an
optional attribute and must be completed for all attachments.
MetaTag[] MetaTags - This attribute defines a collection of
meta information pertaining to the above attachment. This may
be extra information about the encoding of data, format of the
data or even what it is to be used for. This is an optional
attribute and may be left NULL when creating the attachment.
9.8. Block (abstract)
This object defines an abstract block which is used as a base
information object in an ExMP message.
Attributes
----------
MetaTag[] MetaTags - This attribute defines a collection of
meta information pertaining to the deriving object. An example
of this would be if the data buffer contained an audio message
recorded from a telephone answering machine. The meta tags
could detail the exact specifics of the message including the
format of the audio being sent over. This is an optional
attribute and may be left NULL when creating the block.
Taylor Expires - April 2005 [Page 59]
Extensible Mail Protocol (ExMP) October, 2004
9.8.1. Body
This object overrides a block object and defines a body of
information that will be sent to remote mailboxes. A body of
information could be conceived as anything that sends a message
or informs a person. This could include things like text, html,
voice or video. The specifics of what is sent, is not bound to
this object. This means , theoretically, anything could be
sent. There are, however, two derived objects which are
specific implementations of a technology, TextBody and
HtmlBody. Each respectively handles a slightly different type
of text data.
Attributes
----------
Byte[] Data - This attribute defines a buffer of data which
contains a message of some description. Using the meta tags,
the data sent in this buffer could be anything. This is not an
optional attribute and must be completed for all bodies.
9.8.1.1. TextBody
This object extends a body object, adding a description of the
type of text that is being sent in the body. Implementations
MUST use this object whenever sending text messages as this
object could be expanded for future versions of the protocol.
9.8.1.2. HtmlBody
This object extends a TextBody object, allowing for simple
object identification between a Text and Html Body.
Implementations MUST use this object whenever sending HTML
messages as this object could be expanded for future versions
of the protocol.
9.8.2. Confirmation
This object overrides a block object and defines a confirmation
object. This object is used primarily by post offices
confirming the reception of messages to the sending post
office.
Attributes
----------
Guid MessageId - This attribute defines the globally unique
identifier of the message which the confirmation represents.
Taylor Expires - April 2005 [Page 60]
Extensible Mail Protocol (ExMP) October, 2004
This is not an optional attribute and MUST be the same
identifier of the message which it represents.
9.8.2.1. EndPointAcceptance
This object extends a Confirmation object, defining an
EndPointConfirmation object. When a message arrives at its
final destination and is accepted by the remote post office and
mailbox, the receiving post office generates an end point
confirmation (section 6.2.2), sending is back to the sending
post office. Once the sending post office receives this
confirmation it can clear the message out of its dispatch area.
9.8.2.2. EndPointRejection
This object extends a "Confirmation" object, defining an
EndPointRejection object. When a message arrives at its final
destination, it may be rejected by the post office or by the
mailbox. The receiving post office generates an end point
rejection (section 6.2.2) with a reason which is returned to
the sending post office. Once the sending post office receives
this rejection it can clear the message out of its dispatch
area and notify the sender of the rejection.
Attributes
----------
String Reason - This attribute defines the reason for the
message rejection. This message MUST be in clear "English" text
as it will be passed to the originator of the message. The
reason for the rejection MUST be as detailed as possible as to
allow the sender to understand why the message was rejected.
This is not an optional attribute and must be defined for any
end point rejection that is sent back.
9.8.2.3. DeliveryConfirmation
This object extends a "Confirmation" object, defining a
DeliverConfirmation object. When a message has been delivered
successfully or unsuccessfully to the remote post office, a
message with this confirmation is sent to the sender of the
message. For an explanation of this process refer to section
6.2.3.
Attributes
----------
String DateDelivered - This attribute defines the timestamp of
when the message was delivered to the post office. This is not
Taylor Expires - April 2005 [Page 61]
Extensible Mail Protocol (ExMP) October, 2004
an optional attribute and MUST be defined according to the
format in section 13.
9.8.2.4. CollectedConfirmation
This object extends a "Confirmation" object, defining a
CollectedConfirmation object. When a message has been collected
by the intended recipient, a collected timestamp is generated
by the post office. This confirmation may or may not be
returned to the originator of the message by the post office.
For an explanation of this process refer to section 6.2.4.
Attributes
----------
String DateCollected - This attribute defines the timestamp of
when the message is collected from the post office. This is not
an optional attribute and MUST be defined according to the
format in section 13.
9.8.2.5. ReadConfirmation
This object extends a "Confirmation" object, defining a
ReadConfirmation object. When a message has been read by the
intended recipient, a read timestamp is generated by the
client's mail program. This confirmation may or may not be
returned to the originator of the message by the client's
program or the post office. For an explanation of this process
refer to section 6.2.5.
Attributes
----------
String DateRead - This attribute defines the timestamp of when
the message was read by the recipient. This is not an optional
attribute and MUST be defined according to the format in
section 13.
9.9. Mailbag
This object defines a mail bag which is in essence a collection
of messages all traveling to (or via) a post office.
Constants
---------
BagType.DESTINATION - This constant indicates that the post
office to which this mail bag will be traveling will be the
Taylor Expires - April 2005 [Page 62]
Extensible Mail Protocol (ExMP) October, 2004
final destination. Once the mailbag has been posted, none of
the messages contained will travel any further.
BagType.TRANSIT - This constant indicates that next post office
in which this mail bag arrives will be a transit office. Each
one of the messages will be forwarded to either another transit
post office or a destination post office.
Attributes
----------
Guid MailbagId - This attribute defines the globally unique
identifier of the mail bag. This identifier MUST be machine
generated and MUST be as unique as possible. If an
implementation is lazy in the generation of this value a
duplicate mailbag may be detected and deleted (see section
6.2.6). This is not an optional attribute and must be
automatically generated whenever a mail bag is created.
PostOffice Destination - This attribute defines the final
destination of the mail bag. This attribute MUST NOT indicate
the next hop in the routing of the mail bag but the destination
where it will finally arrive. This is not an optional attribute
when delivering a DESTINATION mail bag and must be defined
before a mail bag is delivered. In the case of a TRANSIT mail
bag this attribute can be left NULL.
PostOffice[] PostOffices - The attribute defines a collection
of post offices through which this mail bag has traveled,
aiding in the detection of routing loops. Before a mail bag is
delivered, the sending post office MUST append itself to this
collection. For a detailed explanation of routing refer to
section 6. This is not an optional attribute and must be
appended to before a mail bag is delivered.
BagType Type - The attribute defines the type of mail bag
routing that is to be used. Refer to the above constants for an
explanation of possible values. This is not an optional
attribute and must be set before a mail bag is delivered.
Message[] Messages - This attribute defines the collection of
ExMP messages which need to be delivered to the remote post
office. These messages might all be destined for a single post
office, in the case of a DESTINATION mail bag, or might be a
collection of TRANSIT messages being routed through a routing
post office. Each of these messages MUST be complete and
checked according to section 11.1 before the mailbag is sent.
This is not an optional attribute and must contain at least one
message before a mail bag is delivered.
Taylor Expires - April 2005 [Page 63]
Extensible Mail Protocol (ExMP) October, 2004
MetaTag[] MetaTags - This attribute defines a collection of
meta information pertaining to the above mail bag. Meta
information that might be deemed pertinent could be details
about the sending post office, statistics on the mailbag size
or even security information, preventing mail bag content
modification. This is an optional attribute and may be left
NULL when creating the mail bag.
9.10. Result
This object defines a result object, used to return result
codes and descriptions to remote post offices after a server
operation. While this object is usually not used directly, two
derivatives, MessageReceipt and MailbagReceipt are.
Attributes
----------
int Code - This attribute defines a numerical code which will
denote a response from the post office. This code can be
correlated against the table of know responses in section 8.1.
This is not an optional attribute and must be completed for all
result objects (including derivate objects).
string Description - This attribute defines a detailed
description of the above error code which may be locale
specific. Due to locale issues this is an optional attribute
and may be left NULL when creating result objects (including
derivate objects).
9.11. MessageReceipt
This object extends a "Result" object and defines a receipt
that is received by a client whenever he/she posts a message to
the sever via the post method (section 5.4.2.2.1.1).
Attributes
----------
Guid MessageId - The attribute defines the message identifier
(section 9.2) to which this receipt refers to.
9.12. MailbagReceipt
This object extends a "Result" object and defines a receipt
that is received by a post office whenever it delivers a
mailbag to another post office via the deliver method (section
5.4.2.2.1.2).
Taylor Expires - April 2005 [Page 64]
Extensible Mail Protocol (ExMP) October, 2004
Attributes
----------
Guid MailbagId - The attribute defines the mailbag identifier
(section 9.9) which this receipt refers to.
9.13. ServiceRequest
This object defines a service request object, used in the
request for a new account or in the generation of a new client
certificate. This object MUST be fully completed and sent to
the server.
Attributes
----------
string Name - This attribute defines the name which will be
associated with the account, appearing in the "Display Name"
attribute of the address object. Implementations may choose to
use this name as the unique identifier.
string EmailAddress - This attribute defines the email address
that MUST be created by the post office. This address is the
real world email address from which messages will be sent. This
email address MUST match that contained in the returned client
certificate.
string Password - This attribute defines the password which the
mailbox will be bound to. This password will be used in all
credential checks on the post office.
string PKCS10 - This attribute defines a PKCS10 format request
for a client certificate. This request MUST be generated on the
client's machine and will be bound to that machine. While
generation of this request is outside the scope of this
document, the request MUST contain the data outline in section
4.1.3.1.
MetaTag[] MetaTags - This attribute defines a collection of
meta information pertinent to the request. Meta information
sent with the request could be some type of billing
information, in the case of a signup service, or might just be
extra information about the requesting client. This is an
optional attribute and may be left NULL when creating the
attachment.
9.14. MailboxInfo
Taylor Expires - April 2005 [Page 65]
Extensible Mail Protocol (ExMP) October, 2004
9.15. SysInfo
This object defines a system information object, used when a
client or post office requests information about a post office.
Attributes
----------
PostOffice PostOffice - This attribute defines the current post
office's name and unique identifier (section 9.5).
bool WillTransit - This attribute defines a flag indicating
whether or not the post office is willing to transit mail bags
or not. If this flag is true, the post office will accept a
mail bag and forward the contained messages to their respective
destinations. If this flag is false, the post office will
reject transit mail bags with an error.
long MaxMessageSize - This attribute defines the maximum
message size which it is willing to handle. A post office may
choose to handle smaller messages than the defined standard
(section 4.5.1). This attribute allows the sending post office
to segment messages based on this value.
Note: This value normally should not be smaller than the
standard.
long MaxSpeed - This attribute defines the maximum speed of the
public network link in bits per second. This value allows a
remote post office to determine the fastest link for a list of
known routes.
MetaTag[] MetaTags - This attribute defines a collection of
meta information pertinent to the system information. This
collection might contain custom information which concerns only
this post office. All data here MUST be fully documented in the
post office documentation (section 5.1). This is an optional
attribute and may be left NULL when creating the object.
10. Extending Meta Tags
Meta tags are designed to allow extensibility when sending
messages from one user to another. Below are some examples of
extra meta information which could be sent with a message. When
sending meta information it is vitally important that the
information be presented in a way that it is easily
identifiable and decodable. The "Name" field MUST depict
exactly what is being stored in the meta tag and the "Value"
must be a specific comma separated format.
Taylor Expires - April 2005 [Page 66]
Extensible Mail Protocol (ExMP) October, 2004
Format
------
<MetaTag Name=<type> Value=<attribute,attribute,data> />
type = Type of meta information which is being sent.
attribute = Attribute helping in the decoding of the data.
data = Encoded data which is being sent.
10.1. Adding Pictures
Pictures can be added to address meta tags, allowing a company
to send a logo along with an informational message. In order
for the picture to be sent correctly and decoded, the following
attributes MUST be included in the meta tag value field;
MetaTag Name
------------
picture
Attributes
----------
1. This is the format of the binary data being sent. This can
be of any type but SHOULD be an easily identifiable standard
(bmp, png, jpeg, etc).
2. Encoding technique in which the binary data is converted
into a string representation. The encoding can be of any type
but SHOULD be an easily identifiable standard (Base64, Hex,
Uuencode, etc).
3. This is the binary picture encoded in the above format.
Example
-------
<Address xsi:type="From" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com">
<MetaTags>
<MetaTag Name="picture"
Value="gif,base64,R0lGODlhMQBAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZg
AzmQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMA
ADMMwDMZgDMmQDMzADM/wD/AAD/MwD/qEbLIktxCnKbIHUnPDvpzHAydKQOrSg3
JenQi/4yo7HUKDF92UiElrSZI4VnRz1XloAAADs=" />
</MetaTags>
</Address>
Taylor Expires - April 2005 [Page 67]
Extensible Mail Protocol (ExMP) October, 2004
10.2. Adding Contact Details
Contact details can be added to address meta tags, allowing a
person to send his/her contact details embedded in the address.
This allows the receiving program to simply retrieve the
contact details from the address object and import them
directly into a contacts database. Below is an example;
Example
-------
<Address xsi:type="From" DisplayName="John Smith"
Mailbox="jsmith" PostOffice="remote.mail.com">
<MetaTags>
<MetaTag Name="Address" Value="123 My Street" />
<MetaTag Name="Suburb" Value="My Town" />
<MetaTag Name="Post Code" Value="23444" />
<MetaTag Name="Mobile" Value="+614091231234" />
</MetaTags>
</Address>
11. ExMP Standards
11.1. Message Checks
Before a message is sent in the ExMP network, post offices MUST
perform a series of sanity checks on the message to make sure
that it conforms to below standards. If ANY of the checks fail,
the message MUST be rejected. Failing to reject an invalid
message circumvents the purpose of securing the network.
Below are the minimum checks that each and every post office
accepting messages directly from a client MUST perform;
1.) The header MUST contain a suitably random Message Id,
subject and date.
2.) Every address MUST contain both a complete mailbox and post
office attribute. The noticeable exception to this rule is
when end point confirmations are sent (section 6.2.2) and
the destination address is the post office only.
3.) The message MUST contain at least one valid "From" address.
4.) There can only be one "Sender" address defined (if at all).
5.) Both the "Sender" or "From" addresses MUST match up to the
sending post office's name and ALL MUST have a valid
account in the post office.
Taylor Expires - April 2005 [Page 68]
Extensible Mail Protocol (ExMP) October, 2004
6.) The above user MUST match the name on the client
certificate. The obvious exception to this rule is if a
gateway is used and no client certificate has been passed.
Then this rule can be ignored.
7.) The "Sender" cannot be a reserved mailbox (section 4.4.2)
or a virtual mailbox (section 4.4.3).
8.) There MUST be at least one recipient (To,Cc,Bcc) defined.
9.) At least one body object MUST be defined.
11.2. Mail Bag Checks
Before a mail bag is accepted the receiving post office MUST
perform a series of sanity checks on both the mail bag and the
contained messages. If ANY of the checks fail, the mail bag
MUST be rejected. This allows the sending post office to check
the contents of the mail bag and resend it once the error has
been corrected.
AT NO STAGE SHOULD THE RECEIVING POST OFFICE ACCEPT A MAIL BAG
AND REMOVE ANY MESSAGES FAILING CHECK 6.
1.) The header MUST contain a suitably random Mailbag Id.
2.) If this is a destination mail bag then the destination post
office MUST be defined in the header. If it is a transit
mail bag then the destination may be NULL according to
section 6.3.2.
3.) The sending post office MUST have a valid DNS MX record.
The obvious exception to this rule is if a gateway is used
and the process is on a "known" machine. The IP address
should be configured in the post office and this check can
be bypassed.
4.) The mail bag has not been seen by this post office before.
This check can concern both the mail bag identifier or the
collection of post offices in the PostOffices attribute in
the header.
5.) The mail bag contains at least one message.
6.) Each contained message MUST conform to check 1, 2, 3, 4, 7
and 8 of section 11.1.
Taylor Expires - April 2005 [Page 69]
Extensible Mail Protocol (ExMP) October, 2004
11.3. Message Delivery
11.3.1. Maximum Retry Time
Implementations are free to decide on how regular a message
send retry is performed, but the maximum retry attempt time is
7 days. After this period the post office holding the message
MUST notify the sender of the failure.
12. Security Considerations
In any public system one needs to consider security and just
how secure a system is. This can be as simple as the inspection
of a message on a post office to as complex as hijacking a
person's identity and using it for malicious purposes. The
following section discusses some of the identified areas in the
ExMP design where security could be considered an issue.
12.1. Account Creation
If a post office provides the ability for clients to create
accounts dynamically then the post office may need to consider
the possibility of a "denial of service" attack. The
possibility exists of a remote attacker flooding the post
office with fictitious account requests, overflowing the client
certificate generation and storage resources. One possible
solution is to populate the service request object meta tags
(sction 9.13) with security credentials. These security
credentials may need to exist in another service method not
defined in this version of the protocol.
12.2. Message Persistence
While it is possible to encrypt transmission via a public link,
somewhere along the line the data must be converted into a
plain text representation for processing. In this state the
messages could be considered to be vunerable to both inspection
and modification. Possible solutions to this may be with the
introduction of an encrypted body object (section 9.8.1) or the
WS-Security [14] and encrypted data blocks.
12.3. X.509 Certificates
The security considerations of X.509 certificates themselves
are outside the scope of this document. For any information
concerning X.509 certificates refer to RFC 2459, "Internet
X.509 Public Key Infrastructure Certificate and CRL Profile".
Taylor Expires - April 2005 [Page 70]
Extensible Mail Protocol (ExMP) October, 2004
12.3.1. Client Certificates
The theft of a client's certificate must also be considered
when the client stores his/her certificate on a remote machine.
While binding of this certificate to a single machine does
prevent the theft of the actual certificate, regeneration of
the certificate from another machine does not. The post office
has no real way of determining whether the user of the
certificate is actually the person whose account it is. Once a
certificate has been issued, the post office must assume that
the person using it is the actual account holder.
12.3.1.1. Issuing Authorities
A standard list of reputable issuing authorities exists but it
is entirely possible for an attacker to coerce a post office
administrator to add him to their root server's list. This
provides a potential security hole as that person may then
issue client certificates to non-trusted nodes. These nodes,
using the modified post office as a relay could inject "valid"
messages into the network.
12.3.1.2. Issuing from Server
Whenever a client certificate is issued from the server, there
exists a potential security issue. Access to the client
certificate generation routines MUST be kept private and away
from any possibility for public access. All data MUST be
completely verified before the client certificate is generated.
If a client certificate is revoked, then it MUST be removed
from any storage device and invalidated on the issuing post
office.
12.4. DNS
The openness of DNS makes it the most vulnerable to
modification. DNS MX records could easily be modified,
redirecting valid mail to another IP address. Before a client
or post office attempts to send a message or mail bag, he MUST
make sure that the server certificate is valid in every
respect. Securing MX records is beyond the scope of this
document.
12.5. Messages
It is entirely possible for a post office to ignore all of the
checks outlined in section 11.1. For this reason a potential
loophole in the security could be found. Without every post
office checking the validity of every message against the
Taylor Expires - April 2005 [Page 71]
Extensible Mail Protocol (ExMP) October, 2004
sending post office, this is a problem that exists. The onus
will be on the post office accepting client messages to ensure
that any messages that it accepts are true and valid. If for
any reason a post office is found to be injecting spam in
invalid messages, it runs the risk of having its certificates
revoked, effectively removing it from the network.
13. Formal Syntax
All date and time formats MUST be presented in ISO 8601 [15]
format, as shown below;
YYYY-MM-DDThh:mm:ssTZD
Where
-----
YYYY - four-digit year
MM - two-digit month (01=January, etc.)
DD - two-digit day of month (01 through 31)
hh - two digits of hour (00 through 23) (am/pm NOT allowed)
mm - two digits of minute (00 through 59)
ss - two digits of second (00 through 59)
TZD - time zone designator (+hh:mm or -hh:mm)
Example
-------
2004-09-19T15:15:34+10:00
14. Reference
1 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
2 Klensin, J.(Editor), "Simple Mail Transfer Protocol", RFC
2821, AT&T Laboratories, April 2001
3 Myers, J. and Rose, M., "Post Office Protocol - Version 3",
RFC 1939, Carnegie Mellon and Dover Beach Consulting, Inc.,
May 1996
4 Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 2060, University of Washington, December 1996
Taylor Expires - April 2005 [Page 72]
Extensible Mail Protocol (ExMP) October, 2004
5 Gudgin, M., Hadley, M., Mendelsohn, N., Moreau, J. and
Nielsen, H., "SOAP Version 1.2", http://www.w3.org/TR/soap/,
Microsoft, Sun Microsystems, IBM and Canon, June 2003
6 Rescorla, E., "HTTP Over TLS", RFC 2818,RTFM Inc., May 2000
7 ITU-T Recommendation X.509 (1997 E): Information Technology -
Open Systems Interconnection - The Directory: Authentication
Framework, June 1997
Housley, R., Ford, W., Polk, W. and Solo, D., "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC
2459, SPYRUS, VeriSign, NIST and Citicorp, January 1999
8 Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, Internet Mail
Consortium, February 2002
9 Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
RFC 1034, ISI, November 1987
Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION", RFC 1035, ISI, November 1987
10 Partridge, C., "MAIL ROUTING AND THE DOMAIN SYSTEM", RFC
974, CSNET CIC BBN Laboratories Inc, January 1986
11 Myers, J. "SMTP Service Extension for Authentication", RFC
2554, Netscape Communications, March 1999
12 Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, Innosoft and First Virtual, November 1996
Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft
and First Virtual, November 1996
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
Three: Message Header Extensions for Non-ASCII Text", RCF
2047, University of Tennessee, November 1996
Freed, N., Klensin, J. and Postel, J., "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures",
RFC 2048, Innosoft, MCI and ISI, November 1996
Taylor Expires - April 2005 [Page 73]
Extensible Mail Protocol (ExMP) October, 2004
Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, Innosoft and First Virtual, November
1996
13 Resnick, P. (Editor), "Internet Message Format", RFC 2822,
QUALCOMM Incorporated, April 2001
14 Kaler, C. (Editor), Atkinson, B., Della-Libera, G., Hada,
S., Hondo, M., Hallam-Baker, P., Klein, J., LaMacchia, B.,
Leach, P., Manferdelli, J., Maruyama, H., Nadalin, A.,
Nagaratnam, N., Prafullchandra, H., Shewchuk, J., Simon, D.,
"Specification: Web Services Security (WS-Security)",
http://www-
106.ibm.com/developerworks/webservices/library/ws-secure/,
Microsoft, IBM and VeriSign, April 2002
15 "ISO 8601 Date/Time format", http://www.w3.org/TR/NOTE-
datetime
15. Acknowledgments
Firstly, I would like to thank my family, especially my wife
Elizabeth, who has had to put up with the long hours of
research and development required to complete this document.
Secondly, I would like to thank Dr Paul Watters of Macquarie
University in Sydney for all of his help and support while
writing this document and lastly, James Bourne, of Sublime
Solutions for all of his support and input during the
development cycle of this document.
16. Author's Addresses
Steven Taylor
Sublime Solutions Pty Ltd
PO Box N660
Grosvenor Place
NSW 1220
Australia
Email: steven@sublime.com.au
Appendix A. WSDL
Taylor Expires - April 2005 [Page 74]
Extensible Mail Protocol October 2004
A.1. Account.soap
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="urn:exmp"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="urn:exmp"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified"
targetNamespace="urn:exmp">
<s:element name="Create">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Request" type="s0:ServiceRequest" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="ServiceRequest">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Name"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1"
name="EmailAddress" type="s:string" />
<s:element minOccurs="0" maxOccurs="1"
name="Password" type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="PKCS10"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
</s:sequence>
</s:complexType>
<s:complexType name="ArrayOfMetaTag">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="MetaTag" nillable="true" type="s0:MetaTag" />
</s:sequence>
</s:complexType>
<s:complexType name="MetaTag">
<s:attribute name="Name" type="s:string" />
<s:attribute name="Value" type="s:string" />
</s:complexType>
<s:element name="CreateResponse">
<s:complexType>
<s:sequence>
Taylor Expires - April 2005 [Page 75]
Extensible Mail Protocol October 2004
<s:element minOccurs="0" maxOccurs="1"
name="CreateResult" type="s:base64Binary" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="RequestCertificate">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Request" type="s0:ServiceRequest" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="RequestCertificateResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="RequestCertificateResult" type="s:base64Binary" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="Close">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Mailbox" type="s:string" />
<s:element minOccurs="0" maxOccurs="1"
name="Password" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="CloseResponse">
<s:complexType />
</s:element>
</s:schema>
</types>
<message name="CreateSoapIn">
<part name="parameters" element="s0:Create" />
</message>
<message name="CreateSoapOut">
<part name="parameters" element="s0:CreateResponse" />
</message>
<message name="RequestCertificateSoapIn">
<part name="parameters" element="s0:RequestCertificate" />
</message>
<message name="RequestCertificateSoapOut">
<part name="parameters"
element="s0:RequestCertificateResponse" />
</message>
Taylor Expires - April 2005 [Page 76]
Extensible Mail Protocol October 2004
<message name="CloseSoapIn">
<part name="parameters" element="s0:Close" />
</message>
<message name="CloseSoapOut">
<part name="parameters" element="s0:CloseResponse" />
</message>
<portType name="AccountSoap">
<operation name="Create">
<input message="s0:CreateSoapIn" />
<output message="s0:CreateSoapOut" />
</operation>
<operation name="RequestCertificate">
<input message="s0:RequestCertificateSoapIn" />
<output message="s0:RequestCertificateSoapOut" />
</operation>
<operation name="Close">
<input message="s0:CloseSoapIn" />
<output message="s0:CloseSoapOut" />
</operation>
</portType>
<binding name="AccountSoap" type="s0:AccountSoap">
<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<operation name="Create">
<soap:operation soapAction="urn:exmp/Create"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="RequestCertificate">
<soap:operation soapAction="urn:exmp/RequestCertificate"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="Close">
<soap:operation soapAction="urn:exmp/Close"
style="document" />
<input>
<soap:body use="literal" />
Taylor Expires - April 2005 [Page 77]
Extensible Mail Protocol October 2004
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<service name="Account">
<port name="AccountSoap" binding="s0:AccountSoap">
<soap:address
location="https://localhost/exmp/account.soap" />
</port>
</service>
</definitions>
A.2. Postoffice.soap
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:s1="http://microsoft.com/wsdl/types/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="urn:exmp"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="urn:exmp"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified"
targetNamespace="urn:exmp">
<s:import namespace="http://microsoft.com/wsdl/types/" />
<s:element name="Post">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Messages" type="s0:ArrayOfMessage" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="ArrayOfMessage">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="Message" nillable="true" type="s0:Message" />
</s:sequence>
</s:complexType>
<s:complexType name="Message">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Header"
type="s0:Header" />
Taylor Expires - April 2005 [Page 78]
Extensible Mail Protocol October 2004
<s:element minOccurs="0" maxOccurs="1"
name="Attachments" type="s0:ArrayOfAttachment" />
<s:element minOccurs="0" maxOccurs="1" name="Blocks"
type="s0:ArrayOfBlock" />
<s:element minOccurs="0" maxOccurs="1"
name="ResponseTo" type="s0:Message" />
</s:sequence>
</s:complexType>
<s:complexType name="Header">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1"
name="Addresses" type="s0:ArrayOfAddress" />
<s:element minOccurs="0" maxOccurs="1" name="Subject"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Date"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
<s:element minOccurs="0" maxOccurs="1" name="Segment"
type="s0:Segment" />
</s:sequence>
</s:complexType>
<s:complexType name="ArrayOfAddress">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="Address" nillable="true" type="s0:Address" />
</s:sequence>
</s:complexType>
<s:complexType name="Address" abstract="true">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
</s:sequence>
<s:attribute name="DisplayName" type="s:string" />
<s:attribute name="Mailbox" type="s:string" />
<s:attribute name="PostOffice" type="s:string" />
</s:complexType>
<s:complexType name="ArrayOfMetaTag">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="MetaTag" nillable="true" type="s0:MetaTag" />
</s:sequence>
</s:complexType>
<s:complexType name="MetaTag">
<s:attribute name="Name" type="s:string" />
<s:attribute name="Value" type="s:string" />
</s:complexType>
Taylor Expires - April 2005 [Page 79]
Extensible Mail Protocol October 2004
<s:complexType name="From">
<s:complexContent mixed="false">
<s:extension base="s0:Address">
<s:attribute name="Replyable" type="s:boolean"
use="required" />
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="Sender">
<s:complexContent mixed="false">
<s:extension base="s0:From" />
</s:complexContent>
</s:complexType>
<s:complexType name="To">
<s:complexContent mixed="false">
<s:extension base="s0:Address" />
</s:complexContent>
</s:complexType>
<s:complexType name="Cc">
<s:complexContent mixed="false">
<s:extension base="s0:To" />
</s:complexContent>
</s:complexType>
<s:complexType name="Bcc">
<s:complexContent mixed="false">
<s:extension base="s0:Cc" />
</s:complexContent>
</s:complexType>
<s:complexType name="ReplyTo">
<s:complexContent mixed="false">
<s:extension base="s0:To" />
</s:complexContent>
</s:complexType>
<s:complexType name="Segment">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1"
name="SegmentedBy" type="s:string" />
</s:sequence>
<s:attribute name="Part" type="s:int" use="required" />
<s:attribute name="Total" type="s:int" use="required"
/>
</s:complexType>
<s:complexType name="ArrayOfAttachment">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="Attachment" nillable="true" type="s0:Attachment" />
</s:sequence>
Taylor Expires - April 2005 [Page 80]
Extensible Mail Protocol October 2004
</s:complexType>
<s:complexType name="Attachment">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
<s:element minOccurs="0" maxOccurs="1" name="Data"
type="s:base64Binary" />
</s:sequence>
<s:attribute name="Source" type="s:string" />
<s:attribute name="Type" type="s:string" />
<s:attribute name="Size" type="s:long" use="required"
/>
</s:complexType>
<s:complexType name="ArrayOfBlock">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="Block" nillable="true" type="s0:Block" />
</s:sequence>
</s:complexType>
<s:complexType name="Block" abstract="true">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
</s:sequence>
</s:complexType>
<s:complexType name="Body">
<s:complexContent mixed="false">
<s:extension base="s0:Block">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Data" type="s:base64Binary" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="TextBody">
<s:complexContent mixed="false">
<s:extension base="s0:Body" />
</s:complexContent>
</s:complexType>
<s:complexType name="HtmlBody">
<s:complexContent mixed="false">
<s:extension base="s0:TextBody" />
</s:complexContent>
</s:complexType>
<s:complexType name="Confirmation">
<s:complexContent mixed="false">
<s:extension base="s0:Block">
<s:sequence>
Taylor Expires - April 2005 [Page 81]
Extensible Mail Protocol October 2004
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="CollectedConfirmation">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="DateCollected" type="s:string" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="ReadConfirmation">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="DateRead" type="s:string" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="EndPointRejection">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Reason" type="s:string" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="EndPointAcceptance">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation" />
</s:complexContent>
</s:complexType>
<s:complexType name="DeliveryConfirmation">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="DateDelivered" type="s:string" />
</s:sequence>
</s:extension>
Taylor Expires - April 2005 [Page 82]
Extensible Mail Protocol October 2004
</s:complexContent>
</s:complexType>
<s:element name="PostResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="PostResult" type="s0:ArrayOfMessageReceipt" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="ArrayOfMessageReceipt">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="MessageReceipt" nillable="true" type="s0:MessageReceipt"
/>
</s:sequence>
</s:complexType>
<s:complexType name="MessageReceipt">
<s:complexContent mixed="false">
<s:extension base="s0:Result">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="Result">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="Code"
type="s:int" />
<s:element minOccurs="0" maxOccurs="1"
name="Description" type="s:string" />
</s:sequence>
</s:complexType>
<s:complexType name="MailbagReceipt">
<s:complexContent mixed="false">
<s:extension base="s0:Result">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MailbagId" type="s1:guid" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:element name="Deliver">
<s:complexType>
<s:sequence>
Taylor Expires - April 2005 [Page 83]
Extensible Mail Protocol October 2004
<s:element minOccurs="0" maxOccurs="1"
name="Mailbag" type="s0:Mailbag" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="Mailbag">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MailbagId" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1"
name="Destination" type="s0:PostOffice" />
<s:element minOccurs="0" maxOccurs="1"
name="PostOffices" type="s0:ArrayOfPostOffice" />
<s:element minOccurs="0" maxOccurs="1"
name="Messages" type="s0:ArrayOfMessage" />
<s:element minOccurs="1" maxOccurs="1" name="Type"
type="s0:BagType" />
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
</s:sequence>
</s:complexType>
<s:complexType name="PostOffice">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="Id"
type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1" name="Name"
type="s:string" />
</s:sequence>
</s:complexType>
<s:complexType name="ArrayOfPostOffice">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="PostOffice" nillable="true" type="s0:PostOffice" />
</s:sequence>
</s:complexType>
<s:simpleType name="BagType">
<s:restriction base="s:string">
<s:enumeration value="DESTINATION" />
<s:enumeration value="TRANSIT" />
</s:restriction>
</s:simpleType>
<s:element name="DeliverResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="DeliverResult" type="s0:MailbagReceipt" />
</s:sequence>
</s:complexType>
</s:element>
Taylor Expires - April 2005 [Page 84]
Extensible Mail Protocol October 2004
</s:schema>
<s:schema elementFormDefault="qualified"
targetNamespace="http://microsoft.com/wsdl/types/">
<s:simpleType name="guid">
<s:restriction base="s:string">
<s:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-
9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}" />
</s:restriction>
</s:simpleType>
</s:schema>
</types>
<message name="PostSoapIn">
<part name="parameters" element="s0:Post" />
</message>
<message name="PostSoapOut">
<part name="parameters" element="s0:PostResponse" />
</message>
<message name="DeliverSoapIn">
<part name="parameters" element="s0:Deliver" />
</message>
<message name="DeliverSoapOut">
<part name="parameters" element="s0:DeliverResponse" />
</message>
<portType name="PostofficeSoap">
<operation name="Post">
<input message="s0:PostSoapIn" />
<output message="s0:PostSoapOut" />
</operation>
<operation name="Deliver">
<input message="s0:DeliverSoapIn" />
<output message="s0:DeliverSoapOut" />
</operation>
</portType>
<binding name="PostofficeSoap" type="s0:PostofficeSoap">
<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<operation name="Post">
<soap:operation soapAction="urn:exmp/Post"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="Deliver">
Taylor Expires - April 2005 [Page 85]
Extensible Mail Protocol October 2004
<soap:operation soapAction="urn:exmp/Deliver"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<service name="Postoffice">
<port name="PostofficeSoap" binding="s0:PostofficeSoap">
<soap:address
location="https://localhost/exmp/postoffice.soap" />
</port>
</service>
</definitions>
A.3. Mailbox.soap
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:s1="http://microsoft.com/wsdl/types/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="urn:exmp"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="urn:exmp"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified"
targetNamespace="urn:exmp">
<s:import namespace="http://microsoft.com/wsdl/types/" />
<s:element name="Open">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Username" type="s:string" />
<s:element minOccurs="0" maxOccurs="1"
name="Password" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="OpenResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="OpenResult" type="s:string" />
Taylor Expires - April 2005 [Page 86]
Extensible Mail Protocol October 2004
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetInformation">
<s:complexType />
</s:element>
<s:element name="GetInformationResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="GetInformationResult" type="s0:MailboxInfo" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="MailboxInfo">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageCount" type="s:long" />
<s:element minOccurs="1" maxOccurs="1"
name="TotalSize" type="s:long" />
</s:sequence>
</s:complexType>
<s:element name="GetMessageIds">
<s:complexType />
</s:element>
<s:element name="GetMessageIdsResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="GetMessageIdsResult" type="s0:ArrayOfGuid" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="ArrayOfGuid">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="guid" type="s1:guid" />
</s:sequence>
</s:complexType>
<s:element name="GetMessageSize">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetMessageSizeResponse">
<s:complexType>
Taylor Expires - April 2005 [Page 87]
Extensible Mail Protocol October 2004
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="GetMessageSizeResult" type="s:long" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetMessage">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="GetMessageResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="GetMessageResult" type="s0:Message" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="Message">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="Header"
type="s0:Header" />
<s:element minOccurs="0" maxOccurs="1"
name="Attachments" type="s0:ArrayOfAttachment" />
<s:element minOccurs="0" maxOccurs="1" name="Blocks"
type="s0:ArrayOfBlock" />
<s:element minOccurs="0" maxOccurs="1"
name="ResponseTo" type="s0:Message" />
</s:sequence>
</s:complexType>
<s:complexType name="Header">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1"
name="Addresses" type="s0:ArrayOfAddress" />
<s:element minOccurs="0" maxOccurs="1" name="Subject"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1" name="Date"
type="s:string" />
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
<s:element minOccurs="0" maxOccurs="1" name="Segment"
type="s0:Segment" />
</s:sequence>
Taylor Expires - April 2005 [Page 88]
Extensible Mail Protocol October 2004
</s:complexType>
<s:complexType name="ArrayOfAddress">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="Address" nillable="true" type="s0:Address" />
</s:sequence>
</s:complexType>
<s:complexType name="Address" abstract="true">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
</s:sequence>
<s:attribute name="DisplayName" type="s:string" />
<s:attribute name="Mailbox" type="s:string" />
<s:attribute name="PostOffice" type="s:string" />
</s:complexType>
<s:complexType name="ArrayOfMetaTag">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="MetaTag" nillable="true" type="s0:MetaTag" />
</s:sequence>
</s:complexType>
<s:complexType name="MetaTag">
<s:attribute name="Name" type="s:string" />
<s:attribute name="Value" type="s:string" />
</s:complexType>
<s:complexType name="To">
<s:complexContent mixed="false">
<s:extension base="s0:Address" />
</s:complexContent>
</s:complexType>
<s:complexType name="Cc">
<s:complexContent mixed="false">
<s:extension base="s0:To" />
</s:complexContent>
</s:complexType>
<s:complexType name="Bcc">
<s:complexContent mixed="false">
<s:extension base="s0:Cc" />
</s:complexContent>
</s:complexType>
<s:complexType name="ReplyTo">
<s:complexContent mixed="false">
<s:extension base="s0:To" />
</s:complexContent>
</s:complexType>
<s:complexType name="From">
<s:complexContent mixed="false">
<s:extension base="s0:Address">
Taylor Expires - April 2005 [Page 89]
Extensible Mail Protocol October 2004
<s:attribute name="Replyable" type="s:boolean"
use="required" />
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="Sender">
<s:complexContent mixed="false">
<s:extension base="s0:From" />
</s:complexContent>
</s:complexType>
<s:complexType name="Segment">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1"
name="SegmentedBy" type="s:string" />
</s:sequence>
<s:attribute name="Part" type="s:int" use="required" />
<s:attribute name="Total" type="s:int" use="required"
/>
</s:complexType>
<s:complexType name="ArrayOfAttachment">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="Attachment" nillable="true" type="s0:Attachment" />
</s:sequence>
</s:complexType>
<s:complexType name="Attachment">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
<s:element minOccurs="0" maxOccurs="1" name="Data"
type="s:base64Binary" />
</s:sequence>
<s:attribute name="Source" type="s:string" />
<s:attribute name="Type" type="s:string" />
<s:attribute name="Size" type="s:long" use="required"
/>
</s:complexType>
<s:complexType name="ArrayOfBlock">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="Block" nillable="true" type="s0:Block" />
</s:sequence>
</s:complexType>
<s:complexType name="Block" abstract="true">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
Taylor Expires - April 2005 [Page 90]
Extensible Mail Protocol October 2004
</s:sequence>
</s:complexType>
<s:complexType name="Body">
<s:complexContent mixed="false">
<s:extension base="s0:Block">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Data" type="s:base64Binary" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="TextBody">
<s:complexContent mixed="false">
<s:extension base="s0:Body" />
</s:complexContent>
</s:complexType>
<s:complexType name="HtmlBody">
<s:complexContent mixed="false">
<s:extension base="s0:TextBody" />
</s:complexContent>
</s:complexType>
<s:complexType name="Confirmation">
<s:complexContent mixed="false">
<s:extension base="s0:Block">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="CollectedConfirmation">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="DateCollected" type="s:string" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="ReadConfirmation">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="DateRead" type="s:string" />
</s:sequence>
Taylor Expires - April 2005 [Page 91]
Extensible Mail Protocol October 2004
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="EndPointRejection">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Reason" type="s:string" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:complexType name="EndPointAcceptance">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation" />
</s:complexContent>
</s:complexType>
<s:complexType name="DeliveryConfirmation">
<s:complexContent mixed="false">
<s:extension base="s0:Confirmation">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="DateDelivered" type="s:string" />
</s:sequence>
</s:extension>
</s:complexContent>
</s:complexType>
<s:element name="DeleteMessage">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="MessageId" type="s1:guid" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="DeleteMessageResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="1" maxOccurs="1"
name="DeleteMessageResult" type="s:boolean" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="Close">
<s:complexType />
</s:element>
<s:element name="CloseResponse">
<s:complexType />
Taylor Expires - April 2005 [Page 92]
Extensible Mail Protocol October 2004
</s:element>
<s:element name="Verify">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="Address" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
<s:element name="VerifyResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="VerifyResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
</s:schema>
<s:schema elementFormDefault="qualified"
targetNamespace="http://microsoft.com/wsdl/types/">
<s:simpleType name="guid">
<s:restriction base="s:string">
<s:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-
9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}" />
</s:restriction>
</s:simpleType>
</s:schema>
</types>
<message name="OpenSoapIn">
<part name="parameters" element="s0:Open" />
</message>
<message name="OpenSoapOut">
<part name="parameters" element="s0:OpenResponse" />
</message>
<message name="GetInformationSoapIn">
<part name="parameters" element="s0:GetInformation" />
</message>
<message name="GetInformationSoapOut">
<part name="parameters" element="s0:GetInformationResponse"
/>
</message>
<message name="GetMessageIdsSoapIn">
<part name="parameters" element="s0:GetMessageIds" />
</message>
<message name="GetMessageIdsSoapOut">
<part name="parameters" element="s0:GetMessageIdsResponse"
/>
</message>
<message name="GetMessageSizeSoapIn">
Taylor Expires - April 2005 [Page 93]
Extensible Mail Protocol October 2004
<part name="parameters" element="s0:GetMessageSize" />
</message>
<message name="GetMessageSizeSoapOut">
<part name="parameters" element="s0:GetMessageSizeResponse"
/>
</message>
<message name="GetMessageSoapIn">
<part name="parameters" element="s0:GetMessage" />
</message>
<message name="GetMessageSoapOut">
<part name="parameters" element="s0:GetMessageResponse" />
</message>
<message name="DeleteMessageSoapIn">
<part name="parameters" element="s0:DeleteMessage" />
</message>
<message name="DeleteMessageSoapOut">
<part name="parameters" element="s0:DeleteMessageResponse"
/>
</message>
<message name="CloseSoapIn">
<part name="parameters" element="s0:Close" />
</message>
<message name="CloseSoapOut">
<part name="parameters" element="s0:CloseResponse" />
</message>
<message name="VerifySoapIn">
<part name="parameters" element="s0:Verify" />
</message>
<message name="VerifySoapOut">
<part name="parameters" element="s0:VerifyResponse" />
</message>
<portType name="MailboxSoap">
<operation name="Open">
<input message="s0:OpenSoapIn" />
<output message="s0:OpenSoapOut" />
</operation>
<operation name="GetInformation">
<input message="s0:GetInformationSoapIn" />
<output message="s0:GetInformationSoapOut" />
</operation>
<operation name="GetMessageIds">
<input message="s0:GetMessageIdsSoapIn" />
<output message="s0:GetMessageIdsSoapOut" />
</operation>
<operation name="GetMessageSize">
<input message="s0:GetMessageSizeSoapIn" />
<output message="s0:GetMessageSizeSoapOut" />
</operation>
<operation name="GetMessage">
Taylor Expires - April 2005 [Page 94]
Extensible Mail Protocol October 2004
<input message="s0:GetMessageSoapIn" />
<output message="s0:GetMessageSoapOut" />
</operation>
<operation name="DeleteMessage">
<input message="s0:DeleteMessageSoapIn" />
<output message="s0:DeleteMessageSoapOut" />
</operation>
<operation name="Close">
<input message="s0:CloseSoapIn" />
<output message="s0:CloseSoapOut" />
</operation>
<operation name="Verify">
<input message="s0:VerifySoapIn" />
<output message="s0:VerifySoapOut" />
</operation>
</portType>
<binding name="MailboxSoap" type="s0:MailboxSoap">
<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<operation name="Open">
<soap:operation soapAction="urn:exmp/Open"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="GetInformation">
<soap:operation soapAction="urn:exmp/GetInformation"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="GetMessageIds">
<soap:operation soapAction="urn:exmp/GetMessageIds"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
Taylor Expires - April 2005 [Page 95]
Extensible Mail Protocol October 2004
</operation>
<operation name="GetMessageSize">
<soap:operation soapAction="urn:exmp/GetMessageSize"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="GetMessage">
<soap:operation soapAction="urn:exmp/GetMessage"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="DeleteMessage">
<soap:operation soapAction="urn:exmp/DeleteMessage"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="Close">
<soap:operation soapAction="urn:exmp/Close"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
<operation name="Verify">
<soap:operation soapAction="urn:exmp/Verify"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
Taylor Expires - April 2005 [Page 96]
Extensible Mail Protocol October 2004
</output>
</operation>
</binding>
<service name="Mailbox">
<port name="MailboxSoap" binding="s0:MailboxSoap">
<soap:address
location="https://localhost/exmp/mailbox.soap" />
</port>
</service>
</definitions>
A.4. Service.soap
<?xml version="1.0" encoding="utf-8"?>
<definitions xmlns:s1="http://microsoft.com/wsdl/types/"
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="urn:exmp"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/"
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
targetNamespace="urn:exmp"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<s:schema elementFormDefault="qualified"
targetNamespace="urn:exmp">
<s:import namespace="http://microsoft.com/wsdl/types/" />
<s:element name="Information">
<s:complexType />
</s:element>
<s:element name="InformationResponse">
<s:complexType>
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="InformationResult" type="s0:SysInfo" />
</s:sequence>
</s:complexType>
</s:element>
<s:complexType name="SysInfo">
<s:sequence>
<s:element minOccurs="0" maxOccurs="1"
name="PostOffice" type="s0:PostOffice" />
<s:element minOccurs="1" maxOccurs="1"
name="WillTransit" type="s:boolean" />
<s:element minOccurs="1" maxOccurs="1"
name="MaxMessageSize" type="s:long" />
<s:element minOccurs="1" maxOccurs="1"
name="MaxSpeed" type="s:long" />
Taylor Expires - April 2005 [Page 97]
Extensible Mail Protocol October 2004
<s:element minOccurs="0" maxOccurs="1"
name="MetaTags" type="s0:ArrayOfMetaTag" />
</s:sequence>
</s:complexType>
<s:complexType name="PostOffice">
<s:sequence>
<s:element minOccurs="1" maxOccurs="1" name="Id"
type="s1:guid" />
<s:element minOccurs="0" maxOccurs="1" name="Name"
type="s:string" />
</s:sequence>
</s:complexType>
<s:complexType name="ArrayOfMetaTag">
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded"
name="MetaTag" nillable="true" type="s0:MetaTag" />
</s:sequence>
</s:complexType>
<s:complexType name="MetaTag">
<s:attribute name="Name" type="s:string" />
<s:attribute name="Value" type="s:string" />
</s:complexType>
</s:schema>
<s:schema elementFormDefault="qualified"
targetNamespace="http://microsoft.com/wsdl/types/">
<s:simpleType name="guid">
<s:restriction base="s:string">
<s:pattern value="[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-
9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}" />
</s:restriction>
</s:simpleType>
</s:schema>
</types>
<message name="InformationSoapIn">
<part name="parameters" element="s0:Information" />
</message>
<message name="InformationSoapOut">
<part name="parameters" element="s0:InformationResponse" />
</message>
<portType name="ServiceSoap">
<operation name="Information">
<input message="s0:InformationSoapIn" />
<output message="s0:InformationSoapOut" />
</operation>
</portType>
<binding name="ServiceSoap" type="s0:ServiceSoap">
<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
Taylor Expires - April 2005 [Page 98]
Extensible Mail Protocol October 2004
<operation name="Information">
<soap:operation soapAction="urn:exmp/Information"
style="document" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<service name="Service">
<port name="ServiceSoap" binding="s0:ServiceSoap">
<soap:address
location="https://localhost/exmp/service.soap" />
</port>
</service>
</definitions>
Appendix B. Sample Messages
B.1. ExMP 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"
/>
<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>
<Attachments>
Taylor Expires - April 2005 [Page 99]
Extensible Mail Protocol October 2004
<Attachment Source="A file.txt" Type="text/plain"
Size="22">
<MetaTags>
<MetaTag Name="DisplayName" Value="A file.txt" />
</MetaTags>
<Data>VGhpcyBpcyBhIExpbmUgb2YgVGV4dA==</Data>
</Attachment>
</Attachments>
<Blocks>
<Block xsi:type="TextBody">
<Data>QSBCb2R5IG9mIFRleHQNCg==</Data>
</Block>
</Blocks>
</Message>
B.2. Mail Bag
<?xml version="1.0"?>
<Mailbag xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<MailbagId>425e5a32-a462-403b-9560-fcdc0a67db22</MailbagId>
<Destination>
<Id>1d0107bf-68ab-4394-a5f1-2c1d337a65e7</Id>
<Name>exmp.net</Name>
</Destination>
<PostOffices>
<PostOffice>
<Id>20c7f67e-e96f-49d2-ae3e-97513e5c27c8</Id>
<Name>foo.com</Name>
</PostOffice>
<PostOffice>
<Id>e69e9c3b-bf85-4d96-8ac7-1d903d775654</Id>
<Name>bar.com</Name>
</PostOffice>
</PostOffices>
<Messages>
<Message>
<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>
Taylor Expires - April 2005 [Page 100]
Extensible Mail Protocol October 2004
<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>
<Attachments>
<Attachment Source="A file.txt" Type="text/plain"
Size="22">
<MetaTags>
<MetaTag Name="DisplayName" Value="A file.txt" />
</MetaTags>
<Data>VGhpcyBpcyBhIExpbmUgb2YgVGV4dA==</Data>
</Attachment>
</Attachments>
<Blocks>
<Block xsi:type="TextBody">
<Data>QSBCb2R5IG9mIFRleHQNCg==</Data>
</Block>
</Blocks>
</Message>
</Messages>
<Type>DESTINATION</Type>
</Mailbag>
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the
technology described in this document or the extent to which
any license under such rights might or might not be available;
nor does it represent that it has made any independent effort
to identify any such rights. Information on the procedures
with respect to rights in RFC documents can be found in BCP 78
and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of
an attempt made to obtain a general license or permission for
the use of such proprietary rights by implementers or users of
this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr.
Taylor Expires - April 2005 [Page 101]
Extensible Mail Protocol October 2004
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be
required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION
HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET
SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in
BCP 78, and except as set forth therein, the authors retain all
their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by
the Internet Society.
| PAFTECH AB 2003-2026 | 2026-04-24 10:32:01 |