Blocking TLD (one component access list queries)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Blocking TLD (one component access list queries)

Hadmut
Hi,

I'm getting tons of spam with mail senders or helo names from TLDs like
.date, e.g.


Received: from koan-shf.date (unknown [78.129.179.127]) by...


where the domain names (here: koan-shf.date) rapidly change and are
obviously randomly generated. IP addresses also change daily.


I'd therefore like to block TLDs like .date or .loan, which currently
does not work with postfix. Following it's manpage 5 access, the block
lists for mails and sender machines need at least  .domain.tld, i.e. two
domain components.

This made sense as long as we had country code and the old generic TLDs
like com and gov, but not anymore since ICANN allowed any nonsense to be
registered as a TLD.


I'd like to propose to allow  one component queries for mail addresses
and hostnames in access lists as well. 



regards

Hadmut




Reply | Threaded
Open this post in threaded view
|

Re: Blocking TLD (one component access list queries)

Wietse Venema
Hadmut Danisch:

> Hi,
>
> I'm getting tons of spam with mail senders or helo names from TLDs like
> .date, e.g.
>
> Received: from koan-shf.date (unknown [78.129.179.127]) by...
>
> where the domain names (here: koan-shf.date) rapidly change and are
> obviously randomly generated. IP addresses also change daily.
>
> I'd therefore like to block TLDs like .date or .loan, which currently
> does not work with postfix. Following it's manpage 5 access, the
> block lists for mails and sender machines need at least? .domain.tld,
> i.e. two domain components.

I don't know if that restriction still exists, but you can match
arbitrary names with with PCRE tables.

/etc/postfix.main.cf:
    smtpd_helo_restrictions = pcre:/etc/postfix/tld_access.pcre

/etc/postfix/tld_access.pcre:
    /\.date$/  reject no dates here
    /\.loan$/  reject no loans here

> This made sense as long as we had country code and the old generic TLDs
> like com and gov, but not anymore since ICANN allowed any nonsense to be
> registered as a TLD.
>
>
> I'd like to propose to allow? one component queries for mail addresses
> and hostnames in access lists as well.?
>
>
>
> regards
>
> Hadmut
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Blocking TLD (one component access list queries)

Juri Haberland
In reply to this post by Hadmut
On 10.12.2017 17:03, Hadmut Danisch wrote:

> I'm getting tons of spam with mail senders or helo names from TLDs like
> .date, e.g.

> where the domain names (here: koan-shf.date) rapidly change and are
> obviously randomly generated. IP addresses also change daily.

> I'd therefore like to block TLDs like .date or .loan, which currently
> does not work with postfix. Following it's manpage 5 access, the block
> lists for mails and sender machines need at least  .domain.tld, i.e. two
> domain components.

The following works for me (with 2.11.x and 3.1.x):

/etc/postfix.main.cf:
    smtpd_recipient_restrictions =
        [...]
        check_sender_access pcre:/etc/postfix/sender_access.pcre
        [...]

/etc/postfix/sender_access.pcre:
    /\.bid$/                554 Mail from .bid is currently not accepted
    /\.click$/              554 Mail from .click is currently not accepted
    /\.link$/               554 Mail from .link is currently not accepted


Cheers,
  Juri
Reply | Threaded
Open this post in threaded view
|

Re: Blocking TLD (one component access list queries)

@lbutlr
In reply to this post by Hadmut
I set a list of good Todd that I accept mail from and reject all the others, which has worked out well as the spammer scum keep migrating through the myriad of new TLDs.

Basically I allow the main tlds and some specific country ones and that’s it. Everyone else gets a message that mail from that top level domain is not allowed.

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

> On Dec 10, 2017, at 09:03, Hadmut Danisch <[hidden email]> wrote:
>
> I'd therefore like to block TLDs like .date or .loan, which currently
> does not work with postfix. Following it's manpage 5 access, the block
> lists for mails and sender machines need at least  .domain.tld, i.e. two
> domain components.

Reply | Threaded
Open this post in threaded view
|

Re: Blocking TLD (one component access list queries)

anvartay
In reply to this post by Hadmut
If IP address and domain names continuously changes they are probably fake domain names and emails sent by randomly exploited servers.
Following additions to configuration might help:

smtpd_sender_restrictions =
        [...],
        reject_invalid_hostname,
        reject_unauth_pipelining,
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
        reject_non_fqdn_recipient,
        reject_unknown_recipient_domain,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client sbl.spamhaus.org,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client dul.dnsbl.sorbs.net,
        [...]

smtpd_recipient_restrictions =
        [...],
        reject_invalid_hostname,
        reject_unauth_pipelining,
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
        reject_non_fqdn_recipient,
        reject_unknown_recipient_domain,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client sbl.spamhaus.org,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client dul.dnsbl.sorbs.net,
        [...]

Anvar Kuchkartaev
[hidden email]


 ---- On Sun, 10 Dec 2017 17:03:18 +0100 Hadmut Danisch <[hidden email]> wrote ----
 > Hi,
 >  
 > I'm getting tons of spam with mail senders or helo names from TLDs like
 > .date, e.g.
 >  
 >  
 > Received: from koan-shf.date (unknown [78.129.179.127]) by...
 >  
 >  
 > where the domain names (here: koan-shf.date) rapidly change and are
 > obviously randomly generated. IP addresses also change daily.
 >  
 >  
 > I'd therefore like to block TLDs like .date or .loan, which currently
 > does not work with postfix. Following it's manpage 5 access, the block
 > lists for mails and sender machines need at least  .domain.tld, i.e. two
 > domain components.
 >  
 > This made sense as long as we had country code and the old generic TLDs
 > like com and gov, but not anymore since ICANN allowed any nonsense to be
 > registered as a TLD.
 >  
 >  
 > I'd like to propose to allow  one component queries for mail addresses
 > and hostnames in access lists as well.  
 >  
 >  
 >  
 > regards
 >  
 > Hadmut
 >  
 >  
 >  
 >  
 >


Reply | Threaded
Open this post in threaded view
|

Re: Blocking TLD (one component access list queries)

Hadmut


On 12.12.2017 09:00, Anvar Kuchkartaev wrote:
> If IP address and domain names continuously changes they are probably fake domain names and emails sent by randomly exploited servers.

No, not that way. That's what I used to see 5 or 10 years ago as the
main source of spam.

Nowadays I find most of the spam originating from cloud services / cheap
hosters, where they rent machines for short times, sometimes just hours.
Continuously changing doesn't mean completely random in this context.
Most of the time changing within the address range of a hoster, and
changing the hoster after one or a few days.

However, I find a significant number of helo names like

armbe-the.date                                                                     2

armos-sty.date                                                                     2

axum-obl.date                                                                      2

clay-sod.date                                                                      2

coke-fsa.date                                                                      2

erkoe-war.date                                                                     2

hrist-soc.date                                                                     2

irgot-hkj.date                                                                     2

lirne-hew.date                                                                     2

nerc-jus.date                                                                      2

orlds-kim.date                                                                     2

pike-com.date                                                                      2

rlade-woo.date                                                                     2

treau-eld.date                                                                     2




Sure, PCRE are possible, but I tend to avoid them, since RE are
expensive, and changing needs (afaik) a full reload of postfix, while a
mod to a database file is easier (although I agree that a RE might still
be faster than a database file lookup).

regards

Reply | Threaded
Open this post in threaded view
|

Re: Blocking TLD (one component access list queries)

Noel Jones-2
On 12/14/2017 4:00 AM, Hadmut Danisch wrote:
> Sure, PCRE are possible, but I tend to avoid them, since RE are
> expensive, and changing needs (afaik) a full reload of postfix, while a
> mod to a database file is easier (although I agree that a RE might still
> be faster than a database file lookup).

The expense for PCRE is not significant for relatively small tables,
probably up to low thousands of elements.

As for changes, they will be picked up after either $max_use or
$max_idle, which usually go by pretty quickly.

Or use this cheap trick -- after you change a pcre table, rebuild
some hash table to reload all the changes.



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: Blocking TLD (one component access list queries)

Viktor Dukhovni
In reply to this post by Hadmut


> On Dec 14, 2017, at 5:00 AM, Hadmut Danisch <[hidden email]> wrote:
>
> Sure, PCRE are possible, but I tend to avoid them, since RE are
> expensive, and changing needs (afaik) a full reload of postfix, while a
> mod to a database file is easier (although I agree that a RE might still
> be faster than a database file lookup).

Note that each smtpd(8) process loads a fresh copy of RE tables on startup.
If you reduce max_idle to say 5s, and assume that connection re-use is not
a major factor, then the tables are typically much less than 500s stale.
That should be good enough for most cases, and not require a reload.

You can also add an empty indexed table for some restriction class that's
never used, but causes smtpd(8) to restart at the end of an SMTP session
if the table has been updated.

   main.cf:
        indexed = ${default_database_type}:${config_directory}/
        smtpd_restriction_classes = ... restart
        restart = check_client_access ${indexed}restart

   restart:
        # Empty table, touch the "compiled" hash,btree,cdb or lmdb
        # database file to expedite restart of smtpd(8) processes.

--
        Viktor.