Full Mail Server Solution w/ Virtual Domains & Users (Debian Etch, Postfix, Mysql, Dovecot, DSpam, ClamAV, Postgrey, RBL) - Page 5
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.
