Hi,
I'm currently fine-tuning my mail server (Postfix and Dovecot on CentOS 7).
SPF, DKIM and DMARC work fine, now I'd like to limit the spam tsunami.
Besides the official Postfix documentation, I've read a few articles about Postfix spam restrictions, namely these :
https://www.linuxbabe.com/mail-server/block-email-spam-postfix
https://wiki.centos.org/HowTos/postfix_restrictions
After some experimenting, here's what I currently have on my test server:
--8<----- /etc/postfix/main.cf ----------------------------- ... 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 smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/sender_access, reject_unknown_sender_domain, reject_unknown_reverse_client_hostname, reject_unknown_client_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/rbl_override, 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 --8<--------------------------------------------------------
Before committing this configuration to my main server, I thought I'd share this configuration on the list. Maybe the Postfix gurus among you have the odd comment to make.
My aim is simply to eliminate as much spam as possible (that is, before adding SpamAssassin) while keeping false positives to a minimum.
Any suggestions ?
Niki
On Sun, Jun 7, 2020, 2:47 AM Nicolas Kovacs info@microlinux.fr wrote:
.... My aim is simply to eliminate as much spam as possible (that is, before adding SpamAssassin) while keeping false positives to a minimum.
The one thing that stopped the most spam on my last mailserver was greylisting. Any mta that connects to you to send you mail, you check against a white list, and if they are not on it, you reject the connection with a 'try again later' code and add them to a grey list that will let them in after 10 minutes or so. The vast majority of spambots don't queue up retries, they just move on to the next target.
The downside of greylisting is delayed delivery of mail from non white listed servers, dependent on their retry cycle.
I finally gave up on running my own email services and use Gmail which has excellent spam filtering
On Sun, Jun 07, 2020 at 05:53:28AM -0700, John Pierce wrote:
On Sun, Jun 7, 2020, 2:47 AM Nicolas Kovacs info@microlinux.fr wrote:
.... My aim is simply to eliminate as much spam as possible (that is, before adding SpamAssassin) while keeping false positives to a minimum.
The one thing that stopped the most spam on my last mailserver was greylisting. Any mta that connects to you to send you mail, you check against a white list, and if they are not on it, you reject the connection with a 'try again later' code and add them to a grey list that will let them in after 10 minutes or so. The vast majority of spambots don't queue up retries, they just move on to the next target.
The downside of greylisting is delayed delivery of mail from non white listed servers, dependent on their retry cycle.
I hit another limitation. My backup MX handler is a 3rd party who will not use greylisting. Thus all the 1st timers I rejected just delivered to my alternate MX address and were not blocked at all.
Jon
yeah, then don't use a backup MX server at all. I dropped using one when I realized most spam prevention would just end up at the backup which didn't have the same rules
as long as your server has a decent uptime and is never down more than a few hours and that very rarely, then you really don't need a backup server at all.
On Mon, Jun 8, 2020 at 7:57 PM Jon LaBadie jcu@labadie.us wrote:
On Sun, Jun 07, 2020 at 05:53:28AM -0700, John Pierce wrote:
On Sun, Jun 7, 2020, 2:47 AM Nicolas Kovacs info@microlinux.fr wrote:
.... My aim is simply to eliminate as much spam as possible (that is, before adding SpamAssassin) while keeping false positives to a minimum.
The one thing that stopped the most spam on my last mailserver was greylisting. Any mta that connects to you to send you mail, you check against a white list, and if they are not on it, you reject the
connection
with a 'try again later' code and add them to a grey list that will let them in after 10 minutes or so. The vast majority of spambots don't
queue
up retries, they just move on to the next target.
The downside of greylisting is delayed delivery of mail from non white listed servers, dependent on their retry cycle.
I hit another limitation. My backup MX handler is a 3rd party who will not use greylisting. Thus all the 1st timers I rejected just delivered to my alternate MX address and were not blocked at all.
Jon
Jon H. LaBadie jcu@labadie.us _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On 9/06/20 2:56 pm, Jon LaBadie wrote:
I hit another limitation. My backup MX handler is a 3rd party who will not use greylisting. Thus all the 1st timers I rejected just delivered to my alternate MX address and were not blocked at all.
Don't use a backup MX, they are a relic of the 90s when mail servers were often times not always online. a sending mail server will generally retry the message for up to five days if your MTA is down so backup MXes are really not necessary.
As you have discovered, if you do decide to use a backup MX it really needs to have exactly the same anti-spam protections as the primary MX, but most backup MXes don't and spammers know this. In fact many spammers will ignore the primary MX all together and push out SPAM directly to the backup MX.
Peter
On Tue, Jun 9, 2020 at 12:10 AM Peter peter@pajamian.dhs.org wrote:
On 9/06/20 2:56 pm, Jon LaBadie wrote:
Don't use a backup MX, they are a relic of the 90s when mail servers were often times not always online. a sending mail server will generally retry the message for up to five days if your MTA is down
Or have your backup MX be the same as your primary and well behaved senders will try backup MX right away leading to little delay due to graylisting.
Am 07.06.2020 um 11:46 schrieb Nicolas Kovacs:
Hi,
I'm currently fine-tuning my mail server (Postfix and Dovecot on CentOS 7).
SPF, DKIM and DMARC work fine, now I'd like to limit the spam tsunami.
Besides the official Postfix documentation, I've read a few articles about Postfix spam restrictions, namely these :
https://www.linuxbabe.com/mail-server/block-email-spam-postfix
https://wiki.centos.org/HowTos/postfix_restrictions
After some experimenting, here's what I currently have on my test server:
--8<----- /etc/postfix/main.cf ----------------------------- ... 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 smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, check_sender_access hash:/etc/postfix/sender_access, reject_unknown_sender_domain, reject_unknown_reverse_client_hostname, reject_unknown_client_hostname smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/rbl_override, 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 --8<--------------------------------------------------------
Before committing this configuration to my main server, I thought I'd share this configuration on the list. Maybe the Postfix gurus among you have the odd comment to make.
My aim is simply to eliminate as much spam as possible (that is, before adding SpamAssassin) while keeping false positives to a minimum.
Any suggestions ?
Niki
Hi,
a few points:
- don't split up the smtpd_*_restrictions as shown above. It is simpler to maintain by keeping everything under smtpd_recipient_restrictions.
- use postscreen, it is a Postfix feature. That way relocate the RBL and RHSBL calls to postscreen in a weighted approach
- don't offer SMTP AUTH on smtp port 25. Offer submission (port 587) or submissions (465) or both for your known clients. That way you can much better control what's allowed on port 25.
- reject_non_fqdn_helo_hostname could lead to reject valid mail, use warn_if_reject for some time to check if that would be relevant for you.
- don't make use of permit_mynetworks, control relaying by use of SMTP AUTH.
Alexander
-
Alexander Dalloz -
John Pierce -
Jon LaBadie -
Nicolas Kovacs -
Peter -
Steven Tardy