SysAdmin | sys·ad·min | noun - A system administrator. The duties of a system administrator are wide-ranging, and vary widely from one organization to another. Sysadmins are usually charged with installing, supporting, and maintaining servers or other computer systems, and planning for and responding to service outages and other problems.

Untangling Multiple Mailserver Issues

on Nov 16, 2011 | Case studies | 783 comments

A client was having various problems with email being sent from a new server:

  1. Mail sent from the server was going into e.g. the recipient's Hotmail junk folder
  2. Client was receiving a failure notice from the mail server:
    This message is looping: it already has my Delivered-To line
  3. Some mail sent from the webserver failed with:
    421 Can't connect to an MX for envelope sender's hostname

We'll deal with these one at a time:

1. Hotmail classified the email as junk as it couldn't verify that it was sent from the domain it said it was sent from. This is an effective way to screen junk mail. Avoid your email being junked by creating an SPF record - a record in your DNS zone file that identifies which server(s) are allowed to send mail for the domain. There are many online SPF record generators around, this is what we used. Here's the SPF record we put into the DNS zone file (leaving the first (name) field empty):

v=spf1 a mx a:webserver.domain1.com a:mailserver.domain2.com ip4:x.x.x.x ip4:x.x.x.x -all

Seeing as we used the "a" mechanism (matches any A records in the zone file), naming the servers wasn't strictly necessary, but I wanted them there for completeness. You will notice 2 servers there - this is so that the client's website, and their 3rd party mail hosting provider can both send emails from the same domain. After waiting for the DNS changes to propagate, you can then test your SPF records using various means - we used this automated checker at port25.com.

2. The looping message problem. Here's the scenario: when a new user registers on the webserver, it sends two emails as admin@domain.com: one to the new user, and one to admin@domain.com.

The mailserver was configured with an admin@domain.com account, which forwarded any mails sent to that address to the appropriate people. It also had an auto-reponder to send an acknowledgement to anyone emailing that address. This created a loop.

The webserver only allowed one from: address to be configured.

Solution: send from the webserver as no-reply@domain.com, set up the no-reply@ account on the mailserver, which forwards to the appropriate people (in case someone does reply!) but NO auto-responder. Leave the admin@ account as is for all legit enquiries. Put a message on emails sent from the webserver to send all correspondance to admin@.

This may seem obvious, but it had us tied in knots for hours!

PHP needed forcing to use the from: address we wanted by editing php.ini thus:

sendmail_path ="/usr/lib/sendmail -t -i -f no-reply@domain.com"

(It turns out that /usr/lib/sendmail points to /etc/alternatives/mta-sendmail which points to /usr/lib/sendmail.postfix which points to /usr/sbin/sendmail.postfix!)

3. The "can't connect to an MX for envelope sender's hostname" problem on the webserver.
First, we removed sendmail. The full-blown sendmail server had been installed on the webserver - this was unnecessary, as it just needed to send mail out, not receive mail and host accounts etc. It was also confusing the whole process of sending mail.

yum remove sendmail

This meant that PHP could now use postfix to send mails, as was intended. However, the following error occurred:

postdrop: warning: unable to look up public/pickup: No such file or directory.

This is fixed by recreating a named-pipe which is required by postfix:

mkfifo /var/spool/postfix/public/pickup

...and restarting postfix.

Next we had to configure everything sending email to send as user@domain.com instead of user@server.domain.com. PHP was already taken care of, but postfix needed sorting - this meant editing the file /etc/postfix/main.cf, changing:

myorigin = $myhostname
to
myorigin = $mydomain

...and restarting postfix.

We were still seeing errors in /var/log/maillog. Typing mailq showed lots of old mail still in the mail queue. It turns out the system was still trying to send mails from before we reconfigured everything. Clearing the queue with:

postsuper -d ALL

fixed the problem.

Back

Comments

Comments: