Neu Gsuite Emailversand aus JTL Shop nicht mehr möglich

[STH]

Hallo,

uns wurde gemeldet, dass die Funktion "Passwort zurücksetzen" in unserem Shop V5.3.3 nicht funktioniert.
Erster Schritt war ein eigenständiger Test -> Fehler konnte ich so bestätigen, es wird keine Mail verschickt.
Also direkt die Mailvorlage zurückgesetzt -> Fehler besteht weiterhin.
Nächster Schritt: Wann hat der Webshop eigentlich die letzte Mail verschickt? Siehe da: am 07.11.2024 ging die letzte Mail direkt vom Shop raus.
Also Konfiguration des E-Mailservers im Shop kontrolliert (App Passwort hat sich nicht geändert) - Fehler! "Username and Password not accepted"

Auffällig ist jedoch, dass der Mailversand mit gleichem Apppasswort aus der WaWi problemlos funktioniert.
Was genau kann ich hier noch machen? STARTLS Port 587 sind konfiguriert und gleich wie in den WaWi Emaileinstellungen. Ich kann keinen Unterschied erkennen. Das tägliche Sendelimit von G-Suite Accounts erreichen wir nie!


Konfigurationstest im Shop wirft das aus:

2024-11-26 07:33:37 Connection: opening to smtp-relay.gmail.com:587, timeout=30, options=array()
2024-11-26 07:33:37 Connection: opened
2024-11-26 07:33:37 SERVER -> CLIENT: 220 smtp-relay.gmail.com ESMTP a640c23a62f3a-aa50b5b12a2sm47446766b.234 - gsmtp
2024-11-26 07:33:37 CLIENT -> SERVER: EHLO web3.ecomdata.de
2024-11-26 07:33:37 SERVER -> CLIENT: 250-smtp-relay.gmail.com at your service, [2a10:b040:1::1:14]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
2024-11-26 07:33:37 CLIENT -> SERVER: STARTTLS
2024-11-26 07:33:37 SERVER -> CLIENT: 220 2.0.0 Ready to start TLS
2024-11-26 07:33:37 CLIENT -> SERVER: EHLO web3.ecomdata.de
2024-11-26 07:33:37 SERVER -> CLIENT: 250-smtp-relay.gmail.com at your service, [2a10:b040:1::1:14]
250-SIZE 157286400
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
2024-11-26 07:33:37 CLIENT -> SERVER: AUTH LOGIN
2024-11-26 07:33:37 SERVER -> CLIENT: 334 VXNlcm5hbWU6
2024-11-26 07:33:37 CLIENT -> SERVER: [credentials hidden]
2024-11-26 07:33:37 SERVER -> CLIENT: 334 UGFzc3dvcmQ6
2024-11-26 07:33:37 CLIENT -> SERVER: [credentials hidden]
2024-11-26 07:33:37 SERVER -> CLIENT: 535-5.7.8 Username and Password not accepted. For more information, go to
535 5.7.8 https://support.google.com/mail/?p=BadCredentials a640c23a62f3a-aa50b5b12a2sm47446766b.234 - gsmtp
2024-11-26 07:33:37 SMTP ERROR: Password command failed: 535-5.7.8 Username and Password not accepted. For more information, go to
535 5.7.8 https://support.google.com/mail/?p=BadCredentials a640c23a62f3a-aa50b5b12a2sm47446766b.234 - gsmtp
SMTP error: Authentication failed: Password command failed
2024-11-26 07:33:37 CLIENT -> SERVER: QUIT
2024-11-26 07:33:37 SERVER -> CLIENT: 221 2.0.0 closing connection a640c23a62f3a-aa50b5b12a2sm47446766b.234 - gsmtp
2024-11-26 07:33:37 Connection: closed

 

[STH]

Habe ein neues App Passwort erstellt (2FA ist für den Account aktiviert) - Fehler nach Test im Adminbereich des Webshops ist genau der gleiche, laut Übersicht in der Kontosicherheit wird das Passwort auch gar nicht verwendet:



Google hat ja mittlerweile die "less secure apps" Funktion deaktiviert (bis spätestens Jänner 2025 dann auch bei allen Gmail Accounts!) - insofern kann ich mir nur vorstellen, dass hier die Mailfunktion im Shop überarbeitet werden muss.

 

[STH]

Hat hier noch jemand einen Gsuite Account und könnte dies mit Apppasswort testen?
Der Gsuite Customer Support verweist auf JTL - es wurde nichts geändert und das Apppasswort wird nicht einmal mehr versucht.

 

[STH]

Niemand? Wir stehen vor dem Problem, dass der Kunde nur noch Rechnungen aus der WaWi erhält, aber keine Webshopbestellbestätigungen!

 

[sebjo82]

Liegt am Hoster, wenn das Passwort in einem anderen Client, wie zB Wawi oder Thunderbird funktioniert. Wir mussten auch einmal EcomData anschreiben und seitdem geht es wieder

 

[STH]

Liegt am Hoster, wenn das Passwort in einem anderen Client, wie zB Wawi oder Thunderbird funktioniert. Wir mussten auch einmal EcomData anschreiben und seitdem geht es wieder

Danke, dann schreibe ich dem Hoster!

 

[STH]

Hoster fand keinen Fehler und verweist an JTL (das Apppasswort funktioniert ja mit anderen Programmen, die IMAP/SMTP verwenden).
Bitte ein JTL Ticket lösen

 

[sebjo82]

probier mal diesen befehl auf deinem webserver:

openssl s_client -connect smtp.gmail.com:587 -starttls smtp

dann weißt du zumindest ob der webserver eine verbindung zu den gmail servern aufbauen kann

bei uns hat damals dieser befehl bereits fehlgeschlagen, sodass der fehler an den hoster weitergereicht werden konnte. app-passwort hatten wir auch zuerst in verdacht

 

[STH]

probier mal diesen befehl auf deinem webserver:

openssl s_client -connect smtp.gmail.com:587 -starttls smtp

dann weißt du zumindest ob der webserver eine verbindung zu den gmail servern aufbauen kann

bei uns hat damals dieser befehl bereits fehlgeschlagen, sodass der fehler an den hoster weitergereicht werden konnte. app-passwort hatten wir auch zuerst in verdacht

Danke für den Hinweis - verbindet auf unserem Hostingserver problemlos!
War auch irgendwie zu erwarten, wenn im Log des Webshopmailchecks schon eine Verbindung möglich war, jedoch ein Fehler bezüglich User zurückgeliefert wird.

Ich habe nun testweise meinen eigenen Gsuite Account als SMTP User im Shopbackend hinterlegt und ein Apppasswort erstellt. Der Fehler bleibt der gleiche:

SERVER -> CLIENT: 535-5.7.8 Username and Password not accepted.

Dann habe ich einen Account ohne 2FA hinterlegt, also mit Benutzername und Kennwort des Accounts (kein App Passwort). Der selbe Fehler erneut.

Ich kann mir den Fehler echt nicht mehr erklären.

 

[mh1]

Was meldet er wenn du mit dem App Passwort auf den Port 465 gehst?

 

[STH]

Was meldet er wenn du mit dem App Passwort auf den Port 465 gehst?

2024-12-04 11:27:09 Connection: opening to smtp.gmail.com:465, timeout=30, options=array()
2024-12-04 11:27:09 Connection: opened
2024-12-04 11:27:19 SERVER -> CLIENT:
2024-12-04 11:27:19 Connection: closing due to error
2024-12-04 11:27:19 Connection: closed
SMTP error: Connect failed

Egal welche Form von SMTP Security ich verwende (Keine, TLS, SSL)

Direkt vom Webserver aus:

openssl s_client -connect smtp.gmail.com:465 -starttls smtp
CONNECTED(00000003)

didn't found starttls in server response, try anyway...
write:errno=32
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 35 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1733311870
Timeout : 300 (sec)
Verify return code: 0 (ok)
---

 

[STH]

Egal welche Form von SMTP Security ich verwende (Keine, TLS, SSL)

Direkt vom Webserver aus:

So, nun hab ich einen Fehler gefunden - keine Ahnung wann oder wie, aber die Einstellung "SMTP-Security" muss zwingend auf "Keine" gestellt sein. Irgendwie dürfte sich diese Option geändert haben, da ich die Serversettings seit Initialsetup nicht mehr angerührt habe.
Ich teste momentan den Mailversand, aber zumindest scheint es so, als könne sich der Shop wieder korrekt authentifizieren. Mailversand blieb bisher aber noch aus...
Danke an alle für die Mithilfe!

 

[mh1]

Gmail macht auf Port 465 kein TLS. Der Befehl muss also sein: openssl s_client -connect smtp.gmail.com:465

Benutze für alle weiteren Tests aber ausschließlich openssl, denn nur so siehst du direkt, die Rückmeldungen des Mailservers.
Gmail gibt zu den meisten Fehlern dann auch immer noch nährere Informationen zur Problemlösung. Wenn du also nur auf den Testbutton im Anwendungsprogramm klickst, siehst du nur eine Rückmeldung "tut" oder "tut nicht" und je nach Anwendungsprogrammierung fehlen aber die Hinweise.

Spiele dann den üblichen SMTP Handshake durch. Sende also ein EHLO und melde dich dann mit AUTH PLAIN oder AUTH LOGIN an. Wahrscheinlich siehst du dann, an was es hängt.



EDIT:
Ich sehe gerade, dass deine Frage in der Zwischenzeit ja schon gelöst wurde.
Super, dass du es wieder zum Laufen gebracht hast

 

[STH]

Gmail macht auf Port 465 kein TLS. Der Befehl muss also sein: openssl s_client -connect smtp.gmail.com:465

Benutze für alle weiteren Tests aber ausschließlich openssl, denn nur so siehst du direkt, die Rückmeldungen des Mailservers.
Gmail gibt zu den meisten Fehlern dann auch immer noch nährere Informationen zur Problemlösung. Wenn du also nur auf den Testbutton im Anwendungsprogramm klickst, siehst du nur eine Rückmeldung "tut" oder "tut nicht" und je nach Anwendungsprogrammierung fehlen aber die Hinweise.

Spiele dann den üblichen SMTP Handshake durch. Sende also ein EHLO und melde dich dann mit AUTH PLAIN oder AUTH LOGIN an. Wahrscheinlich siehst du dann, an was es hängt.



EDIT:
Ich sehe gerade, dass deine Frage in der Zwischenzeit ja schon gelöst wurde.
Super, dass du es wieder zum Laufen gebracht hast

Offenbar nicht ganz gelöst, im Shoplog taucht nun dieser Fehler auf:



Email-Vorlage wurde bereits zurückgesetzt.
Im Test der Einstellung kommt zwar ein OK zurück, aber Mails schicken funktioniert dann doch nicht.

 

[STH]

So - nach ewiger Suche fand ich einen ähnlich verärgerten User wie mich:
https://forum.jtl-software.de/threads/smtp-fehler-emails-werden-nicht-versendet.192895/post-1123039

Und tatsächlich - per phpMail Funktion schickt der Shop plötzlich wieder Mails raus. Warum das Ganze bei uns am 07.11.2024 gestorben ist, verstehe ich zwar nicht, aber ich bin mal froh, dass die Kunden wieder Mails aus dem Shop kriegen.
Trotzdem wäre es schön, dem SMTP Fehler tatsächlich ausfindig zu machen, da JTL diese Verbindungsart ja auch empfiehlt.
Wäre ein OAuth für solche Accounts in zukünftigen Shop Versionen denkbar?

 

[STH]

Das Problem am phpMail Workaround ist, dass die Mails aus dem Shop häufig als Spam eingestuft werden.
Insofern wäre uns sehr geholfen, wenn endlich das Problem mit dem Mailversand seitens JTL Shop kontrolliert werden würde. Es liegt ja offensichtlich an der Art und Weise, wie sich JTL am SMTP Server anzumelden versucht.
Im Log erscheinen außerdem Mailvalidationfehler:

 

[mh1]

Hast du mal https://forum.jtl-software.de/threa...-shop-nicht-mehr-moeglich.228289/post-1239562 gemacht?
Was ist di Ausgabe? Wo bricht er ab?

 

[STH]

Hast du mal https://forum.jtl-software.de/threa...-shop-nicht-mehr-moeglich.228289/post-1239562 gemacht?
Was ist di Ausgabe? Wo bricht er ab?

Handschake gehrt durch, am Schluss steht Verify return code: 0 (ok)
Insgesamt sieht die Verbindung von meinem Server bei ecomdata zu google in Ordnung aus. Nur der Webshop will nicht wirklich

 

[mh1]

Handschake gehrt durch, am Schluss steht Verify return code: 0 (ok)
Insgesamt sieht die Verbindung von meinem Server bei ecomdata zu google in Ordnung aus. Nur der Webshop will nicht wirklich

Wie genau sehen denn die Meldungen im Anmeldeprozess aus?
Hast du dich denn jetzt mit AUTH PLAIN angemeldet, oder mit AUTH LOGIN?
....oder hat er schon beim EHLO einen Fehler gemeldet?

wenn du schreibst "am Schluss steht Verify return code: 0 (ok)" hast du ja erst das Zertifikat geprüft. Bekommst du denn keinen 220 oder 250 Statuscode?
Screenshots bzw. den Output hier reinkopieren (Zugangsdaten unkenntlich machen) wäre einfacher.
Lass dir doch nicht alles aus der Nase ziehen. Wenn man nach Hilfe fragt ist es immer gut, möglichst viel Informationen mitzugeben.
Aber da ich ja schonmal gefragt hatte wie der Output jetzt genau aussieht, gibt es wohl Gründe, warum du uns diesen nicht zeigst. Belassen wir es am besten soweit...

Die andere Möglichkeit ist, du bleibst bei dem PHPMail und untersuchst, warum deine Mails als Spam eingestuft werden.
Dazu musst du dir zunächst mal die Header Zeilen einer solchen Email ankucken.

 

[STH]

Wie genau sehen denn die Meldungen im Anmeldeprozess aus?
Hast du dich denn jetzt mit AUTH PLAIN angemeldet, oder mit AUTH LOGIN?
....oder hat er schon beim EHLO einen Fehler gemeldet?

wenn du schreibst "am Schluss steht Verify return code: 0 (ok)" hast du ja erst das Zertifikat geprüft. Bekommst du denn keinen 220 oder 250 Statuscode?
Screenshots bzw. den Output hier reinkopieren (Zugangsdaten unkenntlich machen) wäre einfacher.
Lass dir doch nicht alles aus der Nase ziehen. Wenn man nach Hilfe fragt ist es immer gut, möglichst viel Informationen mitzugeben.
Aber da ich ja schonmal gefragt hatte wie der Output jetzt genau aussieht, gibt es wohl Gründe, warum du uns diesen nicht zeigst. Belassen wir es am besten soweit...

Die andere Möglichkeit ist, du bleibst bei dem PHPMail und untersuchst, warum deine Mails als Spam eingestuft werden.
Dazu musst du dir zunächst mal die Header Zeilen einer solchen Email ankucken.

Bitteschön, hier der gesamte Output von openssl s_client -connect smtp.gmail.com:465

CONNECTED(00000003)
depth=3 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = smtp.gmail.com
verify return:1
---
Certificate chain
0 s:/CN=smtp.gmail.com
i:/C=US/O=Google Trust Services/CN=WR2
1 s:/C=US/O=Google Trust Services/CN=WR2
i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFIzCCBAugAwIBAgIRALZ0vTG2tcxjCagIYRcd1LAwDQYJKoZIhvcNAQELBQAw
OzELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczEM
MAoGA1UEAxMDV1IyMB4XDTI0MTEwNDA4Mzg0N1oXDTI1MDEyNzA4Mzg0NlowGTEX
MBUGA1UEAxMOc210cC5nbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQCwbHN+A+kBxlxRljIk+834+GCFNAFT3lK3bebgVL6DZedY7DWK/lXI
AHpmmuaGuuPXPW07zd0PMYhs96FhRl7JfPui/I8mZ9JyZ46GvKAbTWrXT3SqGN6i
0hYiAeBhr9r+lVrp/FZjsftLq9CC3Vz8BxJ7qQ04DGxCoCjjcHMz6RSG6/8aslf1
pXcOr3plgDishVRins/hC7mk8/azOn0oLXw4BMyNMYeaE1HqQg+VpfS19vy00/3c
WeA97Zvmt1MGTS8+CBXtw5OZTJ8296pKNERO8rvZgQTBYchJt4snsPy9FChJZrUO
r4FXxA4JaB0vvnZyWIEeb63rIYVhk+iHAgMBAAGjggJCMIICPjAOBgNVHQ8BAf8E
BAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH/BAIwADAdBgNVHQ4E
FgQUpNs23nNjqeM1E46DtmwKgMNR5+AwHwYDVR0jBBgwFoAU3hse7XkV1D43JMMh
u+w0OW1CsjAwWAYIKwYBBQUHAQEETDBKMCEGCCsGAQUFBzABhhVodHRwOi8vby5w
a2kuZ29vZy93cjIwJQYIKwYBBQUHMAKGGWh0dHA6Ly9pLnBraS5nb29nL3dyMi5j
cnQwGQYDVR0RBBIwEIIOc210cC5nbWFpbC5jb20wEwYDVR0gBAwwCjAIBgZngQwB
AgEwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2MucGtpLmdvb2cvd3IyLzlVVmJO
MHc1RTZZLmNybDCCAQUGCisGAQQB1nkCBAIEgfYEgfMA8QB2AE51oydcmhDDOFts
1N8/Uusd8OCOG41pwLH6ZLFimjnfAAABkvaKkLkAAAQDAEcwRQIhAOZEH1F6wKCl
jyjnjgSbVSuX6O+gF9NBBoQeWo89hvIpAiBWsL49S3LFLW19eSod04bFqaRujuJW
4RL67FsSj8+qhgB3AKLjCuRF772tm3447Udnd1PXgluElNcrXhssxLlQpEfnAAAB
kvaKkMcAAAQDAEgwRgIhALrF55d4wxYG38LAZJ4umXpJHUEuvjY/5geNdg6UBJeG
AiEA5AD5N/i/joK8JwXfb3XL+AkzEeBlTliiH7cVA9+/VpgwDQYJKoZIhvcNAQEL
BQADggEBAELC6Td4MORCsvyVKXI8/gYLAKjpg+h0DwY1Tw+3tCJfpM1k2RSs8kCM
AD9kQhFMcwI35d0yBoeuzWQqlIy1/UNx1FOftQoKDTGkns9nReKIgGkM3/UBWSBc
NJr+dbOQ5sW3i1LoeJkG/C0y3NyI3ka1f7ti2MNAf2/zA7IN08IOGUfUb8HLe5UN
qQ1c9aHeBqvDGWQk5L2TJz2qmhld1Os2WPq2bABWzxHfKcz9puoEDxzJqbem3tEs
lCppTr8AmV6wDjgA2O8FbGktTeo6BHDJcvd4V901XsZf1IhPvOU5QJQrPBAXaili
tidBcjIt7YknVn8fW1TwPwB8fb17m4Q=
-----END CERTIFICATE-----
subject=/CN=smtp.gmail.com
issuer=/C=US/O=Google Trust Services/CN=WR2
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4718 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES128-GCM-SHA256
Session-ID: EF7E74912C5D79A07A64811EC51E9C08842D630736BBA5DF0F650517E60B4F5C
Session-ID-ctx:
Master-Key: A281A56C93D4D6E0BC2B5E1E9AAFE869CC14C4E42F66B0E0E79544628B7A2E5A4BFF270DE62C374F661D06BD6BE44383
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 02 42 64 57 4e 60 c4 3c-4a 96 99 2f 75 79 cb 1b .BdWN`.<J../uy..
0010 - 34 38 9c 24 1c b9 d4 f4-b1 62 50 fe c8 a1 45 a8 48.$.....bP...E.
0020 - 04 63 e6 c0 a4 f7 fc c5-46 73 2e 94 16 09 0f 10 .c......Fs......
0030 - f9 7f 62 de 26 fd 5a e0-dd b7 44 16 17 8c 7d 2c ..b.&.Z...D...},
0040 - ee cf ad 95 ae 5b ba 30-ca a2 0f eb ca 61 14 59 .....[.0.....a.Y
0050 - 64 78 9a 64 aa 2f 64 26-25 76 4e e3 29 15 3b 77 dx.d./d&%vN.).;w
0060 - 09 8a c4 40 a8 a1 dd 37-34 1e 4f 4b 4b 84 a3 8d ...@...74.OKK...
0070 - cc 6c 3d 47 e9 5d da ea-a8 76 07 e0 dc 35 85 91 .l=G.]...v...5..
0080 - 5f 9c 58 ab ef 14 e6 af-64 71 b2 15 c5 c7 d5 6c _.X.....dq.....l
0090 - 5c cb 0c 06 94 92 a2 89-6d d4 02 71 9f 33 11 91 \.......m..q.3..
00a0 - 33 ef 08 bf 98 1f 1d cf-1e 59 7f 33 5f 92 c3 ca 3........Y.3_...
00b0 - 32 9a 8b e0 6e e3 4e e5-4c 3e e1 9e 83 8d 67 84 2...n.N.L>....g.
00c0 - 7b 43 36 d4 ce a0 f5 11-60 98 f3 ca 88 0e 64 5d {C6.....`.....d]
00d0 - 41 a6 04 84 46 42 52 55-40 8e 65 2e 73 75 78 c0 A...FBRU@.e.sux.

Start Time: 1733908613
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
220 smtp.gmail.com ESMTP 5b1f17b1804b1-434f32b8a65sm121558495e9.6 - gsmtp

und hier der komplette Output von openssl s_client -connect smtp.gmail.com:587 -starttls smtp:

CONNECTED(00000003)
depth=3 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=2 C = US, O = Google Trust Services LLC, CN = GTS Root R1
verify return:1
depth=1 C = US, O = Google Trust Services, CN = WR2
verify return:1
depth=0 CN = smtp.gmail.com
verify return:1
---
Certificate chain
0 s:/CN=smtp.gmail.com
i:/C=US/O=Google Trust Services/CN=WR2
1 s:/C=US/O=Google Trust Services/CN=WR2
i:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
2 s:/C=US/O=Google Trust Services LLC/CN=GTS Root R1
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEVzCCAz+gAwIBAgIRAPqVqBC5D/u/CvbiGAcxt54wDQYJKoZIhvcNAQELBQAw
OzELMAkGA1UEBhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczEM
MAoGA1UEAxMDV1IyMB4XDTI0MTEwNDA4Mzg0N1oXDTI1MDEyNzA4Mzg0NlowGTEX
MBUGA1UEAxMOc210cC5nbWFpbC5jb20wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNC
AASbRPP/xht+b1VTlJqB3qeGO7zVAvf3roK02Qax2KGatyjuXQKlwRwvop1ny2BM
s8mkwQPty0V9KVOQp6KLeXf1o4ICQTCCAj0wDgYDVR0PAQH/BAQDAgeAMBMGA1Ud
JQQMMAoGCCsGAQUFBwMBMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFHRn33XfDyP0
aG86IWN+w29Ht1K/MB8GA1UdIwQYMBaAFN4bHu15FdQ+NyTDIbvsNDltQrIwMFgG
CCsGAQUFBwEBBEwwSjAhBggrBgEFBQcwAYYVaHR0cDovL28ucGtpLmdvb2cvd3Iy
MCUGCCsGAQUFBzAChhlodHRwOi8vaS5wa2kuZ29vZy93cjIuY3J0MBkGA1UdEQQS
MBCCDnNtdHAuZ21haWwuY29tMBMGA1UdIAQMMAowCAYGZ4EMAQIBMDYGA1UdHwQv
MC0wK6ApoCeGJWh0dHA6Ly9jLnBraS5nb29nL3dyMi9vQkZZWWFoemdWSS5jcmww
ggEEBgorBgEEAdZ5AgQCBIH1BIHyAPAAdgDm0jFjQHeMwRBBBtdxuc7B0kD2loSG
+7qHMh39HjeOUAAAAZL2io+WAAAEAwBHMEUCIQDuhQuOZnX61sw0p49A3QAMGYQK
G6L/ZkVniuTCjdP2vAIgJxwspst16TSHYgt+wiovTOQYxpl8AFzCRn2nqKCHKBsA
dgDPEVbu1S58r/OHW9lpLpvpGnFnSrAX7KwB0lt3zsw7CAAAAZL2io+yAAAEAwBH
MEUCIGOJiuHORfkTq7FxcQ2DIIQjGRpEoewoAtDeJsNpeAU1AiEA0z1wWAbLUbeL
+gy0QvYEnPPiynzd5vRSMocHSmBV3qgwDQYJKoZIhvcNAQELBQADggEBAGz4DET7
Emflq5n+fIXRGoJ+k8QFbvGkpxDU/4NJb2Bm8moHHNjtAMj+ySpIgunz5SmbhFrb
cjeMkPyFSzLiYDWvzKNmyHaiAtKE6MfywnoO2ImdnRKpHxz2vX8E3B+dJB8urWx0
ORG1tcwsxdynGP/s66Cnkc48bcnkvwvHHhV6T7uoOwjjAIgFFur+pWoJi/4AGgAX
O0EfQJMEgpLx8SGjNENRw/8upDHoC3aink7xPoMkod+IjopUht7n9DS5NhETonRc
xgyUTtbGrunqbNpmmAGtZvYuoHlhnSXxtB6zJ7V84iv5xHAAPNW2b3e2FZnSz2JJ
p6FhmpjJ78WAyUk=
-----END CERTIFICATE-----
subject=/CN=smtp.gmail.com
issuer=/C=US/O=Google Trust Services/CN=WR2
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4608 bytes and written 450 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES128-GCM-SHA256
Session-ID: 6708A5C96A7DBDE5DCBA4C83CF9A911E962E7508AE182C10A9ADF84BDD26EF1B
Session-ID-ctx:
Master-Key: D119A4C43C6B4976225D12911EEC38266BBBA6BB1FC0653BF26E5CC6485FB23C53644A90572A3CD63DA2D53BA6D7BF4F
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 02 42 64 57 4e 60 c4 3c-4a 96 99 2f 75 79 cb 1b .BdWN`.<J../uy..
0010 - b1 87 00 e5 e4 0d f5 fc-ec 19 a3 75 3c 02 05 0a ...........u<...
0020 - 98 de 75 98 2f 07 f7 6f-8a 09 2e b7 4a 4e c7 66 ..u./..o....JN.f
0030 - dc 86 4f 53 8c ad b9 8b-31 bc 2d e7 cd 6f 4b 26 ..OS....1.-..oK&
0040 - b4 c9 55 35 13 cf d5 e7-d4 1c a0 73 b9 92 7a 80 ..U5.......s..z.
0050 - 80 1b 5e a3 60 ee e9 34-4b 6b 98 eb 87 77 a4 ef ..^.`..4Kk...w..
0060 - f6 5b 5a 88 eb 1a 2f 2f-9d 64 19 58 cc c9 26 0e .[Z...//.d.X..&.
0070 - cf 0d f4 56 2a 9e 91 0c-08 49 25 52 fc 8b c8 b4 ...V*....I%R....
0080 - 96 59 12 82 80 da 27 c7-3a b9 2a 82 ca 58 97 d1 .Y....'.:.*..X..
0090 - 5c b1 8e 2b 05 84 9e 7e-3a d3 d6 c2 e3 8e d9 28 \..+...~:......(
00a0 - 76 85 ab 09 96 b7 f8 e7-16 29 6e 70 72 52 20 8f v........)nprR .
00b0 - cc f5 2f c4 5a 73 05 da-93 df d9 18 96 44 ac 06 ../.Zs.......D..
00c0 - e9 cb 4c 89 ca 57 07 8f-72 90 f3 2f 5d 2d 4f cc ..L..W..r../]-O.
00d0 - e4 c8 05 78 7b 42 52 55-d2 ce f7 48 c5 7e d2 16 ...x{BRU...H.~..

Start Time: 1733908805
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
250 SMTPUTF8

Im Shop habe ich STARTLS/587/Plain hinterlegt und der Anmeldeprozess läuft laut "Konfiguration testen" durch - trotzdem gehen keine Mails raus und im Log ist der Fehler aus https://forum.jtl-software.de/threa...-shop-nicht-mehr-moeglich.228289/post-1239580 zu finden.
phpMail funktioniert, jedoch werden die Nachrichten als Spam markiert (SPF record wird gerade beim Hoster eingepflegt).


EDIT:
Jetzt habe ich den Fehler endlich ausfindig gemacht und kann wieder meine Settings von zuvor verwenden (587 mit SMTP Security TLS)
Es ist ein G-Suiteconfig Fehler - für den Shop musste ein SMTP Relay Dienst eingerichtet werden (für WaWi bereits passiert). Ich habe keine Ahnung, warum der Versand bisher ohne diesen Relay Dienst funktioniert hat, jedenfalls ist das Problem damit gelöst: