Kleiner Nachtrag zu meinem Eingangspost – ich hab mir den Code mal genauer angeschaut und
bin ziemlich sicher, woran der SendAsDenied bei der Newsletter-Anmeldung liegt.
Zur Erinnerung mein Setup (Shop 5.7.1): zwei SMTP-Konten verbunden – shop@ für die
Shop-Mails (globale E-Mail-Einstellungen) und info@ für den Newsletter (Marketing →
Newsletter → Einstellungen). Bei der Newsletter-Anmeldung kommt:
Template: core_jtl_newsletteranmelden
SMTP-Fehler: Daten werden nicht akzeptiert.
Fehler vom SMTP-Server: DATA END command failed
Detail: 5.2.252 SendAsDenied
Der SendAsDenied passt genau ins Bild: Die Mail geht über das globale Konto (shop@)
raus, hat aber die Newsletter-Absenderadresse (info@) im From – der Server lehnt das
„Senden im fremden Namen" ab. Es werden also tatsächlich die falschen SMTP-Daten benutzt.
Betrifft übrigens nicht nur die Anmeldebestätigung, sondern alle drei Wege:
Double-Opt-In, den eigentlichen Newsletter-Versand und den Test aus dem Backend.
Nachstellen: globalen SMTP auf Konto A, Newsletter-SMTP auf Konto B stellen, dann
anmelden bzw. testen – im Mail-Header/SMTP-Log landet alles auf Konto A.
Meine Vermutung (bin kein Kern-Entwickler): MailService scheint die SMTP-Daten immer
aus CONF_EMAILS zu holen. Beim Versand wird in Newsletter::send() zwar per setConfig()
umgestellt, das kommt aber offenbar nicht bis zum eigentlichen Versand durch; bei der
Anmeldebestätigung sehe ich gar keine Newsletter-Config. Dazu laufen die Mails über die
Queue (emails) und werden per Cron verschickt – und dort steht nichts darüber, welcher
Server genommen werden soll. Vermutlich „verfällt" die Auswahl dadurch.
Wann das wohl reingekommen ist: Ich hab mal in die Git-Historie geschaut – früher (bis
5.2.x) hat der alte Mailer den SMTP-Server direkt aus config['emails'] gelesen, und genau
diesen Schlüssel hat Newsletter::send() per setConfig() auf die Newsletter-Daten
umgebogen. Das hat damals also funktioniert. Mit dem Mail-Umbau in 5.3.0 (neue
emails-Queue + MailService, Ticket SHOP-2947) holt sich MailService den Server jetzt
direkt aus CONF_EMAILS und ignoriert das setConfig(). Der Newsletter-Block ist dabei
unverändert geblieben und läuft seitdem ins Leere. Sieht für mich also nach einer
Regression seit 5.3.0 aus – vorher ging's, daher vielleicht für euch leichter
einzuordnen.
Falls es hilft: Ich häng meine Bastellösung als Patch an. Idee: jede Mail bekommt eine
Markierung „gehört zum Newsletter", die in die Queue mitwandert; beim Versand wird darüber
der richtige Server gewählt. Wie ihr es sauber löst, wisst ihr besser. 🙂
Kleiner Hinweis: Die Newsletter-Versandmethode steht per Default auf „mail", nicht SMTP –
muss man erst umstellen.
Danke für eure Arbeit, und sagt Bescheid, wenn ich irgendwo danebenliege!
Viele Grüße
