Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

The title is a bit misleading... what I want to do is a little complicated:

I want to set up my server (running Ubuntu 10.04 Desktop) to send email using PHP's mail() function.

I tried just using it, but the messages don't go anywhere and the return value of mail() is not FALSE, so I really don't know what's going on.

Any advice/ideas for configuring this?

share|improve this question

2 Answers 2

up vote 4 down vote accepted

Here's my opinion of the correct way to accomplish this, and it's not significantly hard if all you want to do is sent out mail for php via your ISP's SMTP server.

Ensure you have an MTA installed on your ubuntu instance, my preference is postfix, but you can use a different one (exim, qmail are both fine), however some of these instructions will need to be adapted/separately researched if you do.

# apt-get install postfix postfix-doc

Then we'll need to tell it how to send out mail to the internet using you're isp's smtp server, you should already have this info, it may be referred to as your Outgoing mail server, replace with this information.

# postconf -e

This will adjust your postfix configuration file to enable your mail server to send to the outside world.

Now we need to edit php.ini to tell it the location of the sendmail binary, this binary is not actually a sendmail MTA but a wrapper for postfix that provides a known consistent sendmail-like interface.

By default in debian/ubuntu the postfix sendmail binary is in /usr/sbin/sendmail.

# whereis sendmail

Will assist you to locate it.

Now that we have the full path for the sendmail binary, we can edit the php.ini file, it should be located in /etc/php5/apache2/php.ini, open it in whatever editor you're familiar with.

Locate the section marked [mail function] and comment out the SMTP and smtp_port directives.

Uncomment sendmail_path and add the full path to the sendmail binary directly after the = sign.

Then issue this

# /etc/init.d/postfix restart
# /etc/init.d/apache2 restart

Then try sending a message from a php script, if it fails check the /var/log/ file.

share|improve this answer
Well, as long as you install postfix (or any other "normal" MTA) using your package manager the default value for sendmail_path= will do fine. Just leave it commented out. That way you will also get the "right" options added. – andol May 15 '10 at 9:59
Also, regarding the install of postfix, you probably want to choose "satellite system" during its install. That way you'll get a chance to directly specify your relayhost. – andol May 15 '10 at 10:01
True, but prefer getting my hands dirty, and you learn more this way :) – Aaron Tate May 18 '10 at 2:21

EDIT The following suggestions are merely troubleshooting steps to determine where the break-down is happening and not suggestions for long-term solutions. END EDIT

Telnet to the server over port 25 that hosts the user you're trying to connect to and initiate a mail session. For example, if you're emailing then you would first get the mx record for (using nslookup), then telnet to the mx record thusly:

telnet 25

From there, follow the WikiHow article I linked to above to attempt to send a mail message to that user. If it works but your PHP script doesn't, then it's time to break out wireshark and see what the network traffic tells you.

Also, can you get the mail() function to work at the PHP CLI rather than through Apache? Are you using AppArmor? What about the (in)famous SELinux?

share|improve this answer
Sorry, in my opinion this is the wrong way™. It is likely that his 'script' is going to properly handle deferred email messages? My post, below is in my opinion the correct way. Doing it this way will break numerous RFC's and cause some if not most well configured MTA's to blacklist you or treat you as a spammer. – Aaron Tate May 15 '10 at 9:18
Why on earth would one want to do something like that? – andol May 15 '10 at 10:02
@fenis and @andol: I was only suggesting those methods as troubleshooting steps to see where the breakdown was taking place. Telnet to see if it was the remote mailserver's issue. The PHP CLI to see if it was an AppArmor problem. Checking SELinux to see if it was a rule allowing traffic out but not in. I've edited my answer to make it clearer that I am not suggesting those are ways to solve the problem, but only to narrow down the field of possible problems. Thanks! – Wesley May 15 '10 at 16:51
Oh, yes ok, an odd first step to take but a useful one once all the local stuff has been ruled out, i've adjusted my vote. – Aaron Tate May 18 '10 at 2:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.