Auteur: Jonathan Hunter Datum: Aan: exim-users Onderwerp: [Exim] Latent transport filter bug still in Exim 3.16?
Hi,
As mentioned previously on this list, transport filters had a bug in
versions 3.033 to 3.14 that prevented them operating correctly. I am now
using version 3.16, and am still having an unusualproblem with transport
filters.
I have a transport filter that looks like this:
#!/bin/sh
cat
echo "Hello"
It is meant to append the text "Hello" to a message (in production use the
echo command is replaced with 'cat /path/to/file'). That works great, as can
be seen in the sanitised output below:
However, replacing the echo command with the following (the -n flag tells
the echo command not to print a trailing newline character):
echo -n "Hello"
does not work as expected. In fact, I seem to be hitting the same bug as in
the ChangeLog for 3.14 (item #3) , where NULL characters in the data stream
would prevent the message being delivered. Exim connects to the remote mail
server, sends its data, and then stops. The remote server times out waiting
for the end of the data:
2000-08-09 12:29:14 13MU2p-0000Rl-00 <= test@??? H=fdev.domain.
[xxx.xxx.xx.xx] P=smtp S=315
2000-08-09 12:39:14 13MU2p-0000Rl-00 == test@???
T=emailfooters_filter defer (60): Operation timed out: SMTP timeout while
connected to smarthost.domain.com [yyy.yyy.yy.yy] after end of data (333
bytes written)
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.
I'd rather not have to extend my shell script to detect the presence or
absence of newline characters in the message - I would have thought that
Exim would append any newline characters if necessary. Presumably most mails
handled by Exim do have a trailing newline already, as if they are arriving
via SMTP then by definition there will be a trailing newline. However
messages generated by the above transport filter may not. I don't know if
these messages are RFC compliant or not, and therefore I don't know if Exim
should be changed or my simple transport filter. The workaround I'm now
using is to ensure that any data appended to messages does have a newline
character, but this is not ideal as there is still room for user error in
this.
