Sorry but i don’t get your point. This post is not about what is visible to end-user but more about combining different technologies ( SPF, DKIM and DMARC) in such way to add more value to Spammassassin.
Since DMARC was not present in Spammassasin by default trough a plugin this was/is a technique to bring also DMARC in equation. It doesn’t mean that you don’t check anymore anything else.

Ordinary SPF (and therefore the spamassassin SPF_PASS test) only works with the envelope sender, which is often not visible to users. DKIM and DMARC are supposed to check the “From” header address, however the rules in this blog post will ignore this address if only the envelope sender address passes the SPF checks.

Hello,

The idea was have a restriction per country per email. For example one user can access his email from DE but another user have DE banned.
The above cannot be done with iptables/ipset. It is useful indeed when you want to block certain countries for all emails. For example you know that nobody will login to your email server from CN and you want to block it.

Thanks for writing. I am not an expert on s/qmail and if i said something which is not true I prefer to that everyone will raise a flag and i will correct it asap.
Now, regarding s/qmail and qmail-spp functionality i usually use my own scripts/logic on different stages.
Just some examples:
1) i want to reject connections if HELO/EHLO is not RFC2821 and i want to do this as soon as possible ( connection/helo stage)
2) for some reasons (maybe better logging) i will temporary move the same on the [mail] stage or even when [rcpt] is presented.
3) maybe i don’t want to use RBL on connection because i want better logging (ex: who send to whom, etc)
4) maybe based on some other checks executed on earlier stages i want to tarpit / greylist / whatever before going further.

Those can be easily achieved in exim and even with qmail/qmail-spp. If you said that you can implement the same with s/qmail than i am very happy to hear and i will obviously change what i wrote months ago.

Btw, do you plan to include it in distros where anyway software is compiled when install ? (ex: Gentoo )

It was never about the math.
You math is fine and i understand your point but you started your investigation from the fact that in order for DMARC to pass you should have DKIM OR(and not AND) SPF to pass.

Actually the DMARC specs ( if you read RFC7489) is leaving a lot of space for interpretation. Plus this is not a standard but an informational RFC.

Just two examples:
1) is actually is enforcing that DMARC should not replace local policy.
I quote: “Mail Receivers MAY choose to reject or quarantine email even if email passes the DMARC mechanism check. The DMARC mechanism does not inform Mail Receivers whether an email stream is “good”. Mail Receivers are encouraged to maintain anti-abuse technologies to combat the possibility of DMARC-enabled criminal campaigns.”
2) is saying that “different treatment of messages that are not authenticated versus those that fail authentication” is not in the scope of this RFC.

It was never about “&& ||” but about how sure i am when i want to reject. Since both DKIM and SPF have their own flows which can be exploited in the benefit of a rogue actor i want to be very sure when i REJECT that message. Moreover my approach(which you might think is more relaxed) is also covering the situation when you don’t have the correct information about a DKIM/SPF due to a DNS issue at that time.

Long story short i prefer to build on a scoring mechanism and double check the info(in my case DKIM and SPF must fail for a DMARC rejection) rather than immediately rejecting based on only one of them.
In an ideal world where all the e-mail/domain administrator will correctly cover DKIM/SPF/DMARC than you might think to put && instead ||. In this world where false positive can be easily created due to unmaintained/incorrectly configuration i prefer to double check. Hope that make more sense now.

Please see other details on: https://dmarc.org/wiki/FAQ#How_does_DMARC_work.2C_briefly.2C_and_in_non-technical_terms.3F