On 2025-03-06 at 03:28:03 UTC-0500 (Thu, 6 Mar 2025 09:28:03 +0100)
Petko Manolov via Postfix-users <pet...@nucleusys.com>
is rumored to have said:
On 25-03-05 15:23:11, Bill Cole via Postfix-users wrote:
On 2025-03-05 at 11:43:07 UTC-0500 (Wed, 5 Mar 2025 18:43:07 +0200)
Petko Manolov via Postfix-users <pet...@nucleusys.com>
is rumored to have said:
I thought spf, dkim and dmarc checks (at least one of them, if not
all) will
stop the message, but this didn't happen.
That's a matter of how you configure your system, specifically
OpenDMARC.
Postfix asks OpenDMARC to decide what to do. I'm unsure if OpenDMARC
is
currently supported but when I last looked it had reasonable
documentation.
The goal was to have my dmarc config as tight as possible. Namely:
SPFSelfValidate true
SPFIgnoreResults true
RejectFailures true
I have no certainty what the consequences of that are, but I suspect
that it will cause rejections of some wanted mail which is not in any
way fake.
If that's what you want, there's no problem.
If you want to reject unsolicited bulk email, you would need to use
other means, because the validation done by DMARC works perfectly on the
overwhelming majority of spam that cannot be identified solely by client
IP or other pre-DATA tests, at least at multi-user sites. (Every person
gets a different mix of spam, so if you have a small site with similar
users, you may see a different reality...)
Quoting dmarc documentation re the latter: " If set, messages will be
rejected if
they fail the DMARC evaluation, or temp-failed if evaluation could not
be
completed." This obviously didn't happen.
I cannot speak to OpenDMARC's details, and would not expect to see that
explained here. This is the Postfix list, not the OpenDMARC list (if
such a thing exists...)
[...]
According to github the source code hasn't been touched in four years.
I believe someone has posted here in recent years regarding fixes, which
may only exist in well-maintained downstream packages (e.g. Debian,
RedHat, etc.) It is very likely to be worth your time to search the
archives for how others have made it useful despite idiosyncrasies.
Even so, I wouldn't denigrate OpenDMARC simply for not having recent
changes. It's not trying to do a hugely complex task, so it is entirely
possible that no new bugs have been found in that time.
I guess the question here is how to prevent this sort of spam from
landing
in my mailbox?
Identifying spam is absolutely NOT what DMARC is for.
DMARC is a mechanism for domain owners to tell anyone who receives
mail
claiming to be from their domain what the owner recommends they do
with mail
that cannot be authenticated and how the owner would like them to
report
success and failure. The lack of a DMARC record for the domain in the
From
header does not correlate with whether a message is "spam" and nor
does the
lack of a DKIM or SPF record. Many spammers have perfect
DMARC/DKIM/SPF
records that authenticates all of their actually sent mail, expresses
a policy
for handling unauthenticated mail, and some even have a reporting
address.
Fighting spam isn't exact science, mostly because the definition of
spam could
be rather blurry at times.
I do really understand that.
This does not change the fact that otherwise purely criminal spammers
using "bulletproof" hosting and stolen resources manage to get their
mail authentication configuration done perfectly, while many people just
don't bother with DMARC, DKIM, or SPF *at all*.
That's based on both the systems I help administer and on the Apache
SpamAssassin RuleQA service which I help maintain, which is fed by
mass-check data from participating mail systems. Mail authentication is
useful primarily as a way to protect legitimate mail from known-good
sender domains being detected as spam, rather than a way to exclude spam
simply because a message fails authentication or a domain does not
support authentication. In other words: authentication alone is useless
if you have no authorization policies.
What _i_ am trying to do is to fend off as many
suspicious messages i can. Those few "good" mail servers that are
false
positives go to the whitelist.
Indeed, it will be "few" if you have relatively few and homogenous
users.
In this particular case, the IP address offering the message to you
(193.222.96.52) is controlled by known bad actors. Spamhaus.org lists
that IP
on their SBL and the whole /24 network on their DROP (Don't Route Or
Peer)
list. See:
https://check.spamhaus.org/results?query=SBL674894
https://www.spamhaus.org/blocklists/do-not-route-or-peer/
You can use the Spamhaus DNSBLs for free if your query volume is low
and your
DNS resolver isn't public. DROP is also available free as a JSON file
which
gets changes every few days. As of this morning it had just 1359
entries, so
your spammer is in a special class. I have never regretted using the
DROP list
as designed, dropping all packets at the edge.
Hmm, zen.spamhaus.org doesn't resolve anymore.
You need to do it right. :) Queries *under* the zen zone work. The plain
name does not and has no reason to. The test record works:
$ dig 2.0.0.127.zen.spamhaus.org
; <<>> DiG 9.20.5 <<>> 2.0.0.127.zen.spamhaus.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31944
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org. IN A
;; ANSWER SECTION:
2.0.0.127.zen.spamhaus.org. 60 IN A 127.0.0.10
2.0.0.127.zen.spamhaus.org. 60 IN A 127.0.0.2
2.0.0.127.zen.spamhaus.org. 60 IN A 127.0.0.4
If you run your own local resolver which is fully recursive (no query
forwarding to open public resolvers) and don't do too many queries
(which I understand to be over 100k/day,) it should work for you. In
some cases you may need to sign up for a free Data Query Service account
which can be used via open resolvers. The example redacts the Spamhaus
account key:
$ dig @9.9.9.9 2.0.0.127.[ACCOUNT_KEY].zen.dq.spamhaus.org
; <<>> DiG 9.20.5 <<>> @9.9.9.9
2.0.0.127.[ACCOUNT_KEY].zen.dq.spamhaus.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28768
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;2.0.0.127.[ACCOUNT_KEY].zen.dq.spamhaus.net. IN A
;; ANSWER SECTION:
2.0.0.127.[ACCOUNT_KEY].zen.dq.spamhaus.net. 1 IN A 127.0.0.10
2.0.0.127.[ACCOUNT_KEY].zen.dq.spamhaus.net. 1 IN A 127.0.0.4
2.0.0.127.[ACCOUNT_KEY].zen.dq.spamhaus.net. 1 IN A 127.0.0.2
I wonder what would be the
correct/contemporary version of:
reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
That *should* work if you are small and run your own resolvers AND are
not querying from a few specific networks which Spamhaus has had issues
with. E.g. they made noise about cutting off anonymous free access via
Hetzner a few weeks back.
If you register with Spamhaus the Postfix equivalent to the above is
reject_rbl_client [ACCOUNT_KEY].zen.dq.spamhaus.org=127.0.0.[2..11]
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com
addresses)
Not Currently Available For Hire
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
