Hello,
perhaps try setting
report_safe 0
Then, according to the documentation at ‘man Mail::SpamAssassin::Conf’,
a header ‘X-Spam-Report’ will be added that might just be what you need.
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 res
Matus UHLAR - fantomas:
> > Matus UHLAR - fantomas:
> > > that will need spamass-milter change.
>
> On 31.05.23 13:52, David Bürgin wrote:
> > Have you tried setting:
> >
> > authres_trusted_authserv fantomas.fantomas.sk
>
> I did. that's why
Matus UHLAR - fantomas:
> that will need spamass-milter change.
Have you tried setting:
authres_trusted_authserv fantomas.fantomas.sk
I think this should work without changing anything in the milter …
Matus UHLAR - fantomas:
> I happily use spamass-milter to filter spam at SMTP time.
> Prior to spamass-milter, I use pyspf-milter/opendkim/opendmarc milters to
> mark if mail passes coresponding checks.
>
> I also use authres plugin to use these results. However, it does not work
> when receivin
Marc:
>
>
> I recently had an issue where mail was temporarily rejected because
> clamav-milter/spamass-milter could not connect to clamd/spamd. Clamd/Spamd
> are a tasks that can automatically change hosts and thus their ips. A simple
> restart of the milter fixes this (resolves the new ip).
Bill Cole:
> If your mailstore uses mbox or Maildir, the unmaintained antique software
> named "procmail" could be used for delivery. As an antique myself, I use it,
> but I cannot in good conscience recommend anyone else adopt it de novo.
It looks like procmail is maintained again, by the origina
I have heard it said many times on this list that auto-learning is
discouraged, so I decided to finally look into disabling it.
But then I realised that I do have a use for auto-learning: In my setup,
I use a milter to reject certain spam (score > 10.0). Now, if I turn off
auto-learning I lose som
Brent Clark:
> Something to see and keep an eye on (Read: Why build this tool)
>
> https://www.kitploit.com/2022/01/espoofer-email-spoofing-testing-tool.html
This is old news. The espoofer tool and research were presented I think
in 2020 and were widely discussed then. And bug fixes for, say, Ope
Martin Gregorie:
> On Sun, 2022-08-14 at 11:39 +1000, Noel Butler wrote:
> > On 14/08/2022 02:38, Martin Gregorie wrote:
> >
> > > 3) It would be rather trivial to return spam to sender with a
> > > suitable
> >
> > WTF, that has been a terrible idea since the 90s, given most spam is
> > spoofed
sebast...@debianfan.de:
> there is a line in the mail-header - for example:
>
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.server.org
>
> Can i set the "name" manually - for example
>
> X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
> manual.set.server.name
DL Neil:
> SpamAssassin x86_64 3.4.0 CentOS 6.el7 release
> Postfix 2.10.1
> unbound 1.6.6
This does not answer your question, but I noticed that the versions you
gave are all ~5–8 years old. Often enough such problems disappear after
upgrading to a current version.
se can't guarantee that.
> > >
> > > This also means that SPF can't be used, thus either those messages have
> > > DKIM
> > > signatures, or they CAN NOT pass DMARC.
>
> On 22.04.22 16:22, David Bürgin wrote:
> > In SPF, when the reverse-pa
Matus UHLAR - fantomas:
> > > and spf is unapplicable since the envelope from is null.
> >
> > Isn't that the case with all bounce messages?
>
> usually yes, it should be. But we of course can't guarantee that.
>
> This also means that SPF can't be used, thus either those messages have DKIM
> si
Don Saklad:
> What does this header mean?...
> X-Spam_score_int: -38
Doesn’t look like anything from SpamAssassin.
Marc:
> I have problems configuring the spamass-milter to connect to the remote
> spamd. I am constantly getting
>
> getaddrinfo(192.168.10.243:34219) failed: Name or service not known
> could not resolve any hosts (192.168.10.243:34219): no such host
>
> Nothing of these seem to work
> -D 192.1
Benny Pedersen:
> : host
> mx1-he-de.apache.org[2a01:4f8:c2c:2bf7::1] said: 550 5.7.23
> : Recipient address rejected: ASF gnomes
> rejected your message: SPF fail - not authorized. See
> https://infra.apache.org/mail-rejection.html (in reply to RCPT TO
> command)
>
>
> is it solv
Look into ‘normalize_charset 1’. For background maybe this:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7656
Cyrille Bollu:
> spamass+ 673 1 0 13:06 ? 00:00:00 /usr/sbin/spamass-milter -P
> /var/run/spamass/spamass.pid -f -p /var/spool/postfix/spamass/spamass.sock -u
> spamass-milter -d func,misc,net,poll,rcpt,spamc,str,uori -i 127.0.0.1 -- -s
> 10485760 -r 10
-r 10 is in the wrong place
> What should happen technically is that Postfix connects to the milter,
> the milter uses spamc to communicate with SpamAssassin/spamd, and
> finally the milter will add the new headers it receives from
> SpamAssassin.
To expand a little bit on this, the crucial thing is that all components
can c
And does Postfix connect via the milter and spamc, or does it call
spamassassin directly? For example, I have this in /etc/postfix/main.cf:
smtpd_milters =
...
unix:spamassassin/spamassassin-milter.sock
Another thing to try is enable more logging in spamass-milter to see
what it’s doing.
Wha
First we would need to see the spamd config,
SpamAssassin config, spamass-milter config
to see how it is all wired up.
One thing that needs clarification is how you want to integrate spam
filtering with SpamAssassin with Postfix:
Apparently, you are trying to do this with two different methods at
once? Once with spamass-milter, which is a milter that uses spamc to
integrate SpamAssassin with Postfix. And once with
Hello Jeff,
> spamassassin got a user named 'spamd' and is run under it.
Are you sure? Note the user and group:
$ ls -ald /var/lib/spamassassin
drwxr-xr-x 6 debian-spamd debian-spamd 81 Apr 3 06:15 /var/lib/spamassassin
Ciao,
David
In your experience, what is a good ‘certain spam’ threshold? By that I
mean the score above which messages are virtually always spam, no false
positives.
The default threshold for spam is 5.0, which works well for me. Only
very rarely a ham message scores above that and lands in my Junk folder.
Wo
David Bürgin:
I should have just tried before asking! Thank you. This works:
add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on
mail.mydomain.ch
And voilà:
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.mydomain.ch
A final remark: This solution has a
David Bürgin:
Resolved. Perhaps the documentation should be updated.
There are notes for options ‘remove_header’ and ‘clear_headers’ that
‘X-Spam-Checker-Version is not removable’, so a straightforward fix to
the documentation would be replacing sentence
note that Checker-Version can not be
Antony Stone:
> On Friday 30 July 2021 at 21:13:43, David Bürgin wrote:
>
> > Is there a way to customise the hostname shown in the line:
> >
> > X-Spam-Checker-Version:
>
> No.
>
> https://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Conf.h
Is there a way to customise the hostname shown in the line:
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
somehost.someprovider.com
So that it reads:
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.mydomain.ch
I understand that I could change the hostname of the ho
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
Matus UHLAR - fantomas:
On 27.07.21 14:18, David Bürgin wrote:
There is an alternative milter (which I maintain) that adds
all X-Spam-* headers received from spamd.
the original milter does the same. Adds headers from spamd.
However, it does NOT take into account ay X-Spam-* headers received
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 t
sults: header(s) added by the former milter appear after
Received: and SA doesn't trust it.
...nobody sees the synthetized Received: header later, they see Received:
added by MTA, before Authentication-Results added by mentioned milter.
On 18.05.21 14:12, David Bürgin wrote:
Thank you, this
David Bürgin:
> David Bürgin:
> > Bother. I think I will try to modify my SpamAssassin milter, so that it
> > will add a synthetic ‘internal’ Received header right after the
> > Authentication-Results headers … that should trick SpamAssassin into
> > recognising them a
Matus UHLAR - fantomas:
this is more an issue of how milter itself operates.
the milter is supposed to see e-mail as it was received from (smtp) client -
even without Received: headers, just with other milters' modifications.
If SpamAssassin (SA from now) has to see Authentication-Results: head
Martin Gregorie:
Have you set the 'internal_networks' configuration parameter (in
local.cf)? If not, try that first.
Thanks, but I don’t think this helps here. I don’t know what I could add
to internal_networks that would somehow change the behaviour. The
problem is with how milters for SpamAss
David Bürgin:
Bother. I think I will try to modify my SpamAssassin milter, so that it
will add a synthetic ‘internal’ Received header right after the
Authentication-Results headers … that should trick SpamAssassin into
recognising them as internal.
Here’s the plan to address this in
David Bürgin:
I remember asking here if SpamAssassin is able to use these instead of
doing its own SPF queries. Now with debug logging on, I see that
SpamAssassin isn’t actually using these results:
...
Is this a bug in the SPF plugin? Do I need to set something in my
config? I’m using
I use a separate SPF component (https://crates.io/crates/spf-milter). It
conveys SPF results for both HELO and MAIL FROM identity, each in its
own Authentication-Results header:
Authentication-Results: mail.gluet.ch; spf=fail
smtp.mailfrom=bounces.amazon.co.jp
Authentication-Results: mail
Hello,
as far as I understand, SpamAssassin can recognise and consume incoming
SPF results in an Authentication-Results or Received-SPF header, so that
it doesn’t have to do its own SPF evaluation.
I’m using SpamAssassin in a milter setup with Postfix, and have an SPF
milter that runs before Spam
Matus UHLAR - fantomas:
> rewrite from scratch?
It is, one of those infamous RIIR (rewrite it in Rust) projects …
> what I miss in spamass-milter is:
> - preserving more X-Spam-* headers
The new milter adds all ‘X-Spam-’ headers received from spamd, if that’s
what you had in mind.
> - defining
@lbutlr:
> On 09 Mar 2020, at 10:43, David Bürgin wrote:
>> I used to be a user of an alternative milter, spamass-milt,
>
> Do you mean spamass-milter or is this another filter for SA I don’t know?
Oh yes, it’s named ‘spamass-milt’ on its homepage
https://savannah.nongnu.org/p
Hello,
I have created a new milter implementation for SpamAssassin, firstly for
my own purposes but perhaps some of you might be interested, too.
https://gitlab.com/glts/spamassassin-milter
SpamAssassin Milter is a milter application that filters email
through SpamAssassin server usi
43 matches
Mail list logo
