Greylisting Configuration

Submitted by xtremeservices on Sat, 06/11/2011 - 22:13

Hi Guys,

I just enabled the VERY COOL greylisting option under Mail Messages and was curious if there is a config for this in Virtualmin?

What I would like to do is decrease the default 5 minute time out to 1 minute for the next week. I have many clients that deal directly with their clients via email and a 5 minute wait when you are talking to the person over the phone could be a phone call to me : ). I would like to keep my phones from ringing off the hook on Mon.

Also, here is my Postfix smtpd_recipient_restrictions setup. I wanted to get your thoughts on the best place to use the check_policy_service.

smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_pipelining reject_invalid_hostname reject_unauth_destination check_policy_service inet:127.0.0.1:10023 reject_rbl_client cbl.abuseat.org reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net permit

A bug (atleast I think it is) that I want to point out is that after I ran the automated setup for Greylisting, the check_policy_service was added after permit in the smtpd_recipient_restrictions. This resulted in warnings in mail.log but more importantly nothing was being greylisted.

Thx,

~Jeremy

Status: 
Closed (fixed)

Comments

Submitted by xtremeservices on Sat, 06/11/2011 - 23:36

Update, I have changed my smtpd_recipient_restrictions to:

smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unknown_sender_domain reject_unknown_recipient_domain reject_unauth_pipelining reject_invalid_hostname reject_non_fqdn_hostname reject_non_fqdn_sender reject_non_fqdn_recipient reject_unauth_destination reject_rbl_client cbl.abuseat.org reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net check_policy_service inet:127.0.0.1:10023 permit

That way the rbl lists actually get to play : ).

~Jeremy

Submitted by JamieCameron on Sun, 06/12/2011 - 00:06

You can change the delay by editing /etc/default/postgrey and in the POSTGREY_OPTS variable adding --delay=60 , and then restarting the Postgrey server with /etc/init.d/postgrey restart

Submitted by xtremeservices on Sun, 06/12/2011 - 01:28

That worked great.

Thank you very much.

Submitted by Locutus on Sun, 06/12/2011 - 03:23

Two notes here from my side:

The "permit" entry should not be necessary in smtpd_recipient_restrictions. The default Virtualmin setup does not add it, so the default policy seems to be "permit", i.e. when no restriction option matches, the mail is permitted.

The "reject_rbl_client" entry should rather go in the "smtpd_client_restriction" directive, since it applies to the connecting client, and not to the destination.

Submitted by Locutus on Sun, 06/12/2011 - 06:16

(Multi-duplicate post, caused by "500 Internal Server Error", deleted.)

Submitted by Locutus on Sun, 06/12/2011 - 06:16

(Multi-duplicate post, caused by "500 Internal Server Error", deleted.)

Submitted by Locutus on Sun, 06/12/2011 - 06:16

(Multi-duplicate post, caused by "500 Internal Server Error", deleted.)

Submitted by Locutus on Sun, 06/12/2011 - 06:16

(Multi-duplicate post, caused by "500 Internal Server Error", deleted.)

Submitted by Locutus on Sun, 06/12/2011 - 06:17

(Multi-duplicate post, caused by "500 Internal Server Error", deleted.)

Submitted by xtremeservices on Sun, 06/12/2011 - 11:28

Hi Locutus,

I set my main.cf up when I was running on Virtualmin GPL using this article for guidance:

http://www.akadia.com/services/postfix_uce.html

They recommend placing everything under the smtpd_client_restrictions because you can know the most about the email at that point:

"All of the anti-UCE checks are under smtpd_recipient_restrictions, instead of having a separate smtpd_client_restrictions. This is because, unless you have set smtpd_delay_reject = no (default is "yes"), no rejecting takes place until after RCPT TO anyway. It's easier, cleaner and more predictable when all of the anti-UCE stuff is under recipient restrictions. "

I agree with you about the permit, I added that and it is not necessary except for readability. But Virtualmin should be able to read that in to see if it is the last entry and make sure not to append the policy after it.

What are Virtualmin recommendations for main.cf and anti UCE setups? Can you point me to some documentation?

Thanks,

~Jeremy

Submitted by andreychek on Sun, 06/12/2011 - 12:26

What are Virtualmin recommendations for main.cf and anti UCE setups? Can you point me to some documentation?

Well, anything that we formally recommend would be setup by default in a typical Virtualmin installation.

And the same goes with Linux distributions -- anything distribution vendors think is a good setting without significant downsides would come enabled by default as well.

Anything outside of would depend on the specific needs of you, your users, and the service you're providing. That comes back to you, the fellow wearing the sysadmin hat for your organization -- you'll have to review the various options, and weigh the benefits and the drawbacks of each.

There's a decent selection of documentation on the Postfix site, in the section titled "UCE/Virus" here:

http://www.postfix.org/docs.html

Remember though, if it's not enabled by default, there's typically a reason for that :-)

For your situation (whatever that happens to be), sometimes the benefits of enabling non-default options will outweigh the drawbacks. And that's where a sysadmin can spend some time -- determining what options will be beneficial to you will require plenty of reading and testing :-)

Submitted by xtremeservices on Mon, 06/13/2011 - 14:08

Hi Eric,

I tried responding yesterday but kept getting the lovely 500 errors. Anyways, I understand that you can't recommend specifics because of all of the different applications for Virtualmin. I do like my sysadmin cap and wear it proudly : ). An update, I am getting extremely good anti UCE success with the new greylisting feature policy after my RBL checks.

This can be marked as fixed.

Thanks,

~Jeremy

Submitted by andreychek on Mon, 06/13/2011 - 14:16

Yeah, sorry, the site here has been pretty crappy lately... the servers should be replaced soon though. Thanks for your patience, I know it's frustrating :-)

I'm glad to hear your greylisting and UCE updates have been helping! Thanks for the update.

Submitted by Locutus on Mon, 06/13/2011 - 17:50

I quite agree with you, Jeremy. The combination of RBLs, greylisting and spamassassin is yielding great results for me as well.

Submitted by xtremeservices on Wed, 06/15/2011 - 18:12

Hope my last comment didn't cause anyone grief. NEVER put greylisting policy before Reject_Unauth_Destination : )

Here is my working setup. Tried and true 80% reduction in SPAM!!

smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unknown_sender_domain reject_unknown_recipient_domain reject_unauth_pipelining reject_invalid_hostname reject_non_fqdn_hostname reject_non_fqdn_sender reject_non_fqdn_recipient reject_unauth_destination reject_rbl_client cbl.abuseat.org reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net check_policy_service inet:127.0.0.1:10023 permit

~Jeremy

Submitted by Issues on Thu, 06/30/2011 - 17:22

Automatically closed -- issue fixed for 2 weeks with no activity.