Setup Postfix as a null client

best practicesemailpostfixsmtp

I'm having a bit of trouble setting up postfix as a null client and have some questions.

I'll be aiming to use SMTP as this is what most web applications use as a way to connect to the email server.

The goal is to use it for email notifications from web applications and monitoring software on the machine.

Are things like SASL and TLS needed? It sounds like encrypting the connection between my web application and the email server is uesless when they're on the same box.
Which user should I connect to the SMTP server as? I originally used the user account I use for daily activities, but this screams bad as my login information is in the wild if my web application is ever cracked. I also tried creating a user with /usr/sbin/nologin as it's shell, but this didn't work either (I'd prefer it the user didn't have shell access).

Any other things to think about while doing this?

Best Answer

I believe what you are asking is for a way to have the mail server accept e-mail that you generate from your web application on the same machine and deliver it to the final destination? I'm not entirely sure because "null client" and your description don't make sense together to me.

Anyway, the way this would typically be done is that in postfix you set "mynetworks" to include "127.0.0.1", and you have your web applications connect to "127.0.0.1" to send e-mail. Mail coming from a host listed in "mynetworks" is not limited in it's ability to send e-mail to only user-names the postfix server directly handles, so you can have your web applications mail your normal e-mail account, or other external users.

mynetworks usually contains 127.0.0.1, so this is likely to be the default configuration.

So, use "postconf mynetworks" to see the current value. Change /etc/postconf/main.cf or use "postconf" to change the value and then restart postfix. Check the logs if your mail still isn't working then.

Related Solutions

Ubuntu – How to Setup Mail Server with Google Apps

Easiest way to do this is to avoid using exim and to use sSMTP which is a lightweight MTA.

All you need to do is install it:

sudo apt-get install ssmtp mailutils

and configure it (edit /etc/ssmtp/ssmtp.conf) to use your Google Mail servers see:

root=noreply@yourdomain.com
mailhub=smtp.gmail.com:587
UseSTARTTLS=yes
UseTLS=yes
AuthUser=youremail@yourdomain.com
AuthPass=password
FromLineOverride=YES

I've been using this set-up for a while now and it just works - It's also nice to not need to be running exim when it's not necessary and let Google's mail servers handle everything for you.

Forwarding only bounce messages to a different SMTP server

I am always reluctant to put services on ports that they don't usually live-- not because of a software deficiency, but because of people deficiencies. A sysadmin who inherits this setup has to be pretty good to track down the architecture of "where emails go when they bounce", or else your documentation needs to be pretty clear (and easy to find).

So, to answer your first question-- my suggestion is to have a separate server that handles bounces. This makes things nicely documented via dns, instead of buried in a config file for postfix.

If you choose to ignore that advice, utilizing the transport maps of postfix will allow you to do so. For example, adding this to main.cf:

transport_maps = regexp:/etc/postfix/transport

and using something like this in your transport file:

/bounce.*/      smtp:bounces.mydomain.com:8025

(don't forget to 'postmap /etc/postfix/transport' and 'postfix reload')

Best Answer

Related Solutions

Ubuntu – How to Setup Mail Server with Google Apps

Forwarding only bounce messages to a different SMTP server

Related Topic