* Adam J. Henry
> Here is the error I am receiving:
>
> LOG: MAIN
> <hank@???>: dspam transport output: An error was
> detected while processing a file of BSMTP input.
> LOG: MAIN
> == hank@??? R=dspam T=dspam defer (0): Child
> process of dspam transport returned 2 from command:
> /usr/local/exim/bin/exim
> Here is a copy of the offending message's body (exim -Mvb 1BugsA-0008Le-5A):
>
> U2VyZ2lvIEhvZmZtYW5uLCAyNSB5Lm8uIHBzeWNob3RoZXJhcGlzdCwgR2Vy
[...]
I've experienced the same problem. What's happening is that DSPAM
unpacks the base-64 encoded message, classifies it, adds the DSPAM tag,
and so on, before sending it back to Exim - unpacked. What gets lost
is the terminating newline. That makes the period that's supposed to
finalize the DATA command end up at the end of a line containing other
characters, instead of on a line by itself. Naturally, this makes
the receiving Exim process see EOF before it has seen the period,
which doesn't make any sense from its point of view.
I inteded to make a patch to fix this bug of DSPAM, but forgot all
about it. What a did as a quick hack was to explicitly add a newline
to the end of the message like so:
transport_filter = /bin/sh -c "/usr/bin/dspam [...]; echo"
Not exactly very pretty, but it works. I reported the bug
back to the DSPAM developers some time ago, for all I know it's
been fixed in the latest developement releases.
An easy way to debug such problems is to simply do something like
command = tee /tmp/transport-filter-debug.log
instead. Then you'd see what was going on immediately.
--
Tore Anderson
