[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on Standards Track Documents
Greetings SMTP-WG --
I've found what appears to be a wacky mistake in the 8-Bit
spec; also, various feedback from my perspective.
I've been following the recent discussions about SMTP
extensions; and I hope I'm not completely out of the picture
with my comments. If I am, feel free to ignore them. Also, if
these questions have been raised and resolved to more-active
people's satisfactions, then fine. I do understand that this
is very much an 11th-hour set of comments.
Thanks for doing such hard work for mail implementors
everywhere. Standards are a hard business.
Cheers,
J.
--------------------
Jonathan Laventhol
Systems Administrator
D. E. Shaw & Co.
120 West 45th Street
New York, NY 10036
(212) 478-0214
<jcl@deshaw.com>
---------------------
DOCUMENTS
I'm referring to these three documents, as shipped by Ned Freed
Date: 15 Nov 1992 05:45:22 -0700 (PDT):
SMTP Service Extensions (Sat Nov 14 16:56:04 1992)
SMTP Service Extension for 8bit-cleanliness (Sun Nov 15 04:02:01 1992)
SMTP Service Extension for Message Size Declaration (14 November 1992)
MISTAKE IN SPECIFICATION:
>From 8-Bit Cleanliness Draft (Sun Nov 15 04:02:01 1992),
Section 4:
(4) one optional parameter using the keyword BODY is added to
the MAIL FROM command. The value associated with this
parameter is a decimal number indicating the size of the
message that is to be transmitted. The syntax of the
value is as follows, using the ABNF notation of [2]:
body-value ::= "USASCII" / "OCTET"
This is surely a mistake! Shouldn't it say something like:
... The value associated with this parameter indicates the type
of the following message content. The syntax of the value is
as follows, using the ABNF notation of [2]:
body-value ::= "USASCII" / "OCTET"
MY PERSPECTIVE:
I lived for 25 years in England and write in French and I am
therefore VERY KEEN INDEED for ANY workable 8-bit extension. I
would use it for ISO-8859-1 and probably nothing else. I have
implemented several SMTP systems, none for Internet hosts;
though I strictly adhered to the RFCs, so that mail would
behave according to reasonable, documented, expectations. I
did, however, make them 8-bit clean, as the systems were to be
used by non-computer people, who have an absolute requirement
(in England) of writing the pound-sterling sign.
GENERAL:
Examples: It would really help if some more examples were added
to the 8-bit cleanliness and Size Extension documents. Also,
the Service Extension Document could do with an example for the
MAIL FROM and RCPT TO extensions.
JUST CHECKING I UNDERSTAND IT:
As I understood this, it goes:
S: mail from:<bill@whitehouse.gov> body=octet
R: 250 <bill@whitehouse.gov> is okay
S: rcpt to:<george@doghouse.gov>
R: <george@doghouse.gov> is okay
S: data
R: 354 Send data, end with dot
anything with less than 1000 octets between crlfs
.
S: 250
OPTIONS:
I would like to see a couple of paragraphs defining what parts
of a given extension are required for an implementation to
claim adherence. This is particularly an issue in the 8-bit
conversion issue, where implementors conceivably might not
implement the CONVERT or MIME options which they didn't like.
I know that's what I'd do if Keeping It Simple was a high goal
in a project -- that is, almost every time.
8-BIT CONVERSION:
My preference? I'm not fond of the CONVERT option. And though
I am fond of the MIME format, I would rather keep SMTP and MIME
as separate as possible, and specifically keep SMTP as *S*imple
as possible. I am concerned that the CONVERT and MIME schemes
would place a high burder on implementors trying to make simple
mail software (that included 8-bit characters); if this happens
too much, then there won't be enough SMTPs with CONVERT or MIME
to make it worthwhile. Also: if a gateway converts, it gets to
the recipient 'mangled' beyond the control of the sender-human,
who might NEVER FIND OUT that this is happening. For myself, I
would prefer not to send 8-bit mail to people unless I knew it
would get there alright. Finally, this conversion will require
more sophistication on the recipients mail reader if it is to
do the right thing. I'd rather any transformations are done
EARLY rather than LATE -- so the sender SMTP might resend with
its conversion, rather than the receiver SMTP doing it when it
forwards.
I don't think there's a place for conversion in this transport
protocol.
I'll stop now. I'm sure you've all discussed this at much
length.
WHERE THE OPTIONAL PARAMETER SHOULD GO
>From the description in Section 5:
If the path to the next hop (or a recipient's user agent) is
not known to preserve all bits in each octet, then the
behavior of the server SMTP depends on the parameter
associated with the EHLO keyword value 8BIT.
It would seem to be better to put the optional parameter-value
pair on the RCPT TO command. That way you could flag an
error. Because you have to give MAIL-FROM before you know
who's getting it, you can't signal an error straight away, thus
complicating it.
CASE-INSENSITIVITY
I'm sure the optional parameters and body values are intended
to insensitive to case, but I couldn't find it.
mAil fRom:<bertie@somewhere.dom> BodY=oCtEt
1000-CHARACTER LINES
We should clarify the 1000-character line limit, perhaps by
incorporating text from RFC-821.
The number 1000 appears twice in the 8-Bit document, without
much clarification. In Section 5:
Finally, although the content body contains arbitrary octet-
aligned material, the length of each line (number of octets
between two CR-LF pairs), must not exceed 1000 characters, as
specified in [1].
But [1] (RFC-821) says:
text line
The maximum total length of a text line including the
<CRLF> is 1000 characters (but not counting the leading
dot duplicated for transparency).
It also says,
****************************************************
* *
* TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION *
* TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH *
* OF THESE OBJECTS SHOULD BE USED. *
* *
****************************************************
I think we should repeat this (in some form) in the ESMTP
documents.
SIZE EXTENSION
--------------
FORMATTING:
The Security Considerations section doesn't have a section
header or number. Some funny pagebreaks. Section 7 is in the
wrong place.
DEFINITIONS:
> Section 6:
> The message size is defined as the number of octets, including CR-LF
> pairs, up to, but not including, the final dot, to be transmitted by the
> SMTP client after receiving reply code 354 to the DATA command.
It would be good if this was explicit about byte-stuffing
dots. It should probably not include the dots (see stuff about
about the 1000-character limit).
SEMANTICS:
Section 6.1 (2):
> A server is permitted, but not required, to accept a message which is,
> in fact, larger than declared in the extended MAIL command, such as
> might occur if the client employed a size-estimation heuristic which was
> inaccurate.
It would be good to clarify this. I read it as meaning that
the receiver can punish the sender for 'lying'. I'm imagining
that the sender bids for 12340 octets; the receiver mallocs
12340 octets (plus whatever amount of extra margin the receiver
thinks is a good idea). The sender then sends too many octets
and the receiver blows it off with "452 insufficient system
storage". The clarification is required becase it isn't the
case that there was enough storage -- it was that the sender
didn't ask for it. (Of course, the receiver SHOULD realloc and
then we've won.) In the final analysis, the receiver can
refuse the message if it likes, surely, but it would be good to
specify here. My choice?
"Even if the sender SMTP sends a message larger than its
declared size, the receiver SMTP SHOULD accept it if it
possibly can. It should not refuse the message merely because
it is larger than the declared size."
(end)