Re: Proposal of new standard

[kankkune@xxxxxxxxxxxxxx (Risto Kankkunen)]

Dan Oscarsson:
> I think it is time we return to defining a new standard for email.
> 
> Lets separate this into two parts:
> The mail format (now RFC 822)
> and SMTP (now RFC 821)

Yes. That's fine. Everything concerning the content of the letter should
be defined in RFC-822(ext). SMTP(ext) specifies only the dialogue
between two mailers.

> Mail format:
> ------------

> An object is included inside an "application program command" as defined
> by ISO 6429. Anything may be included this way. (APC = \237, ST = \234)
> Format:
> <APC> format text CRLF
> encoded object lines
> <ST>

Hmm. I like the line-counting or key-word methods more than this.

> SMTP:

I'd like to extend SMTP only to tell how clever the receiving mailer is,
i.e. can it take 8-bits and/or long lines. What happens, if it cannot,
doesn't need to be written down to the protocol.

If an old sender-SMTP talks to old or new receiver-SMTP, everything goes
like currently. If an extended SMTP-sender wants to send something, it
first asks the receiver, what it can do. If it can handle 8-bits and
long lines, the sending MTA can send the mail whether it was ASCII,
8-bit text or binary. If the receiver tells it cannot handle binary, the
sender might return the letter. Or it might scan the letter to see, if
it anyway meets the requirements (doesn't contain long lines and/or
8-bit codes), and fail only if not. Or it might uuencode (or btoa or...)
the letter and add a suitable (content/encoding) header to the letter
and send it. Or if it knows that it is some kind of text (Latin-n), it
could send a readable approximation of the text (maybe told to the
program by a flag, or specified in the letter with some header
(Fallback-format: reject, Fallback-format: encode, Fallback-format:
approximate or Fallback-format: bitstrip) Hey, is this a good idea?).
What the mailer does in these situations isn't any concern of the SMTP
protocol.

The ability for SMTP to pass binary data is used just to not waste
bandwidth when it isn't necessary. We should design the RFC-822(ext)
level formats so that for every type there is at least one 7-bit
short-line ASCII representation. Ideally one could combine any content
type with any encoder (e.g Content: text,compress,uuencode or Content:
gif,btoa).

The only addition to the SMTP protocol would be a command to ask
receivers capabilities. Because handling binary requires the ability to
handle arbitrary long lines (=distance between CRLF's can be whatever),
it is feasible to separate this from the 8-bit capability. Some sites
might upgrade only to 8-bit text mailers, others to binary mailers and
maybe others to 7-bit long-line mailers depending on availability of
software and depending on operating environment. There are many ways to
query the capabilities. I somewhat like the method I have mentioned here
earlier. The sending MTA sends EXTN command after HELO. If the receiver
is not extended, it gives some error message, so the sender knows to use
only 7-bit short lines in DATA, or fail. If the receiver is extended, it
should reply with

 250-8-BITS         or 250-UNLIMITED-LINE or 250 UNLIMITED-LINE or 250 8-BITS
 250 UNLIMITED-LINE    250 8-BITS

According to this the sender decides what codes it can use in the DATA
part. This requires only one additional roundtrip, is similar to the
current EXPN command and is extendable. If we should need some other
information from the receiver's capabilities in the future (I hope not),
it could simply be added to the response list without breaking anything.

Risto

-- 
 Risto Kankkunen                   kankkune@cs.Helsinki.FI (Internet)
 Department of Computer Science    kankkunen@finuh          (Bitnet)
 University of Helsinki, Finland   ..!mcsun!uhecs!kankkune   (UUCP)