The question would be, does the _input_ to a filter always correctly
have a terminating newline - if it does, and a filter is not keeping
it, then the filter program is at fault.. If it doesnt, and the filter
is passing it though without adding one, then maybe Exim is at fault
(Although I don't think it would be improper if the filter added a
newline at the end anyway)
A good test would be to see if a filter of just:
| #!/bin/sh
| cat
|
worked properly under all circumstances. If it does, then Exim is
working correctly.
On Thu, 10 Aug 2000, Philip Hazel wrote:
> On Wed, 9 Aug 2000, Jonathan Hunter wrote:
>
> > I suspect that Exim isn't checking for a newline on the end of the message
> > produced by the transport filter, and is simply sending a single period to
> > terminate the data stream, which therefore fails if the message does not end
> > in a newline character.
>
> Absolutely right. The documentation says:
>
> The filter's standard output is read and written to the message's
> destination. The filter can perform any transformations it likes, but of
> course should take care not to break RFC 822 syntax.
>
> The assumption is that what the filter outputs is a valid message,
> including the terminating newline. Exim makes no check on what it gets
> back; it is up to you to get it right.
>
>
--
