[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: last call on smtp-8bittransport
(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
> 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
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?