SMTP/MIME Base64 Transport Binding for SOAP 1.2

7th December 2006

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


This document describes a binding of SOAP [SOAP] into SMTP[SMTP] plus MIME[MIME]. Unlike previously published bindings, this binding ensures that the SOAP message is attached as a Base64[BASE64] encoded MIME attachment. This approach reduces the chance of mail scanners and SPAMS filters modifying the SOAP body.


This is an editor’s draft.

Table of Contents

1. Introduction

1.1 Notational Conventions

2. Use of MIME

3. Using WSDL

4. Using WS-Addressing

5. Request / Response semantics

6. Examples

7. Security Considerations

8. References

1. Introduction

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].

1.1 Notational Conventions

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].

2. Use of MIME

SOAP payloads MUST to be packaged into a multipart MIME [MIME] message as an attachment. 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.

2.1 MIME packaging

The SMTP message MUST consist of a multipart MIME message.

The first part MUST be of type text/plain. It is RECOMMENDED that this part has no content.


The SOAP 1.2 payload MUST form the second part in the multi-part mime message, and MUST be Base64 encoded.


There MUST be only one mime part of content-type application/soap+xml

2.1 SOAP Payload

The SOAP 1.2 payload MUST be sent with the content type of "application/soap+xml".

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.


Content-Type: application/soap+xml; charset=UTF-8;action=""


A content transfer encoding of base64 MUST be used.


Content-Transfer-Encoding: base64


A content disposition MUST indicate that this is an attachment.


Content-Disposition: attachment


Many SOAP systems use the URL path (e.g. /soap/services/MyService) to route a message to a specific service. The Content-Description SHOULD be used to contain this path. 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.

3. Using WSDL

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.

In this case the mail client MAY add the SMTP header X-Service-Path with the value, but in addition the Content-Description SHOULD be set to this value.

The receiving agent SHOULD ignore the x-service-path header and rely on the Content-Description.

4. Using WS-Addressing

It is RECOMMENDED that WS-Addressing is used in this case, as this allows the SOAP message routing and service identification to occur independently of the transport.

In the case where WS-Addressing[WSA] headers are present in the SOAP message, the service SHOULD be identified using the X-Service-Path fragment of the mailto URL.

5. Request / Response semantics

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.

6. Examples

A request destined for:"/my/service/urlpath"  







X-Service-Path: "/my/service/urlpath"

MIME-Version: 1.0

content-type: multipart/mixed;




Content-Type: text/plain



Content-Type: application/soap+xml; charset=UTF-8; action="http://test/action"

Content-Transfer-Encoding: base64

Content-Disposition: attachment


Content-Description: "/my/service/urlpath"







7. Security Considerations

To our best knowledge, this introduces no new security considerations.

8. References

[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, Harvard University, March 1997

[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.