https://bugs.exim.org/show_bug.cgi?id=1863
--- Comment #2 from Martin von Wittich <martin.von.wittich@???> ---
> > The servers use a German locale
> Why not change that just for your SA process?
I tried that, but I couldn't figure out how. There doesn't seem to be an option
for that, and adding "export LC_ALL=C" to /etc/default/spamassassin didn't have
any effect. Even if that would work I'd be afraid that that might have any
unforeseen consequences on the SpamAssassin behaviour.
> You could look into the ${rfc2047:<string>} operator.
That one unfortunately encodes too much:
> X-ACL-Warn: =?UTF-8?Q?X-Spam-Checker-Version=3A_SpamAssassin_3=2E4=2E0_=282014-0?= =?UTF-8?Q?2-07=29_on_iserv=2Edev2=2Eiserv=2Eeu?=
> X-ACL-Warn: =?UTF-8?Q?X-Spam-Flag=3A_YES?=
> X-ACL-Warn: =?UTF-8?Q?X-Spam-Level=3A_******************************************?= =?UTF-8?Q?********?=
> X-ACL-Warn: =?UTF-8?Q?X-Spam-Status=3A_Yes=2C_score=3D999=2E0_required=3D5=2E0_a?= =?UTF-8?Q?utolearn=3Dno_autolearn=5Fforce=3Dno?=
> X-ACL-Warn: =?UTF-8?Q?X-Spam-Report=3A?=
> X-ACL-Warn: =?UTF-8?Q?*_-1=2E0_ALL=5FTRUSTED_Nachricht_wurde_nur_=FCber_vertraue?= =?UTF-8?Q?nsw=FCrdige_Rechner?=
> * weitergeleitet
> X-ACL-Warn: =?UTF-8?Q?*_1000_GTUBE_BODY=3A_Test_zur_Pr=FCfung_von_Anti-Spam-Soft?= =?UTF-8?Q?ware?=
> X-ACL-Warn: =?UTF-8?Q?*_-0=2E0_BAYES=5F20_BODY=3A_Spamwahrscheinlichkeit_nach_Ba?= =?UTF-8?Q?yes-Test=3A_5-20%?=
> X-ACL-Warn: =?UTF-8?Q?*______=5Bscore=3A_0=2E1218=5D?=
> X-ACL-Warn: =?UTF-8?Q?*__0=2E0_TVD=5FSPACE=5FRATIO_No_description_available=2E?=
> I don't agree this is a bug. At most it's an RFE
That's fine with me ;)
> and I'm far from convinced it
> should be addressed by special coding in Exim rather than the config file.
Well, as I said, a documentation change might be enough for this case. I just
think it should be noted somewhere that $spam_report may return 8-bit strings,
and that it isn't necessarily safe just to put it into add_header.
I found a bug in my original expression; apparently ${map} removes leading
spaces (is this documented somewhere?) which broke the wrapped X-Spam-Report
header. This one should work better:
> add_header = ${\
> # sg: readd the leading space to * lines that has been removed by map
> sg\
> {\
> # map: run every line from SpamAssassin through $escape{} to escape
> # 8-bit characters
> # https://bugs.exim.org/show_bug.cgi?id=1863
> ${\
> map\
> # sg: remove leading space from lines beginning wit the X-Spam
> # header names, but not from the wrapped lines beginning with *
> {<\n ${sg{$spam_report}{\n\\s+X-Spam-}{\nX-Spam-}}}\
> {${escape:$item}}\
> }\
> }\
> {\
> \n\\*\
> }\
> {\
> \n \\*\
> }\
> }
A sample header produced by this expression:
> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on iserv.dev2.iserv.eu
> X-Spam-Flag: YES
> X-Spam-Level: **************************************************
> X-Spam-Status: Yes, score=999.0 required=5.0 autolearn=no autolearn_force=no
> X-Spam-Report:
> * -1.0 ALL_TRUSTED Nachricht wurde nur \374ber vertrauensw\374rdige Rechner
> * weitergeleitet
> * 1000 GTUBE BODY: Test zur Pr\374fung von Anti-Spam-Software
> * -0.0 BAYES_20 BODY: Spamwahrscheinlichkeit nach Bayes-Test: 5-20%
> * [score: 0.1218]
> * 0.0 TVD_SPACE_RATIO No description available.
May I suggest a new expansion function that only escapes 8-bit characters and
nothing else (for example ${escape8bit})? That would simplify the above code a
lot because I wouldn't have to use ${map}, and then I also wouldn't have to
work around the issue that ${map} removes the leading white space.
--
You are receiving this mail because:
You are on the CC list for the bug.
