On Tue, 27 Jul 2021, David Bürgin wrote:
Dipl-Inform. Frank Gadegast:
On 27.07.21 14:18, David Bürgin wrote:
Dipl-Inform. Frank Gadegast:
Seems to be, that spamass-milter simply strippes out any X-Spam* header
lines, not caring, if the own call to spamd sets them, hm.
Im really not getting, why spamass-milter should strip X-Spam-lines of
the header AFTER SA was running. If Im right, SA is stripping them of
anyway, before running or modifying anything ...
Anybody an idea how to get arround this ?
There is an alternative milter (which I maintain) that adds
all X-Spam-* headers received from spamd.
https://crates.io/crates/spamassassin-milter
Looks like your milter needs to fork a spamc, wich then talks to the spamd.
This will start lots of spamc processes and is not recommened.
Would then not be any different to call spamc dirctly f.e. via procmail.
You should rewrite your milter to talk directly to the spamd via socket or
port.
Yes, it communicates using spamc, just like spamass-milter.
I have been told that it has been working fine in a somewhat larger
deployment. I didn’t mean to derail the thread so will leave it at that.
having a spam filtering milter fork off a shell and then run "spamc" to
communicate with spamd does simplify the milter code (and insulates it from
changes in the spamd protocol) but adds risk of shell escape attacks (as well as
additional overhead).
There's already been security related patches needed by spamass-milter
specifically because of this issue.
Writing a milter that directly talks the spamd protocol via a socket (local or
network) is more work but safer and more efficient.
(been there, done that, got the code to prove it).
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
