I set-up Postfix in a gradual way:
- First I set up a LAN mail server
- Then I configure the mail server to accept emails from the Internet
- Lastly I configure the mail server to allow outgoing emails to the Internet
Starting with a LAN mail server
I start by setting up a mail server that works for the LAN. My LAN network looks as below.
ubuntux and laptop are the hostnames (names) of the computers that can be used to identify them in the LAN. For example if you want to ping ubuntux you don't have to know its IP. You can just ping the computer by providing its hostname. Keep in mind that hostnames cannot be seen outside the LAN.
If you don't know the hostname of your computer you can run in the terminal the command
hostname. Throughout the tutorial I will be using ubuntux as my main computer where I install Postfix.The router has an external IP 20.20.20.20 and an internal 192.168.1.1. Simply put, that means that from the internet our network is seen as 20.20.20.20 while the computers in the LAN sees the router having the IP 192.168.1.1.
Let's install Postfix:
[code]sudo apt-get install postfix[/code]
The install will ask you some questions. Just use the default values. After install, the daemon is launched automatically so we can start sending emails.
Sending the first email in the LAN
If you haven't read my article on sending emails via telnet, you could check it out. In that article I describe how you can use
telnet to send emails via a gmail mail server.To send our emails we will be using
telnet like in that article. The only difference is that while we had to authenticate with the gmail server with a login/password, here we won't. The reason is that our mail server is in the LAN and by default configuration users in LAN are considered trusted.The reason I use telnet and not an email client like Outlook Express is that I want you to see what is actually happening low-level and to get an in insight into the SMTP protocol.
First I send an email from ubuntux (192.168.1.2):
[code]>telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 ubuntux.localdomain ESMTP Postfix (Ubuntu)
HELO whatever
250 ubuntux.localdomain
MAIL FROM: whatever
250 2.1.0 Ok
RCPT TO: animal@localhost
250 2.1.5 Ok
data
354 End data with .
This is a test
.
250 2.0.0 Ok: queued as 22AEA133C91
quit
221 2.0.0 Bye
[/code]
In the telnet session I sent an email to animal@localhost. We assume that animal is the user I am logged in as at the moment. Then I can just type
mail in the terminal and I will see the email arrived. Typing the number of the email I can read it. Typing 'q' will quit the application. All emails can be found in their raw format at /var/spool/mail.Let's try and send an email from the second machine (192.168.1.10):
[code]>telnet 192.168.1.2 25
Trying 192.168.1.2...
Connected to 192.168.1.2.
220 ubuntux.localdomain ESMTP Postfix (Ubuntu)
HELO whatever
250 ubuntux.localdomain
MAIL FROM: whatever
250 2.1.0 Ok
RCPT TO: animal@ubuntux
250 2.1.5 Ok
data
354 End data with .
Sending from my laptop.
.
250 2.0.0 Ok: queued as 68DF4133C91
quit
221 2.0.0 Bye
[/code]
The only difference here is that we connected to
ubuntux instead of localhost. Accordingly we had to change the recipient from animal@localhost to animal@ubuntux.The recipient after "RCPT TO:" can essentially be any user (existing or not) as long as the domain used in the email is the hostname of our mail server (ubuntux in this case). An email with a different domain could be for example animal@randomdomain. The email with such a recipient would get totally discarded from the server and lost.
Taking it a step further - receiving emails from the Internet
At this state, emails can be delivered to the mail server from users in the LAN. We will try and make the mail server to be able and receive emails from the internet as well.
In the illustration above an email is being sent from the gmail server to our own mail server. We don't care how the email got to the gmail mail server. What we care about is how the email will reach our mail server. For the correct routing of the email we have to configure three things:
- Our DNS server
- Our router
- Our mail server
Configuring DNS
Every time we visit a website, a DNS request has to be made to find out the IP of that website. In the same fashion a DNS request is made by the mail server when an email is to be sent. This request is somehow different, in that it looks for a very specific record; an MX (mail exchange) record.
(1) As seen in the illustration the mail server looks at the domain after the '@' symbol in the recipient of the email.
(2) It then sends a DNS request for the mail server in that domain (linuxmeerkat.com). To get an idea of what the answer of such a request can be you can use the debugging tool
dig and test it with dig MX linuxmeerkat.com.(3) A reply arrives from the DNS server with the IP of the mail server.
(4) The email is forwarded to that IP, and further to the mail server.
Now ideally the MX record in the DNS server would look like this:
[code]linuxmeerkat.com. IN MX 10 20.20.20.20[/code]
That is however breaking the standard and therefore it is unacceptable. By defition an MX record should bind a domain to a hostname (or more). Therefore we need to replace the IP in the above example with a hostname:
[code]linuxmeerkat.com. IN MX 10 mail.linuxmeerkat.com.
mail IN A 20.20.20.20[/code]
Since the mail.linuxmeerkat.com hostname (or FQDN to be exact) doesn't exist, we have to create it with an A record. An A record binds a (made up) hostname to an IP by definition. Since our server is behind the router I use the IP of the router instead (the IP should never be a LAN one). For hostname I use
mail but you could use whatever you wish. Just keep in mind that if you change it, the hostname must also be reflected in the MX record - you should also change the FQDN.Keep in mind that if you do changes to the DNS records, it might take some time for the effects to take place. So continue a bit later, or after a day or two depending on how fast the changes are updated (essentially it depends on the TTL values).
Is your network reachable from outside?
Time to test if the DNS configuration works.
When we ping
mail.linuxmeerkat.com we want that it pings 20.20.20.20. So let's test it. Go to http://ping.eu/ping/ and ping your mail server's FQDN (in this case mail.linuxmeerkat.com). It's important that you ping from outside your LAN so that no local cache is used.If you don't get a response, try pinging directly your WAN IP (20.20.20.20). If you still don't get a response, then probably your router is blocking ping from outside. If you are getting a response by pinging the IP but not when you ping the hostname, then you haven't configured your DNS records correctly or they haven't taken effect yet.
If you run your own DNS server you can check for warnings and errors in
/var/log/syslog.Configure your router
At this point we know that an email can arrive as far as to the router. We only need to configure the router so it forwards the email to the correct machine in the LAN.
Since we know that mail servers use port 25 and if we haven't changed that, then our mail server also uses port 25, we just have to configure the NAT of our router.
Forward all TCP at port 25 to your mail server (in my case 192.168.1.2). My router's port forwarding looks as below:
Sending an email to Postfix from gmail
If we can ping the mail server from the internet, then we can assume that our network is reachable. Sending an email to animal@mail.linuxmeerkat.com will not work still though as the router won't know to which computer in the LAN to forward the email to. Setting the NAT of the router to forward all incoming TCP connections on port 25 to the mail server fixes this.
We can now test it by sending an email to animal@mail.linuxmeerkat.com from a gmail account. The mail server will reply with an error:
[code]
Delivery to the following recipient failed permanently:
animal@mail.linuxmeerkat.com
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain mail.linuxmeerkat.com by mail.linuxmeerkat.com. [20.20.20.20].
[/code]
The reason the email gets rejected lies in the Postfix configuration. The configuration file
/etc/postfix/main.cf has this (or a similar) line:
mydestination = ubuntux, localhost
mydestination is the variable that defines what FQDN/domains in emails are accepted. In essence all emails arrive at the server, it's just the depending on this configuration some of these emailes will be discarded and some will be accepted by the server.
With the current configuration we can see that only emails of the format username@megistanas and username@localhost are accepted. Trying to send an email to animal@ubuntux from gmail won't work as ubuntux just can't be seen from outside our LAN; it doesn't resolve to anything. For this reason we want to add one ore more domains that point towards our network. That way, when the an email arrives it doesn't get rejected.
In my case I add linuxmeerkat.com so that I accept all emails with the format username@linuxmeerkat.com:
mydestination = linuxmeerkat.com, ubuntux, localhost
Restart Postfix and sending an email to animal@linuxmeerkat.com should now work.
You could essentially also add mail.linuxmeerkat.com as that would take the same route as well. We can add pretty much any domain that points to our router.
Sending an email to gmail or hotmail from Postfix
There are essentially two entries in the configuration file that we have to change to make sending emails to the Internet possible:
[code]
smtpd_sender_restrictions = permit_mynetworks
mynetworks = 192.168.0.0/16 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
[/code]
smtpd_sender_restrictions can have more options than the one shown. However the only interesting option for us at the moment is to permit anyone from mynetworks to be able and send emails. So make sure permit_mynetworks is amongst the options.
mynetworks specifies local networks where users are considered trusted to use our mail server. For that we have added the 192.168.0.0/16 which includes all computers in the network. Be careful, you don't want to have a WAN ip here as that would make our mail server an open relay (I talk more about that below).
This configuration will let anyone from our computer to send an email of the format username@linuxmeerkat.com. If we want users of the LAN to be able to use our mail server from the Internet, some sort of authentication has to take place (login or key), but I am will not go further into that.
Let's test and see if we can send an email to a gmail account:
[code]>telnet mail.linuxmeerkat.com 25
220 mail.linuxmeerkat.com ESMTP Postfix (Ubuntu)
HELO dickhead
250 mail.linuxmeerkat.com
MAIL FROM: animal@mail.linuxmeerkat.com
250 2.1.0 Ok
RCPT TO: animal@gmail.com
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
This is a test.
.
250 2.0.0 Ok: queued as 3D31311F765
quit
221 2.0.0 Bye
[/code]
If everything went as planned, you should have received an email in your gmail account (animal@gmail.com in the example).
Make sure your mail server is not an open relay
You always want to avoid having an open relay. An open relay constitutes that your mail server can be used by anyone on the internet including spammers.
Once spammers find out that your server is an open relay, they will start using it. At some point, an other mail server will find out that you have an open relay and will blacklist your server.
So how do you ensure that you don't have an open relay? Very simply. In your configuration file pay attention to these two lines:
[code]
smtpd_sender_restrictions = permit_mynetworks
mynetworks = 192.168.0.0/16 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
[/code]
As long as the networks in mynetworks are LAN IPs and not WAN IPs, your mail server is not an open relay as no-one outside the LAN can use your mail server to send emails.
You can test to see if your mail server is an open relay at http://www.mailradar.com/openrelay/.
Use a relay host if you can
Our mail server works fine at the moment but it's very minimal. It doesn't even filter incoming spam emails. Configuring filters etc. can be time consuming and will need further maintenance all the time. An easy solution to this is to forward our emails to a second mail server, a relay server (keep in mind: not same as an open relay, as a relay server is not open to everyone). So if we have to deliver an email to user11@gmail.com, instead of delivering to the gmail server directly, we can use a second mail server which we have access to. That server can then do the filtering etc. for us and deliver the email to its final destination.
My ISP is called Bahnhof and by googling around I found that it offers a relay at mail2.bahnhof.se. Most ISPs do offer mail servers that can be used as relays. Luckily for me, I don't even need to enter a password and username as I am authenticated by my IP or MAC (depends on how you're connected to the ISP). In your case you might need to authenticate first before using the relay. I won't go into how you do that. I will however tell you how you can test to see if you can use the relay as a relay server.
If you can send an email directly from the relay server then you can use it as your relay. See the telnet session below:
[code]
telnet mail2.bahnhof.se 25
Connected to mail2.bahnhof.se.
Escape character is '^]'.
220 mxf3.bahnhof.se ESMTP
HELO dickhead
250 mxf3.bahnhof.se
MAIL FROM: animal@linuxmeerkat.com
250 Ok
RCPT TO: animal@gmail.com
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
This is a test.
.
250 Ok: queued as 0C67C53CEB7
QUIT
221 Bye
[/code]
I just connected to my ISP's mail server and sent an email to a gmail account. Since I got the email delivered and wasn't asked for a login/password, that means that I can directly use the server as a relay without authentication.
If your ISP's mail server requires a username and password you'll have to do some extra work in configuring that. Also keep in mind that in the field "MAIL FROM:" you have to provide an email with a hostname that points to your network. The server will probably check to see if whatever@hostname actually resolves to your network. If not, you will get an error like below:
[code]
450 <spamotron@spammer.spam>: Sender address rejected: Domain not found
[/code]
Now that we know we can use the server as a relay, we simply have to edit
/etc/postfix/main.cf and make sure the relayhost is set correctly:[code]
relayhost = mail2.bahnhof.se:25
[/code]
Restart Postfix and you should be able to use your mail server as before with the difference that now all outgoing emails go first through the relay server and the relay server forwards them further to their destinations.