Support Module Doesn't Receive Email

[Darin]

I have been unsuccessful in my attempts to get the support module to receive email.

 

When I try piping, I get a bounce with the following error:

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

pipe to |/home/myusername/public_html/dev/index.php plugin/support_manager/ticket_pipe/index/1
  generated by support@dev.mydomain.com
  local delivery failed

When I try IMAP or POP retrieval, nothing is retrieved or marked as read/deleted.

 

The various Blesta logs show nothing. No errors are logged on my server.

 

Sending email from Blesta, including support responses for tickets submitted online, works fine.

 

I’ve read every thread in these forums that I can find for email or piping, but nothing has proved a solution for me.

 

cPanel WHM 11.42.1 (build 26)

PHP 5.3.28

MySQL 5.1.67

CENTOS 5.11

 

I’ve made sure that my support address is correctly forwarded for piping in cPanel.

 

I’ve tried piping using both pipe.php and index.php, with and without the hashbang.

 

I’ve made sure that my php path (/usr/local/bin/php) is correct in the hashbang and cron. All other Blesta cron tasks are working fine.

 

I’ve confirmed via phpinfo() that Mailparse is installed (and I didn’t get a mailparse error when I selected piping in the support department). FYI, in my situation I have to use SuPHP in the Blesta .htaccess file to include mailparse.

 

I’ve tested that the given IMAP and POP credentials work in my mail client.

 

I’ve tried manually running the cron.

 

I’ve made sure that all related directory and file permissions are 755 or 777.

 

I have another application installed on the same cPanel account as Blesta, and piping to it works perfectly. I’ve double checked that all permissions, php paths, piping settings, etc. are the same in both apps.

 

This is driving me insane! I don’t know what to try next.

[Darin]

Resolved!

I will explain how I fixed these email issues, but first I want to acknowledge that it was ultimately about my server’s configuration, not a problem with Blesta.

I also thought I should give a lot of detail here, in case it helps anyone else experiencing these issues.

For reference, I’m on a shared hosting reseller account using cPanel. Other systems are likely a bit different. Additionally, Blesta is installed in the webroot of the dev subdomain.

Part 1 - Mail piping

I think this is more of an issue for people who don’t fully control their server, such as shared hosting resellers, because our options for changing server defaults are limited.

As Blesta’s manual states, “The Support Manager requires the MailParse PHP extension in order to parse tickets sent in through email.” Since Mailparse was not available on my server by default, I asked my provider to install Mailparse in my cPanel account and add a custom php.ini file in my dev directory, the path to which I then defined in the Blesta .htaccess file with SuPHP_ConfigPath.

SuPHP_ConfigPath /home/username/public_html/dev/

This works fine for anything accessed in a browser, so when I set up a support department to use email, Blesta didn’t give me any errors.
 
However, it doesn’t necessarily work for commands run via the command-line interface (aka CLI), such as the cron automation used for POP/IMAP retrieval, or the pipe.php script used for email piping. This all depends on your server’s PHP configuration. I had seen references to this in other posts, but I don’t recall seeing specific examples of potential solutions. Since I’d never had to deal with this particular issue in my other web applications, I dismissed it as being irrelevant to my situation. Wrong!
 
My provider’s support team finally realized that my custom php.ini, and therefore Mailparse, wasn’t being used by the cron or pipe.php.

For the cron job, I was able to rectify this by using php -c path to include the custom php.ini.

New cron:

/usr/local/bin/php -c /home/username/public_html/dev/myphp.ini -q /home/username/public_html/dev/index.php cron

For pipe.php, it was a bit more challenging, because I continued to get a bounce error after I appended -c /home/username/public_html/dev/myphp.ini to the hashbang that cPanel had added to the beginning of the script when I set up the mail forwarder to pipe.
 
Eventually, I found this post, which explained that PHP apparently only allows one argument in the hashbang. I finally got it to work by concatenating -q -c and path into one argument.
 
New pipe.php hashbang:

#!/usr/local/bin/php -qc/home/username/public_html/dev/myphp.ini

Success with email piping!
 
I had a working system, so I could have stopped there. But, I also wanted to figure out why POP/IMAP still wasn’t working, even though I didn’t really need it because I now had piping.
 
Part 2 - POP/IMAP Retrieval

The above cron tweak should have fixed my POP/IMAP retrieval issue, so I was surprised when Blesta still didn’t retrieve email.

Again, my provider’s support team found the problem. This time, it was a mail hostname issue that appears to be due to a bug in cPanel.

When I created the dev subdomain, cPanel’s mail client configuration page said to use mail.dev.mydomain.com for the incoming server. However, cPanel failed to create the corresponding DNS record, so checking mail using that hostname failed. I didn’t catch this earlier, because I was using a webmail client that accepted my username and password, but didn’t require the server/host name.

All I had to do was switch Blesta's support department to use my main domain’s mail hostname (mail.mydomain.com) or the server’s generic one.

Problem solved!

All Blesta mail is now flowing as it should, whether incoming or outgoing, piped or retrieved via POP/IMAP. 

[Michael]

Try using /usr/bin/php depending on your cPanel installation that might be the correct one.

[Darin]

Try using /usr/bin/php depending on your cPanel installation that might be the correct one.

 

/usr/local/bin/php is definitely the correct path for my installation. It's the only way anything else works.

[Michael]

/usr/local/bin/php is definitely the correct path for my installation. It's the only way anything else works.

 

Weird it might be the like the issue a client had, but he's crons didn't work on cPanel either which is why he moved to another control panel. Are you hosting on your own VPS or a reseller account?

[Darin]

Weird it might be the like the issue a client had, but he's crons didn't work on cPanel either which is why he moved to another control panel. Are you hosting on your own VPS or a reseller account?

 

I'm not on a VPS, just a reseller account.

 

My cron runs fine. All other Blesta tasks appear to be happening as scheduled. I also have a handful of other cron jobs that run for another app on this account without issues. As far as I can tell, it's not a problem with cron.

 

Piping also works in the other app on this account, so I'm thinking that it's got to be something specific to Blesta.

[Michael]

Piping also works in the other app on this account, so I'm thinking that it's got to be something specific to Blesta.

 

I don't believe it's Blesta, you've done everything correct, and I've done piping many of times on cPanel & InterWorx, and never had an issue except that once helping one client which piping and the crons didn't work. It confused us both and he said he also hated cPanel.

[Blesta Addons]

out the subject , are you still use "CENTOS 5" !!!

[Darin]

My my server support team sent me the following message:

 

We believe there is a problem with your PHP script. While running strace on the pipe process my colleagues found that it hangs while trying to read one of your PHP includes:

 

lstat("/home/myusername/./attachment.class.php", 0x7fff42ae46e0) = -1 ENOENT (No such file or directory)

 

The file /home/myusername/./attachment.class.php clearly does not exist so you'll need to adjust your file paths manually to ensure that it looks for attachment.class.php in the correct location. If you continue to experience difficulties with your pipe script, please also ensure that you use binary mode while uploading through an FTP client. The correct path for attachment.class.php appears to be the following:

 

/home/myusername/public_html/dev/plugins/support_manager/vendors/mime_mail_parser/attachment.class.php

 

Does this mean that pipe.php is somehow including an incorrect path?

 

I'm using Blesta 3.3 and pipe.php is unchanged, except for the required hashbang we've added at the top.

[Michael]

You might not have a mail parser on the server.

[Blesta Addons]

 

My my server support team sent me the following message:

 

 

Does this mean that pipe.php is somehow including an incorrect path?

 

I'm using Blesta 3.3 and pipe.php is unchanged, except for the required hashbang we've added at the top.

 

 

 

upload the support manager plugin from clean blesta source , and try again .

 

also make sure you have set the correct path in blesta settings .

[Darin]

upload the support manager plugin from clean blesta source , and try again .

 

also make sure you have set the correct path in blesta settings .

 

I deleted support manager, then downloaded a fresh copy of 3.3 from the Blesta website and uploaded a new copy of support manager directly from it to my installation. I also deleted my mail forwarder and re-added it. cPanel automatically set permissions and added the correct hashbang to pipe.php

 

I double checked that the path in Blesta settings was correct.

 

Still, I get the same mail bounce error when trying to pipe, and no mail is retrieved when trying to use POP or IMAP.

 

You might not have a mail parser on the server.

 

I do have mailparse, as per my first post. phpinfo confirms that mailparse is installed. But I will ask server support to double check mailparse, just in case there is an issue with it.

 

I appreciate all your efforts to help me try to resolve this! I hope we find a solution.

[Blesta Addons]

Glade you have finally resolved.