RFC 4141
SMTP and MIME Extensions for Content Conversion
RFC 4141: SMTP and MIME Extensions for Content Conversion 🎀
Okay bestie, let's start with the vibe check ✨ This is an RFC, which is basically the Internet's official rulebook for how things work. This one is numbered 4141 and it's titled SMTP and MIME Extensions for Content Conversion.
- Series: Network Working Group 🌸
- Authors: K. Toyoda (PCC), D. Crocker, and Brandenburg 👑
- Category: Standards Track 🔥
- Date: November 2005 💜
- Obsoletes / Updates: the header doesn't list anything this RFC obsoletes or updates 🦋
Status of This Memo 📜
This doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions to make it better 🗣️ To find out where this protocol stands in standardization, check the current "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 💖
Copyright Notice ©️
Copyright (C) The Internet Society (2005).
Abstract ✨
Sometimes a message sender ships content in a format the recipient can't handle, or in a lower-quality version than they'd actually like. That content needs converting into something acceptable, either keeping all the same info or a more limited version, like going from color to black and white 🎨 In store-and-forward setups, it can be super handy for a middleman to do that conversion. This spec puts together two ESMTP extensions and three MIME content header fields to build a cooperative service where intermediaries can do authorized, accountable content form conversion. Iconic 💅
Table of Contents 🗂️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background. . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Notational Conventions. . . . . . . . . . . . . . . . . . 5
2. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Service Specification. . . . . . . . . . . . . . . . . . . . . 5
3.1. Sending Permission. . . . . . . . . . . . . . . . . . . . 9
3.2. Returning Capabilities. . . . . . . . . . . . . . . . . . 10
3.3. Next-Hop Non-Support of Service . . . . . . . . . . . . . 12
4. Content Conversion Permission SMTP Extension . . . . . . . . . 12
4.1. Content Conversion Permission Service Extension
Definition. . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. CONPERM Parameter to Mail-From. . . . . . . . . . . . . . 13
4.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Content Negotiation SMTP Extension . . . . . . . . . . . . . . 13
5.1. Content Negotiation Service Extension Definition. . . . . 13
5.2. CONNEG Parameter to RCPT-TO . . . . . . . . . . . . . . . 14
5.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. MIME Content-Features Header Field . . . . . . . . . . . . . . 16
7. MIME Content-Convert Header Field. . . . . . . . . . . . . . . 16
8. MIME Content-Previous Header Field . . . . . . . . . . . . . . 16
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. CONPERM Negotiation . . . . . . . . . . . . . . . . . . . 17
9.2. Example CONNEG Negotiation. . . . . . . . . . . . . . . . 18
9.3. Content-Previous. . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. CONNEG with Direct SMTP. . . . . . . . . . . . . . . . 22
Appendix B. USING Combinations of the Extensions . . . . . . . . . 23
Appendix C. MIME Content-Type Registrations. . . . . . . . . . . . 241. Introduction 💖
Okay so, Internet specs usually define the basic stuff that every participant supports 🌈 That's what lets you send basic data without knowing what extra features each recipient has. But knowing those extra capabilities unlocks fancier data types and richer content. Without that info, the sender either ships something the recipient can't process, or sends multiple versions of the same thing 🙈 This spec builds on [CONMSG], which lets a recipient ask the originator for other content forms. This one enables MIME content conversion by intermediaries, acting on behalf of both the message originator and the message recipient ✨
1.1. Background 🧚
MIME lets you tell apart and label different kinds of content [IMF, MEDTYP]. The catch is that an email originator can't know whether a recipient can actually interpret a particular data type. To keep basic MIME working, there's a minimum set of data types that everyone supports as a baseline. But then how does the originator find out whether the recipient can handle anything beyond that? Good question 🤔
A way to describe MIME types is specified in [FEAT]. [CONMSG] gives the originator a way to ask the recipient which types it supports, using email messages for the control exchange, so the recipient can send its capability info back. Honestly though, using end-to-end email messages for that control exchange adds a lot of latency and can be unreliable 😭
So here's the alternative: the originator sends the "best" form it can, and includes the same kind of permitted representation info used in [CONMSG]. Hopefully the recipient, or an intermediary, can translate that into something a limited recipient supports. This spec defines exactly that mechanism 🦋 It matches message content to what the recipient device or system can handle, using MIME content descriptors and the optional use of an SMTP-based negotiation mechanism [ESMTP1, ESMTP2].
1.2. Overview 🌸
The originator describes the content forms it'd like in MIME content descriptors. It can give "permission" to any intermediary or the recipient to convert the content into one of those forms 💅 Separately, an SMTP server can report the target's content capabilities back to the SMTP client. Then the client can convert the message into a form that works for the target system and is also acceptable to the originator. Main character energy 👑
A conversion service has to juggle three things: what the originator asks for, what's asked on the recipient's behalf, and what the converting intermediary can actually do. It gets messy because you have to figure out whether those directions are advisory or whether they're hard requirements 🫠 Advisory conversions happen if possible, but they never change message delivery. Conversions treated as a requirement, on the other hand, will block delivery if the recipient won't be able to process the content.
These possibilities combine into different outcomes when the intermediary can't satisfy both the originator and the recipient:
Table 1: FAILURE HANDLING
\ RECEIVER| | |
+-------+ | Advise | Require |
ORIGINATOR\| | |
-----------+----------+----------+
| Deliver | Deliver |
Advise | original | original |
| content | content |
-----------+----------+----------+
| Return | Return |
Require | w/out | w/out |
| delivery | delivery |
-----------+----------+----------+This table is a policy where failure handling is decided only by the originator's direction. So info on the recipient's behalf is used to guide the details of conversion, but it doesn't control whether the message gets delivered 🎀
This keeps the existing email habit of delivering content that a recipient might not be able to process. Honestly, the table could be changed to follow a different policy 🤷♀️ But that would cut into the backward compatibility users are already used to.
This spec gives you a controlled, transit-time mail content conversion service through a few pieces. Those include:
- an optional ESMTP hop-by-hop service that uses the CONPERM SMTP service extensions, issued by the originator 💌
- an optional ESMTP hop-by-hop service that uses the CONNEG SMTP service extensions, issued on behalf of the recipient 📬
- three MIME Content header fields (
Content-Convert,Content-PreviousandContent-Features) that specify the appropriate content header fields and record the conversions that have been performed 🧾
Figure 1: EXAMPLE RELAY ENVIRONMENT
+------------+ +-----------+
| Originator | | Recipient |
+------------+ +-----------+
||Posting Delivering/\
\/ ||
+--------+ +-----------------+ +--------+
| SMTP | | SMTP Relay | | SMTP |
| Client |--->| Server | Client |--->| Server |
+--------+ +--------+--------+ +--------+1.3. Notational Conventions 📝
In examples, C: and S: show lines sent by the client and server, respectively 🫶
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Keep those capitalized words in mind, because they're the real rules here 🔥
2. Applicability 🌷
This spec defines a cooperative mechanism for transforming content early on 🎀 It can save bandwidth and let content render on recipient devices with limited capabilities. In the first case, the assumption is that conversion produces smaller content. In the second case, the assumption is that the recipient device can render a version derived from the original, but can't render the original form itself 💖
The mechanism can put serious resource demands on intermediaries that do the conversions 😮💨 The intermediary also takes on responsibility for conversion before knowing whether it can actually pull it off. And watch out: conversion isn't possible for content that's been digitally signed or encrypted, unless the converting intermediary can decode and re-code the content 🔐
3. Service Specification ✨
Okay bestie, this service is a combo of two ESMTP extensions and three MIME content header fields 💅. Together they let authorized, accountable content form conversion happen along the way. The middlemen, called intermediaries, are ESMTP hosts (clients and servers) sitting on the transmission path between an originator and a recipient 🦋.
An originator says which content-types they'd prefer through the Content-Convert MIME content header field. Those header fields show up in each MIME body-part they apply to, so every body-part keeps its own record of conversion guidance and history 🎀.
The originator's preferences can be upgraded to a hard requirement with the ESMTP CONPERM service extension. CONPERM is only needed when the originator wants the mail transfer service to enforce conversion limitations. And if an acceptable content type can't be delivered, then no delivery happens at all 😭.
Target system capabilities get shared during SMTP sessions through the ESMTP CONNEG service extension. That info only narrows down which conversions are allowed. It doesn't change whether delivery happens 🌸.
When CONPERM is in play, the conversion gets done by the first ESMTP host that can get both the originator's permission and the recipient's capability info. If a relay or client can't pass the message to a next-hop that supports CONPERM, or can't do the right conversion, it stops transmitting and sends a [DSNSMTP, DSNFMT, SYSCOD] back to the originator with status code 5.6.3 (Conversion required but not supported) 💀.
When an SMTP relay or server converts content, it logs exactly which conversions it made in the Content-Previous and Content-Features MIME header fields on each converted MIME body-part 📝.
If a message is protected by strong content authentication or privacy techniques, then an intermediary that converts the content MUST make sure the results of its processing are protected the same way. Otherwise it MUST NOT perform conversion 🔐.
Originator Action:
The originator says what conversion results they want through the MIME Content-Convert header field. If they include a Content-Convert header field, they also have to include a Content-Feature header field, which shows the current form of the content 🧁. Intermediaries MAY read the presence of that header field as permission to convert. When Content-Convert header fields are the only thing guiding conversions, they're just advisories. If an intermediary doesn't follow that guidance, the final delivery is still fine 🌈.
When posting a brand-new message, the originator MAY ask for transit-service enforcement of conversion limitations by using the ESMTP CONPERM service extension. In every MIME body-part where conversion is authorized, conversions MUST be limited to the ones listed in the MIME Content-Convert header fields. If conversion is needed but an authorized conversion can't be done, the message gets returned to the originator. If CONPERM isn't used, then failing to do an authorized conversion won't change normal delivery handling 🙃.
Figure 2: CONPERM USAGE
+------------+
| Originator |
+------------+
SMTP ||
or || CONPERM
SUBMIT \/
+--------+ +----------------+
| SMTP | SMTP | SMTP Relay |
| Client |----------->| Server | |
+--------+ CONPERM +--------+-------+Recipient Action:
With the ESMTP mail transfer service, the capabilities that can be supported on the recipient's behalf SHOULD be shared with intermediaries through the ESMTP CONNEG service extension 🎯.
Figure 3: CONNEG USAGE
+-----------+
| Recipient |
+-----------+
Capabilities||
\/
+----------------+ +--------+
| SMTP Relay | CONNEG | SMTP |
| | Client |<--------| Server |
+-------+--------+ +--------+Intermediary Actions:
An intermediary MAY be given CONPERM direction when it receives a message, and it MAY be given CONNEG guidance before it sends the message 🦋. CONPERM and CONNEG work on a per-message basis and get issued through the ESMTP MAIL-FROM request. The CONNEG response info comes back per-recipient, through the response to ESMTP RCPT-TO 📬.
Conversion MUST be performed by the first CONPERM intermediary that gets the CONNEG capability information. The MIME Content-Type MUST match the result of the converted content, per [MEDTYP] 💜. When an intermediary gets different capability info for different recipients of the same message, it MAY do either of these:
- Make a single converted copy of the content that all of the recipients can support, or
- Make multiple converted copies that match the capabilities of subsets of the recipients. Each version then gets sent separately to the right subset of recipients, using separate, standard SMTP sessions with separate, standard RFC2821.Rcpt-To lists of addresses 🧩.
A record of conversions gets placed into the MIME Content-Previous header fields. The current form of the content is described in the MIME Content-Features header fields 📋.
There's also a special case of differing capabilities, and it's kind of a plot twist 🙈. It happens when an intermediary gets capability info about some recipients but none about others. For example, you might send to some people in your own organization and some people somewhere else. The intermediary might know about the local recipients but have zero info about the distant ones. This gets handled as a variation of what happens when the permissible conversions are the null set, meaning no valid conversions are possible for a recipient.
Instead of just failing the transmission to recipients with no capability info, an intermediary MAY choose to split the addressees into subsets of separate, standard RFC2821.Rcpt-To lists and separate, standard SMTP sessions. Then it can keep sending the original content to those recipients through continued use of CONPERM. So for those recipients, the handling is the same as if no CONNEG transaction had happened at all 🫶.
Once an intermediary has done a conversion, it MAY stop using CONPERM. However, some relay environments, like the ones redirecting mail to a new target device, benefit from more conversion ✨. Intermediaries MAY keep using CONPERM, or MAY start CONPERM up again, when they learn about possible variations in a target device 🌸.
NOTE: A new, transformed version of the content may have less information than the earlier version. Of course, a sequence of transformations may lose more information at each step. Perhaps surprisingly, this can result in more loss than might be necessary. For example, transformation x could change content form A into content form B, and then transformation y changes B into C. However, it's possible that transformation y could have accepted form A directly and produced form D, which keeps more of the original information than C 🤯.
NOTE: An originator MAY validate any conversions that are made by requesting a positive [DSNSMTP]. If the DSN request includes the "RET" parameter, the delivery agent SHOULD return an exact copy of the delivered (converted) message content. That way the originator can inspect the results of any conversion(s) 🔍.
3.1. Sending Permission
A message originator that allows content conversion by intermediaries MAY use the CONPERM ESMTP service extension and the Content-Convert MIME header fields to say which conversions intermediaries are allowed to do 🎀. Other mechanisms for an originator to tell the SMTP message transfer service about this permission are outside the scope of this specification 🙅.
NOTE: This option means a server has to make an open-ended commitment to make sure acceptable conversions get performed. In particular, an intermediary might be required to perform a conversion but be unable to do it. The result is that the intermediary is required to convert, but the conversion ends up happening in undelivered mail 😭.
When an ESMTP client is authorized to take part in the CONPERM service, it MUST talk to the next SMTP hop server about:
- The server's ability to enforce authorized conversions, through ESMTP CONPERM
- The capabilities supported for the target device or system, through ESMTP CONNEG
Using CONPERM successfully doesn't require conversion to happen along the message transfer path 🛤️. What it does require is that conversion happens when a next-hop server reports capabilities that can be supported on the recipient's behalf (through CONNEG) and those capabilities don't include support for the current representation of the content 💅.
NOTE: It's totally acceptable for every SMTP server, including the last-hop server, to support CONPERM while none of them offer CONNEG. In that case, the message gets delivered to the recipient in its original form, and any possible conversions are left up to the recipient. So the recipient gets the original form of the content, along with an explicit list of conversions the originator considers acceptable 🧚.
An SMTP server MAY offer ESMTP CONPERM without being able to perform conversions itself, if it knows conversions can be performed along the rest of the transfer path, or by the target device or system 💖.
3.2. Returning Capabilities ✨
Okay so a target recipient device or system tells the SMTP service about its content form capabilities through a means that's totally outside the scope of this spec 📬. Heads up, though: letting a server issue CONNEG info on the recipient's behalf can need a pretty substantial mechanism between the recipient and the server 🫶. When an ESMTP server knows a target's capabilities, it MAY offer the CONNEG ESMTP service extension 💅.
NOTE: One part of that mechanism, between the recipient and an ESMTP server offering the CONNEG ESMTP service extension, could mean offering capabilities beyond the ones the recipient supports directly 👀. The server, or other intermediaries between the server and the recipient, could support capabilities they can convert into one the recipient has 🦋. As long as the result is acceptable to the set given in the relevant Content-Convert header fields of the message being converted, the details of those conversions are part of the recipient/server mechanism, and they fall outside the scope of this specification 🫠.
If a next-hop ESMTP server says it supports CONNEG while a message is being processed under the CONPERM mechanism, then the SMTP client:
- MUST request CONNEG information
- MUST perform the requisite conversions, if possible, before sending the message to the next-hop SMTP server
- MUST fail message processing if any conversion for the message fails, and MUST return a failure DSN to the originator with status code
5.6.5(Conversion failed) 💀
When performing conversions, as specified in Content-Convert MIME header fields, the Client MUST:
- Add a
Content-Previousheader field and aContent-Featuresheader field to each MIME body-part that has been converted, removing any existingContent-Featuresheader fields 🎀. - Either:
- Send a single copy to the next-hop SMTP server, using the best capabilities supported by all recipients along that path, or
- Separate the transfers into multiple, standard
RFC2821.Rcpt-Toand ESMTP sessions, so the best conversions possible can be provided for subsets of the recipients 🧚.
If the transfers are going to be separated, then the current session MUST be terminated, and new sessions conducted for each subset 🌸.
The conversions to be performed are determined by the intersection of three lists 💜:
- Conversions permitted by the originator
- Content capabilities of the target
- Conversions that can be performed by the SMTP client host
Failed Conversion 🙈
If the result of this intersection is the null set of representations for an addressee, then delivery to that addressee MUST be handled as a conversion failure.
If handling is subject to the CONPERM mechanism and:
- the next-hop SMTP host does not indicate that it can represent the target's capabilities through CONNEG, but
- does respond that it can support CONPERM, then the client SMTP MUST send the existing content, if all other SMTP transmission requirements are satisfied.
If handling is not subject to the CONPERM mechanism, then conversion failures do not affect message delivery 🌈.
3.3. Next-Hop Non-Support of Service 🥀
If a Client is participating in the CONPERM mechanism, but the next-hop SMTP server does not support CONPERM or CONNEG, then the SMTP client:
- MUST terminate the session to the next-hop SMTP server, without sending the message
- MUST return a DSN notification to the originator, with status code
5.6.3(Conversion required but not supported). [DSNSMTP, DSNFMT, SYSCOD]
If a Client is participating in the CONPERM mechanism and the next-hop SMTP server supports CONNEG, but provides no capabilities for an individual RCPT-TO addressee, then the SMTP client's processing for that recipient MUST be either to:
- Treat the addressee as a conversion failure, or
- Separate the addressee from the address list that is processed according to CONNEG, and continue to process the addressee according to CONPERM 🫶.
4. Content Conversion Permission SMTP Extension 🔥
4.1. Content Conversion Permission Service Extension Definition 💅
- The name of the SMTP service extension is
"Content-Conversion-Permission" - The EHLO keyword value associated with this extension is
"CONPERM" - A parameter using the keyword
"CONPERM"is added to the MAIL-FROM command. - The server responds with acceptance or rejection of support for CONPERM, for this message.
4.2. CONPERM Parameter to Mail-From 👑
Parameter: CONPERM
Arguments: There are no arguments. Specification of permitted conversions is located in a Content-Convert header field for each MIME body-part in which conversion is permitted.
Client Action: If the server issued a 250-CONPERM as part of its EHLO response for the current session, and the client is participating in the CONPERM service for this message (such as by having received the message with a CONPERM requirement), then the client MUST issue the CONPERM parameter in the MAIL-FROM. If the server does not issue 250-CONPERM, and the client is participating in the CONPERM service for this message, then the client MUST treat the transmission as permanently rejected 😭.
Server Action: If the client specifies CONPERM in the MAIL-FROM, but the server does not support the CONPERM parameter, the server MUST reject the MAIL-FROM command with a 504-CONPERM reply. If the client issues the CONPERM parameter in the MAIL-FROM, then the server MUST conform to this specification. Either it MUST relay the message according to CONPERM, or it MUST convert the message according to CONNEG information 🍓.
4.3. Syntax 🧾
Content-Conversion-Permission = "CONPERM"5. Content Negotiation SMTP Extension 🌸
5.1. Content Negotiation Service Extension Definition ✨
- The name of the SMTP service extension is:
"Content-Negotiation" - The EHLO keyword value associated with this extension is:
"CONNEG" - A parameter, using the keyword
"CONNEG", is added to the RCPT-TO command. - The server responds with a report indicating the content capabilities that can be received on behalf of the recipient device or system, associated with the target RCPT-TO address.
5.2. CONNEG Parameter to RCPT-TO 🦋
Parameter: CONNEG
Arguments: There are no arguments.
Client Action: If a message is subject to CONPERM requirements and the server issues a 250-CONNEG as part of its EHLO response for the current session, the client MUST issue the CONNEG parameter in the RCPT-TO request. If the message is not subject to CONPERM requirements, and the server issues a 250-CONNEG, the client MAY issue the CONNEG parameter with RCPT-TO.
If the client issues the CONNEG parameter with RCPT-TO, then it MUST honor the capabilities returned in the CONNEG RCPT-TO replies for that message. In addition, it MUST convert the message content, if the current form of the content is not included in the capabilities listed, on behalf of the recipient 💖.
The conversions that are performed are determined by the intersection of the 🧠:
- Conversions permitted by the originator
- Content capabilities of the target
- Conversions that can be performed by the SMTP client host
If the result of this intersection is the null set of representations, then the Client processing depends on whether the next-hop server has offered CONPERM, as well as CONNEG:
- If the message will be subject to CONPERM at the next hop, the Client MAY transmit the original content to the next hop and continue CONPERM requirements.
- Otherwise, the Client MUST treat the conversion as failed.
If the result of the intersection is not null, the client SHOULD convert the data to the "highest" level of capability of the server. Determination of the level that is highest is left to the discretion of the host performing the conversion 👑.
Each converted MIME body-part MUST have a Content-Previous header field that indicates the previous body-part form, and a Content-Features header field indicating the new body-part form 🫧.
Server Action: If the client specifies CONNEG in the RCPT-TO, but the server does not support the CONNEG parameter, the server MUST reject the RCPT-TO addressees with 504 replies.
If the server does support the CONNEG parameter, and it knows the capabilities of the target device or system, then it MUST provide that information through CONNEG. The server MAY provide a broader list than is supported by the recipient if the server can ensure that the form of content delivered can be processed by the recipient, while still satisfying the constraints of the author's Content-Convert specification(s) 🌈.
The response to a CONNEG RCPT-TO request will be multi-line RCPT-TO replies. For successful (250) responses, at least the first line of the response must contain RCPT-TO information other than CONNEG. Additional response lines are for CONNEG. To avoid problems due to variations in line buffer sizes, the total parametric listing must be provided as a series of lines, each beginning with "250-CONNEG", except for the last line, which is "250 CONNEG" 📏.
The contents of the capability listing MUST conform to the specifications in [SYN] and cover the same range of specifications permitted in [CONMSG] 🎯.
5.3. Syntax 🧾
Content-Negotiation = "CONNEG"
Capability = { <filter> specification,
as per [SYN] }6. MIME Content-Features Header Field 🧚
The Content-Features header field describes the characteristics of the current version of the content for the MIME body-part in which the header field occurs. There is a separate Content-Features header field for each MIME body-part. The specification for this header field is contained in [FEAT] 🦄.
7. MIME Content-Convert Header Field ✨
okay so Content-Convert is the header field where the sender basically says "here's what I'm cool with getting converted into" 💅 It's a MAY thing, so you can totally use it without the other stuff in this doc 🎀 But when it's there, it MUST be carried unmodified and delivered to the recipient, no edits, no cap 💖 And if it's missing? That means the content originator gave zero guidance on conversions, so intermediaries SHOULD NOT perform content conversion 🙈
Here's the ABNF so you can see the shape of it 🧚
Convert = "Content-convert" ":"
permitted
Permitted = "ANY" / "NONE" / permitted-list
permitted-list = { explicit list of permitted
final forms, using <filter>
syntax in [SYN] }So if the permitted conversions say "ANY", the intermediary can do whatever conversions it deems appropriate 🦋 And if it says "NONE", the intermediary SHOULD NOT do any conversions to that MIME body-part, even if the target device or system can't handle the original form 😭 That one's giving strict vibes 👑
Big one: if a Content-Convert header field is present, a Content-Features header field MUST also be present to describe the current form of the Content. No Content-Convert without its Content-Features bestie 🫶
8. MIME Content-Previous Header Field 🌸
So when an intermediary converts the content, it has to keep receipts ✨ It MUST record details of the previous representation it converted from, and that info goes in a Content-Previous header field that lives in the MIME body-part with the converted content 🧾 Every converted body-part gets its own Content-Previous header field, so no sharing 💅
Also, after converting, the intermediary MUST record the result by creating or revising the Content-Features header field for that converted body-part 🎀 Main character recordkeeping energy, honestly 😭
Here's the extended [ABNF] grammar for it 🧚
previous = "Content-Previous" [CFWS] ":"
[CFWS]
date by type
date = "Date " [CFWS] date-time [CFWS] ";"
[CFWS]
by = "By " [CFWS] domain [CFWS] ";"
[CFWS]
type = { content characteristics, using
<filter> syntax in [SYN] }The Date field is when the representation got converted into a newer one 🕰️ The By field is the domain name of the intermediary that did the conversion 🦋
And one more lowkey detail: an intermediary MAY choose to derive the Content-Previous header field for a body-part from an already-existing Content-Features header field in that body-part, before that header field gets replaced with the description of the current representation 🌈 Smart move, iykyk 💜
9. Examples 🍓
9.1. CONPERM Negotiation 💌
this is the vibe check for CONPERM, and honestly it's so satisfying to read 🥹 The server and client chat like a group chat that's actually organized 💅
S: 220 example.com IFAX
C: EHLO example.com
S: 250- example.com
S: 250-DSN
S: 250 CONPERM
C: MAIL FROM:May@some.example.com CONPERM
S: 250 <May@some.example.com> originator ok
C: RCPT TO:<June@some.example.com>
S: 250-<June@some.example.com> recipient ok
C: DATA
S: 354 okay, send data
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
Per:
( image-file-structure=TIFF-minimal
dpi=400
image-coding=JBIG
size-x=2150/254
paper-size=letter
)
with MIME body-parts including:
Content-Convert:
(&(image-file-structure=TIFF-minimal)
(MRC-mode=0)
(color=Binary)
(|(&(dpi=204)
(dpi-xyratio=[204/98,204/196]) )
(&(dpi=200)
(dpi-xyratio=[200/100,1]) )
(&(dpi=400)
(dpi-xyratio=1) ) )
(|(image-coding=[MH,MR,MMR])
(&(image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(size-x<=2150/254)
(paper-size=[letter,A4])
(ua-media=stationery) )
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye9.2. Example CONNEG Negotiation 🎀
same vibes but this time it's CONNEG 🦋 The server advertises its wishlist line by line with CONNEG so the client knows exactly what's up 🌸
S: 220 example.com IFAX
C: EHLO example.com
S: 250- example.com
S: 250-DSN
S: 250 CONNEG
C: MAIL FROM:<May@some.example.com>
S: 250 <May@some.example.com> originator ok
C: RCPT TO:<June@ifax1.jp> CONNEG
S: 250-<June@some.example.com> recipient ok
S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
S: 250-CONNEG (MRC-mode=0)
S: 250-CONNEG (color=Binary)
S: 250-CONNEG (|(&(dpi=204)
S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) )
S: 250-CONNEG (&(dpi=200)
S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) )
S: 250-CONNEG (image-coding=[MH,MR,MMR])
S: 250-CONNEG (size-x<=2150/254)
S: 250-CONNEG (paper-size=[letter,A4])
S: 250 CONNEG (ua-media=stationery) )
C: DATA
S: 354 okay, send data
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
Per:
( image-file-structure=TIFF-minimal
dpi=400
image-coding=JBIG
size-x=2150/254
paper-size=letter
)
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye9.3. Content-Previous 🧁
and here's what a Content-Previous header field looks like in the wild 🥐 It's basically the paper trail of the conversion, with the date, the intermediary's domain, and the old content characteristics all in one place 📜
Content-Previous:
Date Tue, 1 Jul 2001 10:52:37 +0200;
By relay.example.com;
(&(image-file-structure=TIFF-minimal)
(MRC-mode=0)
(color=Binary)
(&(dpi=400)
(dpi-xyratio=1) )
(&(image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) )
(size-x=2150/254)
(paper-size=A4)
(ua-media=stationery) )10. Security Considerations 🔐
Okay, this section is serious, so I'm keeping it serious. Read every word.
This service calls for disclosure of capabilities, on behalf of recipients. Mechanisms for determining the requestor's and the respondent's authenticated identity are outside the scope of this specification. These mechanisms are intended to permit disclosure of information that is safe for public distribution, so there is no inherent need for security measures.
Information that should have restricted distribution is still able to be disclosed. Therefore, it is the responsibility of the disclosing ESMTP server or disclosing ESMTP client to determine whether additional security measures should be applied to the use of this ESMTP option.
Use of the ESMTP CONNEG option permits content transformation by an intermediary, along the mail transfer path. When the contents are encrypted, the intermediary cannot perform the conversion, because it is not expected to have access to the relevant secret keying material. When the contents are signed, but not encrypted, conversion will invalidate the signature. This specification provides for potentially unbounded computation by intermediary MTAs, depending on the nature and amount of conversion required. Further, this computation burden might provide an opportunity for denial-of-service attacks, given that Internet mail typically permits intermediaries to receive messages from all Internet sources.
This specification provides for content conversion by unspecified intermediaries. Use of this mechanism carries significant risk. Although intermediaries always have the ability to perform damaging transformations, use of this specification could result in more exploration of that potential and, therefore, more misbehavior. Use of intermediaries is discussed in [RFC3238].
CONPERM/CONNEG provide a cooperative mechanism, rather than enabling intermediary actions that were not previously possible. Intermediaries already make conversions on their own initiative. Hence, the mechanism introduces essentially no security concerns, other than divulging recipient preferences.
11. Acknowledgements 🫶
Graham Klyne and Eric Burger provided extensive, diligent reviews and suggestions. Keith Moore, Giat Hana, and Joel Halpern provided feedback that resulted in improving the specification's integration into established email practice. ✨
12. References 📚
12.1. Normative References 💜
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [CONMSG] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.
- [DSNSMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
- [DSNFMT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
- [SYSCOD] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
- [ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
- [ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
- [FEAT] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
- [IMF] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
- [SYN] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
- [MEDTYP] IANA, "MIME Media Types", <http://www.iana.org/assignments/media-types>
- [CFWS] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
12.2. Informative References 🌷
- [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
Appendix A. CONNEG with Direct SMTP ✨
This Appendix is descriptive 💅 It only talks about usage issues that the normative text already permits or requires 🫶
okay so, in some setups you can have direct, email-based chats 📬 where the originator's system opens a direct, interactive TCP connection straight to the recipient's system 🦋 This setup lets you use the content form negotiation service the way this spec describes, but it gets some simplifications 🎀 Since it's just one SMTP session, there's none of the multi-hop relaying drama 🙈 so you don't need to pass permissions along to intermediaries. no stress 💖
The Originator's system handles the user-level stuff for the originator, and it also holds the SMTP Client that sends the messages 🧚 So the formal email "posting" step is basically internal or virtual, happening inside the Originating system ✨ The recipient's service handles the user-level stuff for the recipient, and it has the SMTP server that receives messages 🌸 So the formal "delivering" and "receipt" steps are also internal or virtual, happening inside the Receiving system 💜
Figure 4: DIRECT CONNEG
Originating system Receiving system
+------------------+ +------------------+
| +------------+ | | +-----------+ |
| | Originator | | | | Recipient | |
| +------------+ | | +-----------+ |
| ||Posting | | /\Receiving |
| \/ | | || |
| +---------+ | | +--------+ |
| | SMTP |<---|-------|----| SMTP | |
| | Client |----|-------|--->| Server | |
| +---------+ | | +--------+ |
+------------------+ +------------------+okay so CONPERM isn't needed here 🙌 because the SMTP Client is part of the originating system, so it already has the permission it needs 💅 And the SMTP server will totally know the recipient's capabilities, since it lives inside the receiving system 🔥
So Direct Mode email transmission can get content capability and form matching by having:
- Originating systems that conform to this specification, plus a communication process between originator and recipient that's the same as what would happen between a last-hop SMTP Relay and the Delivering SMTP server it's connected to 🍓
- That is, the Client and Server MUST employ CONNEG and the Client MUST perform any requisite conversions. 👑
Appendix B. Using Combinations of the Extensions 🦋
this spec defines a bunch of mechanisms 🌈 but it's not required that you use all of them together 🫶 For example, the difference between listing preferred conversions and specifying enforced limits on conversions is covered in the Introduction ✨ This Appendix walks through scenarios where you'd want fewer than the full set, and it also sums up the conditions that mean an intermediary has to do a conversion 💖
This Appendix is descriptive 💅 It only provides discussion of usage issues permitted or required by the normative text.
The available mechanisms are:
- CONPERM Parameter to Mail-From
- CONNEG parameter to RCPT-TO
- MIME Content-Convert Header Field
- MIME Content-Previous Header Field
- MIME Content-Features Header Field
B.1. Specifying Suggested Conversion Constraints 🎀
Using the MIME Content-Convert header field lets the originator say what they'd prefer, if conversion happens 💜 It doesn't put any requirements on the conversion though, it's just advisory vibes 🧚
B.2. Specifying Required Conversion Constraints 👑
When the MIME Content-Convert specification is paired with the ESMTP CONPERM option, the originator's preferred conversions level up to actual requirements 🔥 No other conversions are allowed, except the ones listed in the Content-Convert header field 🙈
Note that having both mechanisms in play doesn't mean conversions have to happen 😭 It just constrains conversions, in case they do happen 💅
B.3. Accepting All Forms of Content 🌸
Okay, it's pretty unlikely that any device can handle every type of existing content 💀 But some devices can be upgraded easily (for example, by adding a plug-in) 🧚 So a device like that is able to process all content effectively ✨
For devices like this, it's better to skip issuing a CONNEG assertion 🦋 Instead, the CONPERM request should be passed along to the target device 🫶
B.4. When Conversion is Required 🍓
A node is required to perform conversion when:
- At least one MIME Content-Covert header field is present in the message,
- ESMTP CONPERM is in force at the node processing the message,
- ESMTP CONNEG is also in force at the same node,
- The current content form is not cited in the CONNEG list,
- At least one content form is present, both in the Content-Convert list and the CONNEG list, and
- The intermediary is able to convert from the current form to one of the forms listed in both Content-Convert and CONNEG.
Appendix C. MIME Content-Type Registrations 📋
C.1. Content-Convert 💖
Header field name:
Content-Convert
Applicable protocol:
Mail (RFC 2822)
Status:
Proposed Standard
Author/Change controller:
IETF
Specification document(s):
RFC 4141.
Related information:
None.C.2. Content-Previous 🌈
Header field name:
Content-Previous
Applicable protocol:
Mail (RFC 2822)
Status:
Proposed Standard
Author/Change controller:
IETF
Specification document(s):
RFC 4141, Section 8
Related information:
None.Authors' Addresses 🫶
Kiyoshi Toyoda
Panasonic Communications Co., Ltd.
4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan
EMail: toyoda.kiyoshi@jp.panasonic.com
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.netFull Copyright Statement ⭐
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔥
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶✨
📦 where this page comes from
- ietf: rfc4141 2005-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms