Full Mail Server Solution w/ Virtual Domains & Users - Page 05 (Postfix on the MX Servers - Spam Prevention)

Want to support HowtoForge? Become a subscriber!
 
Submitted by Vecter (Contact Author) (Forums) on Wed, 2007-10-17 20:30. ::

D. Client permissions

Since we're looking to actually use this mail server in a production environment, we're going to want to restrict who can send mail through it. Being an open relay (Accepting mail To/From everyone) is extremely dangerous, and a great way to get yourself labelled as a SPAM server.

Since the Mail Exchangers really only handle mail TO our domain, we're going to be VERY restrictive. The next commands will tell the mail exchanger to allow email from the internal networks, and reject ANY email to an unauthorized destination.

# postconf -e 'smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, permit'

E. Simple Spam prevention

While DSpam will be handling the ruling majority of our anti-spam measures, there are some simple tricks we can employ on the Mail Exchangers to take some of the load off.

1. Postgrey

Greylisting is a fairly effective countermeasure against spam, so we of course want to enable it on the Mail Exhangers. First of all, let's get Postgrey installed. As always, Debian makes this simple for us:

# apt-get install postgrey

Postgrey will be injected before postfix sends the mail to the postman server, so we need to add it in the very end of the smtp_recipient_restrictions in main.cf.

# postconf -e 'smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_policy_service inet:127.0.0.1:60000, permit'

Open up /etc/default/postgrey in your favorite editor, and change the options line to the following:

[...]
POSTGREY_OPTS="--inet=127.0.0.1:60000 --delay=55"
[...]

Then restart postgrey and incoming mail will be delayed by 55 seconds. You'd be surprised at how much spam this will prevent...

# invoke-rc.d postgrey restart

2. Postfix RBL and other rules

Postgrey is great, and will definitely trim down the amount of spam you see, but there are some more restrictions we can put into the exchangers before they go into production. I highly recommend checking out the postfix website and documentation to determine what all of these commands are:

# postconf -e 'smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unauth_destination, reject_unauth_pipelining, reject_invalid_hostname, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org, reject_rbl_client list.dsbl.org, reject_rhsbl_sender dsn.fc-ignorant.org, check_policy_service inet:127.0.0.1:60000, permit'

It's also worth it to restrict some other areas:

# postconf -e 'smtpd_data_restrictions = reject_unauth_pipelining, reject_multi_recipient_bounce, permit'

F. Final Words on Mail Exchanger

So, at this point, your two mail exchanger servers (MX-1, MX-2) should be set up. These servers have RBL, DNS, and Postgrey SPAM prevention, as well as quota protection.

There is one item worth discussing here, and that is the transport table. Something to keep in mind is that this particular scenario was originally written with the intent of migrating from a qmail based delivery system to postfix. As such, we wanted to be able to control a slow migration, one domain at a time, without having to worry about DNS. We setup the two Mail Exchanger servers to handle all incoming mail, and originally, they just used the smtp transport agent to forward the mail to the qmail server (After checking postgrey). Then, using the SQL Transport queries, we were able to redirect one domain at a time over to the new format.

So, really, you could simplify the transport process if you're starting from scratch. We weren't, therefore we couldn't.


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by Stefan (not registered) on Sat, 2008-11-01 19:07.
There is no explanation on how the mail is actually transfered from the MX server to the Mail Delivery Server. Using the steps in the guide will make the MX server try to deliver the mail directory into the NFS shared vmail folder, which isn't the desired behaviour.
Submitted by sicnarf (registered user) on Thu, 2008-03-27 07:06.

Hi Vector,

I would just like to know how the mail gets transferred from the MX's to the delivery server (postman). I'm trying to understand how this full mail server setup works because I would like to implement something similar to this but using centos and ldap users.