[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: Binary SMTP
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
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
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
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
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"
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?)