Thanks for the detailed explanation, Bill. I ended up registering with spamhaus.org and followed their guide here:
https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/MTAs/020-Postfix.html However, i'm considering postscreen as perhaps better alternative. cheers, Petko PS: Apologies for the top post. On 25-03-06 11:47:39, Bill Cole via Postfix-users wrote: > 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 > _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
