CiviCRM Community Forums (archive)

Which version did you update from and to?

You need to investigate your email server logs – it’s a bit hard to guess what’s wrong.

I upgraded from 1.9 to 2.0, then to 2.1.

Ah, that’s good to know. We haven’t encountered any reports on bounces generated by CiviCRM 2.1. (Please also consider updating your forum profile with the versions you use – once you’re settled down after the upgrade, of course.)

When can I find those logs?

It depends what you use for sending. I assume you’re not using CiviSMTP, so you need to look at your system’s mailserver’s logs; if this is a shared hosting, you might need to ask the administrator(s).

I'm on Bluehost shared hosting so I cannot access the logs.

You might also want to search this forum with the Bluehost keyword to see whether other CiviCRM users did not face this (or other relevant) issue.

Please edit the 122^nd line of packages/Mail/smtp.php and change the $debug variable to true:

    var $debug = false;

Maybe this will tell you what is the exact problem with your SMTP configuration.

Code: [Select]

[…]
DEBUG: Recv: 235 Authentication succeeded
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK


Up to this place it looks ok.

Code: [Select]

DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 250 Reset OK
DEBUG: Send: RSET
DEBUG: Recv: 554 Too many nonmail commands
DEBUG: Send: RSET ...


Now this looks clearly wrong, and it’s no wonder the server gives up in the end with a 554 result.

I dug into the PEAR classes we use for SMTP, and it looks like it’s the Net_SMTP’s rset() function that’s misbehaving (but, apparently, only in your host’s case).

Please edit the packages/Net/SMTP.php file, and where the 1017^th line starts the rset() function, change it from

    function rset()
    {
        if (PEAR::isError($error = $this->_put('RSET'))) {
            return $error;
        }
        if (PEAR::isError($error = $this->_parseResponse(250, $this->pipelining))) {
            return $error;
        }

        return true;
    }

to

    function rset()
    {
        return true;
        if (PEAR::isError($error = $this->_put('RSET'))) {
            return $error;
        }
        if (PEAR::isError($error = $this->_parseResponse(250, $this->pipelining))) {
            return $error;
        }

        return true;
    }

– i.e., make the function return true right away; maybe it’ll make this problem go away.

thanks for your suggestion. I've changed the code, but I'm still not receiving the test mailing message.

Is the debug output the same? What the above fix did was to return early from the RSET call, so it shouldn’t be stuck in the RSET loop that made the SMTP server drop the connection.

What bugs me is that it used to work on my old install so it should work with my host.

Maybe I should reconfigure everything from the start or look for professional help.

It’s definitely some bad interaction between CiviCRM (or, rather, the PEAR packages we ship) and your SMTP server, so you need to debug what exactly triggers the misbehaviour.

Sorry, I forgot to paste the new output:

Code: [Select]

[…]
DEBUG: Recv: 235 Authentication succeeded
DEBUG: Send: QUIT
DEBUG: Recv: 221 box362.bluehost.com closing connection


Ok, I dug deeper into the PEAR Net and Mail classes and the above most probably means that the ‘235 Authentication succeeded’ response is not treated as a successful one by PEAR (hence the RSET commands before and the QUIT one above).

Please revert the rset() function to the state it had before, and you need to debug (or get someone to debug) why the _authLogin() function in the packages/Net/SMTP.php file’s 648^th line does not work as expected (if it’s indeed the place that breaks). From what I see this function should properly parse a 235 response…