A proposal

[Erik Naggum <erik@xxxxxxxxxxxx>]

Gentlefolks,

John Klensin and Paul Vixie have given rise to an idea in my mind.
John insists on _mail_, and I whole-heartedly agree with this.  The
minimal guaranteed communication is extremely important.  Paul insists
on not changing SMTP for a number of excellent reasons.  I'll probably
disappoint Paul, but my proposal has to do with SMTP.

Several contributors to this list have exclaimed that the cost of
another round-trip is too high, and that adding another verb to SMTP
is not the way to go.  To the extent that we not change things that
work, I agree.  There may be things we have to change, and the on-
going debate on multi-media, multiple body part _messages_ signals
such a change.

My proposal consists of two independent parts.  Please treat them so.

The first part is to make a very quiet change to the reply codes in
SMTP so that the client knows whether it can handle an 8-bit data path
before anything is said or done by the client.

Two possible solutions to signal 8-bit capability:

A. Change the 220 greeting to 228, or
B. Mandate that the third token on the 220 greeting line be some
   magic, like "8859-1", unlikely to be part of a normal greeting.

Example:

A.
    <open connection>
    228 dimacs.rutgers.edu  Hi, there, I can do 8-bit stuff.  Yo!
    ...

B.
    <open connection>
    220 dimacs.rutgers.edu 8859-1 rules OK
    ...

There are a few problems with solution A.  There are a number of broken
mailers out there who disregard RFC 821's quite explicit focus on the
first digit in the reply codes.  These will break on the 228 reply code.
I am inclined to shoot down such bogosity at sight, but abiding by
John's point that we must not lose minimal communication capability, I
will concede that this may not be a total winner.  It should be, but I
kind of doubt that sendmail (ack! barf!) does this right, either.  I
have seen sendmails die on the new 252 reply code.  Flame, flame.

Solution B is very quiet, indeed.  Sort of like freemason greetings.
Barring decrepit servers who reply with their host name and not their
FQDN, _and_ having a host name of "8859-1", this is not going to break
anything.  I don't think it's going to break anything.

Upon seeing such a reply code, the client knows that the 8th bit of the
message will be intact after the server has chewed on it.  Whether the
client should contemplate if Emacs has buddha nature or do some con-
version of the message in the absence of such a reply code, I refuse to
discuss.  Maybe it should.  I say lose, and let the sender figure out
how to get the message across sans 8-bit data.

Regarding the point by Paul that it will incur some cost to know whether
the message contains 8-bit data or not, I don't think this is a problem.
The message has to be accepted by the SMTP client somehow before trans-
mission, and that "somehow" usually includes taking it from somewhere
such as a file or pipe, and write it down into a place where the client
alone can access it.  Looking for any 8th bits in that process is not
going to be very costly.  Thus the client knows before sending a message
that it should pay particular attention to the reply code.


The second part concerns full 8-bit binary mail with bells and whistles
just like X.400 of your favorite leap year.  John gives good arguments
for not calling this "mail" and I think this is a good point.  There
are also major incompatibilities with existing mail software that we
can't just ignore.  So, a major break in the protocol will not make
any major change in the working of ordinary mail, just "messages".

I thus propose that for multi-part, multi-media messages, we adopt a new
verb in place of MAIL, but otherwise identical:

	MESG From:<forward-path>

If this fails, messages of this kind cannot be delivered.  If we build
on the first part of this proposal, we can know beforehand that trying
will fail, since it can't handle 8-bit data paths.  If it succeeds, we
add an argument to the DATA verb, also, specifying the number of bytes
to follow, thus:

	220 ifi.uio.no 8859-1 capability, and more!
	MESG From:<erik@naggum.uu.no>
	250 OK, accepting binary message
	RCPT To:<enag@ifi.uio.no>
	250 OK, he's here
	DATA 59636
	<59636 bytes of content>
	250 OK, message delivered
	QUIT
	221 ifi.uio.no welcomes you back

Note that MESG means that we don't necessarily follow RFC 822 in the
message format.  If we decide on something else, we can do that without
the burden of backward compatibility.


Please consider these two parts as independent.  Thanks.

[Erik]