Trouble sending email with PHP mail();

Take a look at the postfixinstallloopback_only function here:

http://www.linode.com/stackscripts/view … ScriptID=1">http://www.linode.com/stackscripts/view/?StackScriptID=1

That's how I installed postfix to send email from my server and it's been working just fine for me.

I got the postfix configured for loopback only and PHP mail() still goes away and dies. Any other ideas?

On the PHP.net site someone says that apparmor can interfere with postfix. I haven't found much on configuring apparmor and what I found is wrong??

Quote……

I recently had an issue where the mail() function would work fine from the php cli but not from apache.

I eventually traced this down to the fact that I was using apparmor specifically, I configured apparmor to deny the apache user the ability to use /bin/dash

After changing apparmor to /bin/dash rix

and reloading the apparmor profile, mail worked

In other words, mail requires the account/program executing the script to be able to use /bin/dash

I'm not sure why PHP's mail() needs access to the dash shell; it should only really need access to sendmail. Maybe it spawns a shell and runs the sendmail command in the background. (postfix or sendmail, they are the same as far as PHP is concerned.)

Anyway, if I remember correctly, Linode's OS images don't come with AppArmor by default. But that was a few years ago, so things might have changed. Or you might have installed it yourself.

If you have AppArmor enabled, you can disable it on Debian/Ubuntu systems by using the following commands:

/etc/init.d/apparmor stop
update-rc.d -f apparmor remove

If you get an error message telling you that /etc/init.d/apparmor doesn't exist, then you'll know that it's not enabled. In any case, try again when you're sure that AppArmor isn't enabled on your server.

Also, set errorreporting to EALL | E_STRICT and enable error logging in your php.ini file, and restart Apache. This will give you access to the maximum amount of error messages – down to the most trivial notices -- which might help track down the problem. PHP hides some errors by default, so you can't rely on what's shown on the browser.

Thanks for your reply,

Apparmor apparently is not installed currently because the OS say so when I try to run /etc/init.d/apparmor stop.

I turned on the PHP error reporting as you suggest. When running the PHPMailer test script I got the following error trying to send smtp through the gmail server:

SMTP -> ERROR: EHLO not accepted from server:

SMTP -> ERROR: HELO not accepted from server:

SMTP -> ERROR: AUTH not accepted from server:

SMTP -> NOTICE: EOF caught while checking if connectedSMTP Error: Could not authenticate. 1: Unable to send to: myaddress@gmail.com

Using mail(), sendmail, and the Qmail options on the PHPMailer test program, all report a happy outcome but I'm not getting any of the emails.

Also when I try sendmail from the command line it acts like it is working but I never get the email.

As for the SMTP errors, but maybe you're connecting to an SSL port without telling PHPMailer to use SSL, or vice versa?

Qmail is irrelevant here, because postfix is not Qmail.

As for mail() and sendmail, is there anything interesting in Postfix's own logs? There are several files in /var/log (mail.log, mail.err, mail.warn, etc.) which can tell you whether the messages were received properly from PHP, and whether they were delivered to the target server.

Also note that many e-mail services will reject e-mails if your hostname doesn't match the reverse DNS for your IP address. If you didn't specify the correct hostname when installing Postfix, you should edit /etc/mailname and /etc/postfix/main.cf (the "myhostname" line) and restart postfix. Otherwise your e-mails won't even reach the spam box.

As for the SMTP errors, but maybe you're connecting to an SSL port without telling PHPMailer to use SSL, or vice versa?

I think the telling is good, I'm using PHPMailer's own program for testing. The issued source looks very similar to the code I use on another server where I send email through the gmail ssl server successfully.

Qmail is irrelevant here, because postfix is not Qmail. Got it

As for mail() and sendmail, is there anything interesting in Postfix's own logs? There are several files in /var/log (mail.log, mail.err, mail.warn, etc.) which can tell you whether the messages were received properly from PHP, and whether they were delivered to the target server. mail.err and mail.log are 0 bytes long and mail.warn doesn't exist

Also note that many e-mail services will reject e-mails if your hostname doesn't match the reverse DNS for your IP address. If you didn't specify the correct hostname when installing Postfix, you should edit /etc/mailname and /etc/postfix/main.cf (the "myhostname" line) and restart postfix. Otherwise your e-mails won't even reach the spam box. When Postfix picked up the hostname at install time it was the same name as is in the hostname file. I took a look at main.cf and it's the same as shows with hostname -f. This issue confuses me on a virtual host server. I have 5 domain names I'm serving for and I need to send emails from each of those.

As for the hostname:

The hostname used by Postfix should be the same as the reverse DNS entry in your Linode's "Network" panel. This does not need to be related to any domain names hosted on the same server, and it does not even need to be the same as the server's own "hostname -f". You can use Linode's default reverse DNS entry if you'd like. Afterwards, you should go to the DNS manager and add an SPF record to each domain, which allows your server to send e-mails on behalf of those domains. (An SPF record is just a TXT record that begins with "v=spf1" followed by a list of hostnames. Find out what you need to put in your SPF record to use your domain with Google Apps, and add your hostname to it.)

Often, test e-mails will be delivered even without proper SPF records. But the hostname & reverse DNS is very important.

As for the log files:

That's weird. There should be something in there if you already tried sending e-mails. Are you sure Postfix is actually running? Try restarting Postfix and see if you get any errors. Also make sure that you don't have any other mail server running on the same Linode. If you already have sendmail-mta or exim, it will conflict with Postfix.

The reverse DNS lookup gives: "li220-189.members.linode.com"

hostname -f gives "scotthill.up_quark.com"

So, how might I go about fixing this?

Put "li220-189.members.linode.com" in /etc/mailname

Also put the same hostname in the "myhostname" line in /etc/postfix/main.cf

Restart Postfix.

@hybinet:

Put "li220-189.members.linode.com" in /etc/mailname

Also put the same hostname in the "myhostname" line in /etc/postfix/main.cf

Restart Postfix.

you might get some servers thinking the numbers makes it look like a dynamic IP/home connection.

@glg:

you might get some servers thinking the numbers makes it look like a dynamic IP/home connection.
If a home connection has a working reverse DNS entry, a matching HELO hostname, and a correct SPF record pointing at it, then any mail server had better accept the message. RBLs and SpamAssassin can take care of the rest.

Unfortunately, some services will spambox all your e-mails no matter what you have in your reverse DNS. I hope *.members.linode.com has a better reputation than any random domain, though.

I'm happy to report that I have outgoing email from within a php script using the PHPMailer package through ssl and the Google servers at smtp.gmail.com

Initially the email was being marked as from li220-189.members.linode.com and flagged as a problem by my receiving mail account. But after entering the TXT suggested here and by Google Apps: "v=spf1 include:_spf.google.com ~all" now emails are being marked as from who I want them to be marked from.

My understanding of this is very fragile and I still need to make a number of other domains and users work but as of tonight tonight I am a lot less frustrated. I have until November to move a bunch of domains to this Linode instance and make them work so I don't have to renew service on the old server network.

Thanks for your help folks.