Re: [exim] fatal errors in BSMTP transport

Hi,

Marco Herrn wrote:
> I am running exim 4.50 with virtual domains/users. Some of the users
> get their mails checked for spam by a seperate transport. Since
> yesterday some mails were rejected, because of problems with this
> transport.

"Funny" thing is that today a similar thing happened to me. I expect the
problem popped up for a different reason over here, but the result is
similar: same error (same 421) from the exim -bS process at transport
time, with about the same router and transport you have.

What I faced was a problem with iptables. I think it's a bug in the
connection tracking module or something (I even had this with the
default redhat iptables config). Anyway: because of this the spamc
session stalled in the middle of it. After inserting a rule that accepts
all incoming traffic from my spamd host, everything ran fine - my
problem was solved for now.

I think that somehow spamc does not handle broken TCP sessions very
well, or other rare problems that arise. For instance the timeout option
does not seem to have any affect if running spamc with -d to a
non-responding host (I mean no icmp reset, with an unused IP for
instance). When spamc dies or timeouts the bsmtp output is invalid (I
suppose), and exim -bS does not know how to handle that, and voila:
there is your error. (At least, that's what I think is happening.)

I am wondering if replacing (simplified, left out my -d ip,ip and more
complex -u for spamc):
command = /usr/local/sbin/exim -oMr spam-scanned -bS
transport_filter = /usr/local/bin/spamc -f -s 500000 -u nobody
with for instance:
command = /usr/local/bin/spamc -B -f -t 30 -s 500000 -u nobody -e
/usr/local/sbin/exim -oMr spam-scanned -bS
(and no transport_filter) helps.

This way the exim -bS is called by spamc (that is now bsmtp aware) and
only _after_ the message is processed by spamassassin. No open pipe to
that process, and exim only has to handle the errors and timeouts from
the pipe, and not both pipe and the transport_filter... No chance that
the filter will timeout and provide broken output to the pipe. (Right?)

I tried this, but I could only simulate an 421 by making the exim -bS
impatient by adding "-os 2s". Then this works, but I'm not sure if it
works with my broken TCP sessions, or your broken whatever it is (maybe
a busy/non-responding spamd or something).

If I'm able to reproduce the problem in a controlled enviroment (which
I'm trying) I can tell if this helps or not, but somehow I think it's
already better than using an transport_filter?

Curious what others think,

Paul