1.1.2 SOAP SMTP Requests
(Sending an Email Message)
1.1.2.1 Addressing and Dates
All email header addresses MUST be RFC 822 compliant email addresses.
The date header field MUST be RFC 822 compliant date.
1.1.2.2 Delivery Status Requests
Delivery Success or Failure Requests must be explicitly requested when creating an email message. RFC’s 1894, 2852 and 2298 go into detail regarding requests for Delivery Status Notifications (DSN) and Message Disposition Notifications (MDN) in email header fields. A detailed description of these Notifications can be found later in this document.
1.1.3 SOAP SMTP Responses
1.1.3.1 Alternatives
SOAP Node Processing Distinct from SMTP Delivery Status
Email Delivery Status is separate from SOAP layer message processing. Resulting SOAP responses to the contained SOAP data will be processed through a new email message with no link to the original requesting email at the SMTP level.
SOAP Node Processing Bound to SMTP Delivery Status
Email Delivery Status is tied and bound to SOAP message-processing request and the MUA’s processing of MDN’s is held until the SOAP node completes processing of the SOAP envelope received. The resulting MDN will carry information of the success or failure of the SOAP request.
Questions for discussion:
Shall the MUA be tied to the SOAP node regarding MDN processing?
Shall we use MDN’s to notify sender of successful processing of SOAP data, or shall we have a distinct break between email delivery success and failure and SOAP message processing success and failure?
Refer to RFC 2298: 3.2.6.2 Disposition types and 3.2.6.3 Disposition modifiers for MDN definitions and their usage in communicating success or failure of processing.
1.1.4 Producing Message Disposition Notifications (MDN’s)
It is assumed that the SOAP application developer will have control over email message construction via a Mail User Agent (MUA), which will be accessible by the SOAP node. MUA’s produce Message Disposition Notifications (MDN’s) and must follow RFC 2298.
See RFC 2298 for Format of MDN’s.
SMTP Intermediaries (MTA’s) are not the same as SOAP Intermediaries and should not be treated as such.
1.1.5 Interpretation of DSN’s and MDN’s by Requester
(Detailed Issues that need to be addressed)
Timeout of Acknowledgements
Single to: addresses
Broadcast to: multiple addresses
1.1.6 SOAP content processing
I believe this is outside the scope of the SMTP binding
1.1.7 Split Messages
(details need to be addressed)
2 SOAP/SMTP Binding Architectural Model
The high level architectural model of the SOAP/SMTP Binding being proposed in this document is shown in Figure 1. It is important to understand the architecture of SMTP in terms of its agents and how they will interact with SOAP components.
The SMTP agent, which resides on most users’ desktops, is called the Mail User Agent or MUA. The MUA is used to format outgoing email messages and retrieve incoming email messages from a designated mail server. An example of an MUA is Microsoft Outlook.
MUA's are
responsible for constructing electronic mail messages in accordance with the
Internet Electronic Mail Specifications identified above.
The mail server software packages, which the MUA’s
communicate with, are called Mail Transfer Agents or MTA’s. MTA’s send and receive email messages with
other MTA’s on behalf of MUA’s. MTA’s
are also called mail hubs or mail servers.
Microsoft Exchange is an example of an MTA.
In Figure1, both SMTP and SOAP components reside on the Sender and Receiver Machine. Figure 1 shows where SMTP acknowledgement processing occurs versus where SOAP node/application processing resides. The dotted line between the SMTP Processing and the SOAP Application illustrates an optional usage of SMTP provided acknowledgement data.
Figure 1
2.1.1 Notes to SOAP Application Developers
Application developers can use the Internet email infrastructure to move data as either email text or attachments. It is the application developer’s responsibility to parse through the email contents and pass it to the appropriate software module for processing, potentially creating a proprietary data exchange format. If the data cargo is passed as an attachment, verifications have to be made to ensure that the attachment is of the correct type. There is also the complication of partial email messages. These occur when an email message is larger than an email infrastructure allows. The original message is split up and numbered for reassembly. There is no guarantee that the partial email messages will be delivered in the proper order. This creates the need to place the partial messages back in the correct order and then piece them all together once they arrive. Delays in email delivery will further complicate development, creating the need for predefined timeout periods.
While SMTP is not a guaranteed delivery protocol, Delivery Notification mechanisms exist, but also are not guaranteed. Email users have grown accustom to requesting Delivery Receipts and Read Receipts for the email messages they send. The underlying protocol mechanisms are called Delivery Status Notifications (DSN’s) and Message Disposition Notifications (MDN’s). These notifications take the form of email messages sent to the email address specified in the mail header. Applications, as well as email end users, can use these mechanisms to provide a status of an email transmission. The application developer must fully understand the capabilities and limitations of these Delivery Notifications or risk assuming a data delivery when none occurred.
Delivery Status Notifications (DSN’s) acknowledge the delivery of an email message to a destination mailbox on a mail server or MTA. DSN’s are provided through Extended SMTP servers, which have been partially deployed throughout the industry at the date of this writing. Due to the partial deployment of ESMTP, a DSN request may be inconclusive if a non-ESMTP server is found along the email delivery path. DSN’s only notify the sender that the email message has been delivered to the appropriate mailbox, not that the intended recipient (or application) has opened the message and processed it. ESMTP servers are mandated by the protocol to honor DSN requests.
Message Disposition Notifications (MDN’s) acknowledge to the sender that the intended recipient has received and opened a particular email message. SMTP, being first and foremost an email protocol, protects an end user’s right to privacy by allowing a mailbox user, at the MUA, to ignore requests for read/processed return receipts. Put in common language, a user not wanting others to know when he has opened an email message, can elect to ignore such request. Application developers need to understand this potential disregard of MDN requests while developing SMTP data transmissions. Decisions will have to be made to handle a no MDN response situation, because it could mean that MDN replies have been disabled, or it could mean that the email system did not complete the delivery to the end destination.
2.1.2 From RFC 2298 – MDN processing scenario
-- User composes message -- User tells UA to send message -- UA passes message to MTA (original recipient information passed along) -- MTA sends message to next MTA -- Final MTA receives message -- Final MTA delivers message to UA (possibily generating DSN) -- UA performs automatic processing and generates corresponding MDNs ("dispatched", "processed", "deleted", "denied" or "failed" disposition type with "automatic-action" and "MDN-sent- automatically" disposition modes) -- UA displays list of messages to user -- User selects a message and requests that some action be performed on it. -- UA performs requested action and, with user's permission, sends appropriate MDN ("displayed", "dispatched", "processed", "deleted", "denied" or "failed" disposition type with "manual- action" and "MDN-sent-manually" or "MDN-sent-automatically"
disposition mode).