Hi Philip,
> What happened was that I was persuaded to extend Exim to use the SIZE=
> option for outgoing mail. The problem is that it doesn't actually know
Sorry, Philip, but I'm sure this is no mistake.
SIZE is broadly understood and really helps to save bandwith and
inform users with intelligent clients early about any limits
(if given on your site).
> the number of bytes that it will send down the line, because (a)
> some things can get added, and (b) more importantly, each LF in the file
> gets turned into CRLF and it doesn't know how many lines there are in
> the file. So, to be on the safe side, it adds 16K to what it sends in
> SIZE to allow a margin for these things.
As I wrote in the PIPELINING-mail, this decision makes it pretty
difficult to implement new features.
At least on our site relaying is much more important than local
mail.
What about the following suggestions?:
- Including the headers at queueing time rather than at delivery
time (they should not change in the meantime). A single file
that might be "dumped" down a channel would clean up the
delivery code a bit.
- Saving messages
- in CRLF-notation.
or
- keeping the numbers of lines in the message so the real
size might be calculated.
Moreover, if Exim announces a few bytes less than the actual message
size, the server might get some extra traffic, but the behaviour
is still better than the old one.
If you take a look at the new RFCs like CHUNKING, CHECKPOINT,
BINARYMIME etc. you'll see many problems with the current design
concept.
> I knew it, I knew it. I should have stuck to the old simple non-ESMTP
> protocol.
They really include nice features, and I think Exim should follow
the ESMTP-developement line.
Greetings,
Georg
--
*** Exim information can be found at
http://www.exim.org/ ***
