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.
Re: [Help] bodyre in hashbl
On Mon, May 17, 2021 at 07:12:47PM +0300, Henrik K wrote: > > Or check the replace_tags in 25_replace.cf, there's ready templates for > characters (but they match some commonly obfuscated variants too). And yeah sorry, these won't work with HashBL, it's just for basic rules..
Re: [Help] bodyre in hashbl
On Mon, May 17, 2021 at 03:02:57PM +0200, Marco wrote: > > So I have to add the accented character literally. > I can't understand why. Are there any limitation in Hashbl plugin with UTF8? > Maybe I have misunderstood something. SA doesn't support UTF8 regex. It's just matching plain byte strings. Depends on normalize_charset setting too, for best compatibility you should match both latin and utf-8 raw byte variants: ü -> (?:\xfc|\xc3\xbc) https://cwiki.apache.org/confluence/display/SPAMASSASSIN/WritingRulesAdvanced Or check the replace_tags in 25_replace.cf, there's ready templates for characters (but they match some commonly obfuscated variants too).
Re: txrep_autolearn range - how does the range influence autolearning
On Mon, 17 May 2021 15:32:48 + Lucas Rolff wrote: > Even for only inbound, do you suggest disabling txrep_spf there as > well, or only particularly important for outbound? For anything TxRep treats the header "From" address as having been authenticated by an SPF pass even if the pass came from an envelope address with a completely different domain.
Re: txrep_autolearn range - how does the range influence autolearning
Even for only inbound, do you suggest disabling txrep_spf there as well, or only particularly important for outbound? - Lucas On 17/05/2021, 17.14, "RW" wrote: On Sun, 16 May 2021 16:50:57 -0400 Greg Troxel wrote: > Lucas Rolff writes: > > > Thanks for the notes about sa-learn, txrep outgoing and the > > autolearn itself. In my particular case, I'll only use it as an > > inbound filter, since I handle outbound very differently (I let > > other people take care of the filtering using an external relay); > > For inbound I've used a commercial solution for years, they sadly > > decided to 5x the cost starting 2022, which then doesn't really > > make it worth it anymore, so time to change! > > It's unfortunate that you can't use it on tx. On outbound, all it > does keep track of who mail was sent to, and that causes it to get > better treatment on inbound. ... > In particular, as you give negative points to mail that is a reverse > match to outbound mail, you can turn up the agressiveness knob with > somewhat less trouble. As I said I don't think this will work well. If you really want to do it you would need to set auto_whitelist_distinguish_signed 0 txrep_spf 0 Turning off SPF support really should be the default until TxRep's broken handling of it is fixed. If I used TxRep I'd rather have DKIM support than outgoing learning. It's not a particularly good way of doing whitelisting anyway because it doesn't involve any authentication.
Re: txrep_autolearn range - how does the range influence autolearning
On Sun, 16 May 2021 16:50:57 -0400 Greg Troxel wrote: > Lucas Rolff writes: > > > Thanks for the notes about sa-learn, txrep outgoing and the > > autolearn itself. In my particular case, I'll only use it as an > > inbound filter, since I handle outbound very differently (I let > > other people take care of the filtering using an external relay); > > For inbound I've used a commercial solution for years, they sadly > > decided to 5x the cost starting 2022, which then doesn't really > > make it worth it anymore, so time to change! > > It's unfortunate that you can't use it on tx. On outbound, all it > does keep track of who mail was sent to, and that causes it to get > better treatment on inbound. ... > In particular, as you give negative points to mail that is a reverse > match to outbound mail, you can turn up the agressiveness knob with > somewhat less trouble. As I said I don't think this will work well. If you really want to do it you would need to set auto_whitelist_distinguish_signed 0 txrep_spf 0 Turning off SPF support really should be the default until TxRep's broken handling of it is fixed. If I used TxRep I'd rather have DKIM support than outgoing learning. It's not a particularly good way of doing whitelisting anyway because it doesn't involve any authentication.
[Help] bodyre in hashbl
Hello,
I'm trying to use Hashbl plugin with bodyre function.
With that function I would like to match utf8 patterns, such as
'([\p{L}\p{M}\d\S]+[\ \t]+[\p{L}\p{M}\d\S]+)'
I'm in particular interested in accented characters, such as /[àèìòù]/.
With Perl, if I try:
```
use utf8;
use open ':std', ':encoding(UTF-8)';
$txt = ' musica è ciao ciao.';
$re = '([\p{L}\p{M}\d\S]+[\ \t]+[\p{L}\p{M}\d\S]+)';
if ($txt =~ /$re/gs) {
print "Match: $1";
}
```
then $txt matches as well.
With Spamassassin I built my own dnsbl of hashes and the Spamassassin rule:
bodyHASHBL_MY_SPAM1
eval:check_hashbl_bodyre('spamhash.example.com', 'sha1/max=10/shuffle',
'([\p{L}\p{M}\d\S]+[\ \t]+[\p{L}\p{M}\d\S]+)', '^127\.0\.0\.2')
This doesn't match the above $txt in the body of the mail.
If I want to match as expected the string ' musica è ciao ciao.' in the
body of the mail, then I must change the above regex in the following way:
bodyHASHBL_MY_SPAM1
eval:check_hashbl_bodyre('spamhash.example.com', 'sha1/max=10/shuffle',
'([\p{L}\p{M}\d\Sàèìòù]+[\ \t]+[\p{L}\p{M}\d\Sàèìòù]+)', '^127\.0\.0\.2')
So I have to add the accented character literally.
I can't understand why. Are there any limitation in Hashbl plugin with UTF8?
Maybe I have misunderstood something.
Thank you very much for every hint.
Kind Regards
Marco
