Raspberry Pi Email Server Part 1: Postfix

Powered by Drupal
Submitted by Sam Hobbs on

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!

Comments

Hi, and great tutorial
The only tiny error I incountered on this page was under this section=
" 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):

On my RASp my users doesn't have a Maildir directory so I created the directory maually for my users and then I could continue with the sudo chown -R USER:USER /home/USER/Maildir command.

Just wanted you to know

Thanks again

Marcel

Sam Hobbs

Sat, 10/11/2014 - 16:45

In reply to by Marcel

Hi Marcel, That's not an error. You're right that you don't already have a Maildir, that's the point of the command - it copies over the "skeleton" Maildir into your user's home directory. Alternatively, you could use the maildirmake.dovecot commands to create the Maildir and its subdirectories directly in the user's home, but copying the skeleton files requires fewer commands so I've done it that way. Did you just do a "mkdir /home/USER/Maildir"? If you did you might get errors later on because it won't contain the subdirectories like cur, new etc. Thanks for your comment! Sam

Hi Sam

And thanks for your reply. You are right... Actually I saw it at one point automatically create the subdirectories. The only thing I had to correct was some rights on the MailDir. I didn't realise the error at start, just when I tried to log on to the Squirrelmail.

All is working now perfectly, I'm just using it for a mailserver for me and my wife, so its Perfect. Thanks for the Toturial, and Answer.

My next project I think is to schedule Backup to a Sftp server or Owncloud,

Thanks

Marcel

Hi Sam

Thank you for your excellent tutorials. I found them extremely usefull and highly detailed. However I have a small problem I cant seme to resolve.

Before I installed postfix/dovecot etc, I had only 1 user.
If i add a new user, then i can log into squirrel mail, and send & recieve emails.
However, if i try to log in using my user account before I installed postfix/dovecot then I cant log in. ALso, new users have more files / directories in their Maildir.

My new users have ....
cur dovecot.index.log dovecot.mailbox.log dovecot-uidvalidity new tmp
dovecot.index.cache dovecot-keywords dovecot-uidlist dovecot-uidvalidity.5450cfb5 subscriptions

my existing user has
cur new tmp.

I tried all the instructions above, and everything seems ok. Certainly i receive no errors. Would you have any ideas?

Many thanks

John

Hi John, For the existing user you're having problems with, can you run this command?
ls -l /home/user/Maildir
I think those other files are created automatically by Dovecot when it accesses the Maildir, they're not something you need to create yourself. Thanks for commenting, Sam

I'm having a terrible time getting past a fatal error message indicating that the /var/spool/postfix/private/auth file isn't found. I noticed in your two telnet displays that the first doesn't have 250-AUTH and the second one does. What did you do to get that working? Perhaps the answer lies ahead in the dovecot part of the tutorial?

Hi Christopher, You shouldn't be seeing the AUTH PLAIN LOGIN until you have done the bit with Dovecot (it indicates that the server has SASL authentication capability). It shouldn't be in that second list on this tutorial, I overlooked it because I went back and added that part to the tutorial at a later date - I'll remove it now to avoid confusion. How far through the tutorial(s) did you get before you got that error? Did you do anything with Dovecot other than install it and use the maildirmake.dovecot command? Sam

Hi Sam,

I've made it through the SASL and IMAP tests. I can telnet localhost 25, 110, 143, 465, and 993 (the latter two close the connection immediately). I can add users to Thunderbird, but I can't send mail from TB. On the server-side, the most persistent error I encounter is this:

$ sudo tail -10 /var/log/mail.log
...
postfix/smtps/smtpd[18002]: warning: SASL: Connect to private/auth failed: No such file or directory
postfix/smtps/smtpd[18002]: fatal: no SASL authentication mechanisms

On the TB client-side, I get different errors depending on how I set up the servers (SSL/TLS vs. STARTTLS, and various permutations involving normal passwords, etc.)

For example, I get this error message when trying to send an email from TB:

Sending of message failed.
The message could not be sent because the connection to SMTP server mydomain.com was lost in the middle of the transaction. Try again or contact your network administrator.

Then I check the server mail.log file and see this:

postfix/smtps/smtpd[18378]: warning: SASL: Connect to private/auth failed: No such file or directory
postfix/smtps/smtpd[18378]: fatal: no SASL authentication mechanisms
postfix/master[17586]: warning: process /usr/lib/postfix/smtpd pid 18378 exit status 1
postfix/master[17586]: warning: /usr/lib/postfix/smtpd: bad command startup -- throttling

Your tutorial is excellent and appears to contain all that I need to figure out how to resolve my problems. I wish I had found it sooner. (Initially, I installed dovecot using apt-get following this tutorial https://help.ubuntu.com/community/Dovecot.)

Thanks for your help.

Chris

Those telnet connections to 465 and 993 are closed immediately because the ports are SSL/TLS only, so you have to use openssl to test them (the commands are in part 2 of the tutorial). If you add your user to the adm group you won't have to use sudo to read your logs, e.g.
sudo usermod -aG adm youusername
...then log out and in again for the changes to take effect. Now to answer your actual question: sounds like postfix has the wrong path for dovecot, I would check /etc/postfix/main.cf to make sure you have specified these parameters:
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
And then make sure your dovecot configuration is consistent with that, e.g. in /etc/dovecot/conf.d/10-master.conf you should only have one block called service auth { and it should look like this:
service auth {
        unix_listener /var/spool/postfix/private/auth {
                mode = 0660
                user = postfix
                group = postfix
        }
}
If I had to guess I would say yours doesn't have the full path for unix_listener, just private/auth. I'm glad you've found the tutorial useful, I was trying to use the ubuntu documentation too at first, got into a horrible mess, and decided I should write this tutorial to save others the hairloss ;) Sam

A number of uncommented blocks in the file 10-master.cf point to /var/spool/postfix/private/auth. One of them is the service auth { block, as you indicated. (At one point I discovered misplaced brackets, so I may need to triple-check that.) I also have that path in the postfix/master.cf file

smtp inet n - - - - smtpd
#smtp inet n - - - 1 postscreen
#smtpd pass - - - - - smtpd
#dnsblog unix - - - - 0 dnsblog
#tlsproxy unix - - - - 0 tlsproxy
submission inet n - - - - smtpd
# -o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=/var/spool/postfix/private/auth
smtps inet n - n - - smtpd

(Note the extra n in the last line -- smtps inet n - n -- smtpd. That didn't change either the TB client or the server-side error messages.)

I am beginning to consider whether the smtp authorization problems might be related to the saslauthd path confusion stemming from yet another earlier Postfix tutorial (https://help.ubuntu.com/community/Postfix). Specifically:

Authentication
The next steps are to configure Postfix to use SASL for SMTP AUTH... First you will need to install the libsasl2-2, sasl2-bin and libsasl2-modules from the Main repository [i.e. sudo apt-get install them all]...
We have to change a few things to make it work properly. Because Postfix runs chrooted in /var/spool/postfix we have change a couple paths to live in the false root. (ie. /var/run/saslauthd becomes /var/spool/postfix/var/run/saslauthd):

Note: by changing the saslauthd path other applications that use saslauthd may be affected.

At this point I may simply need to purge and start over again with your tutorial.

I think it might be best to purge and start again, or I'm probably going to confuse things by guessing what you've already done. By the way, are you actually running Ubuntu on your server or is it Raspbian on a Pi? I ask because newer versions of Postfix have smtpd_relay_restrictions as well as smtpd_recipient restrictions so one of the steps will be a little different if you're running Ubuntu. If not, you can follow the tutorial as it's written. Sam

I am using Ubuntu 12.04 on a vps. Instead of a purge, I may just give it a break and come back to it with fresh eyes. Thanks again for your help. BTW, I am inspired by your tutorial to get a Rasberry Pi.

OK so if you do end up purging, before you start changing the recipient access controls in part 1, find the relay restrictions and replace them with this:
smtpd_relay_restrictions=
(nothing)...then it should behave like the older version of Postfix in Raspbian. When you have worked through the tutorial, read this page from the postfix documentation and you will understand what that change does. Probably best not to read it before you've worked through the tutorial to avoid confusion! I'd definitely recommend getting a Pi to mess around with. Hosting your own services at home is a great learning experience, and it puts you in control of everything, which is nice! To avoid disappointment, it's probably worth checking out how good your ISP is for not blocking port 25, giving static IP addresses without huge extra costs etc, some can be a real pain to work around! Sam

Johnny Ellwood

Fri, 12/19/2014 - 15:36

Hey Sam,
Great guide so far! I am having a few issues when i did the final restart at the end of this page. The full message i got was

stopping postfix mail transport agent: postfixpostmulti: fatal: /etc/postfix/main.cf, line 44: missing '=' after attribute name: "permit_sasl_authenticated,"

Even if I put in the = it still errors out.
Can you assist?

Thanks
Johnny

Hi Johnny, I'm not sure if this is it but it's worth a try: check the other items in that list all have commas after them (apart from the last one). I have a feeling you might have something like:
smtpd_helo_restrictions =
        permit_mynetworks
        permit_sasl_authenticated,
(i.e. no comma after permit_mynetworks) - this would make Postfix think that permit_sasl_authenticated is a configuration parameter in its own right, not just a value for smtpd_helo_restrictions. If not, can you post part of your main.cf (from line 39 to 49 should do it). Sam

Adam J Walters

Mon, 01/05/2015 - 02:47

I was wondering if there was a way to move the mailbox to a usb flashdrive instead of storing it on the raspberry pi's sd card. I would like to keep the read/write's on it to a minimum. I tried doing this and then setting up a link but it did not work. I can move the Maildir folder when logged in as the user it belongs to but cannot change its permissions after it is in the usb folder.

Colin Horner

Sat, 01/17/2015 - 04:02

With port 25 blocked on my ISP, I needed to find a solution to bypass the port. I chose no-ip's port Reflection and Alternate-Port SMTP.

I finally got the receiving email to work on port 2525, by changing smtp to '2525' in /etc/postfix/master.cf, and by changing the relayhost field in /etc/postfix/main.cf to horner.us.com@noip-smtp, but the outgoing mail is still not working. I had to set a password in no-ip alternate-port SMTP, but I don't see where in the the configurations to put that password, so my outgoing mail can communicate with it.

The log from tail -f /var/log/mail.log looks like such:

Jan 17 03:40:58 raspberrypi postfix/smtp[5464]: fatal: valid hostname or network address required in server description: horner.us.com@noip-smtp
Jan 17 03:40:58 raspberrypi postfix/smtp[5465]: fatal: valid hostname or network address required in server description: horner.us.com@noip-smtp
Jan 17 03:40:59 raspberrypi postfix/qmgr[4895]: warning: private/smtp socket: malformed response
Jan 17 03:40:59 raspberrypi postfix/qmgr[4895]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jan 17 03:40:59 raspberrypi postfix/master[4884]: warning: process /usr/lib/postfix/smtp pid 5464 exit status 1
Jan 17 03:40:59 raspberrypi postfix/master[4884]: warning: /usr/lib/postfix/smtp: bad command startup -- throttling
Jan 17 03:40:59 raspberrypi postfix/master[4884]: warning: process /usr/lib/postfix/smtp pid 5465 exit status 1
Jan 17 03:40:59 raspberrypi postfix/qmgr[4895]: warning: private/smtp socket: malformed response
Jan 17 03:40:59 raspberrypi postfix/qmgr[4895]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jan 17 03:41:00 raspberrypi postfix/error[5466]: E6A6146310: to=, relay=none, delay=108221, delays=108220/1.2/0/0.12, dsn=4.3.0, status=deferred (unknown mail transport error)
Jan 17 03:41:00 raspberrypi postfix/error[5467]: E5B47463A4: to=, relay=none, delay=25689, delays=25688/1.2/0/0.04, dsn=4.3.0, status=deferred (unknown mail transport error)
Jan 17 03:41:00 raspberrypi postfix/error[5467]: E5B47463A4: to=, relay=none, delay=25689, delays=25688/1.2/0/0.06, dsn=4.3.0, status=deferred (unknown mail transport error)

Thomas Griffin

Sat, 03/21/2015 - 07:52

When running the telnet localhost 143 and then trying to select inbox i get this error. Any help would be greatly appreciated thanks.

Is your mail_location set up as explained at the part of start 2? Dovecot may be looking in /var/mail if not. Also check to make sure the Maildir exists for the user you're testing with. Sam

Thanks for getting back to me. It turns out this was the issue which I didn't discover until I purged everything and restarted. Anyway I've run into a new issue. I have no errors in anyof the tests in your instructions but I'm unable to send or receive mail. I setup my account on k9 and it connects to the servers perfectly. The problem I run into is when I try to send or receive mail. When I send it I never receive it on the external mail site and when I send mail to an account on my server I get an email about a day later saying that delivery to the recipient has been delayed. Any help would be greatly appreciated. Thanks again.

Add new comment

The content of this field is kept private and will not be shown publicly.

Filtered HTML

  • Web page addresses and email addresses turn into links automatically.
  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.