Re: [exim] spool format error (on some list messages)

Top Page

Reply to this message
Author: exim-users
To: exim-users
Subject: Re: [exim] spool format error (on some list messages)
Hello Heiko,

thanks for your fast analysis.

On 31.05.2018 17:38, Heiko Schlittermann via Exim-users wrote:
> I'm not sure how the sa_exim processing works, I do not use it for long
> time now. Does it see the original spooled message and modifies it?
> After this step, Exim does its own processessing, splitting the message
> into -H and -D?

Yes, original message is analyzed via spamd and altered (headers added)
before further exim processing. Depeding on spamassassin score messages
are temporarily rejected (greylisting).

> I'd see sa_exim as the suspicious. Maybe bad cooperation between sa_exim
> and Exim when we use wire format spool files (do we?) or when the
> message arrives in chunks. I think, we had some other issues in this
> context.

Wire format spool files is currently not enabled.

> For verification, can you add to some ACL the
>     warn    senders = linux-kernel@XXX
>             control = no_mbox_unspool

> directive? This way the message should stay in the $spooldir/scan
> folder, even after scanning. (I'm not sure if this is the way sa_exim
> works, it is just guesswork and it could help to identify the issue.)

Added it, did not disable sa-exim yet to get some more examples for the
issue. Saved messages do not have the X-SA-Exim headers.

>> 1fOL7J-0001BL-DC-H
> …
>> 031 X-Spam-Relay-Country: US US **
>> 090 Subject: [tip:perf/urgent] perf tools: Fix format description of
>> NRCPUS header
>> 065 X-SA-Exim-Version: 4.2.1 (built Tue, 02 Aug 2016 21:08:31 +0000)
>> 066 X-SA-Exim-Scanned: Yes (on s-Mich Richter <tmricht@???>
> [ HERE THE BLANK LINE WAS EATEN, so Exim doesn't recognize
> this as the end of the header section of the message.
>> 042 Acked-by: Andi Kleen <ak@???>
>> 044 Cc: Adrian Hunter <adrian.hunter@???>
>> 036 Cc: David Ahern <dsahern@???>
>> 034 Cc: He Kuang <hekuang@???>
>> 053 Cc: Hendrik Brueckner <brueckner@???>
>> 038 Cc: Jin Yao <yao.jin@???>
> …

You are right, the X-SA-Exim-Scanned header is truncated (after "on", I
missed that before) it is set by sa-exim (code snipplet from sa-exim.c
with line numbers):

  31 /* Exim includes */
  32 #include "local_scan.h"
  33 extern FILE   *smtp_out;               /* Exim's incoming SMTP
output file */
  34 extern int     body_linecount;         /* Line count in body */
  35 extern uschar *primary_hostname;
1277     header_add(' ', "X-SA-Exim-Scanned: Yes (on %s)\n",

All correct messages have a header:
X-SA-Exim-Scanned: Yes (on primary-hostname)

All corrupted messages at least lack "primary-hostname" and the newline,
some have other parts of the message in there. Any simple way to use a
saved message to produce some more debugging information?

However, as sa-exim is kind of unmaintained (it served my needs very
well for >10 years now, though). What would be a similar alternative to
achieve the sa-exim functionality (on the fly spamassassin scanning and
greylisting depending on spamassassin scores)? Spamassassin integration
via exiscan and greylisting as described in or greylistd? Any
best practice on this topic? What I liked on sa-exim is, that there is
no initial greylisting for unknown senders/hosts when they send mails
with reasonable low spamassasin scores.

Best regards,