2010-06-15 3 views
1

J'utilise Symfony + SwiftMailer et obtenir l'erreur suivante de SwiftMailer:Pourquoi SwiftMailer lance-t-il "Internal Server Error"?

500 | Internal Server Error | Swift_TransportException 
Expected response code 220 but got code "", with message "" 

et ne peut pas comprendre pourquoi. J'utilise hMailServer sur ma machine locale, et ai installé mon dossier factories.yml (comme j'utilise Symfony) comme suit:

mailer: 
    class: sfMailer 
    param: 
     logging: %SF_LOGGING_ENABLED% 
     charset: %SF_CHARSET% 
     delivery_strategy: realtime 
     transport: 
     class: Swift_SmtpTransport 
     param: 
      host: splodge.loc 
      port: 25 
      encryption: ~ 
      username: ~ 
      password: ~ 

J'utilise le code suivant pour envoyer:

$message = $this->getMailer()->compose(
    '[email protected]', 
    '[email protected]', 
    'Reset Password', 
    'Message' 
); 
$result = $this->getMailer()->send($message); 

Quelqu'un a-t-il déjà eu un problème comme celui-ci?

J'ai trouvé que parfois, et de façon très aléatoire, l'envoi passe, mais toutes les autres fois, j'obtiens le message d'erreur ci-dessus. Donc actualiser constamment la page qui envoie le courrier, échoue de façon imprévisible, et comme le code fonctionne parfois, il est difficile de comprendre ce qui ne va pas.

Toute aide sera grandement appréciée!


Une enquête plus approfondie a montré que le serveur SMTP n'envoie [220 localhost ESMTP], mais après avoir pris un coup d'oeil à journaux hMailServer, j'ai découvert les suivantes:

"TCPIP" 5232 "2010-06-16 11:40:54.043" "TCPConnection - Posting AcceptEx on 0.0.0.0:25" 
"DEBUG" 5232 "2010-06-16 11:40:54.043" "Creating session 51" 
"SMTPD" 5232 51 "2010-06-16 11:40:54.043" "127.0.0.1" "SENT: 220 localhost ESMTP" 
"DEBUG" 5296 "2010-06-16 11:40:54.199" "The read operation failed. Bytes transferred: 0 Remote IP: 127.0.0.1, Session: 51, Code: 10054, Message: An existing connection was forcibly closed by the remote host" 
"DEBUG" 5296 "2010-06-16 11:40:54.199" "Ending session 51" 

pourrait-il que SwiftMailer est HELO/EHLOing trop tôt, et que c'est simplement un problème de temps? Puis-je retarder un peu la transmission HELO?

Les bons journaux, quand la chose envoie réellement se présente comme suit:

"TCPIP" 5232 "2010-06-16 11:42:21.278" "TCPConnection - Posting AcceptEx on 0.0.0.0:25" 
"DEBUG" 5232 "2010-06-16 11:42:21.294" "Creating session 54" 
"SMTPD" 5232 54 "2010-06-16 11:42:21.294" "127.0.0.1" "SENT: 220 localhost ESMTP" 
"SMTPD" 5224 54 "2010-06-16 11:42:21.294" "127.0.0.1" "RECEIVED: EHLO splodge.loc" 

Il doit être à voir avec la reconnaissance HELO/EHLO. S'il vous plaît donnez votre avis! :)

+0

Le problème est probablement lié à votre hôte. Pourquoi ne pas essayer Gmail et voir si vous rencontrez le même problème. – Dziamid

Répondre

0

Managed pour obtenir ce travail en créant une boucle qui retente l'envoi de courrier ...

$sendResult = false; 
do 
{ 
    try 
    { 
     $message = Swift_Message::newInstance() 
      ->setFrom('[email protected]', 'Mr.Postman') 
      ->setTo($to) 
      ->setSubject('Password reminder...') 
      ->setBody($this->getPartial('resetPasswordEmail', array(
       'newPassword' => $newPassword)), 'text/html'); 
     $sendResult = $this->getMailer()->send($message); 
    } 
    catch(Exception $e){/*Do nothing*/} 
} 
while($sendResult !== 1); 

Ensuite, je vais ajouter quelques paramètres de configuration pour limiter le nombre de tentatives.

2

Ressemble à un problème SMTP.

Que se passe si vous essayez ce qui suit de la ligne de commande:

telnet splodge.loc 25

Pouvez-vous connecter? La ligne de réponse commence-t-elle par 220?

Sinon, vous avez un problème avec votre configuration de serveur SMTP (ou peut-être de pare-feu).

+0

Lorsque j'utilise telnet, j'obtiens: [220 localhost ESMTP] à chaque fois. Le code envoie parfois, parfois, ce n'est pas le cas. C'est vraiment bizarre. –

0

Je voulais juste ajouter à cela. Pour moi, le problème était quand mon serveur smtp redémarre, dovecot n'est pas revenu. Dès que j'ai commencé à dovecot, tout allait bien. Donc, à la fin, c'était un problème de smtp, donc si quelqu'un d'autre a ce problème, vous pouvez être sûr que c'est un problème de smtp.

Questions connexes