Mailing List Archive

Hello Robert,

> Now, I am a bit uncertain about what would be the best practice for a
> milter to place its headers.
>
> I've patched spamass milter to let any previously added "X-Spam"
> headers untouched, and just add its own headers on top of the header
> list as required by spamassassin's results, thus leaving it up to the
> downstream software to choose which "X-Spam" headers to use for furter
> processing. This is okay for me.
>
> In its original code, spamass-milter adds its own headers to the bottom
> of the header list, or updates existing "X-Spam" headers in place if
> their names match those spamass-milter uses.
>
> What do you think?

I can’t speak for spamass-milter, but in an alternative milter that I
created¹, I tried to emulate what the ‘spamassassin’ executable does:
Delete all incoming X-Spam- headers, and insert the newly added headers
at the top.

Ciao,
David


¹ https://crates.io/crates/spamassassin-milter

> I've patched spamass milter to let any previously added "X-Spam"
> headers untouched

Its generally considered bad practice to pass thru X-Spam headers from an
unkonwn source.
Like most anything else in an email header, a spammer could inject his own
headers, probably populated with items designed to generate a negative
score.

Am Sonntag, dem 09.07.2023 um 19:23 +0200 schrieb David Bürgin:
> Hello Robert,
>
> > Now, I am a bit uncertain about what would be the best practice for
> > a
> > milter to place its headers.
> >
> > I've patched spamass milter to let any previously added "X-Spam"
> > headers untouched, and just add its own headers on top of the
> > header
> > list as required by spamassassin's results, thus leaving it up to
> > the
> > downstream software to choose which "X-Spam" headers to use for
> > furter
> > processing. This is okay for me.
> >
> > In its original code, spamass-milter adds its own headers to the
> > bottom
> > of the header list, or updates existing "X-Spam" headers in place
> > if
> > their names match those spamass-milter uses.
> >
> > What do you think?
>
> I can’t speak for spamass-milter, but in an alternative milter that I
> created¹, I tried to emulate what the ‘spamassassin’ executable does:
> Delete all incoming X-Spam- headers, and insert the newly added
> headers
> at the top.
>
> Ciao,
> David
>
Thanks David, never heard of spamassassin-milter before (it's not in
the Debian repos), but I'll give it a try as there seem to be more
issues with spamass-milter.

Robert

> ¹ https://crates.io/crates/spamassassin-milter

--
Robert Senger

Am Sonntag, dem 09.07.2023 um 13:55 -0700 schrieb Loren Wilton:
> > I've patched spamass milter to let any previously added "X-Spam"
> > headers untouched
>
> Its generally considered bad practice to pass thru X-Spam headers
> from an
> unkonwn source.
> Like most anything else in an email header, a spammer could inject
> his own
> headers, probably populated with items designed to generate a
> negative
> score.
>

Sure, but updating headers in place and adding own headers somewhere
else like spamass-milter is doing it is also bad practice in my eyes...

I've seen that other milters (clamav-milter in particular) offer an
option to either keep or remove existing virus scanning headers.

Since I need to patch spamass-milter anyway to resolve a different
issue (calling "sendmail -bv <recipient>" does not work on postfix
systems), it should be easy to add such an option to spamass-milter.

Regards,

Robert

--
Robert Senger

>
> Since I need to patch spamass-milter anyway to resolve a different
> issue (calling "sendmail -bv <recipient>" does not work on postfix
> systems), it should be easy to add such an option to spamass-milter.
>

Hi Robert, are going to work on this milter? :) :) Currently I have the milter seperate from the spamd and if (last time I checked) if spamd changes it's ip, milter is never able to contact it again.

https://www.mail-archive.com/users@spamassassin.apache.org/msg110390.html

>> > I've patched spamass milter to let any previously added "X-Spam"
>> > headers untouched

>Am Sonntag, dem 09.07.2023 um 13:55 -0700 schrieb Loren Wilton:
>> Its generally considered bad practice to pass thru X-Spam headers from an
>> unkonwn source. Like most anything else in an email header, a spammer
>> could inject his own headers, probably populated with items designed to
>> generate a negative score.

On 10.07.23 01:01, Robert Senger wrote:
>Sure, but updating headers in place and adding own headers somewhere
>else like spamass-milter is doing it is also bad practice in my eyes...

I don't see a problem in this particular case.

Nobody but SA or compatible spam filter adds X-Spam: headers.
These headers are to be added by your local MTA when delivering mail and not
distributed over the net, although it happens.
They also should not be used for DKIM signatures.

Trusting them generally when received from external source is silly, just
like trusting "this mail does not contain viruses" headers.

For those few sources I trust their x-spam* headers, I exclude sending MTA
addresses.

>Since I need to patch spamass-milter anyway to resolve a different
>issue (calling "sendmail -bv <recipient>" does not work on postfix
>systems)

you can use -S option to override path to sendmail and call your own script
instead of patching spamass-milter


--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
42.7 percent of all statistics are made up on the spot.

Marc skrev den 2023-07-10 09:07:

> https://www.mail-archive.com/users@spamassassin.apache.org/msg110390.html

lost in transaction with points of why is spamc needed when spamd
provide a port 783 native socket ports just like when clamd provide 3310
on tcp, my point is valid

as with clamav i would prefer internal milter from spamassassin over
spamc/spamd combo

i am now just back to amavisd-new with pr user awl/bayes/userprefs all
in postgresql with roundcube sauserprefs it works pr user nicely

tip: in amavisd sql make policy in sql match mailbox in dovecot, and all
virtual alias in postfix match new amavis users to use same policy if
its same mailbox, this is solving pr user data in spamassassin if not
wanted to be global !

in the policy sql table sa_username should match mailbox login, then
spamassassin knows what user it is to use on all data in sql

old goal with amavisd is scan once, process multiple recipients, i just
don't know yet if it works or not, good results from penpal's support in
amavisd when sql is in use, could this be moved to spamassassin ?

>
> I don't see a problem in this particular case.
>
> Nobody but SA or compatible spam filter adds X-Spam: headers.
> These headers are to be added by your local MTA when delivering mail
> and not
> distributed over the net, although it happens.
> They also should not be used for DKIM signatures.
>
> Trusting them generally when received from external source is silly,
> just
> like trusting "this mail does not contain viruses" headers.
>
> For those few sources I trust their x-spam* headers, I exclude
> sending MTA
> addresses.
>
> > Since I need to patch spamass-milter anyway to resolve a different
> > issue (calling "sendmail -bv <recipient>" does not work on postfix
> > systems)
>
> you can use -S option to override path to sendmail and call your own
> script
> instead of patching spamass-milter
>
>

Agreed, it's not a problem from the technical point of view, as it's
not a problem to use the -S option to call something else which is not
sendmail (that's what I am doing right now).

It's more a matter of, well, cosmetics or aesthetics...

Regards,

Robert

--
Robert Senger