Mandrill not working anymore Oo

[LauraPresta]

For a unknown reason mandrill is not working anymore :

 

<< The SMTP connection failed to start [smtp.mandrillapp.com:587]: fsockopen returned Error Number 111 and Error String 'Connection refused' >>

 

I checked all the connection infos and they are all right.. indeed nothing did change either.

 

Anyone ever faced this problem ?

[AlexanderR]

Yes, I have exactly the same problem since 4 days.

Nothing has been changed or updated in the Prestashop application.

[criptic]

Same problem here since Jan 21. We haven't made any changes to cause this.

Any updates on your side? Have you been able to fix this?

[criptic]

Fixed it. Perhaps your hosting provider started blocking Port 587. I changed the port to 2525 and we are in business! Check if this fix will work for you.

 

http://help.mandrill.com/entries/21738477-What-SMTP-ports-can-I-use-

[LauraPresta]

i will check this but i think you got the good solution.

 

btw, what is your hoster ?

 

(OVH here, i hate them, they are amaziingly bad)

Edited January 27, 2015 by neektoo (see edit history)

[AlexanderR]

It doesn't seem to be the port, since I switched to an SMTP from OVH using the same port, 587, as with Mandrill.

And this SMTP works!

 

My guess is that Mandrill itself has been blocked by OVH.

[LauraPresta]

Everyone here on OVH ?

It is one of the worst web hoster ever been. I have no word to describe how bad they are.

[LauraPresta]

2525 works for me too

[HaCos]

My host does not allow outbound connections on ports 25, 465, and 587 as well. 
However, i managed to succeffully send test messages using the following SMTP settings:

 

Mail domain name: -

SMTP server: smtp.mandrillapp.com
SMTP user: USERAME
SMTP password: PASS
Encryption: NONE 
Port: 2525

 

I received several customers complains for not receiving any email not for customer registration, nor for order confirmation.

 

Unfortunatly for some reason, some emails are being rejected. I contacted mandrill support and they figured that the headers of the messages that are being rejected are passed to mandrill like : 

To: =?UTF-8?B?zprPgc75z4PPhM65zqzOvSDOo86szr3PhM+Bzr/PhQ==? [email protected]

and their comment was that for that string to be encoded correctly, it would need to end with an equals sign, like so:

To: =?UTF-8?B? zprPgc75z4PPhM65zqzOvSDOo86szr3PhM+Bzr/PhQ==? = [email protected]

EDIT: I figured that this is happening only when customer name is spelled with greek chars. When customers name is in English eveyrything works fine.

 

Do you have any idea how i can fix this? 

Edited January 28, 2015 by HaCos (see edit history)

[Pedro Lima]

My host does not allow outbound connections on ports 25, 465, and 587 as well. 

However, i managed to succeffully send test messages using the following SMTP settings:

 

Mail domain name: -

SMTP server: smtp.mandrillapp.com

SMTP user: USERAME

SMTP password: PASS

Encryption: NONE 

Port: 2525

 

I received several customers complains for not receiving any email not for customer registration, nor for order confirmation.

 

Unfortunatly for some reason, some emails are being rejected. I contacted mandrill support and they figured that the headers of the messages that are being rejected are passed to mandrill like : 

To: =?UTF-8?B?zprPgc75z4PPhM65zqzOvSDOo86szr3PhM+Bzr/PhQ==? [email protected]

and their comment was that for that string to be encoded correctly, it would need to end with an equals sign, like so:

To: =?UTF-8?B? zprPgc75z4PPhM65zqzOvSDOo86szr3PhM+Bzr/PhQ==? = [email protected]

EDIT: I figured that this is happening only when customer name is spelled with greek chars. When customers name is in English eveyrything works fine.

 

Do you have any idea how i can fix this? 

 

I am also curious about this because in Portuguese we also use "special chars" in a lot of names.

[chienandalu]

I was having the same issue. After a long debuging I was able to find out what the problem was. There seems to be a mixing encoding in the mail headers (base64 and qoute printable) wich swiftmailer should be able to deal with. And it does until the very end of the proccess in wich it trims our necesesary trailing "=" from our base64 encoded customer name. It's funny because in my case it depended on the original string length (and I didn't find out exactly why).

 

Anyway, I resolved the issue encoding the whole header as base64 changing this line of code in classes/Mail.php (or its override):

 

Instead of:

$message->headers->setEncoding('Q');

this:

$message->headers->setEncoding('B');

I don't really know if it's a good procedure but it works!

[elibanuelos]

 

Thanks  chienandalu is works for me

[elibanuelos]

Well, Just work for 1 day, the next day again it was rejected, any know other solution? I appreciate,  it happen under names in English, Spanish,...