Subject: an attempt to make CONNEG-over-SMTP work reasonably over mail relays

From: Keith Moore <[email-masked]>
Date: Tue, 06 Aug 2002 15:15:44 -0400

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.