Tag: postfix
Postfix Configuration: The argument against reject_unverified_sender
Postfix Configuration: The argument against reject_unverified_sender
When configuring a mail server there techniques available which can help you to reduce spam.
A popular spam reduction technique is to ‘greylist’ emails. This method temporarily rejects an email if the server has never seen a prior attempt to send the same combination of From Email, To Email and From IP address , legitimate emails are tried again after a few moments and the email goes through no problem.
Another option in the postfix system which can be used to reduce spam is the ‘reject_unverified_sender’ option. As postfix confirming that the ‘Sender’ is a valid user, a connection is made to the server associated with the Senders domain (by MX record). It goes through the email sending process far enough to find out if the server accepts or rejects the Sender email (RCPT TO: sender@email.com).
While it seems like a good idea to confirm that the email address that is sending email to us is valid, if the sender’s server has greylisting on their domain they would reject the ‘verification’ connection, which would then ‘reject’ the attempted message.
For this reason, we choose not to globally install postfix servers with reject_unverified_sender.
————————–
There is some argument though that this does not cause a permanent problem, because when the reject_unverified_sender_code is set to 450. Because the rejection of the email will only be temporary and when the email is attempted again, the sender verification should pass the grey listing.
However, this is not good enough for me because there are other reasons that the sender verification could fail. Such as the fact that the server does not accept the MAIL FROM email from the verifying server. This could be because the doublebounce@ email address used for verification is not accepted by the server for other reasons such as the fact that THEY may be doing some sender verification, which would fail when an email is attempted to doublebounce, additionally the verifying server could end up getting a bad ‘reputation’ by only checking to see if email addresses are deliverable, but then never actually delivering a mail message.
For these reasons, I recommend skipping this setting and perhaps only using the reject_unknown_sender_domain which just checks whether there is a valid MX record for a domain.
While postfix is powerful with a plethora of options, not all of them immediately helpful.
Check SPF Records when receiving mail in postfix
Check SPF Records when receiving mail in postfix
This simple install assumes you already have policyd installed
apt-get install postfix-policyd-spf-perl
Another tutorial, said that an executable file might be installed at /usr/sbin/policyd-spf, however it was installed elsewhere on my ubuntu 14.04 system, here is how I found it
#updatedb
#locate policyd-spf|bin
/usr/sbin/postfix-policyd-spf-perl
User the path to add this entry to your /etc/postfix/master.cfm
policy-spf unix - n n - - spawn
user=nobody argv=/usr/sbin/postfix-policyd-spf-perl
So, now we need to update /etc/postfix/main.cf by adding the following line
spf-policyd_time_limit = 3600s
and updateing the ‘smtpd_receiptient_restrictions’ to have the following in the list of services, I added mind after ‘permit_mynetworks’ and another ‘check_policy_service 127.0.0.1:10011’ entry I have.
smtpd_recipient_restrictions = permit_mynetworks,
check_policy_service inet:127.0.0.1:10011,
check_policy_service unix:private/policy-spf,
.....
Reload and watch your logs
/etc/init.d/postfix restart grep spf /var/log/mail.log
Postgrey does not start – postfix rejecting mail – cannot connect to check_policy
Postgrey does not start – postfix rejecting mail – cannot connect to check_policy
On one of our mail servers as we were transitioning to a new server had an identical configuration of postfix, policyd and postgrey put on it, however it was rejecting mail with the following messages.
451 4.3.5 Server configuration problem;
A look at the messages just proceeding this in the mail.log, showed the real reason.
warning: connect to 127.0.0.1:60000: Connection refused warning: problem talking to server 127.0.0.1:60000: Connection refused
A quick look into our postfix configuration shows that we had been running our greylist policy service there.
#grep 60000 /etc/postfix/ -r
/etc/postfix/main.cf:greylist = check_policy_service inet:127.0.0.1:60000
I check that the greylist service was installed correctly, checked the open ports, which ports the service ws supposed to run on and updated the postfix configuration file to use the correct port
# dpkg -l|grep postgrey ii postgrey 1.34-1.2 all greylisting implementation for Postfix #lsof -i:60000 #no results confirms that nothing is listening on port 60000 # grep OPTS /etc/default/postgrey #a lookup of what options would run when postgrey is started shows what I should run to debug the daemon POSTGREY_OPTS="--inet=10023" #postgrey --inet=10023 2015/04/25-09:29:44 postgrey (type Net::Server::Multiplex) starting! pid(1569) Resolved [localhost]:10023 to [127.0.0.1]:10023, IPv4 Resolved [localhost]:10023 to [::1]:10023, IPv6 Binding to TCP port 10023 on host 127.0.0.1 with IPv4 Binding to TCP port 10023 on host ::1 with IPv6 ERROR: Can't connect to TCP port 10023 on ::1 [Cannot assign requested address] at /usr/sbin/postgrey line 776. #lsof -i:10023 #no results confirms that nothing is already listening on port 10023
So I have two changes I had to make,
- update the postfix and postgrey to be operating on the same port
- Find out what is stopping postgrey from listening on port 10023
To change postfix to operate on the same channel as postgrey was a simple choice, either tell postfix to check the policy service on 10023, or change postgrey to be on channel 60000. Since the postgrey was installed with apt-get and automatically choose 10023, I figured that is more standard and since my postfix configuration is older, i would move to 10023.
#sed -i -e's/60000/10023/' /etc/postfix/main.cf #/etc/init.d/postfix reload
Now I have to figure out what postgrey could not start on 10023, the first thing I will do is run it on a couple of different ports to find out if I get the same results
lsof -i:10022 #no results confirms that nothing is already listening on port 10023 #postgrey --inet=10022
A closer look at the error, describes the problem, postgrey is trying to start using IPv6.
Can't connect to TCP port 10023 on ::1 [Cannot assign requested address]
A quick check on the system shows that the system has IPv6 disabled.
#sysctl -a|grep 'ipv6.*disable' net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 net.ipv6.conf.eth0.disable_ipv6 = 1 net.ipv6.conf.lo.disable_ipv6 = 1
so I tested starting postgrey explicity using the IPv4 loopback local address
#postgrey --inet=127.0.0.1:10023 2015/04/25-09:49:09 postgrey (type Net::Server::Multiplex) starting! pid(6085) Binding to TCP port 10023 on host 127.0.0.1 with IPv4 Setting gid to "115 115" Setting uid to "106"
Success! I just had to update the postgrey OPTS and restart postgrey and my postfix problems are solved
# sed -i -e 's/10023/127.0.0.1:10023/' /etc/default/postgrey #/etc/init.d/postgrey start * Starting postfix greylisting daemon postgrey #lsof -i:10023 #results confirm that postgrey is listening COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME /usr/sbin 6557 postgrey 5u IPv4 8665045 0t0 TCP localhost:10023 (LISTEN)
And there we have it, it is now working, I confirmed postgrey was working by greppign my mail.log for postgrey and greylist and found results, I also confirmed that I no longer had any server rejections or errors connecting to post 60000 or 100023.