swiftmailer, ovh, INTERMITTEND Expected response code 250 but got code "", with message ""

Question

This very same problem already has some similar entries in stackoverflow, but none of them ever had any answers/solutions apart from some more basic coding hints.

I am using Symfony2 framework+swiftmailer on an OVH shared server and when sending a mail through the user interface (of the web page) I am getting intermittently the http error: Expected response code 250 but got code "", with message "".

With some googling for this error I understand that the server receives an order to read a mail, which is empty, so that it does not know what to do with an empty mail (no to, no from, no body, ...NULL in a way).

I am not sending mass mail, only one after one. The intermittent character of this makes debugging awkward as anytime you make a little tweak and it seems to work, you can not not be sure if the last tweak fixed it or if "it" simply decided to "wake up" again. So far all my little counter tweaks ended up that the empty smtp return from the server popped up again after some hours/some days. Because of this I am still hiding the site behind a htaccess so that traffic is extremely small (it is basically only myself). Intermittence is around 5 to 10% of all mails. If that empty error appears then for 95% of any tweak in the code the error remains. There is only one "tweak" which so far made the error go away "reliably": reloading the parameter.yml, but since there is 5% of cases where I tweaked something else and the error also went away I can't be sure if I should concentrate on the parameters. But again, the error will come back after hours/days in any case. The whole looks more like a server-cache/CDM issue.

Here's the details of code to be known (since it is working "most of times", the code as such is probably clean.. but one never knows).

parameters.yml:

mailer_transport: smtp
mailer_host: ssl0.ovh.net
mailer_port: 465 
# OR alternatively (gives the same result) :
#    mailer_host: ns0.ovh.net
#    mailer_port: 587
mailer_user: *********
mailer_password: **********

config.yml:

transport: "%mailer_transport%"
host:      "%mailer_host%"
username:  "%mailer_user%"
password:  "%mailer_password%"
port:      "%mailer_port%"

# and also :
fos_user :
    from_email:       
        address:      ********* (same as mailer_user)
        sender_name:  ***********

controllerXYZ:

$mailer=$this->get('mailer');
$params=$form->getData();
$subject=$params['subject'];
$body=$params['body'];
$userManager=$this->get('fos_user.user_manager');
$toUser=$userManager->findUserBy(array('username'=>$comment->getAuthor()));
$to=$toUser->getEmail();
$from=$this->getUser()->getEmail();

$message= \Swift_Message::newinstance()
->setSubject($subject)
->setBody($body)
->setFrom($from)
->setTo($to);

$mailer->send($message);

I "tweaked" with sleep(x), with \vendor\SM\SM\lib\classes\Swift\Transport, file=EsmtpTransport.php timeout, some try/catches, ports/server id's, spool but always got the error back after a while. All the tweaks are set back to "standard" of course.

I could try another mailer (phpmail), but since it seems OVH/CDM/server related I am worried to get the same thing again.

Alternatively I could also try to make the error appear "on purpose" to get a hint; but I could not even get that done.

GIVE ME PLEASE A DIRECTION TO TRY OUT!

Answer 1

i got the same problem, ovh support told me it's not possible to use smtp with shared server. The solution is to use transport: sendmail or transport: mail for older version of swiftmailer (deprecated now)

Answer 2

Here is my OVH plan with shared e-mail config.yml (values are of course parameters, copied here for more visibility):

# Swiftmailer Configuration
swiftmailer:
    transport: mail
    auth_mode: login
    host:      ssl0.ovh.net
    port:      587
    username:  "%mailer_user%"
    password:  "%mailer_password%"
    spool:     { type: memory }

Other transports I tried before: sendmail, smtp. The strange thing is: once I set the transport config to mail, I noticed a delay before Symfony used the chosen Swift_Transport implementation. May I say I was in dev mode?

So, my advice is: set the config, go and have a coffee, enjoy.

Answer 3

Over three months I did not find the cause of the intermittent problem. Therefore I implemented a work around. Although I am not really satisfied, it allowed me to render the website public.

Here is the try and catch workaround, ugly but working since 1 month (with Symphony2 classes):

$message= \Swift_Message::newinstance()
    ->setSubject($subject)
    ->setBody($body)
    ->setFrom($from)
    ->setTo($to);

try
    {
        try
            {
                $mailer->send($message,$failure);
                $translatedText1 = $this->get('translator')->trans('flash.mail.sent1');
                $translatedText2 = $this->get('translator')->trans('flash.mail.sent2');
                $messageOut=$translatedText1.$mailarticle->getAuthor().$translatedText2;
            }
        catch(\Exception $e)
           {
                mail($to,$subject,$body,'From: '.$from);
                $translatedText1 = $this->get('translator')->trans('flash.mail.std1');
                $translatedText2 = $this->get('translator')->trans('flash.mail.std2');
                $messageOut=$translatedText1.$mailarticle->getAuthor().$translatedText2;
           }                                    
    }
catch(\Exception $e)
        {
             $translatedText1 = $this->get('translator')->trans('flash.mail.except1');
             $translatedText2 = $this->get('translator')->trans('flash.mail.except2');
             $messageOut=$translatedText1.$e->getMessage().$translatedText2.$failure;
        }

The $translatedText1/2 and $messageout portions are simply texts of the messages shown to a user after having sent a mail. The object->trans() is a text functionality of Symfony.

Strangely that albeit I did not receive a single answer, the question received some credit points. Still, as the above solution is not solving the root cause - anyone answer addressing the cause will still very much appreciated!