this is an attempt to outline what it will take to make CONNEG-over-SMTP
work reasonably over mail relays
goals:
- make it possible for a client to request recipient capabilities,
for whatever use, provided it can communicate directly with
recipient's SMTP servers.
- make it possible for senders to request "assuredly deliver in a
form the recipient can use, else fail" semantics.
- work with relaying
- no change to current SMTP functioning unless explicitly requested
by sender
1. providing recipient capability information
for general-purpose mail reception, recipient capability information
MUST be under the control of the recipient.
for fixed-function devices which have exclusive use of one or more
mailboxes, the recipient capabilities associated with those mailboxes
MAY be set by such devices to reflect their capabilities. the mechanism
by which this is done, in the case where the SMTP server and the
receiving device are separate, is currently unspecified.
posting of recipient capability information DOES NOT imply that the
recipient is unwilling to accept contents that are outside of those
capabilities. (if this functionality is desirable this needs to be a
separate capability - because it's clearly useful to state preferences
while still being willing to accept the occasional attachment in an
unpreferred format)
2. obtaining recipient capability information
recipient capability information (if available) may be obtained by any
party in the following way:
- do a SRV lookup in DNS for {prefix-tbd}._tcp.{recipient-domain}.
if any servers are returned, contact them using the SMTP protocol.
if server supports CONNEG in the EHLO response. issue RCPT
<recipient> CONNEG=OPTIONAL, record results, issue QUIT, and
close connection.
this allows senders to potentially determine recipient capability
prior to sending the message.
there is no requirement that the SMTP servers advertised in this
manner actually be willing to accept mail, unless they are also
advertised as MXes for that domain. e.g. they can respond to all
DATA and similar commands with 5xx errors.
any CONNEG information returned by such servers MUST be consistent
with CONNEG information that would be obtained by MTAs relaying
mail to the recipient, though the information is allowed to change
over time.
3. originating mail with "deliver recipient-usable content or fail"
semantics
this extension attempts to provide a new transport option, known as
"deliver recipient-usable content or fail" (DRUCOF for short) semantics
- DRUCOF semantics MUST be explicitly requested by the sender
- in SMTP, the sender's request is communicated with a DRUCOF option
to RCPT (which is advertised in EHLO in the usual way, details
to be determined)
- server advertisement of DRUCOF in EHLO asserts that the server is
willing to convey any sender's request for DRUCOF semantics
and to implement them as provide in section 4.
DRUCOF applies only to critical portions of a message. By default
all portions of a message are assumed to be critical. This can be
specified by the sender on a per-body part basis by including an
appropriate body part header. details to be determined.
it should be possible to mark a body-part in any of several ways:
conversion-prohibited, conversion-permitted, omission-permitted;
it should also be possible to mark a body-part as to whether
ability to provide the specified integrity level is critical
to successful message delivery.
the DRUCOF extension is defined as a mechanism to allow the sender's
request for "deliver recipient-usable content or fail" semantics
to be communicated through relays. if initial submission of the
message (from the UA) is directly to the recipient's primary MX,
DRUCOF is not needed, and the behavior of the sender is as specified
in the next section.
4. relaying mail with the DRUCOF option
when an SMTP client attempts to relay mail to a recipient for which
the DRUCOF option was specified, or for which the SMTP client knows
for certain that the sender requests DRUCOF semantics, the following
applies:
- if the SMTP server advertises CONNEG:
- if an attempt to request a CONNEG string for the recipient succeeds {
- if the client can perform conversions to make the message
acceptable to the recipient, or if no conversions are
necessary to make the message acceptable, perform conversions
as necessary and relay the message without asserting DRUCOF
or CONNEG.
- else, if the server supports DRUCOF, relay the message with
the DRUCOF option (if the client can't perform the conversion,
perhaps a later MTA can)
- else, the delivery fails (conversion required but not supported)
}
- else (request for CONNEG string for a recipient fails
due to a permanent or temporary error) {
- if the server supports DRUCOF, relay the message with
the DRUCOF option to RCPT
- else, the delivery fails (DRUCOF specified but capabilities unavailable)
}
- else, if the SMTP server advertises DRUCOF
- relay the message with DRUCOF set
- else
- the delivery fails (no way to relay sender's preference for DRUCOF)
note: the above assumes that it's better to convert as early as possible,
and (more to the point) to provide as many opportunities for conversion
as possible. one could argue that it's better to convert as late as
possible so that the conversion is closer to the recipient and more likely
to be done according to the recipient's preferences. I'm not sure about
which is better.
note 2: it should be feasible to extend this to allow the sender to
optionally request conversion when available and appropriate, but to
deliver intact if conversion cannot be performed.
5. conversions
conversions MUST NOT be performed unless requested by the sender
conversions MUST NOT be performed in the absence of specific information
about the recipient
conversions MUST NOT be performed on content marked conversion-prohibited.
conversions performed by MTAs other than the sender or recipient's
SHOULD be standardized by some appropriate body
conversions SHOULD be chosen in such a way as to minimize loss of
information
when multiple conversions are possible, the least lossy conversion
SHOULD be employed.