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

Góra strony
Delete this message
Reply to this message
Autor: exim-users
Data:  
Dla: exim-users
Temat: 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 perf.data 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):

--cut
  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",
primary_hostname);
--cut


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
https://github.com/Exim/exim/wiki/SimpleGreylisting 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,
Thomas