Difference between revisions of "Postfix greylisting"
From Finninday
(→On CentOS) |
|||
| (9 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | [[Category:Computers]] | ||
On a lark, I decided to implement greylisting on my mail server. It was as easy as "apt-get install postgrey". | On a lark, I decided to implement greylisting on my mail server. It was as easy as "apt-get install postgrey". | ||
Well, almost that easy. I also had to add this to my /etc/postfix/main.cf: | Well, almost that easy. I also had to add this to my /etc/postfix/main.cf: | ||
| Line 4: | Line 5: | ||
check_policy_service inet:127.0.0.1:60000 | check_policy_service inet:127.0.0.1:60000 | ||
This was slipped in at the end of smtpd_recipient_restrictions. | This was slipped in at the end of smtpd_recipient_restrictions. | ||
| + | |||
| + | '''update''' Now postgrey is running on port 10023, so that line is now | ||
| + | check_policy_service inet:127.0.0.1:10023 | ||
| + | |||
| + | The full smtpd_recipient_restrictions looks like this: | ||
| + | <pre> | ||
| + | smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, check_policy_service unix:private/policy-spf | ||
| + | </pre> | ||
Now I have a new service in /etc/init.d: postgrey | Now I have a new service in /etc/init.d: postgrey | ||
| + | |||
| + | Every attempt to deliver mail to my server generates a to, from, sending-host triplet and the request is bounced. After 5 minutes, any requests bearing that same triplet are allowed. After 5 successful mails are sent associated with a single triplet it is whitelisted. | ||
And my logs look like this: | And my logs look like this: | ||
<pre> | <pre> | ||
| − | Oct 17 16: | + | Oct 17 16:16:32 localhost postfix/smtpd[32484]: connect from unknown[201.226.226.55] |
| − | Oct 17 16: | + | Oct 17 16:16:35 localhost postfix/smtpd[32484]: NOQUEUE: reject: RCPT from unknown[201.226.226.55]: 450 <rday@finninday.net>: Recipient address rejected: Greylisted for 300 seconds (see http://isg.ee.ethz.ch/tools/postgrey/help/finninday.net.html); from=<lingrossfastenrathmet@grossfastenrath.de> to=<rday@finninday.net> proto=ESMTP helo=<auditoria01.cwpanama.net> |
| − | Oct 17 16: | + | Oct 17 16:16:35 localhost postfix/smtpd[32484]: lost connection after DATA from unknown[201.226.226.55] |
| − | Oct 17 16: | + | Oct 17 16:16:35 localhost postfix/smtpd[32484]: disconnect from unknown[201.226.226.55] |
</pre> | </pre> | ||
| + | |||
| + | My Bayes filter might get rusty from lack of use now. Hardly anything is persistent enough to get through the greylist. | ||
| + | |||
| + | |||
| + | === On CentOS === | ||
| + | # yum install postgrey | ||
| + | |||
| + | # add the policy to smtpd_recipient_restrictions in main.cf: | ||
| + | |||
| + | smtpd_recipient_restrictions = | ||
| + | permit_mynetworks, | ||
| + | reject_unauth_destination, | ||
| + | check_policy_service unix:postgrey/socket, | ||
| + | |||
| + | # enable the service and start the service | ||
| + | |||
| + | systemctl enable postgrey | ||
| + | systemctl start postgrey | ||
| + | |||
| + | # reload postfix | ||
| + | |||
| + | ==== get reports ==== | ||
| + | # cat /var/log/maillog | postgreyreport --delay=30 | ||
| + | |||
| + | Looking at the report, it seems to be mostly junk that is hopefully getting turned away. | ||
| + | Of the 231 entries in the report, it looks like 95% spam. I'm not sure if they are | ||
| + | turned away by greylisting or if they just get slowed down and then amavis puts them in the junkpile. | ||
Latest revision as of 18:44, 28 January 2022
On a lark, I decided to implement greylisting on my mail server. It was as easy as "apt-get install postgrey". Well, almost that easy. I also had to add this to my /etc/postfix/main.cf:
check_policy_service inet:127.0.0.1:60000
This was slipped in at the end of smtpd_recipient_restrictions.
update Now postgrey is running on port 10023, so that line is now
check_policy_service inet:127.0.0.1:10023
The full smtpd_recipient_restrictions looks like this:
smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023, check_policy_service unix:private/policy-spf
Now I have a new service in /etc/init.d: postgrey
Every attempt to deliver mail to my server generates a to, from, sending-host triplet and the request is bounced. After 5 minutes, any requests bearing that same triplet are allowed. After 5 successful mails are sent associated with a single triplet it is whitelisted.
And my logs look like this:
Oct 17 16:16:32 localhost postfix/smtpd[32484]: connect from unknown[201.226.226.55] Oct 17 16:16:35 localhost postfix/smtpd[32484]: NOQUEUE: reject: RCPT from unknown[201.226.226.55]: 450 <rday@finninday.net>: Recipient address rejected: Greylisted for 300 seconds (see http://isg.ee.ethz.ch/tools/postgrey/help/finninday.net.html); from=<lingrossfastenrathmet@grossfastenrath.de> to=<rday@finninday.net> proto=ESMTP helo=<auditoria01.cwpanama.net> Oct 17 16:16:35 localhost postfix/smtpd[32484]: lost connection after DATA from unknown[201.226.226.55] Oct 17 16:16:35 localhost postfix/smtpd[32484]: disconnect from unknown[201.226.226.55]
My Bayes filter might get rusty from lack of use now. Hardly anything is persistent enough to get through the greylist.
On CentOS
# yum install postgrey
# add the policy to smtpd_recipient_restrictions in main.cf:
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_policy_service unix:postgrey/socket,
# enable the service and start the service
systemctl enable postgrey systemctl start postgrey
# reload postfix
get reports
# cat /var/log/maillog | postgreyreport --delay=30
Looking at the report, it seems to be mostly junk that is hopefully getting turned away. Of the 231 entries in the report, it looks like 95% spam. I'm not sure if they are turned away by greylisting or if they just get slowed down and then amavis puts them in the junkpile.
