Re: last call on smtp-8bittransport

[Neil W Rickert <rickert@xxxxxxxxxx>]

>Hi Neil,
>
>(Per repeated requests, I'm moving this to the smtp list.)
>
>>   SIZE provides worthless information.  It specifies the message size.
>> But it is defined to specify it as an approximation.  What is an
>> approximation?  Is a 1000% error permitted?  I did suggest earlier, but
>> to no avail, that the data to SIZE include either
>> 
>> 	estimated size		error bound
>> or
>> 	lower size bound	upper size bound
>
>SIZE is an upper bound, so it equals estimated size + error.

But the error is not adequately defined.  If it is not defined, an
implementation is forced to either:

	(a) treat SIZE as a NOP, accept the full message, and take
	    size based action only when the true size is known.
or
	(b) use guesswork, and sometimes refuse mail which might actually
	    be within range.

Since I assume the purpose of email is to get the message through, rather
than to play protocol games, I find option (b) as unacceptable.  Thus
my standards of software quality would force me to use option (a).  This
means that the LIMIT value in EHLO would have to be given as effectively
0 INFINITY, and the listing of SIZE in the command verb listing of EHLO
would be completely bogus but required by the proposed standard.  It
offends my quality standards to be required to give such bogus responses.

>>  The problem is that SIZE and EHLO (in the way implemented) are not
>> needed for 8bit, but they change RFC in a way that is ugly, needlessly
>> complex, and because of their poor design will seriously hinder future
>> enhancements.
>
>Could you please expand on how future enhancements are hindered?

Because the obvious way to implement SIZE is, as I indicated above, to
treat it as a NO-OP.  Once you realize this forces your EHLO response
to contain a bogus SIZE verb, the obvious implementation of EHLO is to
just dump the internal verb table into the output stream, without worrying
whether the support for some of the verbs is half-baked.  Indeed the
proposal can be read as requiring this type of implementation of EHLO.
I can almost guarantee that there will be implementations of this kind,
that they will be amongst the first available, and that they will be
widely adopted because of their early availability.

Now, a few years down the road, suppose somebody tries to do something
useful with EHLO.  Then they discover that there are hundreds of thousands
of hosts with just such an implementation, so that the EHLO response is
partially bogus.  No amount of screaming.  It will be back to the drawing
board, to create something that works properly.  In the meantime new
software will still have to honor EHLO for backwards compatibility.

You would be much better off with just EMAL, and dropping EHLO and SIZE.
This is enough to handle 8bit mail, so meets the immediate needs.  Leave
EHLO and SIZE till the future when a more forward looking design can be
found.

 -NWR