search

contao / core-bundle

[READ-ONLY] Contao Core Bundle
GNU Lesser General Public License v3.0
123 stars 58 forks source link

Problem mit sendmail bzw. SMTP #1613

Closed frontendschlampe closed 4 years ago

frontendschlampe commented 6 years ago

Ich war gerade etwas verwundert, als ich in einer neuen Contao 4.5.10 keine Mails mehr über Contao verschicken konnte. Es kam lediglich folgende Fehlermeldung:

[2018-07-11 09:49:23] app.CRITICAL: An exception occurred. {"exception":"[object] (Swift_TransportException(code: 0): Expected response code 220 but got code \"\", with message \"\" at /www/htdocs/XXX/newsletter/vendor/swiftmailer/swiftmailer/lib/classes/Swift/Transport/AbstractSmtpTransport.php:445)"} []

Bisher musste man da ja nix anpassen und Contao hat fein Mails versendet. Nach einer kurzen Recherche bin ich darauf gestoßen, dass wohl irgendwie der Swiftmailer aktualisiert wurde und nun nur noch via sendmail oder smtp die Mails verschickt werden können (wenn ich das so laienhaft richtig verstanden habe). Da liegt nun aber das Problem, denn verschiedene Hoster haben gar kein sendmail bzw. verbieten es (z.B. Hetzner). Bei All-Inkl. ist es eigentlich via PHP verfügbar (via Konsole nicht), aber es werden keine Mails verschickt, sondern mit der o.g. Fehlermeldung abgebrochen. Bei Mittwald konnte ich noch nicht weiter testen, aber da funktioniert der Versand der Mails ohne SMTP auch nicht (selbe Fehlermeldung wie oben).

Natürlich könnte man jetzt als Alternative einfach SMTP benutzen, aber das ist nur sinnvoll, wenn man wirklich nur eine Mailadresse im ganzen System benutzt und keine weiteren Seitenbäume mit verschiedenen Domains im Contao hat, denn man kann nur einen SMTP in der config.yml einrichten.

Dafür bräuchte es eine Lösung. Ein einfacher Weg wäre wahrscheinlich die Einrichtung der SMTP-Daten pro Startpunkt in der Seitenstruktur. Das würde auf jeden Fall das Problem lösen, wenn man mehrere Seitenbäume mit unterschiedlichen Domains hat, aber es löst nicht das Problem, wenn man verschiedene Mailadressen pro Seitenbaum nutzen möchte.

Eigentlich wäre eine Lösung ähnlich dem Notification Center sinnvoll: Ich richte verschiedene Gateways ein, die ich dann bei den entsprechenden Formularen oder Modulen auswählen kann. Wenn man da noch die Auswahl für sendmail und SMTP hätte, wäre das wahrscheinlich am Sinnvollsten.

Fakt ist, dass diverse Installation nach einem Update keine Mails mehr verschicken können und gerade Multidomaininstallation werden ein großes Problem haben.

Wie seht ihr das?

Toflar commented 6 years ago

Es ist tatsächlich ein Problem. Nur vielleicht zum Hintergrund, warum das von vorher nicht mehr geht: Es ist eine potenzielle Sicherheitslücke und deswegen wurde der Support dafür in Swiftmailer komplett entfernt. Es wäre ohnehin immer viel besser, man hätte ein SMTP Postfach für E-Mails. Es löst auch sonst viele Probleme (wie z.B. SPF wenn unterschiedliche Domains etc.) die immer mal wieder im Forum auftreten. Also evtl. sollten wir sogar die Angabe eines Postfachs erzwingen? Ich weiss es nicht...

fritzmg commented 6 years ago

Es wäre ohnehin immer viel besser, man hätte ein SMTP Postfach für E-Mails. Es löst auch sonst viele Probleme (wie z.B. SPF wenn unterschiedliche Domains etc.) die immer mal wieder im Forum auftreten. Also evtl. sollten wir sogar die Angabe eines Postfachs erzwingen? Ich weiss es nicht...

Wie Nicky schon erwähnt hat benötigt man dafür aber evt. mehrere SMTP Server. Wenn du bspw. eine Multidomain Installation hast, mit example.org und dasistgeil.at - und in jedem Website Root eine andere Absenderadresse definiert hast und jede Domain ihren eigenen SMTP Server hat, dann brauchst du auch pro Domain jeweils einen anderen SMTP Server - weil der SMTP Server der einen Domain evt. nicht die Absenderadresse der jeweils anderen Domain akzeptiert.

m-vo commented 6 years ago

Eigentlich wäre eine Lösung ähnlich dem Notification Center sinnvoll: Ich richte verschiedene Gateways ein [...]

Das ist mMn der richtige Ansatz, also den Ouputweg zu abstrahieren. Allerdings verschiebt es die Konfiguration wieder in den Userbereich.

frontendschlampe commented 6 years ago

ok ... also hab ich jetzt erstmal verloren mit meiner Multidomain- und Multimail-Installation?! Oha ...

m-vo commented 6 years ago

Notification-Center mit verschiedenen Gateways als Workaround?

frontendschlampe commented 6 years ago

Notification-Center mit verschiedenen Gateways als Workaround?

Für Formulare sicherlich kein Problem, aber Newsletter?!

leofeyer commented 6 years ago

Wir haben eigentlich einen Workaround dafür eingebaut:

        // The "mail" transport has been removed in SwiftMailer 6, so use "sendmail" instead
        $loader->load(
            function (ContainerBuilder $container): void {
                if ('mail' === $container->getParameter('mailer_transport')) {
                    $container->setParameter('mailer_transport', 'sendmail');
                }
            }
        );
frontendschlampe commented 6 years ago

Wir haben eigentlich einen Workaround dafür eingebaut:

ja, aber sendmail wird von diversen Hostern nicht unterstützt. Bei All-Inkl kann es wohl via PHP angesprochen werden, aber nicht via Konsole, was der Swiftmailer aber macht. Bei Hetzner und Mittwald scheint es ähnlich zu sein.

asaage commented 6 years ago

Für Formulare sicherlich kein Problem, aber Newsletter?!

Witzigerweise gab's für Newsletter mal SMTP Einstellungen in Contao3 image In C4 sehe ich davon nichts.

aschempp commented 6 years ago

Ich sehe da nicht wirklich ein Problem. In der alten Version hast du alles über einen Server versendet, nämlich deinen Webserver. Alle SMTP-Server die ich kenne akzeptieren jeden Absender, wenn du dich erst authenticated hast. In den meisten Fällen bietet der Webserver selber einen SMTP Server, also kannst du weiterhin einfach über den versenden?

frontendschlampe commented 6 years ago

Ich sehe da nicht wirklich ein Problem. In der alten Version hast du alles über einen Server versendet, nämlich deinen Webserver. Alle SMTP-Server die ich kenne akzeptieren jeden Absender, wenn du dich erst authenticated hast.

Dies gilt nur für die angemeldete Domain, aber nicht für eine andere, als die authentifizierte. Du kannst Dich mit den Zugangsdaten für mail@domain-a.tld per SMTP anmelden und in 99 % der Fälle mit jeglicher Adresse der Domain *@domain-a.tld Mails versenden, aber es geht nicht, dass du mit den Anmeldedaten für mail@domain-a.tld dann Mails mit mail@domain-b.tld senden kannst. Selbst wenn es funktionieren sollte, dann endet es spätestens dann, wenn die benutzten Domains von verschiedenen Servern kommen.

In den meisten Fällen bietet der Webserver selber einen SMTP Server, also kannst du weiterhin einfach über den versenden?

Wie meinst du das? Bei diversen Hostern ist der Mailserver getrennt von den Webservern. Also bin ich wieder bei Anmeldedaten via SMTP.

Witzigerweise gab's für Newsletter mal SMTP Einstellungen in Contao3

Ich finde es ebenfalls Schade, dass es diese Einstellung nicht mehr gibt, denn wenn man viele Newsletterempfänger und häufig Newsletter versendet, ist es durchaus sinnvoll, wenn man dafür einen bestimmten Mailserver verwendet. Gibt es denn Gründe, warum es entfernt wurde?

Bei allem hin und her und theoretischen Fachsimpeleien müssen wir uns leider eingestehen, dass das Thema des Mailversandes bisher nicht ausreichend betrachtet wurde. Aber wir mussten uns da auch bisher keine großen Gedanken machen, denn mit der mail() Funktion konnte fast alles problemlos abgehandelt werden. Des weiteren gab es in Contao 3 verschiedene Einstellungen zu SMTP-Servern (also global und zusätzlich Newsletter). Diese Möglichkeit besteht nun nicht mehr und wir sollten uns dazu Gedanken machen.

Aktuell werden wir da noch nicht so viele Probleme haben, denn viele nutzen die LTS-Version Contao 4.4, aber sobald es dann den Wechsel zur nächsten LTS geben wird, werden die Probleme stark sichtbar werden. Vielleicht sollte man sich wirklich Gedanken über die Integration des Notification Centers machen! Wenn man das integrieren würde und für sämtliche Newsletterversandsachen verwenden würde, dann hätten wir diverse Befindlichkeiten gelöst. Darunter fällt z.B. auch die Editierbarkeit der Bestätigungsmails. Ich bin gestern darüber gestolpert, dass ich zwar den Text einer DoubleOptIn Mail für den Newsletter ändern kann, aber der Betreff ist nicht änderbar (nur global über eine Sprachvariable). Außerdem gibt es keine Möglichkeit für die Eingabe einer ReplyTo-Adresse für Newsletter.

fritzmg commented 6 years ago

Alle SMTP-Server die ich kenne akzeptieren jeden Absender, wenn du dich erst authenticated hast.

Die Erfahrung kann ich eigentlich auch nicht teilen.

Die meisten unserer Kunden benutzen außerdem andere Email Lösungen als die des Website Hosters - die das auch meist nicht erlauben.

k-webdesign commented 6 years ago

Gibts hierzu schon was neues zu diskutieren? :)

NinaG commented 6 years ago

Bin gerade auch in diesee Problematik gerutscht. Siehe schon die ganzen Kommentare von Nicky vorher.

leofeyer commented 6 years ago

Wie am 30. August auf Mumble besprochen, wäre es sinnvoll, wenn man mehrere Swiftmailer-Konfigurationen in der config.yml anlegen könnte und diese dann pro Root-Seite, pro Formular und pro Newsletter-Channel auswählen könnte.

leofeyer commented 6 years ago

Als kurzfristige Lösung wollen wir versuchen, wieder mit Swiftmailer 5 kompatibel zu sein.

leofeyer commented 6 years ago

Kurzfristige Lösung implementiert in contao/contao@69d6e34c86b8bf5ad191c1400aa87a264b415214.

contaoacademy commented 4 years ago

Wie am 30. August auf Mumble besprochen, wäre es sinnvoll, wenn man mehrere Swiftmailer-Konfigurationen in der config.yml anlegen könnte und diese dann pro Root-Seite, pro Formular und pro Newsletter-Channel auswählen könnte.

Gibt es hierzu schon einen Fortschritt, wann das implementiert wird?

fritzmg commented 4 years ago

Im Zuge des letzten Entwicklertreffens habe ich dafür einen ersten Draft gemacht: https://github.com/contao/contao/pull/1469

Ist allerdings noch nicht final und noch up for discussion, weil mir diese Lösung nicht gefällt. Habe aber schon eine Idee für etwas besseres.