Prestashop: Email sending error (response code 220) after upgrade to 1.7.7

Created on 5 Dec 2020  路  45Comments  路  Source: PrestaShop/PrestaShop

After i upgraded to 1.7.7 i started havng customers call me and say that they got no email or response that their account or message was created/sent..

i went into email settings and tried to send an email and i got the following message..

#

Error: Please check your configuration

Expected response code 220 but got an empty response

#

The email is set to "Use /usr/sbin/sendmail"
Moreover i tried to setup my own SMTP par according to my server to no success..

Additional informations

Prestashop version: 1.7.7.0
PHP version: 7.3.23

1.7.7.0 Advanced parameters BO Bug Email NMI Topwatchers

Most helpful comment

@ttoine There is no attack in my post, but I think it's not right that Simon practically blames us for not testing it properly...

Regarding the security risk - I reallly don't understand SwiftMailer's move. I have read about the mail() issue and it's dangerous, because you can add extra email headers and other data when calling this function. I think if somebody gets into your Prestashop installation, you have much bigger trouble than that he can use mail().

The solution we have available is sendmail, which needs proc_open. Proc_open, if enabled can run any external command, that is not dangerous? 馃槃

All 45 comments

Hi, in PS 1.7.7.0 we had to disable the use of mail() for security reasons (details https://github.com/PrestaShop/PrestaShop/pull/20124).

But /usr/sbin/sendmail or SMTP should work fine 馃 .

Still... i have 4 Prestashop installations that now give this error..

Hello @Stampa-Stampa
we need more information. When you create an issue, there is a template with some sections you're supposed to fill with the correct information, not delete everything...
Could you please do that ?

Thank you in advance.

Hi there...
The section you mention has nothing to fill or delete when you use the default option (/usr/sbin/sendmail)..
Moreover it was working fine before the update.
Cant understand why Prestashop decided to move with such a change without being sure there is functionality or at least a workaround.
Nevertheless on other server the email test goes on for ever and it ends up with timeout after 4-5 min..
Setting up smtp option ends up with :

#

Error: Please check your configuration

Failed to authenticate on SMTP server with username "[email protected]" using 2 possible authenticators. Authenticator LOGIN returned Expected response code 235 but got code "535", with message "535 Incorrect authentication data ". Authenticator PLAIN returned Expected response code 235 but got code "535", with message "535 Incorrect authentication data ".

#

The same smtp setting work just fine on other email clients.

Cant understand why Prestashop decided to move with such a change without being sure there is functionality or at least a workaround.

mail() has been disabled because it's not secure https://github.com/swiftmailer/swiftmailer/issues/866#issuecomment-289291228

Replacement is /usr/sbin/sendmail and SMTP and they work well. In your usecase something seems wrong but it works for standard prestashop environment.

@matks I told you this is going to be a problem... We asked all major hosting providers in Czech republic and all of them refused to enable sendmail. 馃槥

@matks I told you this is going to be a problem... We asked all major hosting providers in Czech republic and all of them refused to enable sendmail. 馃槥

I'm sorry but if I don't remember that 馃槄 but github notifications are like a never-ending rain so I might have missed something.

But once mail() has been declared unsafe we cannot keep it. Security comes first. There are hundred email providers available 馃槉 I dont think we have limited options.

hello @Stampa-Stampa

Could you please provide your previous PS version and your PHP version.

Thanks!

@matks Wasn't you, sorry 馃槃 https://github.com/PrestaShop/PrestaShop/issues/19957#issuecomment-652165599

It's quite a situaliton we can never win. mail() is considered unsafe, but proc_open() is disabled everywhere, because it poses even bigger threats.

Reading the answer from @atomiix it seems the other alternative is to use your own SMTP parameters. Is it a viable option for you ?

@Stampa-Stampa I was not talking about the configuration in PrestaShop, I was talking about the issue template, when you create an issue on Github. We have a template with some sections to fill (environment, steps to reproduce, other important details) and you deleted everything.

I finally managed to setup smtp but still more problems apear ...
I have added a new issue...

My Prestashop version is 1.7.7.0 and my php version is 7.3.23

Hello @Stampa-Stampa

Could you please provide your previous PS version and your PHP version.

I said your previous version :sweat_smile: So what was your shop version before upgrade.

Thanks!

It appears sendmail via swiftmail needs "proc_open" - which most php installations, has disabled via disable_functions, for security reasons!

Same problem after upgrading to 1.7.6.9 ->1.7.7

Same problem since update to 1.7.7, "Error sending e-mail (response code 220)".
cannot configure the mails in SMTP because hosting on ionos on a shared server. How to do?

Same problem here... pretty messed up that this breaks without notice.
Where is the "send from" email configured now with sendmail?

i also have this problem

Error: Please check your configuration Expected response code 220 but got an empty response

close
An error occurred while sending the e-mail to the customer.

I am not sure it will help but i couldn't even setup my own smtp. The browser i was using was firefox and what i realised was that the browser somehow was changing the pass according to an autoregistry without me noticing it, and i got a break when i tried the same with a chrome.

Same here, tried different browsers amd accounts without any luck.

This should have been handled way better during the upgrade process. There should have been an automatic email test and if it doesn't work it should clearly inform the user after the upgrade process that the email sending is not working anymore and it should be reconfigured. There was no notice at all. Without looking deep into the changelog one wouldn't have even noticed the change in the email settings wording until seeing the emails aren't arriving anymore (e.g, "new order" notifications, which is what happened to my client).

Hello everyone,

this change was made for security purposes. I understand some of you may feel frustrated, but remember that security is one of our top priorities and as such we removed this feature to keep PrestaShop as secure as possible.
I want to also remind you that we published 3 preversions (beta 1, beta 2, RC 1) before releasing the final product. We ask for people to test these preversions with a copy of their production shops to catch any problem before the final build is released. We need people to test them. Sadly we didn't receive a lot of feedbacks, feedbacks that could have helped us catching this in advance.

Thank you for your understanding.

I totally agree that security comes first, and I therefore fully agree with removing the usage of php mail. What I don't agree with is not implementing something like an automated test during the upgrade to see if the new default option still works, or at least telling the user "hey, your email configuration changed, please make sure it still works". I think it's quite a breaking change. The standard message after upgrade doesn't help end users that upgrade with the auto upgrade module. Breaking changes should be tested and informed better, IMHO. In my client's case, sendmail doesn't work even with it enabled on the hosting and the correct path. Had to configure it as SMTP.

Breaking changes should be tested and informed better, IMHO

Totally. Once again, this is an Open Source project, if you feel something is not done right, you are more than welcome to contribute to improve it, so the fix can be released for free for everyone.

Please remember that we are a small team compared to other big ecommerce projects, and therefore cannot test every possible configuration to make sure we don't miss anything.

And once again, we provided 3 preversions. Did you test them ?

@SimonGrn I reported it 7.7.2020 on Slack and 26.7.2020 here (https://github.com/PrestaShop/PrestaShop/issues/19957). We found the cause, so don't say the PS team did not know about it... 馃槈

I warned you that this will piss people off. I run on a private server, so I don't care, but if I was on public hosting, I would be in big trouble. We specifically emailed all the biggest hosting providers in Czech republic, with a question, if they could allow proc_open. Reply from all of them - "No, only on VPS".

_EDITED by @matks_ : no need for passive-aggressive statements.

The issue is actually the 3rd party mailer you use, which is swift mailer - is there any other mailer you could use instead, to stop the proc_open issue?

@Hlavtox
You also make money with PrestaShop software, like a lot of merchants, agencies and freelancers. PrestaShop Company is the biggest contributor, but it's an open source project, and any one can contribute.

Developing, promoting and sustaining an open source software project cost a lot, that's why PrestaShop company has a business model.

That said, this discussion is not really respectful and friendly, and usually this does not help to find a solution. As I would prefer not to close it as "too heated", please try to work together.

The reason of the change is security, and that should not be a compromise. There are ideas in the discussion already, like test and display information. It's time to provide a solution, your pull requests are welcome

@ttoine There is no attack in my post, but I think it's not right that Simon practically blames us for not testing it properly...

Regarding the security risk - I reallly don't understand SwiftMailer's move. I have read about the mail() issue and it's dangerous, because you can add extra email headers and other data when calling this function. I think if somebody gets into your Prestashop installation, you have much bigger trouble than that he can use mail().

The solution we have available is sendmail, which needs proc_open. Proc_open, if enabled can run any external command, that is not dangerous? 馃槃

The problem is your tone. You are agressive and unfriendly, sometimes insulting. And not a surprise, people don't like to work this way.

If you want to find people enthusiastic to work with you here, start with being friendly and positive. PrestaShop is not a proprietary software, so you can improve it.

The issue is actually the 3rd party mailer you use, which is swift mailer - is there any other mailer you could use instead, to stop the proc_open issue?

You will find the details about the security issue in this thread https://github.com/swiftmailer/swiftmailer/issues/866#issuecomment-289291228

Many people in the thread disagree about it being a security issue. Many people agree.

As for us we have chosen to follow Symfony's side: the use of mail() was disabled because of security reasons. We don't want to keep something that will has security issues.

Remember that this is an open source software: you have control on the files of your shop (contrarily to SaaS products). If you disagree with us disabling something for security you can enable it again on your shop 馃槈 .

@ttoine Sorry, but I don't feel it that way. I am discussing pure facts, there is nothing unfriendly and insulting about it. I have nothing against anyone and you can see I am trying to help wherever I can. I don't say this is the case, but this is business and you won't be always handled in white gloves.

Somebody says that the issue was known, I say it was.
Somebody says the community should have tested it, I say it's not (purely) community's task.
What's wrong with that?

@matks The problem is that people cannot revert it easily, other than downgrading SwiftMailer... :(

@Hlavtox Actually, if you would have been friendly in your communication, your advice would have been taken in account with a higher impact. As I said already, people appreciate to work with friendly people, but they don't want to work with unfriendly and agressive people. Being borderline with the Code of Conduct is not really respecting it fully.

Being factual is very good. But that's not enough in an open source project. Even Linus Torvalds, himself, had to change his behavior, recognizing in 2018 that he was a problem to foster a nice Linux community. Now, he gives example. That's also a fact.

Coming here means wanting to build something together. If you come just to blame others, at what point, you will not be welcome anymore. So next time you create an issue, a pull request, or even write a comment, please re-read yourself before you push the button, and ask yourself: "will people like what they will read, and will they want to work with me?"

Any insight on why configuring the SMTP options also doesn't work?

Any insight on why configuring the SMTP options also doesn't work?

Some people said their password manager put their password inside the "password" field, erasing the SMTP password.

@ttoine I think it's difficult to guess the tone from written communication, in a different language. And what could sound harsh can be only because of the language barrier. I assure you there is no anger in anything I write. 馃憤

Coming here means wanting to build something together. If you come just to blame others, at what point, you will not be welcome anymore. So next time you create an issue, a pull request, or even write a comment, please re-read yourself before you push the button, and ask yourself: "will people like what they will read, and will they want to work with me?"

What is the other reason people would come here? If I encounter a bug and I can fix it, I always make PR straight away. If I wouldn't want to help the community, I would fix it for my clients and go on...

And regarding the thing @matks edited out - it was not meant in hate, but maybe we should take the the pink glasses off and feel the reality. Insane amount of work was done on Prestashop, but I think it's still not time to hug each other and say how insanely successful it is. There are maybe PS team + 20 people from the public reporting bugs and testing betas...

Fortunately, there are more contributors that than. Big agencies and big merchants tests with their scenario, even if it is not always with an iso stack (core+module+theme+configuration+data). That's also why 1.7.7 is late: there has been a loooot of issues identified. But this is still not enough.

The pain is that it's difficult to test for the small independent merchants, because it takes time and often, they don't have the skills. And, they are the most important group of users.

Hi everyone,

Can anyone help me with the sollution? It still dont work for me :(

Hi, we tested multiple times the SMTP settings and it seems they are working as expected. SMTP would by my recommandation as it does not depend on your PHP server settings.

I get this error

Any insight on why configuring the SMTP options also doesn't work?

I am not sure it will help but on one of my customer's email smtp setup i also had difficulty setting up and in the end the problem was the port. Despite the fast that my customer's host provider has a card with all the info, the port was not working and in the end he (the customer) was given an alternate one that finally worked..

Any insight on why configuring the SMTP options also doesn't work?

Some people said their password manager put their password inside the "password" field, erasing the SMTP password.

I don't understand what do you mean. I also tried to override the settings in the parameters.php file as the file containted this:
'mailer_host' => '127.0.0.1', 'mailer_user' => NULL, 'mailer_password' => NULL,

But is not working.
As @Stampa-Stampa did, I contacted my host provider but they still don't know why is not working.

I installed 1.7.7 on two websites so far and I have to agree with @Hlavtox - I already have issues too. I'm also in Czech Republic and it's true that proc_open is disabled everywhere. On one hosting I could setup SMTP without problems, but I wasn't able to make it work on the second one, I tried all options / different ports and ways of connection according to hosting manual.
Order cannot be finished because after saving the user details, it can't send email. I can debug it as a developer, but common users will not know why it doesn't work...

Hello, I was able to solve my problem thanks to this thread: https://github.com/PrestaShop/PrestaShop/issues/22298

I went to the database I saw that in ps_configuration, the entry PS_MAIL_PASSWD was invalid.

My password has a < on it and it made my password to be cut from that point.

For example, my_pass<word became my_pass only and that was the whole problem.

I tested with > and it's saved and working.

Is this the expected behavior??
If so, maybe we can output some error message related to it.

@Ouro17 You are right! indeed some "cleaning" happens when you submit the password.

Could you please open another github issue so we can treat this? Or I can open it if you prefer

@Ouro17 I reported it https://github.com/PrestaShop/PrestaShop/issues/22540 so we can start dealing with it ASAP 馃槉

Was this page helpful?
0 / 5 - 0 ratings