Re: rule assistence

>On Sun, Feb 08, 2026 at 11:18:37AM +0100, A.Schulze via users wrote:
>> I like to create SA rules to cover some or all following properties of a message:

>> - RFC5322.From TLD: .de

On 08.02.26 17:05, Matija Nalis wrote:
> this is simple regex (you'll have to learn at least basics of regular 
> expressions to be able to write SA rules) match, as there exist "From:" 
> header in the mail.

>header RFC5322_FROM_DE From:addr =~ /\.de$/
>score  RFC5322_FROM_DE -2.0

I'd use L_FROM_DE and score 0.001 or -0.001

>> - RFC5321.MailFrom: mail.$domain
>
>That depends of where your MTA saves it. Might be e.g. `Return-Path:` or `X-Envelope-From` header etc.
>Then you'd use the same principle as above. But you'll have to look into MTA docs to know what it records and where.

I think SA uses option envelope_sender_header and puts its content to 
EnvelopeFrom meta-header

>> - NS-Record: @cloudflare
>> - MX-Record: @cloudflare
>
>NS and MX records of *what*?

>> - DMARC-Policy: p=reject, rua -> @cloudflare
>> - DMARC-Result: pass

>For DMARC, you can find the rules and their scores with e.g.
>
>% grep -ri DMARC  /var/lib/spamassassin/ /usr/share/spamassassin/ /etc/spamassassin/

there already are DMARC_REJECT and DMARC_PASS rules.
They require DMARC plugin loaded.

(unfortunately it so far doesn't support Authentication-Results header but 
that's just cosmetic issue)

>> - SPF-Record: include: @cloudflare
>> - existence of mail.$domain
>> - SPF-Record for mail.$domain -> include @amazonses
>
>"perldoc Mail::SpamAssassin::Plugin::SPF" for what that plugin allows.
>What it doesn't have, you'll have to find elsewhere, or write plugin code yourself.
>
>For querying DNS records in general (e.g. for DMARC), see Mail::SpamAssassin::Plugin::AskDNS
>
>see e.g. https://www.mail-archive.com/[email protected]/msg95643.html for examples

I'm afraid SPF plugin doesn't support there checks, so AskDNS will be 
needed.

>> - SMTP-Client-IP: $some @amazonses
>
>I don't understand this $ and @, but IP address of connecting peer (if that is what you mean by "SMTP-Client-IP")
>is usually recorded in some header. SA already parses some, so take a look in your /var/lib/spamassassin for examples,
>or feel free to write your own regular expressions to match them.

SA supports meta headers from processed relays in Received:
https://cwiki.apache.org/confluence/display/SPAMASSASSIN/TrustedRelays

I guess you want to check X-Spam-Relays-External for 

/^[^\]]+ rdns=\S+.\.amazonses\.com\s/


similar to __HDR_RCVD_AMAZON, just in this case it's the first external 
relay

>> - DKIM-Signatures: 1k RSA by amazonses.com & 2k RSA by $domain
>
>you need to read the docs on how to enable plugins, then enable the DKIM plugin and read its docs.

looks that DKIM plugin is no help here.
the _DKIMDOMAIN_ only contains on signature and nothing matches the type of 
signature.

Using opendkim and Authentication-Results: headers should be able to match 
like this message:

Authentication-Results: fantomas.fantomas.sk;
         dkim=pass (1024-bit key; unprotected) header.d=voyager.hr [email protected] header.a=rsa-sha256 header.s=def2 header.b=OqJyXaV4;
         dkim-atps=neutral


Just note that your mail server should be able to remove rogue Authentication-Results 
when receiving mail from network.

I did this by putting this to postfix config:

header_checks = pcre:{ {/^Authentication-Results:\s+\Q$myhostname\E[\s;]/ IGNORE} }


I'll keep the rest here:


>Also generally, pipe your message through "spamassassin -D -t" to
>debug and see what is being checked and whether it works.
>
>
>> Any advise?
>
>Yes, but you're asking for like an engineer-week of someoneone's time
>to set it all up for you based on your custom specifications.
>
>Also, lots of what you ask for looks like https://en.wikipedia.org/wiki/XY_problem
>
>e.g. there are things in SA by default like "whitelist_auth" that
>probably handle majority of your SPF&DKIM needs without resorting to
>manual rule writing and matching addresses (which you seem to be trying)
>
>But you really need to read the documentation first to know what is
>possible with existing SA code and rules, and then ask questions
>about things which arent't covered and are giving you real-life problems;
>by giving detailed instructions and samples why existing functionality isn't
>working for you (i.e. you're still getting spam, or your ham is being
>mistagged as spam)
>
>And only armed with that information does it make sense to suggest
>what you think might help your case, and ask people for help whether
>your attempted way to fix the issue is viable, and how it can be
>implemented if it is. But that is advanced usage, and it is instead
>quite likely that you don't really need majority of what you asked
>how to do.
>
>TL;DR: you would likely either need to invest some time into reading
>the existing documentation and examples, contract someone to do that
>work for you, or significantly reduce your requirements to only
>simple things already present and easily documented in SA (and then
>apply one of two solutions above).

-- 
Matus UHLAR - fantomas, [email protected] ; 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.
Save the whales. Collect the whole set.