Raspberry Pi Email Server Part 1: Postfix

Postfix Logo

This is the first part of a five part tutorial that will show you how to install a full featured email server on your Raspberry Pi. This tutorial covers Postfix, the Mail Transfer Agent.

The parts are:
The Introduction & Contents Page (read first)
Raspberry Pi Email Server Part 1: Postfix
Raspberry Pi Email Server Part 2: Dovecot
Raspberry Pi Email Server Part 3: Squirrelmail
Raspberry Pi Email Server Part 4: Spam Detection with Spamassassin
Raspberry Pi Email Server Part 5: Spam Sorting with LMTP & Sieve

Installing Postfix

Note: While you are setting up the mail server on the Pi, it’s a good idea to turn off port forwarding rules for email to the Pi in your router’s firewall. If you don’t have any port forwarding rules now, that’s great, don’t worry – I’ll prompt you to set them up later.

First, log into your Pi with a SSH session and install postfix:

sudo apt-get update
sudo apt-get install postfix

You will see a menu with some choices. Select “Internet Site” and then set the mail name to your domain name, not including www. (e.g. samhobbs.co.uk).

The setup script will then do some automatic configuration for you. The output will look something like this:

Selecting previously unselected package postfix.                                              
(Reading database ... 67653 files and directories currently installed.)                       
Unpacking postfix (from .../postfix_2.9.6-2_armhf.deb) ...                                    
Processing triggers for man-db ...
Setting up postfix (2.9.6-2) ...
Adding group `postfix' (GID XXX) ...
Done.
Adding system user `postfix' (UID XXX) ...
Adding new user `postfix' (UID XXX) with group `postfix' ...
Not creating home directory `/var/spool/postfix'.
Creating /etc/postfix/dynamicmaps.cf
Adding tcp map entry to /etc/postfix/dynamicmaps.cf
Adding sqlite map entry to /etc/postfix/dynamicmaps.cf
Adding group `postdrop' (GID XXX) ...
Done.
setting myhostname: samhobbs
setting alias maps
setting alias database
changing /etc/mailname to samhobbs.co.uk
setting myorigin
setting destinations: samhobbs.co.uk, samhobbs, localhost.localdomain, localhost
setting relayhost: 
setting mynetworks: 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
setting mailbox_size_limit: 0
setting recipient_delimiter: +
setting inet_interfaces: all
/etc/aliases does not exist, creating it.
WARNING: /etc/aliases exists, but does not have a root alias.

You can edit all of this later.

You may also get some warnings like this:

postmulti: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol

IPv6 is a new type of IP address that was introduced because we’re running out of the “old” IPv4 addresses. Not many ISPs support IPv6 yet, so you probably don’t need it. Unless you fix the warning, you’ll see it every time.

Change directory into the postfix configuration folder:

cd /etc/postfix/

Edit /etc/postfix/main.cf with your favourite command line text editor (e.g. sudo nano main.cf) and add inet_protocols = ipv4 to the end of the file.

Now is also a good time to check that your hostname is specified properly in /etc/postfix/main.cf. The setup script takes the hostname of the server and uses that, but it may not be in the right format, i.e. “samhobbs” instead of “samhobbs.co.uk”. Find the line that begins myhostname = and make sure it is your fully qualified domain name. This is important because your server will use this to talk to other mail servers, and some will reject your emails if you don’t use a fully qualified domain name to say hi! This is covered in more detail in the helo access restrictions later.

Restart postfix and you shouldn’t see the warnings any more:

sudo service postfix restart

Testing and Configuration

Before you start, it’s probably worth backing up the configuration files in their current state. This way, you’ll have something to compare to if you’re ever trying to work out which bits were defaults and which bits you changed yourself:

cd /etc/postfix
sudo cp main.cf main.cf.BAK
sudo cp master.cf master.cf.BAK

Mailbox Setup

There are a couple of different types of mailbox you can use, I’ve chosen to use a “Maildir” rather than “mbox” configuration. For users with “real” UNIX accounts on the system (like the one you’re using to log in), Maildir creates a folder in the user’s home directory and places emails inside it, one file for each email.

I prefer this to the alternatives, because it’s easier to see and understand: you can rummage around in your home folder and see all your emails as individual files.

To tell Postfix to use the Maildir format, add the following lines to /etc/postfix/main.cf:

home_mailbox = Maildir/
mailbox_command =

If there's already a line with mailbox_command, comment it out by adding a # at the start of the line.

We also need to create the mail directory and its subfolders for existing users, and add some things to /etc/skel (the template for new users) so that if you create a new account this will be done automatically.

These commands are part of Dovecot, so first we need to install it:

sudo apt-get update
sudo apt-get install dovecot-common dovecot-imapd

You will get a lot of output: some other dovecot packages will automatically be installed and the config files will be created. You will also see some errors – don’t worry about those for now, I’ll explain how to deal with them in part 2, later.

Now we can create those mail folders. Run the following commands to create the template files:

sudo maildirmake.dovecot /etc/skel/Maildir
sudo maildirmake.dovecot /etc/skel/Maildir/.Drafts
sudo maildirmake.dovecot /etc/skel/Maildir/.Sent
sudo maildirmake.dovecot /etc/skel/Maildir/.Spam
sudo maildirmake.dovecot /etc/skel/Maildir/.Trash
sudo maildirmake.dovecot /etc/skel/Maildir/.Templates

Next, copy the files over to existing users’ home directories, and change the ownership and permissions for privacy (replace USER with the username you are doing this for, and repeat for all existing usernames):

sudo cp -r /etc/skel/Maildir /home/USER/
sudo chown -R USER:USER /home/USER/Maildir
sudo chmod -R 700 /home/USER/Maildir

Initial Testing

Now, the best way to test Postfix during configuration is to use Telnet, because it is such a simple way of communicating between programs and there’s less to go wrong and get confused about.

First, install telnet:

sudo apt-get install telnet

Now, still inside the SSH session to your pi, type this command. It will connect you to port 25 on the Pi:

telnet localhost 25

You can now test sending an email using SMTP. Here are the steps:

  1. send an ehlo command to tell the server who you are, and it will tell you its capabilities
  2. use the mail from command to say who the email is from. If you are sending it from an address that exists on the server, you needn’t include the domain name (i.e. user instead of user@yourdomain.com)
  3. use the rcpt to command to tell the server where to send the email
  4. Use the data command to tell the server that you’re about to start giving it the message you want to send
  5. Type Subject: YOUR SUBJECT then enter to set a subject
  6. Type the body of your email. Once you’re done, press ENTER, then ., then ENTER again.
  7. Type quit to exit

Here’s an example:

telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 samhobbs.co.uk ESMTP Postfix (Debian/GNU)
ehlo foobar
250-samhobbs.co.uk
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from: me        
250 2.1.0 Ok
rcpt to: me@outsideemail.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
Subject: test
This is a test email
.
250 2.0.0 Ok: queued as A639C3EE6D
quit 
221 2.0.0 Bye

Some Access Restrictions

Add the following to /etc/postfix/main.cf to restrict who can send emails to external mail servers:

smtpd_recipient_restrictions =
        permit_sasl_authenticated,
        permit_mynetworks,
        reject_unauth_destination

Reload postfix:

sudo service postfix reload
  • Line 1 begins the list of restrictions.
  • Line 2 permits users who have authenticated with Simple Authentication and Security Layer (SASL) to send email to any destination (this is part of the Dovecot config in Part 2, later).
  • Line 3 will let users send emails to any destination if they have connected from an IP address defined in mynetworks.
  • Line 4 will reject the email if none of the above conditions have been met unless the “rcpt to” address is one of the addresses that your server is accepting email to (as defined in main.cf with the mydestination parameter).

In its present state, the email server will allow you to send external emails because the connection is originating from the Pi itself (you are logged in via SSH) and not an unknown computer. Addresses of “trusted” computers are listed under the mynetworks setting in main.cf, e.g.

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

Try sending an external email again, using telnet as before. You should be able to do so without any issues.

Now we want to see what kind of response someone would get if they were connecting from outside of the IP range defined in mynetworks, to make sure Pi won’t allow everyone to send outgoing emails from your server. To simulate this we can comment out permit_mynetworks under smtpd_recipient_restrictions:

smtpd_recipient_restrictions =
        permit_sasl_authenticated,
#       permit_mynetworks,
        reject_unauth_destination

Now reload the postfix configuration:

sudo service postfix reload

This will let you see what kind of response you would get if you weren’t sending the email from mynetworks. Try sending again, and you should receive an error “554: Relay access denied“:

admin@samhobbs /etc/postfix $ telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 samhobbs.co.uk ESMTP Postfix (Debian/GNU)
ehlo samhobbs.co.uk
250-samhobbs
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from: USER
250 2.1.0 Ok
rcpt to: me@externalemail.com
554 5.7.1 <me@externalemail.com>: Relay access denied
quit
221 2.0.0 Bye
Connection closed by foreign host.

Perfect. Leave permit_mynetworks commented out in your smtpd_recipient_restrictions (you'll see why in part 2).

Helo access restrictions

Helo access restrictions can be a very useful way of blocking spam.

Note that we’re not talking about unauthorised people being able to send email outside your network any more (that’s taken care of with the smtpd_recipient_restrictions); we’re now talking about stopping spammers from sending incoming mail to your email address.

Spammers try to conceal their identity so that they don’t end up on block lists, so they rarely use helo hostnames that could identify them – these hostnames are written to the mail log files. As a result, they often make up a random string or use an IP address instead of a domain name.

Luckily, these are easily taken care of.

Add the following to /etc/postfix/main.cf:

smtpd_helo_required = yes
smtpd_helo_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname
  • Line 1 requires people and programs to identify themselves when they send email, using the helo or ehlo commands I mentioned earlier.
  • Line 2 starts the list of restrictions.
  • Line 3 accepts any old rubbish in the ehlo if it comes from an IP address defined in mynetworks. If the connection isn’t connecting from an IP address in mynetworks, then the helo hostname is checked against the rest of the list.
  • Line 4 accepts any helo hostname if the client is authenticated with SASL (I added this to the tutorial recently after troubleshooting problems some people had in the comments – it allows you to connect from any network and still send messages through your Pi. Mobiles will usually work without this because most providers pass mail through their own proxies, so your Pi receives a connection from the proxy – which has a valid hostname – and not from the mobile, which may be called something like “android-b627cfe2efea7e67″).
  • Line 5 rejects connection attempts when the HELO hostname syntax is invalid.
  • Line 6 rejects non-fully qualified domain names (for example, foobar instead of foobar.com). This will also block those random strings, e.g. “kjhrsbvks”.
  • Line 7 rejects the helo hostname if it that domain doesn’t have a valid DNS A or MX record. For example, someone spamming you could make up a domain like theflyingspaghettimonster.com. If that domain doesn’t actually exist and have the right records, then your server won’t accept it as a hostname, and the email will be rejected.

If the helo hostname gets past line 7 and hasn’t been denied, it is accepted. You’d be surprised how much spam these helo access restrictions will block on their own (looking through my log files, I can see numerous spam scripts that have attempted to ehlo with my IP address), but there’s an extra step we can add in here to help:

Blocking people claiming to be your domain name

Many spammers try to send email to you after helo’ing with your own domain name. Since postfix doesn’t check whether or not they’re lying about their helo hostname, this will usually work.

But, since we’ve put permit_mynetworks at the top of the list, anyone actually sending an email from your domain will be accepted already. Anyone using your hostname who isn’t in mynetworks is an imposter.

So, add one more line to the end of the restrictions list:

smtpd_helo_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        check_helo_access hash:/etc/postfix/helo_access

That last line checks a file for custom rules you’ve built in. Create the file:

sudo nano /etc/postfix/helo_access

Add the following lines, edited for your domain:

samhobbs.co.uk          REJECT          Get lost - you're lying about who you are
mail.samhobbs.co.uk      REJECT          Get lost - you're lying about who you are

Now tell postfix to map the file, and restart postfix:

sudo postmap /etc/postfix/helo_access
sudo service postfix restart

Now anyone who tries to ehlo with one of the hostnames you defined in that file gets rejected, and sees the “get lost” message. Your legitimate servers won’t have that problem, because they will already have been accepted higher up the list.

Neat, right? I found that little nugget of wisdom at unixwiz.net.

Moving on…

We’re almost done with Postfix now, athough there are a few bits of configuration that we’ll want to do once we’ve set up SASL with Dovecot, which I’ve chosen to lump in with the Dovecot tutorial.

In Raspberry Pi Email Server Part 2: Dovecot, we’ll set up Dovecot to provide SASL authentication and IMAP capability.

Please leave a comment if you’re having trouble with anything in this tutorial, and I’ll try and help you out!

Type: 

Comments

tail /var/log/mail.err
Sep 24 14:09:02 raspberrypi postfix/sendmail[27989]: fatal: /etc/postfix/main.c f, line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 14:39:03 raspberrypi postfix/sendmail[1915]: fatal: /etc/postfix/main.cf , line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 15:09:01 raspberrypi postfix/sendmail[8234]: fatal: /etc/postfix/main.cf , line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 15:39:02 raspberrypi postfix/sendmail[14527]: fatal: /etc/postfix/main.c f, line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 16:09:01 raspberrypi postfix/sendmail[21294]: fatal: /etc/postfix/main.c f, line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 16:39:02 raspberrypi postfix/sendmail[30748]: fatal: /etc/postfix/main.c f, line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 17:09:02 raspberrypi postfix/sendmail[7193]: fatal: /etc/postfix/main.cf , line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 17:39:02 raspberrypi postfix/sendmail[14231]: fatal: /etc/postfix/main.c f, line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 18:09:03 raspberrypi postfix/sendmail[25404]: fatal: /etc/postfix/main.c f, line 40: missing '=' after attribute name: "inet protocalls = ipv4"
Sep 24 18:39:02 raspberrypi postfix/sendmail[5877]: fatal: /etc/postfix/main.cf , line 40: missing '=' after attribute name: "inet protocalls = ipv4"

Looks like you might have misspelt "protocols" in the config file... fix the typo, then reload postfix and see if it starts properly.

Sam

I fired up webmin and tried to start post fix. got the following error:

postfix: fatal: /etc/postfix/main.cf, line 40: missing '=' after attribute name: "inet protocalls = ipv4"

Do you know what it is trying to tell me? here are the last few lines of my config file:
inet_interfaces = all
inet protocalls = ipv4
home_mailbox = Maildir/
mailbox_command =

Why are you using webmin? Careful with that if it's accessible from the internet bots will go crazy trying to brute force your login.

You can restart postfix with this command (which is in the tutorial!):

sudo service postfix restart

Like I said in my last reply, you misspelt "protocols". You are also missing an underscore in inet_protocols.

Sam

Thanks Sam. I finally got it working. Old eyes don't see as well as the used to! I am continuing on with the tutorial. To answer your question. I'm not really using webmin. Since I'm new to the Linux world I installed it just to play around with it since it is running on my internal wireless lan I didn't think it would be a securiry issue. To give you some of my background I retired 5 years ago after working 40 years in the IT industry. I recently decide I needed to excersise my brain a little more and thought the raspberry pi would be a cheap way to learn more about the open source world. It had been slow going to say the least. The old neurons don't fire as fast as they used to! :-) your site has been invaluable ro my learning experience. Thank you for it.

Del Thompson

Hi Sam. Me again. I'm slowly slogging my way through your tutorial everything seems to be working until I get to the send mail part of your tutorial. When I attempt it I get the following:

AUTH PLAIN AHRlc3RtYWlsAHRlc3QxMjM0
235 2.7.0 Authentication successful
mail from:testmail
250 2.1.0 Ok
rcpt to:me@externalemail.com
250 2.1.5 Ok
Subject: This is my first email that has been authenticated with Dovecot SASL
221 2.7.0 Error: I can break rules, too. Goodbye.
Connection closed by foreign host.
pi@raspberrypi:~ $
Is it possible that I took you too literally when I gave it the recpt to: address? should it be something else?

Thanks,

Del

Del,

me@externalemail.com should be a freemail account you own (so you can see if the message arrives!)

Sam

I have postfix running per your tutorial but when I sen mail it never arrives in my inbox in either my live.com or gmail.com account. When I do a status on postfix I get the following:
Oct 01 15:07:57 raspberrypi postfix/smtp[21712]: 82769220157: to=, relay=none, ...ut)
Oct 01 15:08:17 raspberrypi postfix/smtp[22535]: connect to mx4.hotmail.com[65.55.92.152]:25: Connectio...out
Oct 01 15:08:47 raspberrypi postfix/smtp[22535]: connect to mx4.hotmail.com[65.54.188.126]:25: Connecti...out
Hint: Some lines were ellipsized, use -l to show in full.
I'm not sure how to read this but it looks to me like the test message is being sent. Can you tell me what might be going on?
Here are the last few lines from my test:
AUTH PLAIN AHRlc3RtYWlsAHRlc3QxMjM0
235 2.7.0 Authentication successful
mail from:testmail
250 2.1.0 Ok
rcpt to:dlthompson471@live.com
250 2.1.5 Ok
data
354 End data with .
Subject: This is my first email that has been authenticated with Dovecot SASL
.
250 2.0.0 Ok: queued as 82769220157
quit
221 2.0.0 Bye
Connection closed by foreign host.
are the last few lines of my test:

Del Thompson

Can you confirm that "connection...out" is a truncated version of "connection timed out"?

If so, I think your ISP might be blocking port 25 (try telnet samhobbs.co.uk 25 to see if you can connect).

Sam

When I try to telnet into your site I get the following and it never connects:
telnet samhobbs.co.uk 25
Trying 195.166.151.235...

I assume that means comcast is blocking port 25? Can I get around that somehow?

Del Thompson here again Sam. Doing some research on the web I found this tip on getting around Comcast blocking port 25:
=====================================================================================================
The usual fix is simple but may not work for all servers. In Thunderbird's "Outgoing Mail Server" panel, replace the default 25 with 587. RFC 2476 explains why this works for newer SMTP servers. (For sbcglobal.net, the fix is to change port to 26.) "

could I use port 587 for my testing in your tutorial?

Del

Sam.
I continued on with your tutorial, was able to connect telnet through port 465 but when I tried to open SSL here is what I got:

openssl s_client -connect localhost:465 -quiet
3069191376:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:782:

have I missed something somewhere?

Del

I think you might have missed the tls wrappermode option (if you connect with telnet and it works, postfix is listening for plain text connections).

Sam

Here is the full results when I just send: openssl s_client -connect localhost:465
CONNECTED(00000003)
3069891792:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:782:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None

PLease ignore my last post. I found it in master.cf
here is how it is set:
smtps inet n - - - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
So does this force an encrypted connection? can I run without it?

By the way, when I try to access your site from firefox I get the following error message now:
Security Error

Your request has been blocked for security reasons. Please try again in a few minutes.
Should the problem persist, please email me (see the contact page for details) with the
following unique ID, which will help to identify your request:

V-F@h38AAQEAAH2lXuQAAAAH

Sorry for any inconvenience.

This is all explained in part 2 of the tutorial:

OK, so now it’s listening on the right port, but it’s allowing unencrypted connections. Here’s how you force TLS on port 465: open /etc/postfix/master.cf and find the line you uncommented earlier. Below it are some options, you want to edit them so that they look like this (i.e. uncomment lines 2 and 3):

smtps     inet  n       -       -       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes

Line 3 is forcing TLS on port 465, and line 2 means that connections to port 465 have a different label in the logs, which can be useful for debugging.

sudo service postfix restart

Now try connecting with Telnet again… you should be able to establish a connection, but not receive any prompts from the server:

telnet localhost 465

Thanks for reporting the block - my web firewall thought one of your cookies was dodgy (false positive). If you want to access the site using firefox now, clear your cookies for my site, or you can just wait until I'm home and I'll add an exception.

Sam

Dos this mean I can complete your tutorial using ports 587 and 465? Since my ultimate goal is to send email from my pi is it really necessary for port 25 to be involved? Sorry for all the questions. as you can probably tell I'm a real newbie to all of this.

Del

No, you can't replace port 25 with 587. You could set up the server with port 25 blocked, but until your ISP unblocks port 25 your server won't be able to send email to external accounts, since that can only be done on port 25. Without port 25, your server can't talk to other servers.

Sam

Hi Sam,

By enabling smtpd_helo_required I can see how effective this is to block potential spammers. However, sometimes legitimate senders do not use helo. I have looked for the equivalent of: permit_123.456.7.8 as an entry in smtpd_helo_restrictions to allow a legitimate non-helo sender but cannot find something that will work. There doesn't seem to be anything in postfix conf parameters as far as I can see.

Is it possible to provide exceptions to the normal "reject_unknown_helo_hostname" rule?

John

Do you really mean they don't use helo/ehlo, or that they provide a helo but it's not a valid hostname or something similar?

If you want to allow a certain IP address with invalid helo hostname, you can do this (line 4):

smtpd_helo_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_client_access hash:/etc/postfix/helo_client_access,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        check_helo_access hash:/etc/postfix/helo_access

Create /etc/postfix/helo_client_access with contents:

123.456.7.8 OK

And then postmap the file and reload postfix:

sudo postmap /etc/postfix/helo_client_access
sudo service postfix restart

Since that IP address gets an OK higher up the list than the reject rules, it should pass the helo restrictions. You can also allow/deny IP subnets, hostnames etc - see the access control documentation.

Sam

Hi Sam,

I have been getting: Helo command rejected: host not found for emails which I should receive. I started to make a note of valid email senders' IP addresses in case there was a way round this problem. But this soon became untenable since I had to monitor mail.info frequently. I then noticed that on occasions email was still getting through. I found this comment which explained why (with regard to helo host not found):

"the first time that someone connects and tries to send an email, your server will give a temporary error, and then remember the sending IP address, the FROM and the TO. The next time the sender connects with those same IP, FROM and TO, the email will be allowed."

So I decided to drop "reject_unknown_helo_hostname" from main.cf and monitor main.cf for a few days. No further valid email rejections. But contined helo rejections from "need fully_qualified hostname". Various other senders rejected for other reasons "relay access denied", "Recipient address rejected".

So far it seems that scammers are still being rejected; and all regular senders are getting through correctly. Only some were previously rejected because of helo hostname. (You pointed out that one sender's helo hostname had neither an A nor an MX record which caused the rejection.)

Thank you for your tip about "check_client_access". I will keep this in reserve if needed. I am satisfied from a daily monitor of mail.info over the last few days that email that is being rejected, should be rejected and that email delivered should be delivered.

I also notice occasions when brief connections are made (probing?) for no obvious reason.
Oct 9 10:44:18 jmnpi2 postfix/smtpd[10461]: connect from unknown[93.174.93.46]
Oct 9 10:44:28 jmnpi2 postfix/smtpd[10461]: disconnect from unknown[93.174.93.46]
Oct 9 10:47:48 jmnpi2 postfix/anvil[10463]: statistics: max connection rate 1/60s for (smtp:93.174.93.46)

Thanks again for advice.

John

If you're getting lots of those errors for valid domains it might be your DNS provider's fault - you do get slightly different results for queries to ISP nameservers and opendns, for example.

The comment you are describing is talking about something called greylisting, which isn't on by default or turned on in this tutorial, so I don't think it explains the problems you were having.

Sam

Hi Sam,

You are right!

I have re-visited mail.info and noted that the series of problems I mentioned all arose on Oct 7. I have found that Demon reported a problem with its DNS servers on that day which was resolved later in the afternoon. As a result I have changed DNS servers from Demon to Open DNS; re-instated reject_unknown_helo_hostname and the only remaining problem is now from TelAppliant (my VoIP provider). Their email address is xxx.voiptalk.yyy but their helo hostname is aaa.voipworld.yyy which has no DNS entry - whereas aaa.voiptalk.yyy does. I suggested to them that this might be a mistake. In the meantime I have added their base email address to the check_client solution you suggested.

I am glad that there is a solution.

John

Hello Sam,

thank you very much for your tutorials, with your help I succeed to finally make my rpi an working email server.

After installation I found that my private senders IP are included in emails header and because this pose a security/privacy risk I search for a solution how to remove private IP data only from my sent emails; maybe you can review and update tutorial if it is OK.

in master.cfg I added a new line under section:
smtps inet n - - - - smtpd
...

-o cleanup_service_name=subcleanup

and in the same file under section:
cleanup unix n - - - 0 cleanup
I added two lines:

subcleanup unix n - - - 0 cleanup
-o header_checks=regexp:/etc/postfix/submission_header_checks

then I made the file submission_header_checks:
sudo nano /etc/postfix/submission_header_checks
with content:

/^Received:.*\(Postfix/ IGNORE

finally restart postfix and test it sending emails to other external email address. success.

Best Regards
Lucian

p.s.
I was inspired from this solution:
http://askubuntu.com/questions/78163/when-sending-email-with-postfix-how...

I bought a Pi 3 for a specific purpose that won't work, so I have a new toy to play with and maybe learn something about Linux. Unfortunately, I can almost guarantee there will be other questions after I ask the first few to show how utter a newbie I am.

I'm stuck at setting up the mailboxes. I'm familiar with the concept of users and groups in general, but am uncertain about these points:

At the place in your tutorial (part 1) where you say, "Next, copy the files over to existing users’ home directories, and change the ownership and permissions for privacy (replace USER with the username you are doing this for, and repeat for all existing usernames)," I'm not sure if I should take that literally. Part of the script is "USER:USER" which a description of the chown command says is used to change ownership to a user and a group. So, for user sam, do I enter "sam:sam" or "sam:group_name" where you wrote "USER:USER"?

Next, that same quote also refers to "existing usernames." Where did those "existing usernames" come from? Postfix created a system admin when it installed with a group, both called "postfix." At this point, is that the only existing username (and group)? Does it need a set of folders? Am I automatically creating new users when I set up the mail file structure? Or is there some other place I have to create users and then set up the folders for each one in this step?

And to prove that I'm really starting from scratch, am I correct that the users we are talking about are users only of the new mail system? There's no need to add users in Raspbian itself, right?

Thanks for pointing me in the right direction.

Hi,

Thanks for explaining your questions clearly.

The users I am talking about in the tutorial are "normal" users with login accounts on the server. By default, Raspbian comes with one "normal" login (pi) but you can add more with the adduser command as in part 2 when we add the "testmail" account. The authentication backend used by Dovecot is PAM (Pluggable Authentication Modules) which allows it to look up usernames and passwords from the system-wide database - it's possible to set up Postfix and Dovecot to use a different set of usernames and passwords for authentication, but I wanted to keep it simple in this tutorial so it's the same password for everything.

You're right that other users are created to run the dovecot and postfix daemons (this is why), but these are "system logins" rather than "normal logins". You couldn't use a system username to log in via SSH, and their "home directories" are generally not in /home, they are somewhere else on the filesystem - for example, the apache webserver process runs as www-data and its home directory is generally /var/www/ where all of the web server files are stored.

In the chown command you enter sam:sam because by default on Debian based systems the home directory of every "real"/"normal" user is owned by that user with a group of the same name.

The point of adding files to /etc/skel is that the files in there are a template for new users' home directories. Once you have created a Maildir in /etc/skel, every new login you create will have it in their newly created home directory (/home/USER/). So, if you only have one login ("pi") then you only need to add the Maildir at /home/pi/Maildir, and give it ownership pi:pi.

If you haven't changed the default password for pi, do it now!

Sam

Hey, great tutorial! I have everything working except one thing. I can receive email without a problem and login without any issues, but I cannot send any emails. I think I have my helo_access misconfigured, but I'm not too sure. Any time I send mail through squirrelmail, postfix errors out and the webpage says I'm sending spam, so my HELO command is rejected.

What could be going wrong?

Pages

Add new comment