Configure Postfix to reject emails from Spam domains.

carltonfsck

carltonfsck

Greetings,

I am currently using Postfix for my MTA (Mail Transfer Agent) on FreeBSD 12.4-RELEASE-p1. Occasionally, I'll receive emails from SPAM domains. I have spam blocklists in place. I'm also using the port 'pyspf-milter' for SPF filtering. However, these domains are allowed to get through because the domain's SPF passes the pyspf-milter check. I read on another forum where you can use Postfix to essentially block Spam mail domains. The steps are outlined below...


Add the following to Postfix main.cf:

smtpd_sender_restrictions = hash:/etc/postfix/access
reject_unauth_destination = hash:/etc/postfix/access


Add the Spam domains to /etc/postfix/access (example domain names used below):

aol.com REJECT
yahoo.com REJECT
msn.com REJECT


Run the following command after adding the domains above...

# postmap hash:/etc/mail/access


Then restarted Postfix.

# service postfix restart

It's said that this will prevent the offending domains from sending you mail to your host and will also prevent your users from sending mail to those domains specified. Unfortunately, this is not working as the Spam emails are still getting through. What am I missing here? Has anyone had any success with configuring this? Any suggestions are welcomed.
There aren't really any guides available online.

Thank You in advance for your help!


--Cf
 
The fact that the emails are still coming through, and apparently pass SPF suggests that - while the "From" text in the email itself says yahoo/msn - this more than likely isn't the address they are providing as the envelope sender during SMTP.

What do the postfix logs show for one of these emails? You should have from/to lines in the log for the relevant email that show the addresses provided during SMTP transport.

Generally speaking, SMTP servers don't care what is actually in the email (including the headers that contain the sender name/address your mail client shows) any more than real post offices care what names/addresses are written on a letter inside an envelope.

Unfortunately as is usually the case with spam, you'll probably end up chasing your own tail as the sender addresses used will be pretty much anything they can get away with using and will likely change constantly. Often it will be the domain of whatever open mail server or flawed website they are sending via as that is more than likely going to allow them to pass SPF and look more legitimate.

Postfix does have a header checks feature which allows scanning the actual headers of an email. I've used this a couple of times in the past to try and stop particularly regular spam. More often than not spam is so randomised that blocking specific senders/words/phrases is futile. You may also note than one of my matches below is base64, because they are using the fact that mail clients will happily accept base64 encoded data to try and avoid spam filters.

/usr/local/etc/postfix/main.cf
Code: 
header_checks = pcre:$config_directory/header-checks

/usr/local/etc/postfix/header-checks
Code: 
/^Subject:.*g!rl/ REJECT message content rejected - g!rl in subject
/^From:.*S2lhIEdyb3VwIC0gTXIgQWxsZW4=/ REJECT constant Kia Group spam

It's also worth looking at rspamd which is fairly easy to get working with postfix and will handle spf/dkim/blacklists/virus checking and provides a decent interface to show what score it's given each email and the various filtered that have been triggered. It's not perfect but probably the best I've found short of signing up for paid scanning services or hardware.
 
Just to add, it looks like your sender_restrictions entry in postfix config is probably wrong. This is supposed to be a list of restrictions, some of which may take a file as an argument. For example, my client_restrictions (different setting but same format) looks a bit like this -

Code: 
smtpd_client_restrictions = permit_mynetworks,
        check_client_access hash:$config_directory/access,
        reject_non_fqdn_helo_hostname,
        reject_unknown_reverse_client_hostname
        reject_unknown_sender_domain

This is allowing my local networks regardless, rejecting a bunch of common issues for badly configured clients, and also allowing me to manually block clients via the access file - or accept them and bypass the rest of the checks which is why it's second - I can accept badly configured clients that would hit the last 3 restrictions by manually whitelisting them via the second restriction.

Your sender_restrictions should probably be something like -

Code: 
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access
 
i just put this in my sendmail.cf and get no spam
O SmtpGreetingMessage=$j of Borg. You will be assimilated; $b
/s
 
I use greylisting and blocklists to do this very effectively. Greylisting delays mail from unknown sources for around 30 minutes by rejecting it temporarily and setting a timer. A legitimate sending MTA will repeat attempts to deliver it at decreasing intervals. A spambot probably won't bother. 30 minutes is plenty of time for a honey trap address to report it to a blocklist so even if the spambot does try again that second technique will reject it permanently.

Install milter-greylist and set up the milter options in main.cf to use it. I have:
Code: 
# milter options
milter_default_action = tempfail
milter_connect_macros = j
milter_protocol = 6
smtpd_milters = unix:/var/milter-greylist/milter-greylist.sock

Add blocklisting to main.cf:
Code: 
# Recipient restrictions
smtpd_recipient_restrictions =
        check_sender_access hash:/usr/local/etc/postfix/access,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client b.barracudacentral.org,
        reject_rbl_client dnsbl-1.uceprotect.net,
        permit

If you want to be really draconian there is also:
Code: 
reject_rbl_client dnsbl.sorbs.net

but that will reject gmail and hotmail servers etc if someone sneaks spam through them, which will also block lots of legitimate mail. The sorbs maintainers would doubtless argue google and hotmail (and their customers) should not be exempt from the need to block spammers, which is a fair enough point, but it's a bit of a collective punishment in practice.
 
I personally found that greylisting caused too many problems. There are many situations where people are expecting an email such as signing up to a website or waiting for an email whilst talking to the sender on the phone, and the delay just caused issues.

There's a couple of blacklists I don't mind using such as spamhaus, but generally I really do recommend rspamd as it not only performs numerous useful checks (spf/dkim/url&ip blacklists/realtime spam fingerprints/etc), but scores the messages to allow/add header/reject rather than taking a sledgehammer to it and either blocking entire domains or greylisting everyone.
 
I also use greylisting (spamd), but do field the occasional complaint about delayed sign-in emails, etc. from my very small user base.

I've tried DNS blacklists in the past and found that they always either block too much or too little.

It does seem like the world is moving towards Rspamd, though. It's on my todo list.
 
It seems common these days that Postfix users dealing with significant amounts of spam use postscreen to reject most of it. It's very lightweight and has its own scoring system.
 
Jose said:
It does seem like the world is moving towards Rspamd, though.
Click to expand...

I'm not sure it's entirely justified. People claim that it's faster than SpamAssassin because it's written in C - it's really because it has a small default set of tests and because it's multi-threaded. The latter advantage disappears when real world servers scan emails in parallel.

The main developer of Rspamd claimed it was much faster than SpamAssassin on its own rule set. This benchmark was much quoted, but to get that result he serialized the scans, preventing SpamAssassin from using more than one core. On paper SpamAssassin could well have better performance on a large ruleset because of its fully compiled regexes.
 
bob2112 said:
Postfix users dealing with significant amounts of spam use postscreen
Click to expand...
Agree, I use postscreen with zen.spamhaus.org for DNSBL. This catches about 95% of the spammers.

Code: 
postscreen_cache_map = btree:/var/db/postfix/postscreen_cache
postscreen_disable_vrfy_command = yes
postscreen_greet_action = enforce
postscreen_access_list =
        permit_mynetworks,
        cidr:/usr/local/etc/postfix/cal_cidr
postscreen_denylist_action = enforce
postscreen_dnsbl_allowlist_threshold = -1
postscreen_dnsbl_sites = zen.spamhaus.org*2
postscreen_dnsbl_action = enforce
postscreen_dnsbl_threshold = 2

However, I also use fail2ban with openbgpd to update a pf table on the firewall - to silence repeat offenders and brute-forcers.
 
You must log in or register to reply here.
Back
Top