| Subject: | Lift encoding restriction according to RFC 6533: can't have encoding quoted-printable for message type message/global-headers |
Trying to update my software to generate a DSN according to RFC 6533
(Internationalized Delivery Status and Disposition Notifications),
I stumbled across the following diagnostic from MIME-Tools-5.505:
can't have encoding quoted-printable for message type message/global-headers!
This is generated by the following code in MIME::Entity::build() :
### Type-check sanity:
if ($type =~ m{^(multipart|message)/}) {
($encoding =~ /^(|7bit|8bit|binary|-suggest)$/i)
or croak "can't have encoding $encoding for message type $type!";
}
The restriction above needs to be relaxed,
the RFC 2045 requirements were relaxed by RFC 6532:
RFC 2045 section 6.4
If an entity is of type "multipart" the Content-Transfer-Encoding
is not permitted to have any value other than "7bit", "8bit" or "binary".
[...]
Certain Content-Transfer-Encoding values may only be used on certain
media types. In particular, it is EXPRESSLY FORBIDDEN to use any
encodings other than "7bit", "8bit", or "binary" with any composite
media type, i.e. one that recursively includes other Content-Type
fields. Currently the only composite media types are "multipart" and
"message". All encodings that are desired for bodies of type
multipart or message must be done at the innermost level, by encoding
the actual body that needs to be encoded.
RFC 6532:
3.5. Changes to MIME Message Type Encoding Restrictions
This specification updates Section 6.4 of [RFC2045]. [RFC2045]
prohibits applying a content-transfer-encoding to any subtypes of
"message/". This specification relaxes that rule -- it allows newly
defined MIME types to permit content-transfer-encoding, and it allows
content-transfer-encoding for message/global (see Section 3.7).
3.7. The message/global Media Type
[...]
If an object of this type is sent to a 7-bit-only system, it MUST
have an appropriate content-transfer-encoding applied. (Note that a
system compliant with MIME that doesn't recognize message/global is
supposed to treat it as "application/octet-stream" as described in
Section 5.2.4 of [RFC2046].)
[...]
Encoding considerations: Any content-transfer-encoding is permitted.
The 8-bit or binary content-transfer-encodings are recommended
where permitted.
[...]
Restrictions on usage: This is a structured media type that embeds
other MIME media types. An 8-bit or binary content-transfer-encoding
SHOULD be used unless this media type is sent over a 7-bit-only transport.
RFC 6533:
Note that [RFC6532] relaxed a restriction from MIME [RFC2046] regarding
the use of Content-Transfer-Encoding in new "message" subtypes. This
specification explicitly allows the use of Content-Transfer-Encoding
in message/global-headers and message/global-delivery-status.
RFC 6533:
4.5. Additional Requirements on SMTP Servers
If an SMTP server that advertises both SMTPUTF8 and DSN needs to
return an undeliverable SMTPUTF8 message, then it has two choices for
encapsulating the SMTPUTF8 message when generating the corresponding
multipart/report:
If the return-path SMTP server does not support SMTPUTF8, then the
undeliverable body part and headers MUST be encoded using a 7-bit
Content-Transfer-Encoding such as "base64" or "quoted-printable"
[RFC2045], as detailed in Section 4.
Otherwise, "8bit" Content-Transfer-Encoding can be used.