Re: Blocking TLDs

2023-02-18 Thread Matus UHLAR - fantomas

08.02.2023 12:14, Viktor Dukhovni wrote:
..

/etc/postfix/sender-access:
top REJECT I employ crude anti-spam measures
.topREJECT I employ crude anti-spam measures


On 18.02.23 09:34, Michael Tokarev wrote:

I wonder how effective to block just the TLDs. I guess it is zero, no?


guys use this because many people use parent_domain_matches_subdomains to 
contain smtpd_access_maps, even when it's discouraged:


http://www.postfix.org/postconf.5.html#parent_domain_matches_subdomains


I *guess* foo@top shouldn't really work, as it is non-fqdn in terms of
postfix, and is blocked by, say, reject_non_fqdn_sender.

So only entries like .top (with the leading dot) are needed here
(± the context, which is about how good it is to block-by-tld).


.top only works when parent_domain_matches_subdomains does NOT contain 
smtpd_access_maps:


http://www.postfix.org/access.5.html


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; 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.
Windows found: (R)emove, (E)rase, (D)elete


Re: Blocking TLDs

2023-02-17 Thread Michael Tokarev

08.02.2023 12:14, Viktor Dukhovni wrote:
..

 /etc/postfix/sender-access:
 top REJECT I employ crude anti-spam measures
 .topREJECT I employ crude anti-spam measures


I wonder how effective to block just the TLDs. I guess it is zero, no?

I *guess* foo@top shouldn't really work, as it is non-fqdn in terms of
postfix, and is blocked by, say, reject_non_fqdn_sender.

So only entries like .top (with the leading dot) are needed here
(± the context, which is about how good it is to block-by-tld).

/mjt


Re: Blocking TLDs

2023-02-16 Thread Wietse Venema
James Pifer:
> On 2/16/2023 9:56 AM, Wietse Venema wrote:
> > James Pifer:
> >> On 2/16/2023 9:21 AM, Viktor Dukhovni wrote:
> >>> Don't forget set an empty:
> >>>
> >>>   parent_domain_matches_subdomains =
> >>>
> >> Where should that go exactly?
> > In main.cf.
> >
> > Wietse
> 
> I should have been more specific. Where in main.cf should it go? Does it 
> matter?

Before or after smtpd_recipient_restrictions

Wietse


Re: Blocking TLDs

2023-02-16 Thread James Pifer

On 2/16/2023 9:56 AM, Wietse Venema wrote:

James Pifer:

On 2/16/2023 9:21 AM, Viktor Dukhovni wrote:

Don't forget set an empty:

  parent_domain_matches_subdomains =


Where should that go exactly?

In main.cf.

Wietse


I should have been more specific. Where in main.cf should it go? Does it 
matter?

Re: Blocking TLDs

2023-02-16 Thread Wietse Venema
James Pifer:
> On 2/16/2023 9:21 AM, Viktor Dukhovni wrote:
> > Don't forget set an empty:
> >
> >  parent_domain_matches_subdomains =
> >
> 
> Where should that go exactly?

In main.cf.

Wietse


Re: Blocking TLDs

2023-02-16 Thread James Pifer

On 2/16/2023 9:21 AM, Viktor Dukhovni wrote:

On Thu, Feb 16, 2023 at 08:23:00AM -0500, James Pifer wrote:


Anyone see anything wrong with it or have other suggestions?

smtpd_recipient_restrictions =
      check_client_access inline:{
      { 107.182.131   = REJECT This mail server rejects mail
from the 107.182.131.0 network }
      }
      check_sender_access inline:{
      { .store    = REJECT This mail server rejects messages 
from the .store domain }
      { .shop = REJECT This mail server rejects messages 
from the .shop domain }
      { .tk   = REJECT This mail server rejects messages 
from the .tk domain }
      { .beauty   = REJECT This mail server rejects messages 
from the .beauty domain }
      }

Don't forget set an empty:

 parent_domain_matches_subdomains =



Where should that go exactly?

Re: Blocking TLDs

2023-02-16 Thread Viktor Dukhovni
On Thu, Feb 16, 2023 at 08:23:00AM -0500, James Pifer wrote:

> Anyone see anything wrong with it or have other suggestions?
> 
> smtpd_recipient_restrictions =
>      check_client_access inline:{
>      { 107.182.131   = REJECT This mail server rejects mail 
> from the 107.182.131.0 network }
>      }
>      check_sender_access inline:{
>      { .store    = REJECT This mail server rejects messages 
> from the .store domain }
>      { .shop = REJECT This mail server rejects messages 
> from the .shop domain }
>      { .tk   = REJECT This mail server rejects messages 
> from the .tk domain }
>      { .beauty   = REJECT This mail server rejects messages 
> from the .beauty domain }
>      }

Don't forget set an empty:

parent_domain_matches_subdomains =

-- 
Viktor.


Re: Blocking TLDs

2023-02-16 Thread James Pifer

On 2/8/2023 1:13 PM, James Pifer wrote:

On 2/8/2023 1:02 PM, Jaroslaw Rafa wrote:

Dnia  8.02.2023 o godz. 12:55:58 James Pifer pisze:

I would prefer to quarantine rather than reject, if I can figure out
how to do that. I would at least be able to look through them
periodically and see if something is legit.

I suddenly started getting these (.store,.shop, etc) a could days
ago. They are all coming from this block of addresses:
107.182.131.0.

So definitely a better idea is to block these IP addresses.


Good suggestion. I have modified accordingly (I think). ;-)

Thanks


So I've had this setup in my main.cf for a couple weeks now. For the 
most part it has been working great, but every so often things get 
through. Over night I had 5 emails get through from .shop, but they were 
from a different network than I was receiving before. Now I'm wondering 
if my "check_sender_access inline" is working at all.


Anyone see anything wrong with it or have other suggestions?

smtpd_recipient_restrictions =
    check_client_access inline:{
    { 107.182.131   = REJECT This mail server rejects mail 
from the 107.182.131.0 network }

    }
    check_sender_access inline:{
    { .store    = REJECT This mail server rejects 
messages from the .store domain }
    { .shop = REJECT This mail server rejects 
messages from the .shop domain }
    { .tk   = REJECT This mail server rejects 
messages from the .tk domain }
    { .beauty   = REJECT This mail server rejects 
messages from the .beauty domain }

    }

Example of one that got through:
Feb 16 07:48:41 server2 postfix/smtpd[612125]: connect from 
subjectqualify.shop[31.210.23.54]
Feb 16 07:48:41 server2 postfix/smtpd[612125]: discarding EHLO keywords: 
CHUNKING
Feb 16 07:48:41 server2 postfix/smtpd[612125]: BBC37406EE01: 
client=subjectqualify.shop[31.210.23.54]
Feb 16 07:48:42 server2 postfix/cleanup[612129]: BBC37406EE01: 
message-id=
Feb 16 07:48:42 server2 postfix/qmgr[602363]: BBC37406EE01: 
from=, size=7508, nrcpt=1 (queue 
active)
Feb 16 07:48:51 server2 postfix/relay/smtp[612130]: BBC37406EE01: 
to=, relay=192.168.1.8[192.168.1.8]:25, delay=9.9, 
delays=1/0.02/5.6/3.3, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 
55693E081CFC)

Feb 16 07:48:51 server2 postfix/qmgr[602363]: BBC37406EE01: removed
Feb 16 07:48:57 server2 postfix/smtpd[612125]: disconnect from 
subjectqualify.shop[31.210.23.54] ehlo=1 mail=1 rcpt=1 data=1 quit=1 
commands=5


Thanks

Re: Blocking TLDs

2023-02-08 Thread postfix

dnf -y install postfix-pcre



It was added later, but by then I had already converted to regex.


FYI: I was given the impression that pcre has better performance than regex in 
postfix, if that is something relevant to you.


Re: Blocking TLDs

2023-02-08 Thread mailmary


It was added later, but by then I had already converted to regex.



On Wed, 08 Feb 2023 11:34:49 -0500 post...@ptld.com wrote:

> > Since I'm using AlmaLinux, a derivative of RHEL, it does not have PCRE 
> > because Redhat decided to remove it entirely from RHEL.
> > Thus, I had to convert all my "pcre:" into "regexp:", like the above.  
> 
> 
> I'm using a similar flavor of RHEL and
> 
>  dnf -y install postfix-pcre
> 
> worked for me. Is that package available for Alma?


Re: Blocking TLDs

2023-02-08 Thread James Pifer

On 2/8/2023 1:02 PM, Jaroslaw Rafa wrote:

Dnia  8.02.2023 o godz. 12:55:58 James Pifer pisze:

I would prefer to quarantine rather than reject, if I can figure out
how to do that. I would at least be able to look through them
periodically and see if something is legit.

I suddenly started getting these (.store,.shop, etc) a could days
ago. They are all coming from this block of addresses:
107.182.131.0.

So definitely a better idea is to block these IP addresses.


Good suggestion. I have modified accordingly (I think). ;-)

Thanks


Re: Blocking TLDs

2023-02-08 Thread Jaroslaw Rafa
Dnia  8.02.2023 o godz. 12:55:58 James Pifer pisze:
> I would prefer to quarantine rather than reject, if I can figure out
> how to do that. I would at least be able to look through them
> periodically and see if something is legit.
> 
> I suddenly started getting these (.store,.shop, etc) a could days
> ago. They are all coming from this block of addresses:
> 107.182.131.0.

So definitely a better idea is to block these IP addresses.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."


Re: Blocking TLDs

2023-02-08 Thread James Pifer

On 2/8/2023 12:37 PM, Rob McGee wrote:

On 2/8/2023 3:14 AM, Viktor Dukhovni wrote:

On Wed, Feb 08, 2023 at 10:00:14AM +0200, mailm...@ionos.gr wrote:


/\.top$/ REJECT
/\.xyz$/ REJECT
/\.cam$/ REJECT
/\.fun$/ REJECT
/\.buzz$/ REJECT
/\.club$/ REJECT
/\.link$/ REJECT
/\.hinet\.net$/ REJECT


Why everyone feels they need regular expressions for this is a mystery.

 /etc/postfix/sender-access:
 top REJECT I employ crude anti-spam measures
 .top    REJECT I employ crude anti-spam measuressnip


Very good post as always, but there was a typo. Here's a regexp (!) to 
fix it:


s/crude/crude and ineffective/g

HTH :)

Those of you doing this should refer back to Viktor's previous post. 
This is a bad idea: it won't really do much against spam and could 
easily block non-spam. Again, none of these TLDs employ any tests to 
ensure that registrants are spammers.


Something I have noticed recently: many times the envelope and header 
sender addresses differ. It's an easy way for large-scale hosting 
operations to manage their own DKIM keys. I saw this with Amazon 
Workmail hosting.


Google Workspace hosting always uses the single account name as the 
envelope sender, so when multiple domains are configured in the same 
company account, each user always has the same envelope sender, 
regardless of the header sender.


Here's a rule of thumb: if you think you can do much about spam based 
on sender addresses, whether envelope or header: you're wrong.



I would prefer to quarantine rather than reject, if I can figure out how 
to do that. I would at least be able to look through them periodically 
and see if something is legit.


I suddenly started getting these (.store,.shop, etc) a could days ago. 
They are all coming from this block of addresses: 107.182.131.0.





Re: Blocking TLDs

2023-02-08 Thread Rob McGee

On 2/8/2023 3:14 AM, Viktor Dukhovni wrote:

On Wed, Feb 08, 2023 at 10:00:14AM +0200, mailm...@ionos.gr wrote:


/\.top$/ REJECT
/\.xyz$/ REJECT
/\.cam$/ REJECT
/\.fun$/ REJECT
/\.buzz$/ REJECT
/\.club$/ REJECT
/\.link$/ REJECT
/\.hinet\.net$/ REJECT


Why everyone feels they need regular expressions for this is a mystery.

 /etc/postfix/sender-access:
 top REJECT I employ crude anti-spam measures
 .topREJECT I employ crude anti-spam measuressnip


Very good post as always, but there was a typo. Here's a regexp (!) to 
fix it:


s/crude/crude and ineffective/g

HTH :)

Those of you doing this should refer back to Viktor's previous post. 
This is a bad idea: it won't really do much against spam and could 
easily block non-spam. Again, none of these TLDs employ any tests to 
ensure that registrants are spammers.


Something I have noticed recently: many times the envelope and header 
sender addresses differ. It's an easy way for large-scale hosting 
operations to manage their own DKIM keys. I saw this with Amazon 
Workmail hosting.


Google Workspace hosting always uses the single account name as the 
envelope sender, so when multiple domains are configured in the same 
company account, each user always has the same envelope sender, 
regardless of the header sender.


Here's a rule of thumb: if you think you can do much about spam based on 
sender addresses, whether envelope or header: you're wrong.

--
   http://rob0.nodns4.us/



Re: Blocking TLDs

2023-02-08 Thread postfix

Since I'm using AlmaLinux, a derivative of RHEL, it does not have PCRE because 
Redhat decided to remove it entirely from RHEL.
Thus, I had to convert all my "pcre:" into "regexp:", like the above.



I'm using a similar flavor of RHEL and

dnf -y install postfix-pcre

worked for me. Is that package available for Alma?


Re: Blocking TLDs

2023-02-08 Thread James Pifer

On 2/8/2023 8:32 AM, Wietse Venema wrote:

James Pifer:

The error was:
Feb? 8 07:38:11 mailserver postfix/smtpd[446839]: NOQUEUE: reject: RCPT
from mail-qt1-f179.google.com[209.85.160.179]: 451 4.3.5 Server
configuration error; from=
to= proto=ESMTP helo=

The cause of the problem was logged IMMEDIATELY BEFORE THAT LINE.

Wietse



Yes, looks like you are correct. Looks like a typo. Previous line:

 warning: unknown smtpd restriction: "check_sender_acces"


And for those that asked:

# postconf -m
btree
cidr
environ
fail
hash
inline
internal
memcache
nis
pipemap
proxy
randmap
regexp
socketmap
static
tcp
texthash
unionmap
unix


Re: Blocking TLDs

2023-02-08 Thread natan

Hi
Before add sender-acces works fine ?

Can you send output postconf -m ?

W dniu 8.02.2023 o 14:15, James Pifer pisze:

On 2/8/2023 4:14 AM, Viktor Dukhovni wrote:

On Wed, Feb 08, 2023 at 10:00:14AM +0200, mailm...@ionos.gr wrote:


/\.top$/ REJECT
/\.xyz$/ REJECT
/\.cam$/ REJECT
/\.fun$/ REJECT
/\.buzz$/ REJECT
/\.club$/ REJECT
/\.link$/ REJECT
/\.hinet\.net$/ REJECT

Why everyone feels they need regular expressions for this is a mystery.

 /etc/postfix/sender-access:
 top REJECT I employ crude anti-spam measures
 .top    REJECT I employ crude anti-spam measures
 cam REJECT I employ crude anti-spam measures
 .cam    REJECT I employ crude anti-spam measures
 ...

 main.cf:
 texthash = texthash:${config_directory}/
 smtpd_sender_restrictions =
 check_sender_access ${texthash}sender-access

or directly in main.cf:

 main.cf:
 smtpd_sender_restrictions =
 check_sender_access inline:{
   { top   = REJECT I employ crude anti-spam measures }
   { .top  = REJECT I employ crude anti-spam measures }
   { cam   = REJECT I employ crude anti-spam measures }
   { .cam  = REJECT I employ crude anti-spam measures } }

or an indexed table (with same sender-access file, after "postmap"):

 main.cf:
 # "cdb" is better when available
 default_database_type = hash
 indexed = ${default_database_type}:${config_directory}/
 smtpd_sender_restrictions =
 check_sender_access ${indexed}sender-access

Whatever you choose, regular expressions should last or on your list, or
not at all.  A very small fraction of mortals are capable of using
regular expressions correctly.



Thanks for everyone who has responded. This (directly in main.cf) 
appears to be the answer that works for me and is much simpler.


I tried the suggested regexp before this one and still got the same 
error.


The error was:
Feb  8 07:38:11 mailserver postfix/smtpd[446839]: NOQUEUE: reject: 
RCPT from mail-qt1-f179.google.com[209.85.160.179]: 451 4.3.5 Server 
configuration error; from= 
to= proto=ESMTP helo=


--



Re: Blocking TLDs

2023-02-08 Thread Wietse Venema
James Pifer:
> The error was:
> Feb? 8 07:38:11 mailserver postfix/smtpd[446839]: NOQUEUE: reject: RCPT 
> from mail-qt1-f179.google.com[209.85.160.179]: 451 4.3.5 Server 
> configuration error; from= 
> to= proto=ESMTP helo=

The cause of the problem was logged IMMEDIATELY BEFORE THAT LINE.

Wietse


Re: Blocking TLDs

2023-02-08 Thread James Pifer

On 2/8/2023 4:14 AM, Viktor Dukhovni wrote:

On Wed, Feb 08, 2023 at 10:00:14AM +0200, mailm...@ionos.gr wrote:


/\.top$/ REJECT
/\.xyz$/ REJECT
/\.cam$/ REJECT
/\.fun$/ REJECT
/\.buzz$/ REJECT
/\.club$/ REJECT
/\.link$/ REJECT
/\.hinet\.net$/ REJECT

Why everyone feels they need regular expressions for this is a mystery.

 /etc/postfix/sender-access:
 top REJECT I employ crude anti-spam measures
 .topREJECT I employ crude anti-spam measures
 cam REJECT I employ crude anti-spam measures
 .camREJECT I employ crude anti-spam measures
 ...

 main.cf:
 texthash = texthash:${config_directory}/
 smtpd_sender_restrictions =
 check_sender_access ${texthash}sender-access

or directly in main.cf:

 main.cf:
 smtpd_sender_restrictions =
 check_sender_access inline:{
   { top   = REJECT I employ crude anti-spam measures }
   { .top  = REJECT I employ crude anti-spam measures }
   { cam   = REJECT I employ crude anti-spam measures }
   { .cam  = REJECT I employ crude anti-spam measures } }

or an indexed table (with same sender-access file, after "postmap"):

 main.cf:
 # "cdb" is better when available
 default_database_type = hash
 indexed = ${default_database_type}:${config_directory}/
 smtpd_sender_restrictions =
 check_sender_access ${indexed}sender-access

Whatever you choose, regular expressions should last or on your list, or
not at all.  A very small fraction of mortals are capable of using
regular expressions correctly.



Thanks for everyone who has responded. This (directly in main.cf) 
appears to be the answer that works for me and is much simpler.


I tried the suggested regexp before this one and still got the same error.

The error was:
Feb  8 07:38:11 mailserver postfix/smtpd[446839]: NOQUEUE: reject: RCPT 
from mail-qt1-f179.google.com[209.85.160.179]: 451 4.3.5 Server 
configuration error; from= 
to= proto=ESMTP helo=


Re: Blocking TLDs

2023-02-08 Thread Wietse Venema
mailm...@ionos.gr:
> Here is how I do it:
> 
> check_sender_access regexp:/etc/postfix/sender_domain_checks
> 
> here are the (partial) contents of /etc/postfix/sender_domain_checks:
> 
> /\.top$/ REJECT
> /\.xyz$/ REJECT
> /\.cam$/ REJECT
> /\.fun$/ REJECT
> /\.buzz$/ REJECT
> /\.club$/ REJECT
> /\.link$/ REJECT
> /\.hinet\.net$/ REJECT
> 

Again what is the error message in Postfix logs?

https://www.postfix.org/DEBUG_README.html#logging

Wietse


Re: Blocking TLDs

2023-02-08 Thread Viktor Dukhovni
On Wed, Feb 08, 2023 at 10:00:14AM +0200, mailm...@ionos.gr wrote:

> /\.top$/ REJECT
> /\.xyz$/ REJECT
> /\.cam$/ REJECT
> /\.fun$/ REJECT
> /\.buzz$/ REJECT
> /\.club$/ REJECT
> /\.link$/ REJECT
> /\.hinet\.net$/ REJECT

Why everyone feels they need regular expressions for this is a mystery.

/etc/postfix/sender-access:
top REJECT I employ crude anti-spam measures
.topREJECT I employ crude anti-spam measures
cam REJECT I employ crude anti-spam measures
.camREJECT I employ crude anti-spam measures
...

main.cf:
texthash = texthash:${config_directory}/
smtpd_sender_restrictions =
check_sender_access ${texthash}sender-access

or directly in main.cf:

main.cf:
smtpd_sender_restrictions =
check_sender_access inline:{
  { top   = REJECT I employ crude anti-spam measures }
  { .top  = REJECT I employ crude anti-spam measures }
  { cam   = REJECT I employ crude anti-spam measures }
  { .cam  = REJECT I employ crude anti-spam measures } }

or an indexed table (with same sender-access file, after "postmap"):

main.cf:
# "cdb" is better when available
default_database_type = hash
indexed = ${default_database_type}:${config_directory}/
smtpd_sender_restrictions =
check_sender_access ${indexed}sender-access

Whatever you choose, regular expressions should last or on your list, or
not at all.  A very small fraction of mortals are capable of using
regular expressions correctly.

-- 
Viktor.


Re: Blocking TLDs

2023-02-08 Thread natan

Hi
Please send info like:

postconf -m

Probably you dont have pcre

try postmap -q your_ask pcre:/etc/postfix/reject_domains

W dniu 7.02.2023 o 22:49, James Pifer pisze:
Hello all. I'm trying to block some TLDs and everything I try I'm 
getting:  451 4.3.5 : Sender address rejected: Server 
configuration error;


Obviously this is a configuration issue. I've tried following these 
sites among others:

https://forum.centos-webpanel.com/index.php?topic=10649.0
https://www.davidmartinwhite.com/2016/10/25/fighting-spam-block-entire-ttld-with-postfix/ 


https://www.ericmichaelstone.com/how-to-block-an-entire-tld-in-postfix/

Hoping there's and easy fix in my configuration. Sorry, not a postfix 
expert. If you see any issues in my config I would appreciate 
suggestions.


Thanks


My /etc/postfix/reject_domains looks like:

/\.(pro)$/ REJECT We reject all .pro domains
/\.(date)$/ REJECT We reject all .date domains
/\.(science)$/ REJECT We reject all .science domains
/\.(top)$/ REJECT We reject all .top domains
/\.(download)$/ REJECT We reject all .download domains
/\.(work)$/ REJECT We reject all .work domains
/\.(click)$/ REJECT We reject all .click domains
/\.(link)$/ REJECT We reject all .link domains
/\.(diet)$/ REJECT We reject all .diet domains
/\.(review)$/ REJECT We reject all .review domains
/\.(party)$/ REJECT We reject all .party domains
/\.(zip)$/ REJECT We reject all .zip domains
/\.(xyz)$/ REJECT We reject all .xyz domains
/\.(stream)$/ REJECT We reject all .stream domains
/\.(bid)$/ REJECT We reject all .bid domains
/\.(store)$/ REJECT We reject all .store domains



My /etc/postfix/main.cf

virtual_alias_maps = hash:/etc/postfix/virtual
relay_domains = mydomain.com
relayhost = 192.168.1.188:25
mynetworks = 192.168.188.0/24
recipient_delimiter = +
#debug_peer_list = 0.0.0.0

smtpd_restriction_classes = sender_white_list
sender_white_list = check_client_access 
hash:/etc/postfix/check_client_access


### AS SOON AS I UNCOMMENT THESE TWO LINES I GET THE ERROR ON ALL 
EMAILS##

#smtpd_recipient_restrictions =
#    check_sender_access pcre:/etc/postfix/reject_domains

smtpd_helo_required = yes
smtpd_helo_restrictions =
    permit_mynetworks
    permit_sasl_authenticated
    check_helo_access hash:/etc/postfix/helo_access
    reject_invalid_helo_hostname
    reject_non_fqdn_helo_hostname
#    reject_unknown_helo_hostname   ## Commented out 01/30/2023 
##

#    reject_rhsbl_helo dbl.spamhaus.org,
#    reject_rhsbl_reverse_client dbl.spamhaus.org,
#    reject_rhsbl_sender dbl.spamhaus.org,
#    reject_rbl_client zen.spamhaus.org

smtpd_client_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unknown_sender_domain,
    reject_unknown_reverse_client_hostname,
    reject_unknown_client_hostname,
    #...the rest of them,
    permit


--



Re: Blocking TLDs

2023-02-08 Thread mailmary
Here is how I do it:

check_sender_access regexp:/etc/postfix/sender_domain_checks

here are the (partial) contents of /etc/postfix/sender_domain_checks:

/\.top$/ REJECT
/\.xyz$/ REJECT
/\.cam$/ REJECT
/\.fun$/ REJECT
/\.buzz$/ REJECT
/\.club$/ REJECT
/\.link$/ REJECT
/\.hinet\.net$/ REJECT


Since I'm using AlmaLinux, a derivative of RHEL, it does not have PCRE because 
Redhat decided to remove it entirely from RHEL. Thus, I had to convert all my 
"pcre:" into "regexp:", like the above.



On Tue, 7 Feb 2023 16:49:13 -0500 James Pifer  wrote:

> Hello all. I'm trying to block some TLDs and everything I try I'm 
> getting:  451 4.3.5 : Sender address rejected: Server 
> configuration error;
> 
> Obviously this is a configuration issue. I've tried following these 
> sites among others:
> https://forum.centos-webpanel.com/index.php?topic=10649.0
> https://www.davidmartinwhite.com/2016/10/25/fighting-spam-block-entire-ttld-with-postfix/
> https://www.ericmichaelstone.com/how-to-block-an-entire-tld-in-postfix/
> 
> Hoping there's and easy fix in my configuration. Sorry, not a postfix 
> expert. If you see any issues in my config I would appreciate suggestions.
> 
> Thanks
> 
> 
> My /etc/postfix/reject_domains looks like:
> 
> /\.(pro)$/ REJECT We reject all .pro domains
> /\.(date)$/ REJECT We reject all .date domains
> /\.(science)$/ REJECT We reject all .science domains
> /\.(top)$/ REJECT We reject all .top domains
> /\.(download)$/ REJECT We reject all .download domains
> /\.(work)$/ REJECT We reject all .work domains
> /\.(click)$/ REJECT We reject all .click domains
> /\.(link)$/ REJECT We reject all .link domains
> /\.(diet)$/ REJECT We reject all .diet domains
> /\.(review)$/ REJECT We reject all .review domains
> /\.(party)$/ REJECT We reject all .party domains
> /\.(zip)$/ REJECT We reject all .zip domains
> /\.(xyz)$/ REJECT We reject all .xyz domains
> /\.(stream)$/ REJECT We reject all .stream domains
> /\.(bid)$/ REJECT We reject all .bid domains
> /\.(store)$/ REJECT We reject all .store domains
> 
> 
> 
> My /etc/postfix/main.cf
> 
> virtual_alias_maps = hash:/etc/postfix/virtual
> relay_domains = mydomain.com
> relayhost = 192.168.1.188:25
> mynetworks = 192.168.188.0/24
> recipient_delimiter = +
> #debug_peer_list = 0.0.0.0
> 
> smtpd_restriction_classes = sender_white_list
> sender_white_list = check_client_access 
> hash:/etc/postfix/check_client_access
> 
> ### AS SOON AS I UNCOMMENT THESE TWO LINES I GET THE ERROR ON ALL 
> EMAILS##
> #smtpd_recipient_restrictions =
> #    check_sender_access pcre:/etc/postfix/reject_domains
> 
> smtpd_helo_required = yes
> smtpd_helo_restrictions =
>      permit_mynetworks
>      permit_sasl_authenticated
>      check_helo_access hash:/etc/postfix/helo_access
>      reject_invalid_helo_hostname
>      reject_non_fqdn_helo_hostname
> #    reject_unknown_helo_hostname   ## Commented out 01/30/2023 ##
> #    reject_rhsbl_helo dbl.spamhaus.org,
> #    reject_rhsbl_reverse_client dbl.spamhaus.org,
> #    reject_rhsbl_sender dbl.spamhaus.org,
> #    reject_rbl_client zen.spamhaus.org
> 
> smtpd_client_restrictions =
>      permit_mynetworks,
>      permit_sasl_authenticated,
>      reject_unknown_sender_domain,
>      reject_unknown_reverse_client_hostname,
>      reject_unknown_client_hostname,
>      #...the rest of them,
>      permit


Re: Blocking TLDs

2023-02-07 Thread Viktor Dukhovni
On Tue, Feb 07, 2023 at 04:02:13PM -0600, Noel Jones wrote:

> > Hello all. I'm trying to block some TLDs and everything I try I'm 
> > getting:  451 4.3.5 : Sender address rejected: 
> > Server configuration error;
> > 
> 
> What is the error message logged before that?
> 
> Does your postfix support the pcre map type?  Maybe try regex: instead
> of pcre:
> 
> postconf -m will show supported map types.

Those are the right questions, but perhaps the OP should consider the
errors fortuitous, and forgo blocking by TLD.  Few if any TLDs consist
entirely of abusive domains.

For example, ".xyz" is probably a poor choice to block (as are the rest
to various extents).  Focus on client IP reputation and message content.

-- 
Viktor.


Re: Blocking TLDs

2023-02-07 Thread Noel Jones

On 2/7/2023 3:49 PM, James Pifer wrote:
Hello all. I'm trying to block some TLDs and everything I try I'm 
getting:  451 4.3.5 : Sender address rejected: 
Server configuration error;




What is the error message logged before that?

Does your postfix support the pcre map type?
Maybe try regex: instead of pcre:

postconf -m will show supported map types.


  -- Noel Jones


Re: Blocking TLDs with check_sender_access

2018-06-26 Thread Viktor Dukhovni



> On Jun 26, 2018, at 1:15 PM, @lbutlr  wrote:
> 
>> No, it works substantially better in check_sender_access, and very poorly
>> in header_checks.
> 
> It works very well for me, and has for years.

The regular expressions you posted are fragile, subject to easy false
posititves and should not be used by anyone else.  If this happens to
have worked for you so far, enjoy, but this is not suitable for general
use.

-- 
Viktor.



Re: Blocking TLDs with check_sender_access

2018-06-26 Thread @lbutlr
On Jun 26, 2018, at 09:10, Viktor Dukhovni  wrote:
> No, it works substantially better in check_sender_access, and very poorly
> in header_checks.

It works very well for me, and has for years.

-- 
This is my signature. There are many like it, but this one is mine.




Re: Blocking TLDs with check_sender_access

2018-06-26 Thread Viktor Dukhovni



> On Jun 26, 2018, at 6:07 AM, @lbutlr  wrote:
> 
> I use header checks:
> 
> /.*\.example.top/ DUNNO
> /.*\.FriendwithJokeDoamin.xxx/ OK
> /.*\.(com|net|org|edu|gov|ca|mx|de|dk|fi|uk|us|tv|info|biz|eu|es|il|it|nl|name|jp|host|au|nz)$/
>  DUNNO
> /.*\.*/ 550 Mail to or from this TLD is not allowed
> 
> But this should basically work much the same in check_sender_access

No, it works substantially better in check_sender_access, and very poorly
in header_checks.  DO NOT use header checks for sender address blacklists.

-- 
Viktor.



Re: Blocking TLDs with check_sender_access

2018-06-26 Thread @lbutlr
On 25 Jun 2018, at 14:45, Alex  wrote:
> I have a check_sender_access restriction that blocks many TLDs like
> .red and .space. Problem is that we have one legitimate .red customer
> (what was he thinking?) that needs to send us mail. How can I allow
> this single domain?

I use header checks:

/.*\.example.top/ DUNNO
/.*\.FriendwithJokeDoamin.xxx/ OK
/.*\.(com|net|org|edu|gov|ca|mx|de|dk|fi|uk|us|tv|info|biz|eu|es|il|it|nl|name|jp|host|au|nz)$/
 DUNNO
/.*\.*/ 550 Mail to or from this TLD is not allowed

But this should basically work much the same in check_sender_access

red  500 This TLD sends spam
good.red DUNNO

-- 
A bartender is just a pharmacist with a limited inventory.




Re: Blocking TLDs with check_sender_access

2018-06-25 Thread Wietse Venema
Alex:
> HI,
> 
> I have a check_sender_access restriction that blocks many TLDs like
> .red and .space. Problem is that we have one legitimate .red customer
> (what was he thinking?) that needs to send us mail. How can I allow
> this single domain?
> 
> smtpd_sender_restrictions =
> permit_mynetworks,
> check_sender_access hash:/etc/postfix/sender_checks,
> check_sender_access pcre:/etc/postfix/sender_checks.pcre,
> check_sender_access hash:/etc/postfix/spamsources,
> check_sender_ns_access hash:/etc/postfix/blacklist_ns.cf,
> reject_unknown_sender_domain
> 
> /etc/postfix/spamsources contains lines like:
> 
> red 500 This TLD sends spam
> pw  500 This TLD sends spam
> trade   500 This TLD sends spam
> party   500 This TLD sends spam
> 
> I see that it's legitimately blocking this domain, but when I use
> postmap to test, it fails:
> 
> # postmap -q a...@sub.red hash:/etc/postfix/spamsources
> #
> 
> I would have expected "This TLD sends spam". I've tried adding the
> following at the top of the file then recreating the hash db, but
> testing doesn't seem to work:

Postmap command does not know that this is an access map. Until
it does, you need to manually make the queries described in the
"man 5 access": the queries are sub.red then red.

To exclude sub.red::

red 500 This TLD sends spam
sub.red DUNNO
pw  500 This TLD sends spam
trade   500 This TLD sends spam
party   500 This TLD sends spam

The result does not have to be upper case.

Wietse


RE: Blocking TLDs

2016-02-25 Thread Wolfe , Robert
Thank you for the points.  They are all well taken and filed away for future 
reference :)  

Yes, this is my own personal email server.  I run postfix with amavisd and all 
the good stuff that is installed when one installs the iRedMail package :)

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of pe...@ixp.jp
Sent: Thursday, February 25, 2016 12:38 AM
To: postfix-users@postfix.org
Subject: Re: Blocking TLDs

On Feb/19.15:36:11, Wolfe, Robert wrote:
> I get a LOT of emails from domains that have *.download and *.xyz and 
> their TLDs and I was wondering if there was a way in Postfix that I 
> could block emails that are coming in from these (and other) TLDs at 
> the connection level?

I'm actually a fan of using the DBL for domains of evil. (well, I've 
been using 
spamhaus stuff for a decade or more now.)


While you can take the "your village sucks and all the people in it 
too."
approach of rejecting *.TLD, you miss out on some juicy data points.

If this is just your personal server, well and good. I'd block ".ru" on 
principle,
but that is just me. Although checking suggests rambler.ru is enough to 
get rid of
all my phish.

If you have other users, you can bet your booties that someone wants to 
get mail
from happythrobbingelephants.diet or something stupid like that.

https://plus.google.com/+BunnyEvans/posts/8yHH1Mhcj8A

We see that .DOWNLOAD, .CLICK and .REVIEW are actually deserving of the 
bit bucket,
the others are less clearcut.

postscreen also does a rocking good job of keeping out the chaff.

P
 



Re: Blocking TLDs

2016-02-21 Thread Ansgar Wiechers
On 2016-02-20 Sebastian Nielsen wrote:
> 1: REJECT tells the spammer "Hey, your spam got stuck in the spam
> filter. Wanna try again?". Better to DISCARD it so the spammer think
> they got the spam through, then they won't switch to a new domain.
> 
> I don't think anyone ever will receive legitimate mail from any of
> those spammy TLDs listed in the rules file I gave.

You're sorely mistaken about this.

a) Spammers don't care if their crap gets rejected. At all. They will
   fire at anything that looks even remotely like an e-mail address.
   Every day I see multiple delivery attempts to mail addresses that
   have been disabled for years, to addresses with truncated localparts
   that have never worked in the first place, and even to message IDs.
   Message IDs!

b) Just because spammers are early adopters (not only when it comes to
   new domains) doesn't mean nobody will ever use those domains for
   legitimate purposes. For instance, Google's new holding Alfabet uses
   the domain abc.xyz. Blocking entire TLDs is throwing the baby out
   with the bath water.

c) Discarding mail may subject you to legal repercussions, depending on
   where you're located and whose mail you're handling.

Regards
Ansgar Wiechers
-- 
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky


Re: Blocking TLDs

2016-02-19 Thread yahoogroups
Actually I have a xyz domain that mirrors my com domain. I use it for test 
purposes. 

Sent from my BlackBerry 10 smartphone.
  Original Message  
From: Sebastian Nielsen
Sent: Friday, February 19, 2016 3:53 PM
To: postfix-users@postfix.org
Subject: SV: SV: Blocking TLDs

1: REJECT tells the spammer "Hey, your spam got stuck in the spam filter. Wanna 
try again?".
Better to DISCARD it so the spammer think they got the spam through, then they 
won't switch to a new domain.

I don't think anyone ever will receive legitimate mail from any of those spammy 
TLDs listed in the rules file I gave.

2: Its just a habit, everytime some process complains of not able to access a 
file, "666" is the universal solution. Of course, this isn't recommended in a 
web hosting setup, but if you're hosting for example a mail server for a 
company, and only you as a sysadmin has shell access to the server, its no 
danger 666'ing files that throw permission errors. Then the file isn't really 
"world writable", since only you have a account on the server anyways.

-Ursprungligt meddelande-
Från: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
För A. Schulze
Skickat: den 19 februari 2016 23:52
Till: postfix-users@postfix.org
Ämne: Re: SV: Blocking TLDs


Sebastian Nielsen:

> Then paste all the DISCARD lines into a new file called 
> /etc/postfix/banned_tlds (and also add some own TLDs there, its just 
> to copy paste one line and then change the TLD), and also remove lines 
> for TLDs you don’t want to block.
>
> Chmod the banned_tlds file to 666 to ensure the postfix process can read it.

two annotations:
- I would not suggest DISCARD but REJECT
- mode 666 (world writable) is generally not needed. 644 is enough

Andreas

>
>
>
>
> Then do “service postfix restart”
>
> Then you should be all set.
>
>
>
> Test the permission by sending a email using a spoofed address in your 
> email software, to yourself. The mail will always be successfully sent, but:
>
> If all goes well, you should see in the logs that “DISCARD” action was 
> triggered, which means the mail will be tossed in the dustbin without 
> delivering it to you.
>
> Remember to return your email client to non-spoofed state after that, 
> for obvious reasons.
>
>
>
> Från: Wolfe, Robert [mailto:robert.wo...@robertwolfe.org]
> Skickat: den 19 februari 2016 23:19
> Till: 'Sebastian Nielsen' ; 
> postfix-users@postfix.org
> Ämne: RE: Blocking TLDs
>
>
>
> Just copy and passed the DISCARD contents into banned_tlds?
>
>
>
> From: owner-postfix-us...@postfix.org
> <mailto:owner-postfix-us...@postfix.org>
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian 
> Nielsen
> Sent: Friday, February 19, 2016 3:50 PM
> To: postfix-users@postfix.org <mailto:postfix-users@postfix.org>
> Subject: SV: Blocking TLDs
>
>
>
> smtpd_sender_restrictions = check_sender_access 
> pcre:/etc/postfix/banned_tlds
>
>
>
> banned_tlds:
>
> /\.bid$/ DISCARD
>
> /\.top$/ DISCARD
>
> /\.xyz$/ DISCARD
>
> /\.date$/ DISCARD
>
> /\.faith$/ DISCARD
>
> /\.download$/ DISCARD
>
>
>
>
>
> Problem solved.
>
>
>
>
>
> Från: owner-postfix-us...@postfix.org
> <mailto:owner-postfix-us...@postfix.org>
> [mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
> Skickat: den 19 februari 2016 22:36
> Till: postfix-users@postfix.org <mailto:postfix-users@postfix.org>
> Ämne: Blocking TLDs
>
>
>
> Greetings all!
>
>
>
> This is actually my first posting to the mailing list, but have 
> actually been following along on a regular basis and have learned 
> quite a bit of good things (and bad things *smiles*) about Postfix. 
> Unfortunately, I have one question that I am hoping someone here on the 
> mailing list can answer.
>
>
>
> I get a LOT of emails from domains that have *.download and *.xyz and 
> their TLDs and I was wondering if there was a way in Postfix that I 
> could block emails that are coming in from these (and other) TLDs at 
> the connection level?






RE: Blocking TLDs

2016-02-19 Thread Wolfe, Robert
Just copy and passed the DISCARD contents into banned_tlds?

 

From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Sebastian Nielsen
Sent: Friday, February 19, 2016 3:50 PM
To: postfix-users@postfix.org
Subject: SV: Blocking TLDs

 

smtpd_sender_restrictions = check_sender_access
pcre:/etc/postfix/banned_tlds

 

banned_tlds:

/\.bid$/ DISCARD

/\.top$/ DISCARD

/\.xyz$/ DISCARD

/\.date$/ DISCARD

/\.faith$/ DISCARD

/\.download$/ DISCARD

 

 

Problem solved.

 

 

Från: owner-postfix-us...@postfix.org

[mailto:owner-postfix-us...@postfix.org] För Wolfe, Robert
Skickat: den 19 februari 2016 22:36
Till: postfix-users@postfix.org  
Ämne: Blocking TLDs

 

Greetings all!

 

This is actually my first posting to the mailing list, but have actually
been following along on a regular basis and have learned quite a bit of good
things (and bad things *smiles*) about Postfix.  Unfortunately, I have one
question that I am hoping someone here on the mailing list can answer.

 

I get a LOT of emails from domains that have *.download and *.xyz and their
TLDs and I was wondering if there was a way in Postfix that I could block
emails that are coming in from these (and other) TLDs at the connection
level?