headers
KLENSIN | 3 Oct 1991 01:12
Picon

Revised RFC-ZZZZ part 2 of 6

Network Working Group                           J. C. Klensin
INTERNET DRAFT                                  R. Kankkunen
Updates: 821                                    G. M. Vaudreuil
                                                C. F. Everhart
                                                July 9, 1991

     SMTP Extensions for Transport of Enhanced Text-Based Messages

Status of this Memo

   This document specifies an extension to the SMTP protocol.  It will
   be submitted to the RFC editor as a proposed standard.  Distribution
   is unlimited.  Comments are solicited and should be sent to the
   first listed author at Klensin <at> MIT.EDU or, preferably, by joining in
   discussions on the ietf-smtp mailing list (subscription requests to 
   ietf-smtp-request <at> dimacs.rutgers.edu, postings to 
   ietf-smtp <at> dimacs.rutgers.edu).

1. Introduction

RFC 821 [RFC821] defines a protocol, SMTP, to transfer mail reliably
and efficiently. It is largely independent of the transmission
subsystem used.    It requires only a reliable ordered data stream of at
least 7-bit units that consists of "lines" and "characters".  It also
makes some implied assumptions about end-to-end virtual circuit
connections as the primary model for transporting and delivering mail.

SMTP, as described in RFC821, is restricted to the transport of data in
7-bit ASCII [ANSI-X3.4] encoding.  The term "ASCII", as used in this
RFC, refers to ANSI X3.4, and not to any national language variations
(Continue reading)

Permalink | Reply | 0 comments |
headers
KLENSIN | 3 Oct 1991 01:11
Picon

Revised RFC-ZZZZ part 1 of 6

Dear long-suffering ietf-smtp reader,
   I am posting a vastly revised and expanded RFC-ZZZZ in several parts
(it totals about 98Kb).  This might be considered "part 0".  It
discusses what the revised document is all about and is very important
in understand the other pieces.  The most important point below is that
this is *not* a proposal but an attempt at focusing discussion on
issues in the hope that enough material can be agreed upon as suitable
for elimination that a real proposal can be constructed. 
   My apologies for the length, but I felt that one very long document
that drew the issues together in one place might provide a better focus
than days of debate about isolated components of the system.  I hope
that effort has at least partially succeeded.
    --john klensin
     Klensin <at> infoods.mit.edu

---------------------------------
Foreword and notes (not part of the RFC)

  This document is a drastic revision of the 9 July (pre-Atlanta)
RFC-ZZZZ, aka draft-ietf-smtpext-8bittransport.  It responds to several
factors, most real and a few probably imagined.  They include:
  - A sense of need to focus discussion on issues of transport for mail
that handles other than 7bit characters.  This sense is partially
predicated on multiple affirmations that "8bit transport isn't going to
go away, the only question is whether we will regularize it in some
reasonable way or just, by default, encourage vendors to do their own
things".  This principle, and the consequent requirement for an
enhanced transport proposal, was affirmed in Atlanta.
  - Multiple expressed desires to expand SMTP to transport several new
sorts of things and to support several additional features.  As a
(Continue reading)

Permalink | Reply | 0 comments |
headers
KLENSIN | 3 Oct 1991 01:12
Picon

Revised RFC-ZZZZ part 6 of 6 (last part)


11.2 Responses when EMAL is recognized.

An SMTP server which does implement this RFC may nonetheless respond to
the EMAL verb or its variations with an error message.  The new code
556 is assigned to this purpose, to be construed as "enhanced transport
not accepted" if it appears in response to an enhanced FROM verb.
Presumably this would occur only if the originator specification (the
parameter to the enhanced FROM verb) was unacceptable for enhanced
transport for some reason since implementations conforming to this RFC
must be able to accept at least the TYPE forms specified above.  It
should be construed as "specified enhanced transport type not
acceptable" in response to a TYPE command.

<>    Discussion: Ideally, a server that can accept a particular
      enhanced transport option for any destination should be able to
      accept it for any destination for which it accepts mail.  In
      practice, that may sometimes not be the case.  In addition, the
      general design of RFC-821 permits a server to decline to accept
      particular piece of mail for any particular destination for any
      reason.  Consequently, it is not possible to prohibit a server
      from accepting enhanced mail and a particular type and then
      rejecting a delivery address.  Our design choices in the matter
      are limited to whether to permit RCPT TO to deliver 556
      (indicating that the particular transport type is not acceptable)
      or whether it should be restricted to one of existing (RFC-821)
      non-delivery codes.

556 may also be returned in response to one or more of the RCPT
commands if the refusal is destination-specific.  More specifically, a
(Continue reading)

Permalink | Reply | 0 comments |
headers
KLENSIN | 3 Oct 1991 01:16
Picon

Revised RFC-ZZZZ part 5 of 6


8. Interaction with the message format and headers.

Both RFC821 and 822 explicitly reference "ASCII" as the character code
in which all text is written and with which it is interpreted.    The
introduction of an enhanced transport mechanism introduces a potential
ambiguity, since, while there is only one ASCII, there are many
character sets and mechanisms using 8-bit and longer coding.  This has
two implications:

8.1 Message format.

When sending a message using this protocol extension, the message
header format MUST conform to <draft-ietf-822ext-messagebodies> and, in
particular, with its provisions for specifying message body types and
character sets.

8.2 Header character set.

<>    Discussion and request for lots more discussion: There are two
      basic theories about how one might handle the headers of a
      message that is envelope-specified to be in, e.g., 32 bit ISO
      10646.  Your friendly editor can argue for either approach,
      although the exercise of writing this and discussions with others
      have gradually convinced me that the first one is much cleaner.
      Those involved in discussions about "non-ASCII in the headers"
      within the RFC-XXXX context should try to understand the first
      option, because it has profound implications for message format
      protocols built in the RFC822 style.  On the other hand, the
      second alternative implies a moderately nasty message
(Continue reading)

Permalink | Reply | 1 comment |
headers
KLENSIN | 3 Oct 1991 01:12
Picon

Revised RFC-ZZZZ part 3 of 6


4. The EMAL FROM and related verbs

The SMTP protocol, as specified in RFC821, is extended to permit the
use of a new set of verbs, that replace the "handling" components of
what we shall refer to as the "FROM" verbs. The relationship is
specified by the table

      MAIL  ->    EMAL
      SEND  ->    ESND
      SOML  ->    ESOM
      SAML  ->    ESAM

If these new verbs are to be taken as acronyms, "E" should be read as
"enhanced", not as "eight".

As now specified in RFC821, DATA is treated as introducing a stream of
ASCII (and therefore 7-bit) characters, divided into lines that are
delimited by the ASCII control characters CR followed by LF, with
potential restrictions on line lengths, and terminated with the
sequence "CR LF . CR LF".

If enhanced transport is desired, the appropriate FROM verb is replaced
by the enhanced form (MAIL FROM by EMAL FROM, etc.). If the receiver
does not recognize that verb (which will be the case with all SMTP
servers that conform to RFC821 alone) or will not accept enhanced mail
features, it gives a fatal negative reply.  Such a reply would indicate
that the sender MUST NOT send octets with the high bit turned on and
that it SHOULD NOT send a TYPE verb (which will presumably be
rejected).  Otherwise the receiver sends an "ok" (250) reply (see
(Continue reading)

Permalink | Reply | 0 comments |
headers
KLENSIN | 3 Oct 1991 01:12
Picon

Revised RFC-ZZZZ part 4 of 6


5.4 Provisions for adding additional TYPE forms.

Additional RFCs may be written to specify additional TYPE forms which
should then be registered with the Internet Assigned Number Authority
(IANA).  To provide adequate definition, they should cover the same
issues covered in section 5.2 above.  Specifically, they must specify
the transport width (or widths) associated with the character set,
provide a complete definition of that character set either internally
or by reference, and specify the one to one and reversible mapping from
those characters (or a 128 character subset of them) onto the 128 ASCII
characters.  They should also provide information or suggestions about
permitted and optimal conversions for use in seven-bit transport
environments or should explicitly prohibit such conversions when they
cannot be made meaningfully.

<>    Discussion:  Some mechanism should be in place to assure that
      these things are not used until they are properly documented.
      The text above is not adequate for that purpose unless we put a
      lot of decisions-making authority onto the RFC editor (a not
      unreasonable choice).  These things could be put through the full
      ritual of IETF standardization, but that is probably excessive in
      terms of both form and duration.  Other possibilities involve
      breaking new ground: writing rules about what IANA needs before
      it will register something or creating a new procedure for
      fast-tracking this type of thing through the standards process.

<>    Discussion: I don't intend to imply that there should or will be
      any cases of "conversion prohibited always".  But it seems useful
      to be clear that it is a possibility.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Einar Stefferud | 5 Oct 1991 18:48

Your Authorship Question Re: Revised RFC-ZZZZ part 5 of 6

Hello John -- Regarding authorship credits, I am only interested in
resolving the questions, and though it is nice to be credited for my
contributions, I am happy to merely be noticed as among the group that
helped to shapre the end results.  Or not as the case may be.

In short, it is my view that the best progress is that with which I
have nothing to do.  I am happy for you to be the sole author on the
title page...\Stef
Permalink | Reply | 0 comments |
headers
Bob Smart | 16 Oct 1991 03:39
Picon
Picon

Use of dubious smtp/rfc822 for e-mail submission

Recent discussion on the pp-workers mailing list has focused on
the fact that it is quite common for very dumb mail-writer/UA
software on PCs or workstations to use a sort of pseudo-smtp to
transfer a mail message to the organization's mail hub. Typical
non-standard things that are done in this operation include:

1. From address may be incomplete. E.g. it may just say 

	Mail from:<fred>

and similarly in the header lines. It is expected that the mail
hub will change this to <fred <at> organization.com> or similar.

2. Destination address may be incomplete in a wider variety of ways.
For example local user destination may just have a local part. Also
users expect to be able to use abbreviations which are expanded at
the mail hub not at the PC. E.g. we might have

	Rcpt to:<bill <at> xyz>

which the mail hub will pass on as <bill <at> xyz.com.au> in the envelope
and in the headers.

3. If the PC doesn't know the date/time it just omits the Date header.

Are there other examples of non-standard behaviour?

In this case a part of the UA function is performed in the mail hub
and smtp is being used as an internal channel within a multi-host UA
function.
(Continue reading)

Permalink | Reply | 1 comment |
headers
atkinson | 16 Oct 1991 10:59
Picon
Picon

Re: Use of dubious smtp


% Recent discussion on the pp-workers mailing list has focused on
% the fact that it is quite common for very dumb mail-writer/UA
% software on PCs or workstations to use a sort of pseudo-smtp to
% transfer a mail message to the organization's mail hub. Typical
% non-standard things that are done in this operation include:

(details omitted)

  The use described is clearly non conforming with RFC-821 and the
host requirements RFC and I see no reason that RFC-ZZZZ should step
into this quagmire.  

  The charter of RFC-ZZZZ is for wide transport, not for legalising
broken PC implementations.  If the non conforming behaviour described
by Bob Smart is to be addressed in any RFC (it isn't clear whether it
is desirable to address it at all), it should be done as a separate
effort from RFC-ZZZZ.  There is a lot on the plate here already.

  The broken implementations sound more nearly like material for the
host requirements RFC than anything else.

Regards,

  Ran
  atkinson <at> itd.nrl.navy.mil
Permalink | Reply | 0 comments |
headers
Bob Smart | 16 Oct 1991 12:10
Picon
Picon

The SIZE command, and whether dot-doubling is an encoding.

I agree with the idea of a SIZE command as in John Klensin's latest
rfc-zzzz draft. I would like to disagree about a few details.

The first advantage of a SIZE command (which becomes essential with very
large messages: file transfer, video, even audio) is that the receiving
side can pre-allocate space to receive the message. It can also delay or
deny messages which temporarily or permanently can't be received.

Suppose that the SIZE parameter were in bytes, as it could easily be.
The SIZE command specifies a maximum size: if you were writing the sending 
code how much larger than the actual size would you be prepared to send
in this parameter? If you give a SIZE which is even 1 byte larger than
the actual size then the receiving end may reject the message unnecessarily. 
I know that if I were writing the sending code I would send the exact 
size, not a larger number, so that no messages from my site would be 
unnecessarily rejected.

A minimum size would also be useful to the receiving end. The receiving
end could then read that minimum amount very efficiently without having
to search for "CR LF . CR LF". In fact the receiving end could on many
systems map the preallocated space for the message into virtual memory
and read the specified minimum into the file in a single "read" call.

We could allow the SIZE to have 2 parameters: a maximum and a minimum.
However I think this would be a waste as most implementors would choose to
send both numbers as the same and equal to the exact size of the message.

I think the SIZE command should specify the exact size of the message.
This gives both advantages and some others: in particular it is a major 
step on the road to providing binary transport. It is true that sending
(Continue reading)

Permalink | Reply | 2 comments |

Gmane