Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail
Extracted elements (30)
Earliest delivery time ('X-Mms-Delivery-Time:') is a message submission feature, not a relay feature, so it is stripped and not mapped to any SMTP relay element. This prevents intermediate relay servers from attempting to honor a future delivery constraint they cannot correctly enforce.
The 'X-Mms-Expiry:' header is mapped to the SMTP DELIVER-BY extension with by-mode 'R' (relative) rather than an Internet message header because expiry is a transport-layer concern. Each SMTP server decrements the remaining time; if by-mode is 'N' (notify), a 'relayed' DSN MUST be issued instead.
MMS allows UTF-16 content encoding, but Internet message format does not. UTF-16 MUST be translated to UTF-8 or another suitable charset. Additionally, charset encodings whose line endings are not US-ASCII CR LF cannot be used in text/* body parts without suitable transfer encoding.
MMS delivery reports are plain text with no defined structure, making conversion to standard Internet multipart/report format difficult. The gateway must parse the MMS report to determine event type, time, status, and original message headers in order to synthesize a conforming DSN or MDN.
VPIM 'Sensitivity:' header (values 'personal' or 'private') is not an MMS feature. Messages with this header MUST NOT be forwarded to an MMS system; on conversion Internet-to-MMS, a negative DSN with extended status code 5.6.0 MUST be generated. MMS systems do not support the Privacy header field described by VPIM.
Any Internet messages containing a 'Sensitivity:' header MUST NOT be sent to an MMS system; the associated negative delivery status report MUST include extended status code 5.6.0 indicating that privacy could not be ensured.
Blind copy (Bcc) recipients appearing in the SMTP envelope but not in headers MUST NOT be added to message headers (including address and trace headers) unless there is only one recipient total.
Each recipient address MUST be transmitted in the SMTP envelope as a RCPT TO value. At least one 'To:', 'Cc:', or 'Bcc:' header MUST be present in the Internet message; if none exist, a 'To:' header using empty group syntax SHOULD be created.
If there are any non-7-bit characters in the local part of an address, the message MUST be rejected. Non-7-bit characters in an address domain MUST be encoded with IDNA; non-7-bit characters elsewhere in a header MUST be encoded per RFC 2047 (Hdr-Enc).
Implementations MUST convert reports received from one side (MMS or Internet mail) destined for the other, and MUST generate reports as appropriate for messages received from either side. The 'DSN-Gateway:' field in delivery reports MUST be created.
Messages MUST NOT be sent to an Internet mail system with an unqualified E.164 number (a number with no domain) instead of a fully-qualified domain name. All addresses in 'To:', 'Cc:', and 'Bcc:' headers MUST be in the form of fully-qualified domains.
Reply charging SHOULD NOT be honored at the MM3 interface because misapplied reply charging may cause incorrect billing and security issues have not been properly addressed. Messages containing a reply-charging usage request SHOULD be rejected.
The MAIL FROM value MUST be set to null ("<>") for all automatically-generated MMs such as those with 'X-Mms-Message-Class: Auto', reports, and out-of-office replies. This is critical to prevent mail loops.
The 'Message-Id:' header MUST be retained when converting from MMS to Internet format. If not present, it MUST be created with a unique value per RFC 2822.
The 'Subject:' header MUST be preserved in both MMS-to-Internet and Internet-to-MMS conversions. Non-7-bit characters MUST be encoded according to RFC 2047 in the absence of an SMTP 8-bit extension.
UTF-16 encoding used in MMS content MUST be translated to UTF-8 or another charset suitable for Internet message format/protocols, because Internet message format does not support UTF-16.
When a message is gatewayed from MMS to Internet mail, a 'Received:' header MUST be added as per SMTP. A message MAY be rejected if the number of 'Received:' headers exceeds a locally-defined maximum, which MUST conform to SMTP Section 6.2 and SHOULD be no less than 100.
When converting Internet mail to MMS, 'To:' and 'Cc:' headers MUST be retained. Each recipient in the SMTP envelope (RCPT TO) MUST be considered a recipient; recipients in headers but not the envelope MUST be ignored.
When sending a message to an Internet mail system, the MMS Relay/Server MUST convert the MM if required and MUST comply with the requirements of SMTP. The server SHOULD use associated information elements to define control information (header fields and SMTP envelope values).
Delivery report mapping from Internet to MMS (Table 5): DSN Action 'delivered' maps to X-Mms-Status 'retrieved'; 'failed' maps to 'unreachable'; 'relayed' maps to 'forwarded'. A single DSN reporting multiple recipients results in several MMS delivery reports. DSN Action 'delayed' MUST NOT be mapped (deferred MUST NOT be used).
Delivery report mapping from MMS to Internet (Table 4): MMS 'X-Mms-Status:' maps to DSN Action and Status fields. MMS status 'retrieved'/'rejected' maps to Action 'delivered'; 'expired'/'unreachable' maps to 'failed'; 'deferred' MAY map to 'delayed'; 'indeterminate' maps to 'relayed'.
Importance/priority bidirectional mapping: MMS X-Mms-Priority High/Normal/Low maps to Internet Importance: High/omitted/Low (Table 2). Reverse: Internet X-Priority 1-2 or Importance: High maps to X-Mms-Priority: High; X-Priority 4-5 or Importance: Low maps to Low; Normal SHOULD omit the header (Table 3).
Read report mapping between MMS and Internet (Tables 6 and 7): MMS 'X-Mms-Read-Status: read' maps to MDN disposition-type 'displayed'; MMS 'Deleted without being read' maps to 'deleted'. Reverse: MDN 'displayed' maps to X-Mms-Read-Status 'read'; 'deleted'/'denied'/'failed' with automatic-action maps to 'Deleted without being read'.
Table 1 defines the complete mapping between MMS information elements (X-Mms-* headers), SMTP envelope elements, and RFC 2822 header fields. Key mappings include: Message-ID ↔ Message-ID, recipients ↔ RCPT TO / To:/Cc:, sender ↔ MAIL FROM / From:, expiry ↔ DELIVER-BY, delivery report request ↔ DSN, priority ↔ Importance:, and read reply ↔ Disposition-Notification-To:.
The MM3 reference point is the interface between an MMS Relay/Server and external (non-MMS) systems such as Internet mail. This specification defines message exchange over MM3 using native SMTP and RFC 2822 message format, mapping MMS X-Mms-* headers to standard Internet message headers and SMTP envelope values.
IANA added "MMS" as a new value under the "WITH protocol types" in its "MAIL Parameters" registry, with the description "Multimedia Messaging Service" and a reference to RFC 4356. This allows the MMS gateway to be identified in SMTP 'Received:' header "with" clauses.
Reply charging and sender address hiding are identified as higher-risk MMS features. Support for these mechanisms is excluded from this specification because misapplied reply charging can cause incorrect billing and security issues have not been properly addressed.
When a message uses end-to-end security such as PGP or S/MIME, gateways MUST be careful not to accidentally destroy the integrity of protected content by altering text within the region covered by a signature during MMS-to-email mapping. RFC 2480 discusses MIME security issues in gateways.
Internet delivery and disposition reports use the multipart/report MIME type (RFC 3462): first subpart is text/plain (human-readable); second subpart is message/delivery-status or message/disposition-notification (structured); optional third subpart is message/rfc822 containing the original message headers. MMS reports are plain text with no defined structure.
MMS resend history is carried in 'X-Mms-Previously-Sent-By:' and 'X-Mms-Previously-Sent-Date-and-Time:' headers, each prefixed with a sequence number starting at '0' for the original submission. These map to RFC 2822 'Resent-From:' and 'Resent-Date:' headers on conversion to Internet format, with date-time converted between HTTP-date and RFC 2822 date-time syntax.