Shopware 6 versendet keine Mails

Hallo,

da bei mir der Wunsch nach einem Onlineshop im Raum steht, bin ich auf der Suche nach einem geeigneten Tool. Ich bin also irgendwie bei Shopware 6 gelandet.

Allerdings habe ich ein riesiges Problem:
Der Shop versendet keine Mails!

Im BE ist “Lokaler E-Mail-Agent” ausgewäht, unabhängig davon, ob der Mailversand synchron oder asynchron stattfindet (mehr dazu später), kommen Mails nicht an.

Alle E_Mail-Vorlagen sind dem Verkaufskanal zugewiesen.

Bestellungen, Registrierungen und alles drum herum funktioniert, nur Mails werden halt nicht versendet.

 

Beim asynchronen Mailversand gibt es keine Fehlermeldung und die Mails werden nicht verschickt. Beim synchronen Mailversand, bekommt der Kunde zB nach Eingabe der Mailadresse bei der “Passwort vergessen” Funktion die Fehlermeldung “Leider ist etwas schief gelaufen”. Im Logfile taucht dann diese Fehlermeldung auf:
[2020-05-09 15:18:02] request.CRITICAL: Uncaught PHP Exception Swift_TransportException: "Expected response code 220 but got an empty response" at /home/users/####/www/####.de/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php line 445 {"exception":"[object] (Swift_TransportException(code: 0): Expected response code 220 but got an empty response at /home/users/####/www/####.de/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php:445)"} []  

Der Mailversand von der Kommandozeile funktioniert sowohl über “sendmail -t” als auch über “sendmail -bs” problemlos. Mails, die über den Shop versendet werden, tauchen gar nicht erst unter /var/log/syslog auf.

Ich habe mich schon quer durchs Internet gesucht, bisher leider erfolglos. Mittlerweile ist es sehr frustrierend und ich bin kurz davor die Flinte ins Korn zu werfen und mir ein anderes Tool für den Onlineshop zu suchen. Bevor ich aber aufgebe, wollte ich fragen, ob hier irgendjemand ne Idee hat, woran es liegt und wie ich es behebe?

Ich habe gerade Mal Shopware 5 installiert, dort funktioniert der Mailversand umgehend und problemlos… Was um alles in der Welt!?

Jemand ne Idee?

Darf der Webbenutzer auch den Prozess starten? Liegt sendmail unter „/usr/sbin/sendmai“? 

Shopware 5 benutzt die php mail methode. Diese gibt es in Shopware 6 nicht mehr. Da sie veraltet ist.

1 „Gefällt mir“

Zuerst einmal Danke für deine Antwort, ich bin echt am verzweifeln…

@Shyim schrieb:

Darf der Webbenutzer auch den Prozess starten?

Das ist eine gute Frage… bis eben bin ich davon ausgegangen, dass der Webbenutzer mit dem Benutzer übereinstimmt, dem auch die Dateien gehören. Dieser darf den Prozess zumindest in der Bash starten. Gerade fällt mir aber auch ein: Ist es nicht möglich, dies in der php.ini zu unterbinden? Welches Modul wäre das?

@Shyim schrieb:

Liegt sendmail unter „/usr/sbin/sendmai“? 

Ja

@JKersten schrieb:

Ist es nicht möglich, dies in der php.ini zu unterbinden? Welches Modul wäre das?

Das ist es! 

Ich habe kurzer Hand einfach mal alle Module, die standartmäßig disabled sind zugelassen und dann funktioniert es… Jetzt muss ich nur wissen, welche Module tatsächlich von Shopware benötigt werden. Gibt es da irgendwo ne Übersicht?

Und warum wird curl_multi_exec bei der Installation abgefragt und darauf hingewiesen, aber bei so etwas essentiellen wie dem Mailversand wird das Modul nicht überprüft?

Hast du sowas wie proc_open, exec in der disabled_functions?
Ansonsten könnte es auch an open_basedir liegen

1 „Gefällt mir“

@Shyim schrieb:

Hast du sowas wie proc_open, exec in der disabled_functions?
Ansonsten könnte es auch an open_basedir liegen

Ja, genau. Habe beides drin stehen. Habe durch Trial and Error herausgefunden, dass es nicht exec sondern proc_open ist.

Sollte ich exec auch zulassen?

Weißt du zufällig, ob es sonst noch irgendwas gibt, was ich definitiv nicht disablen sollte?

 

Und vor allem: Danke, durch deinen Beitrag ging es endlich voran!

Wenn du proc öffenst kannst du auch exec öffnen.

Die machen das selbe :) 

1 „Gefällt mir“

Hallo,

ich habe nach meiner SW6 Shop Installation ein ähnliches Problem wie das hier beschriebene. Bei mir werden E-Mails an Kunden (Registrierung, Bestellbestätigung, Passwort, Recovery etc.) erst versendet, sobald ich mich als Admin im Backend einlogge. Ich vermute, dass es ebenfalls daran liegt, dass ein Webnutzer den Prozess nicht starten kann.

Könntet ihr mir sagen, wie ich auf die php.ini zugreifen kann um das proc_open zu enablen?

bei mir aktuell das gleiche Verhalten, vom Frontend ausgelöste Mails (Bestellbestätigung, Passwort vergessen) werden neuerdings erst verschickt wenn ich mich als Admin ins Backend einlogge. Hat bis vor kurzem noch funktioniert. Vermutlich besteht das Problem seit dem Update aus 6.4.0.0 Im Backend ausgelöste Mails (Versandbestätigung usw.) gehen sofort raus.
Leider kann ich die Ursache nicht finden.
Wäre für jeden Tip dankbar!

Konntest du das Problem schon lösen?

Ich habe es noch mal mit einer kompletten Neu-Installation von Shopware 6.4.0.0. bei meinem Shared-Host Anbieter probiert. Aber leider auch hier das gleiche Verhalten: Im Demo-Shop werden E-Mails (wie z.B. die Registrierung im Frontend) bei mir erst versendet, wenn ich mich als Admin im Backend einlogge.

Ich habe seit 6.4 das gleiche Problem. Bei mir werden z.Zt. gar keine Mails versandt (auch nicht nach dem Einloggen). Vor einigen Tagen wurden noch einige Mails mit großer Verzögerung (>24 h) versandt. Ich habe alle möglichen Konfigurationen (Lokaler E-Mail-Agent / SMPT-Server / Umgebungs-Konfiguration / verschiedene SMPT-Hosts) durchprobiert.
Ach ja - es funktioniert anscheinend bei den Spam-Anmeldungen, die irgendwie am normalen Frontend vorbei getätigt werden.

Guckt mal bitte über ein Datenbanktool eurer Wahl in eurer Datenbank nach, ob in der Tabelle
enqueue Einträge vorhanden sind. Vor allem in dem Moment wo ihr erwartet das eine E-Mail rausgeht.

Ich hatte gerade in unserem Shop dasselbe Phänomen.
Wenn ja, sollte es eigentlich reichen wenn ihr euch in euren Adminbereich einloggt, alternativ auf der Konsole eures Projektes den folgenden Befehl ausführen

bin/console messenger:consume

Hintergrund: Mit der Umstellung auf den Symfony Mailer mit 6.4 scheint es nun über den Symfony Messenger versendet zu werden, der so konfiguriert ist, das er über eine „message queue“ arbeitet (in dem Falle die enqueue Tabelle). Würde mich auch freuen wenn das wer von SW nochmal bestätigen könnte, so kann ich das auf jeden Fall hier bei uns reproduzieren.

Leider habe ich noch keine Lösung, habe verschiedene SMPT Ports durchprobiert, aber ohne Erfolg. Laut Ereignis-Log werden die Mails versendet, in Wirklichkeit bleiben sie aber irgendwo stecken und gehen dann beim Einloggen ins Backend alle aus einmal raus…

Das bestätigt meinen Verdacht und ist tatsächlich ein Breaking Change zu SW 6.3 gewesen (wo die E-Mails „direct“ versendet wurden). Jetzt scheint es wirklich nur noch asynchron versendet zu werden. Mehr zu Message Queues:

das klingt vielversprechend, wie kann ich das bei meinem Share-Host Anbieter (Netcup) unter Plesk umstellen?

Wir haben für die Shops die wir betreuen meistens einen Cronjob eingerichtet, der alle 5 Minuten den von mir genannten Befehl startet

bin/console messenger:consume --time-limit=300 --memory-limit=1G

Somit stellen wir sicher das alle 5 ein neuer PHP Prozess „erscheint“ der alle Aufgaben abarbeitet und auch 5 Minuten läuft, wenn man nicht im Adminbereich eingeloggt ist.
Hierzu habe ich folgenden Supportartikel für Plesk gefunden

Leider ist das wirklich von Anbieter zu Anbieter unterschiedlich wie man das konfigurieren kann, weswegen ich hier leider keine weitere Hilfestellung geben können werde.

1 „Gefällt mir“

super , danke! Das mit dem Cronjob dürfte ich hinbekommen.

Hallo, spannendes Thema. Ich habe den Cronjob unter Plesk bei mir ausprobiert. Der Shop liegt in einem Unterverzeichnis. Wenn ich den Console befehl aufrufe, erhalte ich folgende Fehlermeldung.

Die Aufgabe „unterverzeichnis/bin/console message:consume --time-limit=300 --memory-limit=1G“ wurde in 1 Sekunden abgeschlossen, jedoch traten Fehler auf

-: unterverzeichnis/bin/console: /usr/bin/env: bad interpreter: No such file or directory

Hat jemand einen Tipp?
Danke.

Ich denke es muss „messenger“ heißen