Re: WG Last Call: Binary SMTP

[Keith Moore <moore@xxxxxxxxxx>]

Greg writes (to ietf-smtp):

>     At the last meeting of the IETF mail extensions working group, I took 
>     an action to initiate a 4 week working group last call period for this 
>     SMTP binary extension.
>     
>     The document is in the Internet-Drafts directories as 
>     <draft-vaudreuil-smtp-binary-04.txt>.  It will be reposted as an 
>     Internet draft under the filename <draft-mailext-smtp-binary-04.txt>
>     
>     The working group discussed this proposal and identified no problems.  
>     However, there was an insufficient people present who felt competent 
>     to fully approve this document, and a last mailing list review was 
>     requested.  Please give this document a final once-over (or twice) and 
>     send comments.  There is already one implementation of this protocol 
>     extension. 

Comments on the CHUNKING extension:

1) it would be useful, I think, to explicitly state that BDAT and DATA
   cannot both be used in the same mail transaction.  Once BDAT has been
   issued, any DATA command (without an intervening MAIL or RSET command)
   should result in a 5XX error.  Similiarly for use of BDAT after DATA.

2) Explicitly state that RSET clears all accumulated chunks.

3) I believe there is also a need for checkpoint/restart mechanism based on
   chunking, which should be included in the chunking extension.  Though an
   additional extension along these lines would be cheap to implement, each
   new SMTP extension introduces the potential for bugs in the client-server
   interaction.  (If nothing else, there are more conditions to test.)  This
   is particularly true for an SMTP extension that changes the SMTP state
   machine. 

   I realize that checkpoint/restart introduces its own set of concerns,
   (including the possible need for security measures), but I would like to
   see further discussion of this matter to determine whether this is the
   right set of functionality, before putting the CHUNKING extension on the
   standards track. 

Comments on the BINARYMIME extension:

1) The introduction of binary transparent transport in Internet mail 
   raises some problems with regard to MIME interoperability in
   multiprotocol environments.  Despite the careful specification of 
   CR LF as a line terminator in both RFC 822 and MIME, MIME mail 
   is presently sent as ordinary text between systems, using whatever
   end-of-line convention is normally used in that environment.  For
   SMTP this is CR LF at the ends of lines, but for (say) UUCP each
   line is terminated by a newline.  Existing UAs and some MTAs expect
   these conventions to be followed, at least for the headers (both
   message and body-part headers) and all body parts using a
   content-transfer-encoding of 7bit, 8bit, quoted-printable, or base64.

   In order to achieve both transparency (for MIME BINARY-encoded
   body parts) and compatibility (for the other content-transfer-encodings),
   an MTA which supported both BINARY SMTP and UUCP would need to
   carefully translate each message which passed from one environment
   to the other.  All BINARY-encoded body parts would need to be passed 
   verbatim, while all headers, boundary markers, and text-encoded
   body parts would be passed using the text conventions of this
   environment.  

   Some careful specification of this translation would be necessary to 
   avoid interoperability problems.  For instance: should the boundary 
   marker following a BINARY body part that is being sent over UUCP 
   be formatted as "\r\n--gibberish\r\n"  or "\r\n--gibberish\n"
   or "\n--gibberish\n"?

   This is not, strictly speaking, a problem with BINARY SMTP.  However,
   this problem doesn't crop up in practice until BINARY SMTP is 
   introduced.  Those implementing BINARY SMTP from the current draft
   specification have no warning about the interoperability 
   problems that would likely result from implementing this, and no
   guidance as to how to address such problems.

   I think this problem needs to be addressed before this proposal
   is issued as an RFC (regardless of its standardization status).

2) Even assuming that a specification for translation of BINARY MIME 
   objects across different transports were produced, it seems likely
   that there would be some kinks to work out.  I therefore would
   prefer that the BINARYSMTP proposal be issued first as an 
   Experimental protocol rather than a Proposed Standard protocol.

3) There should be an explicit instructions for a SMTP server 
   which is presented with "MAIL FROM...BODY=BINARYMIME" followed 
   by "DATA".  (i.e. which error code, and what state is the SMTP 
   server in after this?)

Keith