Re: last call on smtp-8bittransport

[Jim Knowles <jknowles@xxxxxxxxxxxxxxxxxx>]

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.  In addition,
SIZE is given in kilobytes.  It's hard (for me) to imagine a case where
the addition of headers will make a meaningful difference.  The case of
a small message with an encyclopedia of headers doesn't really apply until
their total exceeds 64K.  The client should have a pretty good idea of a
reasonable upper bound on the message (including headers it adds).  The
server should treat the estimate as correct.

>  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?

> To implement SIZE and EHLO as specified:  Enormously costly.  The cost
> is not a $$ cost.  It is the cost of creating and releasing software
> of which I am personally ashamed.  It is an offense to my standards of
> quality and integrity.

Since your client never needs to use SIZE, I guess your objection is to
the server's response to SIZE.  I think it's very clear that the server
should base its response on a comparison of the SIZE arg and its own
upper limit.  Why is this so offensive?

Jim