SMTP bei 1&1 aka IONOS

Hi,

nach einem Providerwechsel zu 1&1 kommt es zu Problemen mit dem Mailversand per SMTP.

Umgebung:

  • Shopware 5.5.6
  • PHP 7.1
  • Meldung bleibt sich mit und ohne FixSMTP Plugin gleich
    • Wobei ich das eh als nicht notwendig rausgelesen habe mit einer aktuellen Version?
    • "Falls Du Deine Shopware-Installation nicht updaten kannst […] "
    • Oder ist das FAQ hier unklar formuliert??

Fehlermeldung (wie gesagt gleich mit und ohne Plugin):

{
  "exception": "[object] (Zend_Mail_Protocol_Exception(code: 501): Syntax error in parameters or arguments\r\n at /engine/Library/Zend/Mail/Protocol/Abstract.php:420)"
}

Caches etc. habe ich alle schonmal geleert via UI,  bzw. nach dem Umzug natürlich auch erstmal /var/cache.

Hier noch die Settings aus dem Shop und die Infos von 1&1 - man muss dazu sagen, dass die Firewall Port 587 gar nicht auf hat und ich das schon beim Support angemeckert habe. Anfragen gehen daher aktuell auf Port 25.

Ob die Fehlermeldung oben dann schon daher rührt kann ich nicht sagen. Kurz über Zeile 420 steht aber „Parse server response for successful codes“, könnte also einfach sein, dass die auf Port 25 nicht mitspielen wollen?

Bei der affenartigen Geschwindigkeit und Kompetenz des 1&1 Supports wäre ich nur sehr froh, wenn hier jemand ggfs. weitere Ideen hat oder das Problem ggfs. selbst schonmal hatte.

Viele Grüße

Oliver

 

Checking smtp.ionos.de:

Looking up MX hosts on domain "smtp.ionos.de"

No Mail eXchangers found; will try TLS directly to host

Trying TLS on smtp.ionos.de[213.165.67.97:25] (0):

seconds test stage and result
[000.083] Connected to server
[000.166] EHLO www6.CheckTLS.com
[000.249] STARTTLS
[000.334] EHLO www6.CheckTLS.com
[001.341] MAIL FROM:
[001.432] QUIT
[001.515] EHLO www6.CheckTLS.com
[000.283] STARTTLS
[000.378] EHLO www6.CheckTLS.com
[001.492] MAIL FROM:
[001.587] QUIT
[001.681]	

 

Dein Host ist - höchstwahrscheinlich - falsch eingetragen…

Hm, Port 587 ist für SMTP aber üblich.

Er hat aber 25 und tls stehen - das passt wahrscheinlich nicht zusammen

Port 587 haben die Deppen wie gesagt auf ihren Hostinstanzen gar nicht offen (oder eben ggfs. am Mailserver).

(uiserver):u123456789:~$ nc -v smtp.ionos.de 587 -w 7
nc: connect to smtp.ionos.de port 587 (tcp) timed out: Operation now in progress
nc: connect to smtp.ionos.de port 587 (tcp) timed out: Operation now in progress
(uiserver):u123456789:~$ nc -v smtp.ionos.de 993 -w 7
nc: connect to smtp.ionos.de port 993 (tcp) failed: Connection refused
nc: connect to smtp.ionos.de port 993 (tcp) failed: Connection refused
(uiserver):u123456789:~$ nc -v smtp.ionos.de 25 -w 7
Connection to smtp.ionos.de 25 port [tcp/smtp] succeeded!
220 kundenserver.de (mreue108) Nemesis ESMTP Service ready

Ich weiß nur nicht wie/ob ich herausfinden kann ob Shopware auch über 25 alles laufen lassen könnte, sofern die Gegenstelle auf 25 starttls macht.

Bin aus den Einträgen nicht ganz schlau geworden ob Shopware jetzt nach 5.4.5 selbstständig TLS >1.0 macht, bzw. im Optimalfall starttls, ob das wieder nen anderen Parameter braucht, oder oder oder.

Natürlich kann am Ende immer noch der 1&1 Server auf 25 nicht passend konfiguriert sein.

[edith]

Aus dem Auszug vom SMTP Checker oben vermute ich aber, dass der durchaus starttls machen kann :open_mouth:

Muss im Mailer ggfs. explizit starttls eingetragen werden (auch wenn es das im Dropdown nicht gibt), damit starttls probiert wird??

[/edith]

Muss im Mailer ggfs. explizit starttls eingetragen werden (auch wenn es das im Dropdown nicht gibt), damit starttls probiert wird??

Glaube das kann ich mir selbst beantworten und würde für “nein” plädieren :open_mouth:

// If a TLS session is required, commence negotiation
        if ($this->_secure == 'tls') {
            $this->_send('STARTTLS');

 

Ergänzend: Eine vorher bereits mit dem IONOS SMTP funktionierende Shopware Installation habe ich gerade vom eigentlichen Besitzer des Webpakets updaten lassen…das war nämlich noch 4.5.4 oder sowas (mit dem Endlos ladenden Backend Bug).

Nach dem Update auf 5.5.6 geht es dort auch nicht mehr.

Muss mich da anschließen, das betrifft auch unseren Shop - nach Update auf 5.5.6 geht der Mailversand mit tls nicht mehr. Dito auch mit SSL. Wäre toll, wenn von Shopware hier mal eine Lösung kommt. Das wird bestimmt noch andere Shopnutzer betreffen.

Kann man irgendwo auslesen/ein Debuglevel hochschrauben, sodass ersichtlich wird wo es genau stört, oder sodass man die Connectzeile ausgegeben bekommt?

sorgt nirgendwo für mehr Ausgabe in diesem Fall.

Was die Source angeht, sehe ich bei direktem Dateibezug nicht wirklich viele Änderungen, und auch ein Einspielen der alten smtp.php (edit: aus der Source von 5.4.4) stellt die Funktionalität nicht wieder her.

Abstract.php

smtp.php

Hat hier jemand noch eine Idee/einen Tipp was man probieren könnte?

Es wäre sicher nicht das erste Mal, dass 1&1 hier am Ende als Schuldiger rauspurzelt, aber bei denen ihrer Größe macht es durchaus Sinn wenn Shopware nicht defaultmäßig mit - aus Usersicht - „kaputtem SMTP“ shipt.

Ich baue gerne an ein paar php Dateien rum oder wir machen ne TeamViewer Session oder sowas, aber ohne etwas Hintergrundwissen zum Code im Shop geht da nichts. Da hört es dann eben beim laienhaften „Änderungen abgleichen“ wie oben auf - spätestens! Von möglichen Änderungen abseits der augenscheinlich direkt betroffenen Dateien und entsprechenden Seitenrelationen ganz abgesehen.

Der Shop ist eine 0815 Installation, Plugins ist nur PayPal drin, ansonsten nichts irgendwo custom rumeditiert oder sowas.

Checks nach dem Umzug habe ich alle gemacht und auch die PHP Config erweitert bzgl. RAM etc. Ebenso ist in der phpinfo zusehen dass die TLSv1.2 Lib auch verfügbar ist.

edit: Ergänzend:

CGI Mailer funktioniert, ist aber halt komplett behindert das zu benutzen. Falscher Absendername und -Adresse, und sowieso mehr als fraglich warum 1&1 das überhaupt zulässt.

edit 2: „Dann macht doch ein Ticket beim Shopware Support auf“

Hinter dem Shop steht eine nonProfit (NPO). Das fällt daher flach :open_mouth:

Falls man in diesem Fall einen Issue aufmachen soll bitte um kurze Info (https://issues.shopware.com).

https://www.ionos.com/help/email-office/general-topics/settings-for-your-email-programs-imap-pop3/

Wie oben bereits erklärt: Port 587 ist zu, das ist auch beim 1&1 Support adressiert. Ebenso ist eine offizielle Aussage angefragt, ob der SMTP denn auch auf 25 verschlüsselt sprechen möchte. Wir wissen alle wie fähig der 1&1 Support ist, ich rechne da also nicht mit viel Abhilfe. Ich habe heute das 3. Mal das Problem schildern dürfen und erwarte mir wenig Verständnis auf der Gegenseite.

Zum SMTP Port 25: Soweit ich es (Post 2) erkennen kann macht der Server STARTTLS.

Ebenso wie gesagt die Info, dass es im gleichen Webpaket (andere Installation, anderer SMTP User, ansonsten gleiche Settings) mit Shopware 5.4.x noch lief und nach dem Update zu 5.5.6 nicht mehr -> https://forum.shopware.com/discussion/comment/241681/#Comment_241681

[000.249] STARTTLS
[000.334]	

 

1&1 Support:

ich kann Ihnen definitiv bestätigen, dass der Port 25 für den Versand mit smtp.ionos.de zwingend zu verwenden ist. Der Port 587 ist gesperrt.

kombiniert mit

@DarkWorldShopware schrieb:

Ergänzend: Eine vorher bereits mit dem IONOS SMTP funktionierende Shopware Installation habe ich gerade vom eigentlichen Besitzer des Webpakets updaten lassen…das war nämlich noch 4.5.4 oder sowas (mit dem Endlos ladenden Backend Bug).

Nach dem Update auf 5.5.6 geht es dort auch nicht mehr.

bringt uns dann definitiv auf den Punkt, dass irgendwie aus Sicht von Shopware zu ergründen ist was hier wem nicht schmeckt.

Entweder es gab von 5.4.x -> current eine Änderung in der Formulierung der Requests, die jetzt dem 1&1 SMTP nicht mehr schmecken.

Oder es gab eine Änderung in der Verarbeitung der Responses, sodass jetzt Shopware die Daten von 1&1 nicht mehr schmecken.

Die genannte Installation mit der alten Version hat noch am 11.02.2019 um 16:04 eine Mail via shop@domain.tld verschicken können, über den 1&1 SMTP, mit gleichen Settings wie jetzt nach dem Update und eben auch in unserer Haupt-Installation. Eine Umstellung im Sinne von “1&1 hat TLS <1.3 deaktiviert” kann man also aktuell auch ausschließen.

edit: http://php.net/manual/en/mail.configuration.php#ini.mail.log erzeugt keine Datei.

(error_log aber schon, also kein Syntaxproblem oder so)

https://github.com/shopware/shopware/commit/73c8b96d23601ef11c1a898c67cbfd3f3cc558dd

Es gab Änderungen in 5.4.5, da es Probleme mit php5.6 gab. Es wird nun anders geprüft ob tls vorhanden ist. Wenn müsstet ihr wohl da ansetzen.

Aktuelle tls-Versionen sollte aber generell keine Probleme machen. Die Einstellungen wurden mit vielen verschiedenen Anbietern getestet und hier gab es keine Probleme.

1 Like

Das einzige was sich dort geändert hat ist SW-21899 - Remove usages of a deprecated constant in the mail compone… · shopware/shopware@b327552 · GitHub . Mach das doch mal rückgängig

1 Like

tl;dr: So zum 5. letzten Satz springen.


Wenn ich auf den alten Stand zurückgehe gibt es nun

{
  "exception": "[object] (Zend_Mail_Protocol_Exception(code: 0): Unable to connect via TLS at /engine/Library/Zend/Mail/Protocol/Smtp.php:207)"
}

Schreibe ich mit - wieder auf 5.5.7 gedrehten Dateien - in die ProtocolTrait

$cryptoMethod |= STREAM_CRYPTO_METHOD_TLSv1_2_CLIENT;

oder auch 1_1 sind wir wieder bei der gleichen Meldung [Zend_Mail_Protocol_Exception(code: 501)].

Ich habe dann mal in der Zweit-Shopinstallation dasselbe gemacht.

Zurückgedreht…Unable to Connect via TLS.

Auf 5.5.7 gedreht…plötzlich werden Mails verschickt.

Ich habe dann mal die Mailadresse des Haupt-Shopsystems getilgt und neu angelegt. Keine Veränderung.

Dann habe ich das Mailtemplate für die Bestellbestätigung im Haupt-Shopsystem getilt und mit Unfug gefüllt (test1 und sowas) um alle Variablen auszuschließen. Keine Veränderung.

Das geht mir jetzt schonmal massiv auf den Sack. Nicht gegen Shopware gerichtet verstehen, rein technisch. Weil jetzt ist es das gottverdammt gleiche System auf dem gleichen Host mit derselben Config.

Shopware 5.5.7 frisch runtergeladen habe ich vorhin zur Sicherheit (trotz ja bereits mehrfach durchgeführten Dateichecks) dann nochmal hochgeschubst (bis auf htaccess und config logischerweise). Aber schauen wir doch mal.

dcp_shop = Zweitsystem (geht ja jetzt), shop = Hauptsystem (geht weiterhin nicht)

dir=bin
diff --brief --recursive dcp_shop/$dir shop/$dir

dir=custom
diff --brief --recursive dcp_shop/$dir shop/$dir

dir=engine
diff --brief --recursive dcp_shop/$dir shop/$dir
Only in shop/engine/Shopware/Plugins/Community/Backend: SwagImportExport
Only in dcp_shop/engine/Shopware/Plugins/Community/Core: SwagBulgaria
Only in dcp_shop/engine/Shopware/Plugins/Community/Core: SwagFrance
Only in dcp_shop/engine/Shopware/Plugins/Community/Core: SwagItaly
Only in dcp_shop/engine/Shopware/Plugins/Community/Core: SwagNetherlands
Only in dcp_shop/engine/Shopware/Plugins/Community/Core: SwagSpain
Only in shop/engine/Shopware/Plugins/Community/Frontend: ComerPluginHomeIcon
Only in dcp_shop/engine/Shopware/Plugins/Community/Frontend: SwagDemoDataDE

# Man weiß ja nie....mal das HomeIcon Plugin deaktiviert (hier nicht gelistet), ändert nichts.

dir=themes
diff --brief --recursive dcp_shop/$dir shop/$dir
Only in dcp_shop/themes: .htaccess
Only in dcp_shop/themes/Frontend: DarkcryptLarpshop
Only in shop/themes/Frontend: ShopDWS

dir=vendor
diff --brief --recursive dcp_shop/$dir shop/$dir
Only in shop/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Endpoints: ReIndex.php
Only in shop/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Endpoints/Tasks: Show.php
Only in shop/vendor/elasticsearch/elasticsearch/src/Elasticsearch/Namespaces: TaskNamespace.php
Only in dcp_shop/vendor/symfony/intl/DateFormatter/DateFormat: TimeZoneTransformer.php
Files dcp_shop/vendor/symfony/intl/Resources/data/currencies/ff_GN.json and shop/vendor/symfony/intl/Resources/data/currencies/ff_GN.json differ
Files dcp_shop/vendor/symfony/intl/Resources/data/currencies/ff_MR.json and shop/vendor/symfony/intl/Resources/data/currencies/ff_MR.json differ
Only in shop/vendor/symfony/intl/Resources/data/scripts: en_GB.json

Damit mir das jetzt noch wer glaubt - hier die Config.

de = Zweitsystem (geht ja jetzt), info = Hauptsystem (geht weiterhin nicht)

…und jetzt halten wir uns mal alle gut fest. Das hier wars:

Das wurde unter meinem Login nicht ausgespuckt*, bin durch einen Hinweis des einen Shopusers bei uns aber eben zum Fixen dieser Thematik übergegangen und…tada…

* Ich weiß, ich weiß. Wahrscheinlich wurde es auch angezeigt. Bei diesem ultra mies langsamen drecks 1&1 Hosting habe ich aber bereits 50 Configfenster aufgeklickt im Backend wenn ich was vorhabe, und wahrscheinlich hat dann - als eben entsprechend dann alles auf einmal geladen hat - das immer brav überlagert.

Selbst Schuld mit dem Hoster.

Ich habe jetzt gerade nochmal eine Bestellung aus Kundensicht durchgeklickt, und es läuft.

Danke an alle Beteiligten und echt sorry dass es am Ende an so einem Schmarn hängen musste. Wobei das ja auch sein Gutes hat - es liegt nicht an der Software.

Summa summarum scheint das beim Umzug auf den 1&1 Hoster passiert zu sein, weil auf dem alten Hoster gab es das Problem nicht. Der Eintrag wurde in der DB nun auch mit s:23:mail@domain.tld angelegt. Im Export steht er mit s:22. Verstehe wer will, manuell hat das ja keiner angefasst, und es war auch ein simpler Export via phpMyAdmin.

So. Ich geh mir jetzt Benzin an der Tankstelle kaufen und irgendwas anzünden. Das hält man ja im Kopf nicht aus die Geschichte Blush

Könntes Du bitte erläutern, wie Du das Problem gelöst hast? Ich verstehe Deinen letzten Post nicht :-D 

1 Like

@voelpel schrieb:

Könntes Du bitte erläutern, wie Du das Problem gelöst hast? Ich verstehe Deinen letzten Post nicht :-D 

Ich ebenfalls nicht :D 

Falls es noch jemanden betrifft.

Ich hatte das Problem eben auch (Shopware 5.4.4 und IONOS Email Server).

Der Shopware mailer funktionierte lange Zeit mit PORT 587 Präfiix = nix.

Nun muss da stehen: PORT 25, Präfix TLS.

Dann werden Emails wieder versandt.