"Gjermund S\xF8rseth" <gjermund(_at_)nextel(_dot_)no> writes:
Philip Guenther <guenther(_at_)gac(_dot_)edu>:
>But procmail should really be able to do this by itself!
Why add quite a bit of complexity to procmail when there's already an
efficient way to do it?
Efficient maybe, but it's still a hack. The question is whose job it is
to localy deliver the message correctly, and that's not sendmail. :)
Agreed, it's not the job of sendmail alone, but the job of sendmail and
procmail together. After that, the message has been delivered and
anything you do with it is reprocessing. This may sound picky, but I
think the distinction is useful here.
(I don't see why this would be such a complex addition to procmail).
The problem is that you don't know how big the header is going to be
until you've read in the entire message, at which point you have to
shift the entire (possibly multi-megabyte) body down just to insert
some dozen-plus bytes (and no, shifting the header backwards is only
worse). You could preallocate a spot right after the "From " pseudo-
header and before any other real header line, but then what if there's
already a Content-Length: header in the message? Procmail reads in the
message in large chunks, so once again you're stuck with copying around
the body. The whole message reading part of procmail is one of the
more complicated parts of it (in my opinion) changing the design to the
amount required would make it even more complex and take quite a while
to debug.
Sendmail, on the other hand, already has to break up the header into
individual lines, so adding the Content-Length: header would be at zero
cost programatically and at effectively zero cost at runtime.
Furthermore, if you've set a maximum message size in your sendmail.cf,
then you can even set the correct size for the field value, something
you can't do with a value compiled into procmail.
Philip Guenther