Not all of us do mail server configuration everyday, so it is easy to get lost on unfamiliar grounds.

Fortunately, there is fantastic (up to date / unofficial) postfix documentation, it is the best I’ve seen on the net, this guide explains how to get following oiled and running:

Ubuntu + Postfix + Courier IMAP + MySQL + Amavisd-new + SpamAssassin + ClamAV + SASL + TLS + Roundcube + Postgrey. (Besides roundcube I think everything is essential).

I followed this guide to the word, but got myself into trouble on several occasions. Internet research didn’t yield any results, so I had to solve problems myself.

Problem #1.

I got instant reject: RCPT

Log file (/var/log/mail.log) said following:

127.0.0.1:10023 seemed strange, since this is ipv6 port. At this point I remembered I had to install postgrey, and by default it is configured to listen on ipv6 address in ubuntu (probably was not when original article was written). I checked postfix configuration main.cf, and I saw the problem check_policy_service inet:127.0.0.1:10023. Changing this line to check_policy_service inet:::1:10023 fixed reject error.

Another solution is to change postgrey to bind to ipv4 instead of ipv4 and leave postfix/main.cf alone.
In that case you would edit /etc/default/postgrey

Problem #2.

Testing IMAP over ssl:

This worked fine.

But SMTP did not. Confusing part was that I could telnet to server fine and send email via SMTP, but my mac mail app was refusing to do the same!

Log file (/var/log/mail.log) revealed following:

There was something wrong with SSL certificate obviously, but what? This bugged me for few hours, but finally I had a realisation: postfix and courier use different SSL certificates. And since I host both smtp and imap on same server, maybe SSL should be same too.

I simply linked postfix snake oil certificate (pem, since this what I found in default courier directory) in courier config. But I got this error:

By examining courier default .pem certificate, I realised courier requires a single
file to contain both the private key and the certificate, in PEM format. So I created new .pem file in courier directory, and merged inside output of default snakeoil certificate and key into 1 .pem.

I also ran

Problem was solved. But there was a new error…

Problem #3.

Again with SMTP:

Excerpt from /var/log/mail.log

Excerpt from /var/log/auth.log

If you were not following original article closely, maybe you have missed that SASL (secure authentication layer) does not support encrypted passwords on Ubuntu, but guide helps us set-up SASL to ask PAM to compare passwords.

After hours of going through config files, I discovered that commenting out these lines:

inside /etc/pam.d/smtp, fixes authentication problems.

I encountered 1 more weird error, but that was very specific to my scenario, I doubt anyone in the wild will encounter it, but hey for completeness I will document it too.

Problem #4.

Sending mail from my postfix server to specific hostgator account was bouncing back emails.

Using telnet. I will just copy relevant lines here:

Weird, why is hostgator postfix verifying sender? Clearly mail came from another server, so why is hostgator checking if SENDER exists on its own system?

I ran another test, this time, sending mail from hostgatoraccount.com account that does not exist to existing one, to check if my theory was right:

Indeed, same error! So in fact hostgator installation of postfix was thinking that domain that was configured with my server in another datacenter was its own and was looking at itself for verification. This was clearly wrong. Besides, other servers were just fine with mails sent from my server.

I went on a long chat with several hostgator technicians on live support. And they all blamed my postfix installation for this error. They would not listen, had their own theories and were lazy to check. To cut the chase, hostgator server had my domain set as parked or add-on domain in cpanel. I contacted owner of this account directly, and he acknowledged problem and deleted my domain from cpanel, allowing me to send emails in that direction without bouncing it back.

Problem #5.

Some emails sent from my mail server are not being delivered, in the bounced back mail I see following header:

Problem in this case is obvious. Need to set-up PTR record.

PTR record resolves an IP address to a fully-qualified domain name (FQDN) as an opposite to what A record does. PTR records are also called Reverse DNS records.

PTR records are mainly used to check if the server name is actually associated with the IP address from where the connection was initiated, and some mail servers will not accept mail unless this record is present.

In some cases you will need to ask server provider to set-up this record. To check if PTR record exists for IP address you can use dig (unix/linux):

Result, if PTR record exists should have following:

Note IP will be reversed and appended with in-addr.arpa. Record will point to your FQDN.

Problem #6.

Some of my mails were finishing inside spam folder of gmail and other big mail provider users.

To increase credibility, and decrease amount of my mails wrongly tagged as spam, I added SPF record.

Sender Policy Framework (SPF) is an email validation system designed to prevent email spam by detecting email spoofing, a common vulnerability, by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF record (or TXT record) in the Domain Name System (DNS).

I simply added following in my mail server DNS.

Result was instantly verifiable by sending mail to gmail account. In mail header I saw this:

Meaning SPF was added correctly.

Problem #7.

If you, like me, have multiple users, than limiting disk space per inbox is essential. We don’t want users to go crazy and eat up all available space on the server.

(Note: table users created, while following postfix installation guide I linked at the top, contains column ‘quota’. We will use this to set disk space quota).

Before we can do this, we need to reinstall postfix with VDA patch. Follow this tutorial from #3 Apply The Quota Patch To Postfix.

Edit the /etc/postfix/main.cf, and add:

Next, create mysql_virtual_mailbox_limit_maps.cf in /etc/postfix/, and add:

Remember to adjust the username and password of the database accordingly.

Problem #8

Quota system was working ok, I tested it and indeed when inbox was full, postfix was bouncing back emails. But I had little trouble with displaying remaining disk quota to the users. I use rainloop as webmail, sleek and sexy, and I confimed with creator that it indeed does have feature to display remaining disk quota.

So problem was postfix/courier installation.

Manually testing courier confirmed this:

GETROOTQUOTA didn’t return anything.

Web research led me to: virtual_create_maildirsize = yes. But this option has been discontinued in current version of VDA postfix, since there is no documentation about vda postfix I couldn’t verify if this was changed into something else…

Finally I solved problem by deleting user directories in /var/mail/virtual/* and letting postfix recreate them. Surprisingly maildirsize file was created correctly this time.

Problem #9

Found a glaring problem with flurdy’s tutorial! If you followed tutorial, setup allows authenticated user to use another user’s sender address! This is unacceptable in any environment.

Easy to fix:

main.cf

create mysql_sender_access.cf in /etc/postfix dir.

Problem #10

AUTH PLAIN, AUTH LOGIN are working fine. It appears CRAM-MD5 and DIGEST-MD5 are not functioning correctly – no idea how to fix this at the moment.

/quit

Leave a Reply

Your email address will not be published. Required fields are marked *