RFC 1426 problem and solution

[Michael D'Errico <mike@xxxxxxxxxxxxxxxxx>]

Hello everyone,

I just joined this list and read the latest archive, but it only
goes up to January, 1993 so if this has been discussed before,
please calmly ignore it.  It does specify a simple method for
providing a true 8bit transport so you may want to read it....

I have gone over RFC 1426 again and again and have finally realized
that it is indeed possible to send arbitrary binary messages IF you
don't do the things that sendmail normally does (conversion of CRLF
to LF).  I've been using UNIX way too long!

There is still one problem that bothers me -- the 1000 byte line
length restriction.  If that single restriction could be removed,
then sending completely arbitrary binary messages is possible.
As it stands, any binary file that I may want to transfer must have
no more than 1000 arbitrary bytes between CRLF pairs.  And since the
probability of CRLF occurring randomly is one in 65536, it is un-
likely that any of my binary files over 1000 bytes long can be trans-
ferred using the 8BITMIME extension to SMTP.

It would be possible to have true 8-bit transport by adding a simple
extension, call it the "I don't have line length restrictions"
extension which tells the sending SMTP that the receiver will take
anything it's got.  Call it "LENGTH" for lack of a better idea.

This seems like a good candidate for an addition to ESMTP and it
doesn't even require any extended MAIL or RCPT commands.  The sender
only has to look for the keyword in the EHLO response.

So if you see:
	220 software.com SMTP ready at Thu, 30 Sep 93 16:47:06 PDT
	EHLO rome.software.com
	250-software.com Hello rome.software.com
	250-8BITMIME
	250 LENGTH

then you know a true 8-bit path is waiting.  The only minor problem
I see is that the message body must have a CRLF as the last two
octets so that the receiver knows when the .CRLF occurs.  This can
be dealt with either by extending the MAIL command or by forcing the
binary data to be enclosed within a section of a multipart MIME message
since the encapsulation boundary will have the trailing CRLF.  I think
the latter is a much better solution even though it restricts the
message format somewhat, but it is better than extending the MAIL
command in my opinion.

Any comments?

Michael D'Errico
mike@software.com