You are either not logged in or not registered with our community. Click here to register.
April 10, 2021, 09:08:40 am

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

Click here if you are having problems.
Default Wide Screen Beige Lilac Rainbow Black & Blue October Platinum Send us your theme!

Adulting Successfully
Deserves a moment of bragging.

Wiki Blogs Dicebot

Author Topic: The Elliquiy LAMP Stack: Postfix configuration  (Read 3306 times)

0 Members and 1 Guest are viewing this topic.

Offline VekseidTopic starter

The Elliquiy LAMP Stack: Postfix configuration
« on: March 27, 2009, 08:29:52 pm »
The Elliquiy LAMP Stack

1: Introduction and Overview
2: General Configuration
3: General Security
4: IPTables configuration
5: Postfix configuration
6: ntp configuration
7: Apache compilation and configuration
8: MySQL compilation and configuration
9: PHP compilation and configuration
10: Conclusion and future plans


Not all sections are created equal. This is split out largely because not everyone is going to want to use postfix.

I have a pretty bare setup - bsd-mailx, alpine and postfix for me. Dovecot is just another application that I'd have to watch security announcements for, and my e-mail traffic is fairly low. I prefer postfix because configuring sendmail is simply a nightmare, and postfix, at least by comparison, is really quite simple. It also has the advantage of possessing a far superior security history.

SELinux notes:
1) SYNC_CHROOT="n" must be added to /etc/default/postfix
2) postfix-nochroot needs to be run to remove the rest of postfix's chroot.

Skip if you're not using SELinux of course.

I split up my smtp lines in /etc/postfix/ like so:
Code: [Select]
localhost:smtp      inet  n       -       -       -       -       smtpd inet  n       -       -       -       -       smtpd

Replacing the smtp      inet  n       -       -       -       -       smtpd line. If you ran postfix-nochroot you will see n's in the chroot column.

This lets me explicitly specify which ips postfix is listening on and how. If you are only receiving mail at a domain, and not sending from it, you may want to bind domains specifically, for example:

Code: [Select] inet  n       -       -       -       -       smtpd -o inet  n       -       -       -       -       smtpd -o

You only get one per ip doing this, however.

Postfix, or at least the version packaged with Debian, does not currently ask if you want to specify a bind address for outgoing e-mails. This can make the difference between getting thrown in the spam bucket or not, so be sure to set smtp_bind_address to your intended outgoing ip in /etc/postfix/ :

Code: [Select]
smtp_bind_address =

Since this machine is handling several domains, and I want to send and receive mail from them, I want to keep them separate. This is especially the case for say, having someone manage these e-mail accounts. I add the extra domains to /etc/postfix/ (at the end):
Code: [Select]
virtual_alias_domains =
virtual_alias_maps = hash:/etc/postfix/virtual

Maps are not entirely necessary for us but they may be useful in the event that we want to split up say, the webmaster or postmaster aliases for Personal Roleplaying, Blue Moon, Ewrimo and Elliquiy. See Postfix's documentation for a more detailed explanation of this, and a more proper way to do it (virtual mailbox domains) if you want to give some people only pop3 access, for example.

If you go the virtual alias domains route, you will want to edit /etc/postfix/virtual and then run postmap /etc/postfix/virtual after each time you do in order to recreate the database.

Note: Postfix needs to be able to read its own configuration files, so it's not safe to just prevent world-reading without at least giving its group read access.

Postfix uses such a tiny amount of resources that I have not given any thought to trying to optimize it. This server currently handles roughly six thousand e-mails, sent and received, per day. If I ever split mail functions from the webserver/firewall it will probably be more for security reasons than load reasons.
« Last Edit: March 28, 2009, 07:54:38 pm by Vekseid »