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.
In components/email/email.php at line 90
private function newMessage() {
$this->message = Swift_Message::newInstance();
$this->message->setMaxLineLength($this->max_line_length);
$this->message->setCharset($this->charset);
}
add this line before the closing curly bracket:
$this->message->setReturnPath('bounces@example.com');
so that you end up with this:
private function newMessage() {
$this->message = Swift_Message::newInstance();
$this->message->setMaxLineLength($this->max_line_length);
$this->message->setCharset($this->charset);
$this->message->setReturnPath('bounces@example.com');
}
It will add your custom return-path to outgoing mail.
It would be nice to see this as an option for each company in Settings.
