We need to block the a TLD ( .bio)
I have tried the regex examples I found here but even the example fails the test.
TIA
I have tried the regex examples I found here but even the example fails the test.
TIA
Blocking TLD
- Thread starter vsupport
- Start date
Hi. In this situation i use rule like this:
1 In what object create group "Block by TLD"
2 In group create object Match Field with value From=@.+\.bio$
3 Create rule TLD off with action Block and Object Block by TLD
1 In what object create group "Block by TLD"
2 In group create object Match Field with value From=@.+\.bio$
3 Create rule TLD off with action Block and Object Block by TLD
Thanks...
This will simplify things a lot
Been reading about the new TLD .zip that google has introduced which the powers that be want blocked..
This will simplify things a lot
Been reading about the new TLD .zip that google has introduced which the powers that be want blocked..
Did this really work?
For me with this, From (should it be From: ?)
@.+\.ru$
it still sends .ru to the regular spam checks, instead of blocking it. (admin@s6.whatever.ru)
Rule is first in list for me, '99'
Block TLD
Priority: 99
Direction: In
Active: Yes
Action: Block
What: Block by TLD.
For me with this, From (should it be From: ?)
@.+\.ru$
it still sends .ru to the regular spam checks, instead of blocking it. (admin@s6.whatever.ru)
Rule is first in list for me, '99'
Block TLD
Priority: 99
Direction: In
Active: Yes
Action: Block
What: Block by TLD.
Please provide the logs for such a mail - maybe then we can see what the issue is.
Is the Object with the regex a 'What' Object to match the from header or a Who Object to match the envelope sender?
It's a WHAT object as per the "how to" above 
But I updated yesterday to
.*@.*\.ru
and that seems to match better. (past 24 hours, so could be too early to say)
Maybe the rule engine didn't allow for domain only matches anymore.. ?
But I updated yesterday to
.*@.*\.ru
and that seems to match better. (past 24 hours, so could be too early to say)
Maybe the rule engine didn't allow for domain only matches anymore.. ?
Confirmed. The new rule blocked it.
Not sure why ti goes through spamassassin and gets a score first, when block is set as first rule. But perhaps it's part of SA process to also block?
Not sure why ti goes through spamassassin and gets a score first, when block is set as first rule. But perhaps it's part of SA process to also block?
Where can I get a list of "Fields"? Can I use "Client" in the "Field:" section? Is there a "Subject" Field?
I recently answered a few questions here on this topic. It seems that most people are not aware of it, but this is the intended behavior.
All emails go through the entire SA filter chain. At the end of this chain, the action object is executed. If a sender is listed under Mail Filter → Who Object in either the blocklist or the welcomelist, it will take effect—but only after the entire SA filter chain has been processed.
If you want to block the email earlier, this must already happen in Postfix, for example in /etc/postfix/senderaccess.
Drawback: if you manually add entries there, Proxmox will regularly overwrite them, because this list is managed via PMG under Mail Proxy → Welcomelist.
However, it is only possible to add positive entries ("OK") there, not negative entries ("reject").
This bothered me as well, so I wrote my own policy service (“policyguard”) that handles these tasks in Postfix for me. There you can define your own blocklists or regex rules, which can also block your domain, among other things.
From my side, the tool is mainly designed to deal with annoying Google junk, but I do actually maintain a few senders there manually as well.
Just add your TLD to the SENDER_BLOCK_INCLUDE:
From my point of view, I don’t think much of blocking individual TLDs.
There are simply too many domains to maintain them in a huge regex list. Instead, do it the other way around and assign penalty scores to everything you don’t regularly expect mail from.
Additionally: use geoblocking—this targets the geographic region rather than the domain extension.
I wrote an exceptionally detailed article on this topic.
All emails go through the entire SA filter chain. At the end of this chain, the action object is executed. If a sender is listed under Mail Filter → Who Object in either the blocklist or the welcomelist, it will take effect—but only after the entire SA filter chain has been processed.
If you want to block the email earlier, this must already happen in Postfix, for example in /etc/postfix/senderaccess.
Drawback: if you manually add entries there, Proxmox will regularly overwrite them, because this list is managed via PMG under Mail Proxy → Welcomelist.
However, it is only possible to add positive entries ("OK") there, not negative entries ("reject").
This bothered me as well, so I wrote my own policy service (“policyguard”) that handles these tasks in Postfix for me. There you can define your own blocklists or regex rules, which can also block your domain, among other things.
From my side, the tool is mainly designed to deal with annoying Google junk, but I do actually maintain a few senders there manually as well.
Just add your TLD to the SENDER_BLOCK_INCLUDE:
Code:
SENDER_BLOCK_INCLUDE = ["firebaseapp.com", "ru" ]From my point of view, I don’t think much of blocking individual TLDs.
There are simply too many domains to maintain them in a huge regex list. Instead, do it the other way around and assign penalty scores to everything you don’t regularly expect mail from.
Additionally: use geoblocking—this targets the geographic region rather than the domain extension.
I wrote an exceptionally detailed article on this topic.
Last edited: