XF 1.4 Bounce Handler error: cannot read - connection closed?

[melbo]

Bounced email handling issue:

• Created a new inbox (on my server) dedicated to bounced emails
• Set XF ACP options to use this bounced email address, -f parameter, provided domain, port, user and pass as appropriate. ports are correct
• Inspected a regular board email and the VERP (+stuff+more=stuff) is present in headers. SPF and DKIM also functional, passed
• New inbox is receiving bounced emails
• XF is not processing these emails as bounced and throwing errors on every cron as listed in the title: cannot read - connection closed? This also occurs if I run the cron manually.
• Email Bounce log is empty
• Have tested as imap and pop with similar results.

This is more than likely a server issue on my part but I've beaten my head against it since Tuesday and thought maybe I'm missing something easy

Error Info
Zend_Mail_Protocol_Exception: cannot read - connection closed? - library/Zend/Mail/Protocol/Imap.php:139
Generated By: Unknown Account, Today at 2:08 PM

Stack Trace
#0 /home/user/public_html/library/Zend/Mail/Protocol/Imap.php(155): Zend_Mail_Protocol_Imap->_nextLine()
#1 /home/user/public_html/library/Zend/Mail/Protocol/Imap.php(104): Zend_Mail_Protocol_Imap->_assumedNextLine('* OK')
#2 /home/user/public_html/library/Zend/Mail/Storage/Imap.php(273): Zend_Mail_Protocol_Imap->connect('localhost', 993, 'TLS')
#3 /home/user/public_html/library/XenForo/Model/EmailBounce.php(292): Zend_Mail_Storage_Imap->__construct(Array)
#4 /home/user/public_html/library/XenForo/Deferred/EmailBounce.php(19): XenForo_Model_EmailBounce->openBounceHandlerConnection()
#5 /home/user/public_html/library/XenForo/Model/Deferred.php(256): XenForo_Deferred_EmailBounce->execute(Array, Array, 7.9999988079071, '')
#6 /home/user/public_html/library/XenForo/Model/Deferred.php(390): XenForo_Model_Deferred->runDeferred(Array, 7.9999988079071, '', false)
#7 /home/user/public_html/library/XenForo/Model/Deferred.php(335): XenForo_Model_Deferred->_runInternal(Array, NULL, '', false)
#8 /home/user/public_html/deferred.php(23): XenForo_Model_Deferred->run(false)
#9 {main}

Request State
array(3) {
["url"] => string(43) "https://www.domain.com/deferred.php"
["_GET"] => array(0) {
}
["_POST"] => array(4) {
["_xfRequestUri"] => string(10) "/admin.php"
["_xfNoRedirect"] => string(1) "1"
["_xfToken"] => string(8) "********"
["_xfResponseType"] => string(4) "json"
}
}

 

[Jake Bunce]

That error means XenForo is failing to connect to the mail server. You need to confirm your bounce mail server settings:

Admin CP -> Home -> Options -> Email Options -> Automated Bounced Email Handler

 

[Jim Boy]

Its these sort of reasons why XF should have developed an API that emails can get submitted directly to, rather than having to faff about with managing inboxes and permissions.

 

[TPerry]

The biggest problem I had was configuring dovecot and getting it to play nicely with Postfix. Once I did that, everything worked well. Now I just have to do it on the other 3 VPS's.

 

[Jeremy P]

Its these sort of reasons why XF should have developed an API that emails can get submitted directly to, rather than having to faff about with managing inboxes and permissions.

Uhh, what? For that to even work at all without an existing email server receiving mails, XenForo would have to create, at the very least, an SMTP daemon.. which then would mean the feature wouldn't work on shared hosting providers (not to mention take a lot of work to basically reinvent the wheel).

It's literally a cakewalk to enter the host, username, and password to an existing IMAP service. If you consider that a lot of work then I really don't know what to say.

 

[TPerry]

It's literally a cakewalk to enter the host, username, and password to an existing IMAP service. If you consider that a lot of work then I really don't know what to say.

Highlighted the important portion. Not everyone sets their server up for remote mail access. None of mine were since I either read the mail on the actual VPS when logged in via SSH or just forward them to another email account on another domain.

 

[Jeremy P]

Oh, I agree, configuring email stacks sucks. Hard. I gave up on that after I had to upgrade dovecot and postfix to new major versions at the same time a few years ago.

I just don't see XF developing an SMTP daemon as the proper alternative. If someone can't be bothered, they don't have to use the bounce handling.

Even then, if they're willing to forego a @domain.com email they can send through Mandrill (and their domain) and have the reply/bounce/board contact email be boardname@gmail.com (or almost any other free provider), which supports IMAP out of the box.

Or even buy Google Apps or use Mandrill inbound if the @yourdomain.com is that important and you don't want to be responsible for administering an email service. It just seems like a joke to suggest that it should be XenForo who are responsible for providing working email daemons for this optional feature.

 

[melbo]

The biggest problem I had was configuring dovecot and getting it to play nicely with Postfix

This is probably where my issue lies as the server settings in the ACP are correct. I can hit the box from thunderbird or my iPhone. Been reading about SSL IMAP timeouts in PHP but haven't gotten anything to work yet.

Thanks for the tips.

 

[Jim Boy]

Uhh, what? For that to even work at all without an existing email server receiving mails, XenForo would have to create, at the very least, an SMTP daemon..

All you need is postfix - very simple then to configure it so that it passes any emails received directly to a php script, which wouldbe part of XF. It's not a solution that will work for everyone or people running on cpanel, but the current solution is not suitable for large forums. As it I see that am going to have write my own add-on.

Or even buy Google Apps

Google apps want people to use their services, not apps, they will from time to time throw up some process to show you are human if they suspect you aren't. The first you'll now about it is when nothing comes through in your inbox for long periods. Anyway why spend money when there is a free and more reliable solution?

 

[melbo]

Could this have anything to do with running a commercial SSL cert on the domain but a self signed cert for email on php 5.6? Seems like this is discussed here: https://xenforo.com/community/threads/php-5-6-0-released.81903/#post-817668

I do not have any SSL Context Options set which means that verify_peer & allow_self_signed are likely defaulting against me.

 

[AlexT]

All you need is postfix - very simple then to configure it so that it passes any emails received directly to a php script, which wouldbe part of XF. It's not a solution that will work for everyone or people running on cpanel, but the current solution is not suitable for large forums.

Having postfix spawn a php script for each incoming bounce email is certainly not suitable for large forums.

Using IMAP to process bounces is the most suitable and flexible way using the KISS principle.

 

[Mike]

Could this have anything to do with running a commercial SSL cert on the domain but a self signed cert for email on php 5.6? Seems like this is discussed here: https://xenforo.com/community/threads/php-5-6-0-released.81903/#post-817668

I do not have any SSL Context Options set which means that verify_peer & allow_self_signed are likely defaulting against me.

It's certainly very possible. Unfortunately, there isn't a way to globally disable peer validation in PHP 5.6 (it has to be done for each connection) so it would require code changes (this is happening in Zend Framework code mostly). If you have a non-encrypted method, that may be useful for testing.