This version:
Latest version:
Authors (alphabetically):
Saminda Aberuwan, Apache
Paul Fremantle, Apache
Patrik Johansson, Accenture
Hans Guldager Knudsen, Lenio
Christian Laang, XXXXX
Gert Sylvest, Avanade
CopyrightŠ 2006 XXXXXXXX
This document describes a binding of SOAP [SOAP] into SMTP[SMTP]. Unlike previously published bindings, this binding ensures that the SOAP message is attached using Base64-encoding[BASE64] MIME[MIME] attachment. This greatly reduces the chance of mail scanners and SPAM filters modifying the SOAP body.
This is an editors draft.
3. Identifying SMTP transports in WSDL
4. Request / Response semantics
There is a published SMTP binding for SOAP 1.2[SOAP12SMTP]. However, this encodes the SOAP XML message as the textual body of the mail message. This binding enforces that the SOAP XML message is base64 encoded.
The aim of this binding is to allow SOAP systems to use the store and forward nature of SMTP to allow small businesses and other users to interact via SOAP without having to host publicly-accessible HTTP servers.
This binding is designed to work with MTOM[MTOM] attachments. In addition it is expected that this binding will successfully compose with SOAP-based standards such as WS-Security[WSSEC] and WS-ReliableMessaging[WSRM].
The keywords "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 [RFC-2119].
SOAP payloads in SMTP MUST to be packaged into a multipart MIME [MIME] message. This provides a standard packaging layer that can take care of specifying transfer encodings, to cope with SMTP's 7bit nature. Also most MIME attachments are not modified by SPAM filters and anti-virus tools, minimizing problems.
There MUST be an empty part of type text/plain with no content first. The SOAP payload MUST form the second part in the multi-part mime message.
SOAP 1.2 payloads MUST be sent with the content type of "application/soap+xml" when SOAP entity body is encoded as a single-part MIME message. The charset parameter MUST be used to specify the character encoding as per RFC2046 [RFC2046]. The action parameter SHOULD be used to specify the SOAP action. There MUST be only one mime part of content-type application/soap+xml
Example:
Content-Type: application/soap+xml;
charset=UTF-8;action="http://my.com/action"
A content transfer encoding of base64 is MUST be used.
2.3
Content-Description
Many SOAP systems use the URL path (e.g. /soap/services/MyService) to route a message to a specific service. The Content-Description is used to contain this path.
A content description which identifies the service being called SHOULD be used. This SHOULD be enclosed in quotes ("). This path is defined in section 3.
2.4
Other SMTP headers
The other SMTP headers can be used and will not change the outcome of the SOAP processing.
The URI http://xxxxxxxxxxxxx/yyy/zzz SHOULD be used to identify SMTP transports compliant with this specification in the transport attribute of the soap:binding element of a WSDL [WSDL] document.
There is a address of the SOAP service in the soap:address element of a WSDL document SHOULD be given by a URL based on the "mailto" URL scheme as defined by RFC 2368 [MAILTO]. In this case the following mailto syntax SHOULD be used.
mailto:mailbox@soapserver.mycom.com?X-Service-Path=/soap/services/MyService
In this case the mail client MAY add the SMTP header X-Service-Path with the value, but in addition the Content-Description MUST be set to this value. If the X-Service-Path header is undefined in the mailto URL, then the Content-Description header MUST be present with value "".
The receiving agent SHOULD ignore the x-service-path header and rely on the Content-Description.
SOAP applications requiring request / response semantics will need to perform some sort of message correlation. This SHOULD be achieved via the standard Message-Id and In-Reply-To SMTP headers [SMTP]. The request will include a Message-Id header, and the associated response should include a In-Reply-To header that contains the Message-Id of the request, and a new Message-Id header.
The responder SHOULD also reflect the incoming subject header into the response, with no modifications.
A request destined for:
mailto:soap-mailbox@mail.org?X-Service-Path="/my/service/urlpath"
From: test@mail.com
To: soap-mailbox@mail.org
Message-ID:
<8868170.01165394158287>
Subject: ANYTHING
MIME-Version: 1.0
content-type: multipart/mixed;
boundary=--boundary_0_9fdec710-2336-4dc9-8bcd-45f2c06cf605
----boundary_0_9fdec710-2336-4dc9-8bcd-45f2c06cf605
Content-Type: text/plain
----boundary_0_9fdec710-2336-4dc9-8bcd-45f2c06cf605
Content-Type: application/soap+xml; charset=UTF-8; action="http://test/action"
Content-Transfer-Encoding: base64
Content-Description: "/my/service/urlpath"
PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0ndXRmLTgnPz48c29hcGVudjpFbnZlbG9wZSB4
Y3VtZW50YXRpb24uPC9EZXNjcmlwdGlvbj48L05vdGlmaWNhdGlvbj48L3NvYXBlbnY6Qm9keT48
L3NvYXBlbnY6RW52ZWxvcGU+
----boundary_0_9fdec710-2336-4dc9-8bcd-45f2c06cf605
This should introduce no new security considerations.
[SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", May 2000.
[SMTP] Klensin J., "Simple Mail Transfer Protocol" RFC2821, April 2001.
[RFC2119] Bradner S., "Key words for use in RFCs to
Indicate Requirement Levels", RFC
2119,
[MIME] Freed N., Borenstein N. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" RFC2045, November 1996.
[WSDL] Christensen E., Curbera F., Meredith G., Weerawarana S. "Web Services Description Language (WSDL) 1.1", March 2001.
[MAILTO] Hoffman P., Masinter L., Zawinski J. "The mailto URL scheme" RFC2368, July 1998.
[RFC822] Crocker D.H., "Standard for the format of ARPA internet text messages" RFC822, August 1982.