Re: Expanded Spam Report
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.
Re: Best practice for adding headers?
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
Re: authres missing when ran from spamass-milter
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 it works then checking later. > > > I think this should work without changing anything in the milter … > > milter adds own synthetised Received: header at the very beginning, which is > mosts possibly the correct reason. > > spamass-milter should add this header behind locally added > Authentication-Results: headers, but it needs change in spamass-milter. I understand, but I still think AuthRes can do this without a change in the milter. Note the doc for authres_trusted_authserv: > Use strongly recommended, possibly along with authres_networks all. So, if you set: authres_networks all authres_trusted_authserv fantomas.fantomas.sk then the relative position of ‘Received’ and ‘Authentication-Results’ headers shouldn’t matter. You just have strip out forged results in an earlier milter. I’ll try it out some other time.
Re: authres missing when ran from spamass-milter
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 …
Re: authres missing when ran from spamass-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 receiving mail. > > I tried debugging both spamass-milter and spamd, and I see that the headers > are indeed there: > > > May 30 17:57:03 fantomas spamd[1101]: authres: no Authentication-Results > headers found from internal > May 30 17:57:03 fantomas spamd[1101]: rules: [...] Authentication-Results: > fantomas.fantomas.sk; dmarc=none (p=none dis=none) header.from=xxx.sk > May 30 17:57:03 fantomas spamd[1101]: rules: [...] > May 30 17:57:03 fantomas spamd[1101]: rules: [...] Authentication-Results: > fantomas.fantomas.sk; arc=none smtp.remote-ip=192.0.2.1 > May 30 17:57:03 fantomas spamd[1101]: rules: [...] > May 30 17:57:03 fantomas spamd[1101]: rules: [...] Authentication-Results: > fantomas.fantomas.sk; spf=pass (sender SPF authorized) smtp.mailfrom=xxx.sk > (client-ip=192.0.2.1; helo=smtp8.xxx.sk; envelope-from=y...@xxx.sk; > receiver=) > > Does anyone have an idea why spamd misses these? > > > when I pipe message to spamd manually, those headers are there and AUTHRES > matches: > > X-Spam-Status: No, score=-0.9 required=5.0 tests=AUTHRES_SPF_PASS,BAYES_00, > DCC_CHECK,DMARC_MISSING,KAM_DMARC_STATUS,KAM_NUMSUBJECT,RDNS_NONE, > SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no > autolearn_force=no version=4.0.0 Did you check if the ‘Authentication-Results’ headers are above the ‘Received’ header generated by the milter? Per your own observation in an older thread: https://lists.apache.org/thread/q1vvoqvfv3fxjhwjzbjztq1y85hyn3mk (To be sure I’m not currently using AuthRes, so don’t know if relevant.)
Re: spamassassin milter auto ip address update
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). > > However, it would be nice if something could be added to the milter code > that, if it can't contact spamd, it tries to re-resolve the ip address > automatically. > > ps. as you can deduct from the text I am not a 100% sure which milter caused > this actually. > > pps. even nicer would be, the ability to use srv records and use dynamic > ports. spamass-milter spawns a new spamc process for each incoming message. It does not keep around any such state and wouldn’t need a restart for a changed spamd host.
Re: The rewrite_header Subject [SPAM] directive has stopped working?!
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 original author even (with interesting background on the procmail code, too): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006633#24
Auto-learning ‘considered harmful’: not so much when rejecting spam?
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 something. Because, as far as I understand the default spam auto-learning threshold of 12.0 causes incoming high-probability spam to be learned as spam, even though the message is then rejected and not available locally later. Is my understanding correct? Auto-learning of spam can be useful if spam is rejected during the SMTP conversation but after it has been seen – and learned – by SpamAssassin?
Re: Espoofer - An Email Spoofing Testing Tool That Aims To Bypass SPF/DKIM/DMARC And Forge DKIM Signatures
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, OpenDKIM and OpenDMARC became available later, presumably also for other affected software.
Re: subscribe to blacklist for domains
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, the end result of this will be your mail server getting the > > poor reputation as source of backscatter and going into blacklists :) > > > greed - I don't do that, but almost as long as I've been on this list > there have been advocates of it. As I said, I thought about it, but the > effort of writing a filter to determine what, if anything should be > bounced or rejected, has never seemed worth the effort for such a low > volume mail used as myself. To clarify: Backscatter is caused by ‘rejecting’ mail with a bounce message, after first accepting it. Backscatter is not caused by rejecting mail directly during the SMTP conversation. The Wikipedia page explains this really quite well: https://en.wikipedia.org/wiki/Backscatter_%28email%29 Depending on one’s goals it may be useful to reject spam, at least obvious spam, early, eg using a milter.
Re: manual set of name
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 > > Is there any possibility? Yes, add a line such as this in /etc/spamassassin/local.cf: add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on manual.set.server.name
Re: Log reporting spamd[11912]: dns: [...] messages
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.
Re: How to deal with bounce messages
Matus UHLAR - fantomas: > > > > > and spf is unapplicable since the envelope from is null. > > > > > > > > Isn't that the case with all bounce messages? > > > Matus UHLAR - fantomas: > > > 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 > > > signatures, or they CAN NOT pass DMARC. > > On 22.04.22 16:22, David Bürgin wrote: > > In SPF, when the reverse-path is null, the HELO name is instead > > verified. So a null reverse-path can work fine with relaxed alignment. > > but related to DMARC, this could only be applied only in case of the HELO > being identical to From: domain I guess If some mail server sends you a bounce message, part of the conversation will be: EHLO mail.mydomain.org MAIL FROM:<> ... From: me When MAIL FROM is empty, SPF will verify the HELO domain (with local-part ‘postmaster’) instead. In this example, given the proper setup, mail.mydomain.org would pass SPF, and using the default relaxed alignment, DMARC would pass based on SPF alone.
Re: How to deal with bounce messages
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 > signatures, or they CAN NOT pass DMARC. In SPF, when the reverse-path is null, the HELO name is instead verified. So a null reverse-path can work fine with relaxed alignment.
Re: What does this header mean?... X-Spam_score_int: -38
Don Saklad: > What does this header mean?... > X-Spam_score_int: -38 Doesn’t look like anything from SpamAssassin.
Re: getting spamass-milter to work with remote spamd (on CentOS8)
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.168.10.243:34219 inet:34219@hostname > > this spamc commandline is processed ok > spamc -d .xxx.xxx -p 34219 < /etc/mail/spamassassin/sample-spam2.txt Usually a SpamAssassin milter can accept additional arguments after ‘--’ that it will pass to spamc. So: spamassassin-milter ...other args... -- -d 192.168.10.243 -p 34219 Or configure the connection in /etc/spamassassin/spamc.conf, that works too.
Re: spf fails at apache.org forwards ipv6
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 solved ? The server rejected your message because you are using a sender address that is not allowed according to SPF policy? Impossible to say more without knowing the context (sender email and IP address).
Re: Rawheader or Rawsubject? Or how to match UTF-8 Emoji in Header.
Look into ‘normalize_charset 1’. For background maybe this: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7656
Re: Spamassassin detects spam but don't add X-Spam headers
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. You need to put it before the ‘--’.
Re: Spamassassin detects spam but don't add X-Spam headers
> 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 communicate properly via sockets. That is, for every component you must configure where it can reach the next component. And make sure user/permissions match, too. My setup on Ubuntu 20.04 looks something like this: Postfix ⇅ SpamAssassin Milter (https://crates.io/crates/spamassassin-milter) /var/spool/postfix/spamassassin/spamassassin-milter.sock ⇅ spamc spamd (SpamAssassin) /run/spamassassin/spamd.sock
Re: Spamassassin detects spam but don't add X-Spam headers
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. 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.
Re: Spamassassin detects spam but don't add X-Spam headers
First we would need to see the spamd config, SpamAssassin config, spamass-milter config to see how it is all wired up.
Re: handle_user and connect to spamd failed
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 a self-made spamfilter.sh script that also uses spamc but pipes into /usr/sbin/sendmail? It is not obvious what the intention is there so I recommend to clean this up first.
Re: problems updating when using a cron job on debian 11
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
Score for certain spam
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. Would 10.0 be a good ‘certain spam’ threshold? 15.0? I could then reject such messages at the SMTP layer, without having to worry about rejecting legitimate messages. Thank you!
Re: Customise hostname shown in X-Spam-Checker-Version?
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 side effect. It changes the order of inserted headers so that X-Spam-Checker-Version is now the last instead of the first X-Spam- header … … all right then.
Re: Customise hostname shown in X-Spam-Checker-Version?
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 changed or removed with note that Checker-Version can not be removed Cheers, David
Re: Customise hostname shown in X-Spam-Checker-Version?
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.html > #BASIC-MESSAGE-TAGGING-OPTIONS > > "Here are some examples (these are the defaults, note that Checker-Version > can > not be changed or removed)" 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 Resolved. Perhaps the documentation should be updated.
Customise hostname shown in X-Spam-Checker-Version?
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 host itself, but I would prefer not to do that. (The host might be used for other things than mail, I may not want to have a mail domain as the hostname.) Other mail software that I use does have such settings. For example, Postfix will use its ‘myhostname’ setting when generating the Received header. The milters that I use also have similar settings or will fall back to the hostname setting from Postfix.
Re: sa daemon loads config different to shell ?
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. Ciao, David
Re: sa daemon loads config different to shell ?
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 from remote server. The point is that spamass-milter does not add custom headers like ‘X-Spam-ASN’ received from spamd, only a few select ones. The alternative milter on the other hand adds all X-Spam- headers. This is also what’s discussed in the linked GitHub issue.
Re: sa daemon loads config different to shell ?
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
Re: SPF plugin ignores existing Authentication-Results
Matus UHLAR - fantomas: 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: headers from other milter, the other milter must run before milter using SA (spamass-milter, amavisd-milter, etc) SA milter has to synthetize the Received: header it passsed with mail to SpamAssassin. If it prepends Received: header (as expected), the Authentication-Results: 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 is a good summary of the problem. I want to add to this old thread, that last few changes fixed this problem. When milter adds header, it can add it at position 0 which means before MTA-added Received: header. pull requests were submitted to put Authentication-Results in case of OpenDKIM - https://github.com/trusteddomainproject/OpenDKIM/pull/126 OpenDMARC - https://github.com/trusteddomainproject/OpenDMARC/pull/171 and openARC - https://github.com/trusteddomainproject/OpenARC/pull/141 so hopefully, next releases will put headers at proper place. I have patched OpenDKIM and OpenDMARC and can verify, that not only other milters, but also later programs see Authentication-Results: at proper place, so sendmail can trust them. Just to be clear, these changes don’t help in the SpamAssassin milter case. A workaround like ‘--synth-relay’ proposed in this thread is still necessary when SpamAssassin is integrated as a milter.
Re: SPF plugin ignores existing Authentication-Results
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 as internal. > > Here’s the plan to address this in SpamAssassin Milter > (https://crates.io/crates/spamassassin-milter): Add an option that takes > a regular expression which matches headers *after which* the synthetic > ‘internal’ Received header should be inserted. For those following along, I have added a new experimental option to my SpamAssassin milter implementation. Here’s the documentation: --synth-relay POS Synthesize the internal relay header after position POS. POS may be either an integer, in which case the relay header will be in‐ serted after skipping POS header lines, or a regular expression, in which case the relay header will be inserted after skipping all header lines matching POS. This option is useful in situations where the default position of the synthesized internal relay header (the MTA’s Received header, https://cwiki.apache.org/con‐ fluence/display/SPAMASSASSIN/TrustedRelays) at the very beginning of the message header is not appropriate. For example, when other milters insert Authentication-Results headers for SpamAssassin to consume, SpamAssassin will not trust these headers unless they ap‐ pear before the internal relay header; in this case setting POS to “^(?i)authentication-results:” achieves proper placement of the relay header after such header lines. Now, using the following setting I should get SpamAssassin to reuse Authentication-Results provided by SPF Milter: --synth-relay '^(?i)authentication-results: *mail\.gluet\.ch;' And here we go: May 21 19:08:21 mail spf-milter[42418]: mxout1-he-de.apache.org (helo): pass May 21 19:08:21 mail spf-milter[42418]: users-return-124577-dbuergin=gluet...@spamassassin.apache.org (mailfrom): pass May 21 19:08:21 mail spf-milter[42418]: E87B4400D309: adding Authentication-Results header May 21 19:08:21 mail spf-milter[42418]: E87B4400D309: Authentication-Results: mail.gluet.ch; spf=pass smtp.helo=mxout1-he-de.apache.org May 21 19:08:21 mail spf-milter[42418]: E87B4400D309: adding Authentication-Results header May 21 19:08:21 mail spf-milter[42418]: E87B4400D309: Authentication-Results: mail.gluet.ch; spf=pass smtp.mailfrom=spamassassin.apache.org May 21 19:08:22 mail spamassassin-milter[55644]: E87B4400D309: inserting synthetic relay header at index 4 May 21 19:08:22 mail spamd[56256]: spf: checking to see if the message has a Received-SPF header that we can use May 21 19:08:22 mail spamd[56256]: spf: found an Authentication-Results header added by an internal host: Authentication-Results: mail.gluet.ch; spf=pass smtp.helo=mxout1-he-de.apache.org May 21 19:08:22 mail spamd[56256]: spf: re-using helo result from Authentication-Results header: pass May 21 19:08:22 mail spamd[56256]: spf: found an Authentication-Results header added by an internal host: Authentication-Results: mail.gluet.ch; spf=pass smtp.mailfrom=spamassassin.apache.org May 21 19:08:22 mail spamd[56256]: spf: re-using mfrom result from Authentication-Results header: pass Success! For now I’m keeping this on a separate branch. Don’t know if it feels too hacky to keep, feedback welcome. I would prefer if this could be solved in SpamAssassin (bug 6918). Ciao, David
Re: SPF plugin ignores existing Authentication-Results
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: headers from other milter, the other milter must run before milter using SA (spamass-milter, amavisd-milter, etc) SA milter has to synthetize the Received: header it passsed with mail to SpamAssassin. If it prepends Received: header (as expected), the Authentication-Results: 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. Thank you, this is a good summary of the problem. Possible workarounds require trusting the Authentication-Results: header either via SA milter (which would add synthetized Received: header after it), or via SpamAssassin itself (trust headers added by "host" immediately after last trusted/internal "Received" header.) I prefer the second setup, as it's possible to re-check SA score for such e-mail later. I have tried receiving mail with fake Authentication-Results: header and it got deleted by opendkim-milter, to opendkim-milter may be trusted for this setup. SA would need an option which hosts to trust Authentication-Results: from. To the SpamAssassin developers: Would you consider adding a configuration option to trust *all* Authentication-Results headers with a certain authserv-id (https://www.rfc-editor.org/rfc/rfc8601#section-2.5)? That would be very helpful for setups that (securely) manage Authentication-Results headers themselves.
Re: SPF plugin ignores existing Authentication-Results
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 SpamAssassin operate.
Re: SPF plugin ignores existing Authentication-Results
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 SpamAssassin Milter (https://crates.io/crates/spamassassin-milter): Add an option that takes a regular expression which matches headers *after which* the synthetic ‘internal’ Received header should be inserted. --trusted-relay-after Then one would use this like this: --trusted-relay-after '^(?i)authentication-results:[\t ]*mail\.gluet\.ch;' The effect this would have is that a message that is sent to SpamAssassin in this form currently: Received: from m43-8.mailgun.net by mail.gluet.ch (Postfix) ... Authentication-Results: mail.gluet.ch; dmarc=pass ... [← untrusted!] Authentication-Results: mail.gluet.ch; dkim=pass ... [← untrusted!] Authentication-Results: mail.gluet.ch; spf=pass ...[← untrusted!] Message-ID: <1...@execute-api.eu-central-1.amazonaws.com> ... Would now be sent to SpamAssassin in this form: Authentication-Results: mail.gluet.ch; dmarc=pass ... [← now trusted] Authentication-Results: mail.gluet.ch; dkim=pass ... [← now trusted] Authentication-Results: mail.gluet.ch; spf=pass ...[← now trusted] Received: from m43-8.mailgun.net by mail.gluet.ch (Postfix) ... Message-ID: <1...@execute-api.eu-central-1.amazonaws.com> ... I’m interested to hear what comments others might have about the problem and this solution. (Also a bit surprised that no one seems to have noticed this before.) To highlight the problem once more: When used as a milter, SpamAssassin cannot take into account Authentication-Results added by earlier milters, because it does not trust them.
Re: SPF plugin ignores existing Authentication-Results
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 SpamAssassin 3.4.4-1ubuntu1.1 on Ubuntu Server 20.04. Oh, it actually cannot work. SpamAssassin only accepts Authentication-Results that come *before* an ‘internal’ Received header (https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustedRelays). I use SpamAssassin as a milter, so the ‘internal’ Received header is added by Postfix only *after* the milters add their headers. That means my milters’ Authentication-Results headers will never look like internal to SpamAssassin, and will never be used. 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.
SPF plugin ignores existing Authentication-Results
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.gluet.ch; spf=fail smtp.helo=bounces.amazon.co.jp 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: May 17 20:11:06 mail spf-milter[836]: bounces.amazon.co.jp (helo): fail May 17 20:11:06 mail spf-milter[836]: gexymv...@bounces.amazon.co.jp (mailfrom): fail May 17 20:11:07 mail spf-milter[836]: 8599A400D309: adding Authentication-Results header May 17 20:11:07 mail spf-milter[836]: 8599A400D309: Authentication-Results: mail.gluet.ch; spf=fail smtp.helo=bounces.amazon.co.jp May 17 20:11:07 mail spf-milter[836]: 8599A400D309: adding Authentication-Results header May 17 20:11:07 mail spf-milter[836]: 8599A400D309: Authentication-Results: mail.gluet.ch; spf=fail smtp.mailfrom=bounces.amazon.co.jp May 17 20:11:07 mail spamd[11230]: spf: checking to see if the message has a Received-SPF header that we can use May 17 20:11:07 mail spamd[11230]: spf: checking HELO (helo=bounces.amazon.co.jp, ip=160.251.60.97) ... Is this a bug in the SPF plugin? Do I need to set something in my config? I’m using SpamAssassin 3.4.4-1ubuntu1.1 on Ubuntu Server 20.04.
Make SpamAssassin use SPF results in an Authentication-Results header?
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 SpamAssassin and that inserts an Authentication-Results header with the result. Does SpamAssassin really use this header? How to make sure? Or what is the configuration that would enable this? Thank you. -- David
Re: SpamAssassin Milter – Milter for spam filtering with SpamAssassin
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 fallback user rather than nobody > (-u defaultuser is only used with multiple recipients) > - mapping e-mail addresses to local users on non-sendmail systems > (sendmail -bv on postfix sends mail insteand of returning local user) There is an open issue about the first one, but as I don’t myself use these features, no such thing is implemented yet. Currently the new milter is really rather minimalist. I’m happy with it, but power users of spamass-milter might be disappointed. If you’re interested, please try it out and give feedback on the issue tracker.
Re: SpamAssassin Milter – Milter for spam filtering with SpamAssassin
@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/projects/spamass-milt, but ‘spamass-milter’ is perhaps its proper name.
SpamAssassin Milter – Milter for spam filtering with SpamAssassin
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 using the spamc client. It is a light-weight component that serves to integrate Apache SpamAssassin with a milter-capable MTA (mail server) such as Postfix. I used to be a user of an alternative milter, spamass-milt, but due to some minor complaints I had with it (including the age and quality of the code, and lack of tests), I decided to do it over. Compared with spamass-milt, this new milter has a reduced feature set – for now. On the other hand, it makes use of milter features such as automatic macro negotiation, skipping large messages, or preserving header whitespace exactly as-is. It is not a clone of spamass-milt, rather a more minimal incarnation, so expect some functional differences. Thank you for reading. -- David
