number (i.e., 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. Unqualified E.164 numbers MUST NOT be
used.
Sender address
The address of the message sender SHOULD appear in the ’From:’
header.
The address of the message sender for all user-generated messages
(’X-Mms-Message-Class: Personal’) SHOULD be transmitted in the
[SMTP] envelope as the MAIL FROM value.
The return addresses in the [SMTP] envelope must be fully-qualified
in accordance with [SMTP]. In particular, messages MUST NOT be sent
to an Internet mail system with an E.164 number instead of a fully-
qualified domain name. Note that qualified E.164 numbers, that is,
those that contain an E.164 number as the local-part of an address
that also includes a domain, are acceptable.
The address(es) in the ’From:’ header SHOULD be in the form of
fully-qualified domains. Unqualified E.164 numbers SHOULD NOT be
used.
Because of the risk of mail loops, it is critical that the MAIL FROM
be set to null ("<>") for all automatically-generated MMs (such as
’X-Mms-Message-Class: Auto’). The MAIL FROM value MUST be set to
null for all automatically-generated messages. This includes
reports, "out-of-office" replies, etc.
Current Internet message format requires that only 7-bit US-ASCII
characters be present in headers. Non-7-bit characters in an address
domain must be encoded with [IDN]. If there are any Non-7-bit
characters in the local part of an address, the message MUST be
rejected. Non-7-bit characters elsewhere in a header MUST be encoded
according to [Hdr-Enc]. Note that it would be possible to define an
[SMTP] extension to permit transmission of unencoded 8-bit
characters, but in the absence of such an extension [Hdr-Enc] MUST be
used.
The sender address MUST obey the length restrictions of [SMTP].
Content type
The ’Content-Type:’ header SHOULD be preserved.
Message class
The ’X-Mms-Message-Class:’ header MAY be retained in order to provide
information on the source of the message. A ’Precedence: bulk’
header MAY be inserted for class=auto or class=advertisement. See
’Sender Address’ above. (Class=personal and class=informational do
not require special handling.)
Time of Expiry
The ’X-Mms-Expiry:’ header, if present, SHOULD be removed.
The remaining time until the message is considered expired SHOULD be
transmitted in the [SMTP] envelope by using the DELIVER-BY extension
with a by-mode of "R", as specified in [Deliver-By].
Note that the [SMTP] DELIVER-BY extension carries time remaining
until expiration; each server decrements the value by the amount of
time it has possessed the message. The ’X-Mms-Expiry:’ header may
contain either the absolute time at which the message is considered
expired or the relative time until the message is considered expired.
Earliest delivery time
The ’X-Mms-Delivery-Time:’ header, if present, SHOULD be removed.
Future delivery is a message submission (e.g., [Submission]), not
message relay feature.
Delivery report request
Requests for delivery status notifications (DSNs) SHOULD be
transmitted in the [SMTP] envelope by using the DSN extension as
specified in [DSN-SMTP] to request "success" or "none" notification
(depending on the value of the ’X-Mms-Delivery-Report’ header). When
the NOTIFY extension is used, the unaltered recipient address SHOULD
be transmitted as the ORCPT value.
The ’X-Mms-Delivery-Report:’ header, if present, SHOULD be removed.
Importance
The message sender’s importance value (also called "priority",
although this can be confused with class-of-service values) SHOULD be
transmitted using an ’Importance:’ header.
Suggested mappings are shown in Table 2:
2.1.3.2.1. Table 2: Importance Mappings (MMS to Internet Message)
---------------------------|------------------
’X-Mms-Priority: High’ |’Importance: High’
---------------------------|------------------
’X-Mms-Priority: Normal’ |[omit]
---------------------------|------------------
’X-Mms-Priority: Low’ |’Importance: Low’
---------------------------|------------------
Normal importance messages should omit the ’Importance:’ header.
The ’X-Mms-Priority:’ header, if present, SHOULD be removed.
Sender visibility
Support for sender address hiding is not currently supported.
A message that contains an ’X-Mms-Sender-Visibility:’ header with a
value of ’Hide’ SHOULD be rejected.
The ’X-Mms-Sender-Visibility:’ header, if present, SHOULD be removed.
Read reply request
A request for a read reply SHOULD be transmitted using a
’Disposition-Notification-To:’ header as specified in [MDN].
The ’X-Mms-Read-Reply:’ header, if present, SHOULD be removed.
Reply charging
Reply charging permission and acceptance are complex issues requiring
both user agent and server support. Misapplied reply charging may
cause incorrect billing. Until the security issues have been
properly addressed, reply charging SHOULD NOT be honored when using
this interface.
The ’X-Mms-Reply-Charging:’, ’X-Mms-Reply-Charging-Deadline:’, ’X-
Mms-Reply-Charging-Size:’, and ’X-Mms-Reply-Charging-Id:’ headers MAY
be removed. Messages containing a reply-charging usage request (’X-
Mms-Reply-Charging-Id:’ and ’X-Mms-Reply-Charging: accepted’ or ’X-
Mms-Reply-Charging: accepted (text only)’ headers) SHOULD be
rejected.
Subject
The ’Subject:’ header MUST be preserved. The current Internet
message format requires that only 7-bit US-ASCII characters be
present. Other characters MUST be encoded according to [Hdr-Enc].
Note that it is possible for an [SMTP] extension to be defined that
would permit transmission of unencoded 8-bit characters, but in the
absence of such an extension, [Hdr-Enc] MUST be used.
Resending
A message may be resent to one or more new recipients. It may be
resent more than once, each time new ’Resent-’ headers are added at
the top of the existing headers. Thus, if more than one series of
’Resent-’ headers are present, the original series is the last; the
most recent is the first.
Forward counter
An ’X-Mms-Forward-Counter:’ header, if present, SHOULD be removed.
The ’Resent-Count:’ header is NOT RECOMMENDED. Loop control is
usually done by counting ’Received’ headers, which are more general
than ’Resent-’ headers.
Previously-Sent Information
MMS lists the resending history of a message in two headers: ’X-
Mms-Previously-Sent-By:’ and ’X-Mms-Previously-Sent-Date-and-Time:’.
’X-Mms-Previously-Sent-By:’ contains a number followed by one or
more addresses. ’X-Mms-Previously-Sent-Date-and-Time:’ contains a
number followed by a date-time. With both headers, the number "0" is
used for the entry that corresponds to the original submission of the
message, with higher values being used for each subsequent resending.
The final (most recent) resending information is in the ’From:’ and
’Date:’ headers. There is also an ’X-Mms-Forward-Counter:’ that
indicates how many times the message has been resent.
Any ’X-Mms-Previously-Sent-By:’, ’X-Mms-Previously-Sent-Date-and-
Time:’, and ’X-Mms-Forward-Counter:’ headers, if present, SHOULD be
removed. The information contained in them SHOULD be translated into
[Msg-Fmt] headers as follows:
The ’X-Mms-Previously-Sent-Date-and-Time:’ header whose value starts
with "0" SHOULD be used to create a ’Date:’ header, converting the
date and time from HTTP-date [HTTP] to date-time [Msg-Fmt]. The ’X-
Mms-Previously-Sent-By:’ header whose value starts with "0" SHOULD be
used to create a ’From:’ header.
A ’To:’ header SHOULD be created using list syntax with a value of
"unrecoverable-recipients" and no mailboxes.
A ’Message-ID:’ header SHOULD be created.
Any ’X-Mms-Previously-Sent-Date-and-Time:’ headers whose value starts
with "1" or a larger value are mapped to ’Resent-Date:’ headers.
Any ’X-Mms-Previously-Sent-By:’ headers whose value starts with "1"
or a larger value are mapped to ’Resent-By:’ headers.
The ’From:’, ’To:’, ’Date:’, and ’Message-ID:’ headers are mapped to
’Resent-From:’, ’Resent-To:’, ’Resent-Date:’, and ’Resent-Message-
ID:’ headers in the top-most block of ’Resent-*’ headers.
Example:
The MMS message:
X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org>
is mapped to an Internet mail message:
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 08:02:03 +0000
Resent-From: Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 06:02:03 +0000
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <000.000.000@gateway.example.org>
’Received:’ Headers
When a message is gatewayed from MMS to Internet mail, a ’Received:’
header MUST be added as per [SMTP]. The "with" clause should specify
"MMS".
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.
Privacy
Note that MMS systems do not currently support the ’Privacy’ header
field as described by [VPIM].
Content
The message content appears in the message body. Note that Internet
message format requires that line endings be encoded as US-ASCII CR
LF octets; thus, charset encodings that do not have this property
cannot be used in text/* body parts. (They may be used in other body
parts, but only when they are suitably encoded or when binary
transmission has been negotiated, e.g., [BINARY].) In particular,
MMS allows UTF-16, whereas the Internet message format does not.
UTF-16 encoding MUST be translated to UTF-8 or another charset and
encoding that is suitable for use in Internet message
format/protocols.
2.1.3.3. Conversion of Messages from Internet to MMS Format
3GPP MMS Version
An ’X-Mms-3GPP-MMS-Version:’ header SHOULD be added.
Message Type (of PDU)
An ’X-Mms-Message-Type:’ header SHOULD be used in accordance with the
specific MMS interface (e.g., MM1, MM4).
Transaction ID
An ’X-Mms-Transaction-Id:’ header SHOULD be used in accordance with
the specific MMS interface (e.g., MM1, MM4).
Message ID
The ’Message-Id:’ header MUST be retained. If not present, it MUST
be created, with a unique value.
Recipient(s) address
’To:’ and ’Cc:’ headers MUST be retained.
Each recipient contained in the [SMTP] envelope (RCPT TO values) MUST
be considered a recipient of the message. Recipients who appear in
address headers but not the [SMTP] envelope MUST be ignored.
Recipients who appear in the [SMTP] envelope but do not appear in
headers are considered "blind" (Bcc) recipients; such recipients MUST
NOT be added to message headers (including address and trace headers)
unless there is only one recipient total.
Sender address
The ’From:’ header MUST be retained.
Content type
The complete ’Content-Type:’ header (including any parameters) SHOULD
be preserved.
Message class
An ’X-Mms-Message-Class: personal’ header MAY be created for all
received messages with a non-null return path (MAIL FROM value in the
SMTP envelope). An ’X-Mms-Message-Class: auto’ header MAY be created
for messages with a null return path.
Time of Expiry
An ’X-Mms-Expiry:’ header SHOULD be created if the message contains a
relative time to expiration in the DELIVER-BY extension with a by-
mode of "R", as specified in [Deliver-By].
If the by-mode is "N", a "relayed" DSN MUST be issued per
[Deliver-By] and an ’X-Mms-Expiry:’ header SHOULD NOT be created.
Delivery report request
An ’X-Mms-Delivery-Report:’ header SHOULD be created for messages
that request ’success’ or ’none’ delivery status notification by use
of the DSN extension as specified in [DSN-SMTP]. Requests for
’delay’ notifications or non-default actions, such as that only the
message headers should be returned, cannot be mapped onto MMS headers
and thus SHOULD be ignored.
Importance
The message sender’s importance value (also called "priority",
although this can be confused with class-of-service values) is
expressed with an ’Importance:’ header. Historically, some clients
used the older and non-standard ’X-Priority:’ header for this
purpose. As a result, some clients generate both.
An ’X-Priority:’ or ’Importance:’ header, if present, SHOULD be
replaced with an ’X-Mms-Priority:’ header. If both headers are
present, ’Importance:’ SHOULD be used. Suggested mappings are shown
in Table 3:
2.1.3.3.1. Table 3: Priority Mappings (Internet Message to MMS)
-------------------------------|----------------------
’X-Priority: 1 (highest)’ |’X-Mms-Priority: High’
-------------------------------|----------------------
’X-Priority: 2 (high)’ |’X-Mms-Priority: High’
-------------------------------|----------------------
’Importance: High’ |’X-Mms-Priority: High’
-------------------------------|----------------------
’X-Priority: 3 (normal)’ | [omitted]
-------------------------------|----------------------
’Importance: Normal’ | [omitted]
-------------------------------|----------------------
’X-Priority: 4 (low)’ |’X-Mms-Priority: Low’
-------------------------------|----------------------
’Importance: Low’ |’X-Mms-Priority: Low’
-------------------------------|----------------------
’X-Priority: 5 (lowest)’ |’X-Mms-Priority: Low’
-------------------------------|----------------------
Normal importance messages SHOULD omit the ’X-Mms-Priority:’ header.
Sender visibility
Support for sender address hiding is not currently supported.
Read reply request
A request for a read reply contained in a ’Disposition-Notification-
To:’ header as specified in [MDN] SHOULD be replaced with an ’X-Mms-
Read-Reply:’ header.
Subject
The ’Subject:’ header MUST be preserved.
Resending
Mapping from ’Resent-’ and other [Msg-Fmt] headers to ’X-Mms-
Previously-Sent-’ headers SHOULD be done as follows:
The original ’From:’ header is mapped to an ’X-Mms-Previously-Sent-
By:’ header with a leading "0" value. The value of the top-most
’Resent-From:’ header is mapped to the ’From:’ header. The value of
each subsequent ’Resent-From:’ header is mapped to an ’X-Mms-
Previously-Sent-By:’ header with the next larger leading value.
The original ’Date:’ header is mapped to an ’X-Mms-Previously-Sent-
Date-and-Time:’ header with a leading "0" value. Note that the value
is also converted from date-time syntax [Msg-Fmt] to HTTP-date syntax
[HTTP]. The value of the top-most ’Resent-Date:’ header is mapped to
the ’Date:’ header. The value of each subsequent ’Date:’ header is
mapped to an ’X-Mms-Previously-Sent-Date-and-Time:’ header with the
next larger leading value.
If one or more ’Resent-Message-ID:’ headers are present, the top-most
one SHOULD be mapped to ’Message-ID:’; otherwise, the ’Message-ID:’
header should be retained.
An ’X-Mms-Forward-Counter:’ header SHOULD be created when ’Resent-’
headers have been mapped to ’X-Mms-Previously-Sent-’ headers. Its
value SHOULD be the number of ’Resent-’ blocks that existed prior to
mapping.
Example:
The original message:
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
Is resent by Colonel Corn to L. Eva Message:
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
L. Eva then resends to her MMS device:
Resent-Date: Fri, 1 Apr 2005 18:02:03 -0800
Resent-From: L. Eva Message <lem@example.org>
Resent-To: b1ff@mms.example.com
Resent-Message-ID: <99887766.112233@mail.example.org>
Resent-Date: Fri, 1 Apr 2005 16:02:03 -0800
Resent-From: Colonel Corn <gcorn@example.mil>
Resent-To: L. Eva Message <lem@example.org>
Resent-Message-ID: <msg234@mail.example.mil>
Date: Fri, 1 Apr 2005 14:02:03 -0800
From: General Failure <mfail@example.mil>
To: Colonel Corn <gcorn@example.mil>
Message-ID: <msg123@mail.example.mil>
This would be mapped to an MMS message as:
X-Mms-Forward-Counter: 2
X-Mms-Previously-Sent-Date-and-Time: 0, Fri, 01 Apr 2005 06:02:03 GMT
X-Mms-Previously-Sent-By: 0, General Failure <mfail@example.mil>
X-Mms-Previously-Sent-Date-and-Time: 1, Fri, 01 Apr 2005 08:02:03 GMT
X-Mms-Previously-Sent-By: 1, Colonel Corn <gcorn@example.mil>
Date: Fri, 1 Apr 2005 18:02:03 -0800
From: L. Eva Message <lem@example.org>
To: b1ff@mms.example.com
Message-ID: <99887766.112233@mail.example.org>
Note that the original ’From:’ and ’Date:’ values were moved to ’X-
Mms-Previously-Sent-By:’ and ’X-Mms-Previously-Sent-Date-and-Time:’
headers with a leading "0" value. The first ’Resent-From:’ and
’Resent-Date:’ values were moved to a second set of ’X-Mms-
Previously-Sent-’ headers, with a leading "1" value. The third set
of ’Resent-’ headers were moved to the ’Date:’, ’To:’, and ’From:’
headers.
Note also that the format of the date and time differs between the
’Date:’ / ’Resent-Date:’ and the ’X-Mms-Previously-Sent-Date-and-
Time:’ headers, in that the latter use HTTP-date [HTTP] instead of
date-time [Msg-Fmt].
’Received:’ Headers
Each system that processes a message SHOULD add a ’Received:’ header
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.
Sensitivity
The ’Sensitivity:’ header field (value = "personal" or "private")
[VPIM] indicates the desire of a voice message originator to send the
message contents to the original recipient list with assurance that
the message will not be forwarded further by either the messaging
system or the actual message recipient(s). Since sensitivity is not
an MMS feature, any messages that contain a ’Sensitivity:’ header
MUST NOT be sent to an MMS system. The associated negative delivery
status report MUST include the extended status code [RESP] 5.6.0 as
specified in [VPIM] ("Other or undefined protocol status") indicating
that privacy could not be ensured.
Content
The message content appears in the message body.
2.1.4. Report Generation and Conversion
Internet message systems use the multipart/report MIME type for
delivery and disposition reports as specified in [Report-Fmt]. This
format is a two- or three-part MIME message; one part is a structured
format describing the event being reported in an easy-to-parse
format. Specific reports have a format that is built on
[Report-Fmt]. Delivery reports are specified in [DSN-Msg]. Message
disposition reports, which include read reports, are specified in
[MDN].
By contrast, MMS reports are plain text, with no defined structure
specified. This makes it difficult to convert from an MMS report to
a standard Internet report.
An implementation conforming to this specification MUST convert
reports received from one side (MMS or Internet mail) destined for
the other. In addition, reports MUST be generated as appropriate for
messages received from either side. For example, if an MM to be sent
via Internet mail is not deliverable, a delivery status MM shall be
generated. Likewise, if an Internet message is received that cannot
be further relayed or delivered, a delivery status report [DSN-Msg]
MUST be generated.
When creating delivery or disposition reports from MMS reports, the
MMS report should be parsed to determine the reported event and time,
status, and the headers of the referenced (original) message. These
elements, once determined, are used to populate the subparts of the
delivery or disposition report. The first subpart is of type
text/plain, and contains a human-readable explanation of the event.
This text may include a statement that the report was synthesized
based on an MMS report. The second subpart is of type
report/delivery-status (for delivery reports) or report/disposition-
notification (for disposition reports). This second part contains a
structured itemization of the event. The optional third subpart is
of type message/rfc822 and includes the headers and optionally the
body of the referenced (original) message. Note that, per [DSN-Msg],
the ’DSN-Gateway:’ field in delivery reports MUST be created.
2.1.4.1. Delivery Report Mapping from MMS to Internet Message
Below, Table 4 maps information elements from MMS delivery reports to
the format specified in [DSN-Msg].
2.1.4.1.1. Table 4: Delivery Report Mappings (MMS to Internet Message)
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
ID of message whose |Message-Id: |’Message-ID:’ preserved in third
delivery status is | |subpart of delivery report.
being reported | |
----------------------|------------|-----------------------------------
Recipient address of |From: |’Final-Recipient’ field of the
the original message | |per-recipient section.
(object of delivery | |
report) | |
----------------------|------------|-----------------------------------
Destination address of|To: |’To:’ header field value of top-
report | |level.
----------------------|------------|-----------------------------------
Date and time the |Date: |’Date:’ header field value of top-
message was handled | |level.
----------------------|------------|-----------------------------------
======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem |
======================|============|===================================
Delivery status of |X-Mms- |Action and Status fields of
original message to | Status: |per-recipient section.
each recipient | |
| |The ’Action’ field indicates if the
| |message was delivered.
| |
| |For failed delivery, an appropriate
| |’Status’ value shall be included
| |per [DSN-Msg].
| |
| |The Action field is set to one of
| |the following values:
| |