Postfix MTA configuration problems and solutions Ubuntu 12.04
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.
1 2 3 |
telnet mail.domain.com 25 mail from: me@gmai.com rcpt to: existinguser@domain.com |
I got instant reject: RCPT
Log file (/var/log/mail.log) said following:
1 2 3 4 5 |
Jan 3 20:37:38 domain postfix/smtpd[1802]: warning: connect to 127.0.0.1:10023: Connection refused Jan 3 20:37:38 domain postfix/smtpd[1802]: warning: problem talking to server 127.0.0.1:10023: Connection refused Jan 3 20:37:39 domain postfix/smtpd[1802]: warning: connect to 127.0.0.1:10023: Connection refused Jan 3 20:37:39 domain postfix/smtpd[1802]: warning: problem talking to server 127.0.0.1:10023: Connection refused Jan 3 20:37:39 domain postfix/smtpd[1802]: NOQUEUE: reject: RCPT from [79.6.235.127]: 451 4.3.5 Server configuration problem; from=<me@gmail.com> to=<existinguser@domain.com> proto=ESMTP helo=<mail.domain.com> |
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
1 |
POSTGREY_OPTS="--inet=127.0.0.1:10023 --max-age=365" |
Problem #2.
Testing IMAP over ssl:
1 2 3 4 5 |
openssl s_client -connect mail.domain.com:993 -quiet a1 LOGIN MyUsername MyPassword a2 LIST "" "*" a3 EXAMINE INBOX a4 LOGOUT |
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:
1 2 3 |
Jan 4 09:25:55 domain postfix/smtpd[3063]: SSL_accept error from [79.6.235.127]: lost connection Jan 4 09:25:55 domain postfix/smtpd[3063]: lost connection after STARTTLS from [79.6.235.127] Jan 4 09:25:55 domain postfix/smtpd[3063]: disconnect from [79.6.235.127] |
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:
1 |
imapd-ssl: couriertls: /etc/ssl/certs/ssl-cert-snakeoil.pem: error:0906D06C:PEM routines:PEM_read_bio:no start line |
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
1 |
openssl gendh >> snakeoil.pem |
Problem was solved. But there was a new error…
Problem #3.
Again with SMTP:
Excerpt from /var/log/mail.log
1 2 3 4 |
May 7 21:42:27 domain postfix/smtpd[5668]: connect from [12.34.956.178] May 7 21:42:30 domain postfix/smtpd[5668]: warning: SASL authentication failure: Password verification failed May 7 21:42:30 domain postfix/smtpd[5668]: warning: e[12.34.956.178]: SASL PLAIN authentication failed: authentication failure May 7 21:42:33 domain postfix/smtpd[5668]: warning: [12.34.956.178]: SASL LOGIN authentication failed: authentication failure |
Excerpt from /var/log/auth.log
1 2 3 4 5 6 7 8 9 |
May 7 21:42:27 domain postfix/smtpd[5668]: sql auxprop plugin using mysql engine May 7 21:42:28 domain saslauthd[5659]: pam_unix(smtp:auth): check pass; user unknown May 7 21:42:28 domain saslauthd[5659]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= May 7 21:42:30 domain saslauthd[5659]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure May 7 21:42:30 domain saslauthd[5659]: do_auth : auth failure: [user=postmaster@foo.bar] [service=smtp] [realm=ccmail.me] [mech=pam] [reason=PAM auth erro$ May 7 21:42:30 domain saslauthd[5660]: pam_unix(smtp:auth): check pass; user unknown May 7 21:42:30 domain saslauthd[5660]: pam_unix(smtp:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= May 7 21:42:33 domain saslauthd[5660]: DEBUG: auth_pam: pam_authenticate failed: Authentication failure May 7 21:42:33 domain saslauthd[5660]: do_auth : auth failure: [user=postmaster@foo.bar] [service=smtp] [realm=ccmail.me] [mech=pam] [reason=PAM auth erro$ |
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:
1 2 3 |
#@include common-auth #@include common-account #@include common-password |
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:
1 2 3 4 5 6 |
mail from: sandro@postfixdomain.com 250 OK rcpt to: exists@hostgatoraccount.com 550-Verification failed for <sandro@postfixdomain.com> 550-No Such User Here" 550 Sender verify failed |
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:
1 2 3 4 5 6 |
mail from: thisuserdoesnotexist@hostgatoraccount.com 250 OK rcpt to: exists@hostgatoraccount.com 550-Verification failed for <thisuserdoesnotexist@hostgatoraccount.com> 550-No Such User Here" 550 Sender verify failed |
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:
1 2 3 |
Diagnostic-Code: smtp; 550 We cannot accept email from IP XX.XXX.XXX.X without a DNS PTR record. Contact your ISP/HSP to set up a PTR record for your server. |
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):
1 |
dig -x XX.XXX.XXX.6 |
Result, if PTR record exists should have following:
1 |
6.XXX.XXX.XX.in-addr.arpa. 86400 IN PTR mail.domain.com. |
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.
1 2 3 4 5 |
Name: mymailserverdomain.com TTL: 14400 Class: IN Type: TXT Record: v=spf1 a mx ptr ip4:XX.XXX.XXX.6 mx:mail.mymailserverdomain.com -all |
Result was instantly verifiable by sending mail to gmail account. In mail header I saw this:
1 2 3 |
Received-SPF: pass (google.com: domain of sandro@mymailserver.com designates XX.XXX.XXX.6 as permitted sender) client-ip=XX.XXX.XXX.6; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sandro@mymailserver.com designates XX.XXX.XXX.6 as permitted sender) smtp.mail=sandro@mymailserver.com |
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:
1 2 3 4 5 6 |
virtual_maildir_extended = yes virtual_mailbox_limit_maps = mysql:/etc/postfix/mysql_virtual_mailbox_limit_maps.cf virtual_mailbox_limit_override = yes virtual_maildir_limit_message = Sorry, the user's maildir has no space available in their inbox. virtual_overquota_bounce = yes proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps |
Next, create mysql_virtual_mailbox_limit_maps.cf in /etc/postfix/, and add:
1 2 3 4 5 6 7 8 |
user=mail password=mailPASSWORD dbname=maildb table=users select_field=quota where_field=id hosts=127.0.0.1 additional_conditions = and enabled = 1 |
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:
1 2 3 |
openssl s_client -connect mail.domain.com:993 -quiet a1 LOGIN MyUsername MyPassword a2 GETROOTQUOTA INBOX |
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
1 2 3 4 5 |
smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch, permit_sasl_authenticated, permit_mynetworks, warn_if_reject reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauth_pipelining, permit smtpd_sender_login_maps = mysql:/etc/postfix/mysql_sender_access.cf proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps $virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains $relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps $recipient_canonical_maps $relocated_maps $transport_maps $mynetworks $virtual_mailbox_limit_maps $smtpd_sender_login_maps |
create mysql_sender_access.cf in /etc/postfix dir.
1 2 3 4 5 6 7 8 |
user=dbuser password=dbpassword dbname=maildb table=users select_field=id where_field=id hosts=127.0.0.1 additional_conditions = and enabled = 1 |
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