-
-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem mit sendmail bzw. SMTP #1613
Comments
|
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. |
Wie Nicky schon erwähnt hat benötigt man dafür aber evt. mehrere SMTP Server. Wenn du bspw. eine Multidomain Installation hast, mit |
Das ist mMn der richtige Ansatz, also den Ouputweg zu abstrahieren. Allerdings verschiebt es die Konfiguration wieder in den Userbereich. |
|
ok ... also hab ich jetzt erstmal verloren mit meiner Multidomain- und Multimail-Installation?! Oha ... |
|
Notification-Center mit verschiedenen Gateways als Workaround? |
Für Formulare sicherlich kein Problem, aber Newsletter?! |
|
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');
}
}
); |
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. |
|
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? |
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.
Wie meinst du das? Bei diversen Hostern ist der Mailserver getrennt von den Webservern. Also bin ich wieder bei Anmeldedaten via SMTP.
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 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. |
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. |
|
Gibts hierzu schon was neues zu diskutieren? :) |
|
Bin gerade auch in diesee Problematik gerutscht. Siehe schon die ganzen Kommentare von Nicky vorher. |
|
Wie am 30. August auf Mumble besprochen, wäre es sinnvoll, wenn man mehrere Swiftmailer-Konfigurationen in der |
|
Als kurzfristige Lösung wollen wir versuchen, wieder mit Swiftmailer 5 kompatibel zu sein. |
|
Kurzfristige Lösung implementiert in contao/contao@69d6e34. |
Gibt es hierzu schon einen Fortschritt, wann das implementiert wird? |
|
Im Zuge des letzten Entwicklertreffens habe ich dafür einen ersten Draft gemacht: contao/contao#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. |
Description ----------- | Q | A | -----------------| --- | Fixed issues | - | Docs PR or issue | - <!-- Bugfixes should be based on the 4.4 or 4.9 branch and features on the master branch. Select the correct branch in the "base:" drop-down menu above. Replace this notice with a short README for your feature/bugfix. This will help people to understand your PR and can be used as a start for the documentation. --> Commits ------- 8428d922 Fix the Contao toolbar labels
Description ----------- | Q | A | -----------------| --- | Fixed issues | Fixes contao/core-bundle#1613 | Docs PR or issue | contao/docs#465 _Note:_ this PR depends and is based on #1829. It will be rebased, once #1829 got merged. This is the alternative version of #1469, based on the [Symfony Mailer Component](https://symfony.com/doc/4.4/mailer.html) instead of the Swiftmailer Bundle. It makes the configured `framework.mailer.transports` selectable in the back end. Example: ```yml # config/config.yml framework: mailer: transports: app: smtps://app@example.org:foobar@example.org:465 page: smtps://page@example.org:foobar@example.org:465 forms: smtps://forms@example.org:foobar@example.org:465 newsletter: smtps://newsletter@example.org:foobar@example.org:465 contao: mailer: transports: page: ~ forms: ~ newsletter: ~ ``` <img src="https://user-images.githubusercontent.com/4970961/84607561-e3a06d00-aea5-11ea-9f89-daac495b8a85.png" alt="mailer_transport_01" width="576"> _Note:_ only the transports configured in `contao.mailer.transports` will be available for selection. You can also provide translations: ```yml # translations/mailer_transports.en.yml page: 'Page' forms: 'Forms' newsletter: 'Newsletters' ``` <img src="https://user-images.githubusercontent.com/4970961/84607577-f7e46a00-aea5-11ea-9cd1-59271843609b.png" alt="mailer_transport_02" width="576"> And you can override the `From` address for each transport in the Contao configuration: ```yml contao: mailer: transports: page: from: Contao Page <page@example.org> forms: from: Contao Forms <forms@example.org> newsletter: from: Contao Newsletter <newsletter@example.org> ``` <img src="https://user-images.githubusercontent.com/4970961/84607478-670d8e80-aea5-11ea-9bdd-1cb2b090fd5a.png" alt="mailer_transport_03" width="576"> _Note:_ only the transports configured in `contao.mailer.transports` will be available for selection. Using the Symfony Mailer Component for this seems more elegant to me, since it requires no change whatsoever in the `\Contao\Email` class ([see the comparison](fritzmg/contao@feature/symfony-mailer...feature/available-symfony-mailers)). With the Symfony Mailer Component, the transport to be used is simply chosen with an `X-Transport` header in the email message itself. This PR decorates the `mailer` service and automatically sets an `X-Transport` header based on the website root settings - and automatically overrides the `From` address based on the chosen transport. Commits ------- fd3da56 switch to symfony/mailer 6c21d67 change MAILER_DSN back to MAILER_URL eeaea32 dynamically add default mailer 6ad300c add \Swift_Mailer fallback 71a5553 use MAILER_DSN with MAILER_URL fallback cc34824 remove Email deprecation 8c2480a increase symfony/mailer dependency 3926766 switch to symfony/mailer 3fd2799 dynamically add default mailer 43aa11c provide mailer transport selection and from override c38e864 add missing model property 8cee6db fix AvailableTransportsTest 08c9b20 fix code style a8d9b59 fix yml style ca47801 only show configured mailer transports within Contao e4f774f change translation domain 1722e81 restore previous version requirement 21b55d2 code style fix 1abfc38 rename mailer_transport DCA field to mailerTransport af8563c use Annotations for mailerTransport options callback 058da89 implement some early outs 4585e9d add missing model methods a2da52c fix code style f802003 Merge remote-tracking branch 'origin/master' into feature/available-symfony-mailers a5d7c74 add more unit tests 94203d7 use assertSame 38c3de9 improve testAnnotatedCallbacks test 3ca8e02 Rearrange the form fields in the back end 33f38c4 add missing methods b7159fe change wording to 'mailer transport' ba4f423 merge with master b8ffb36 Apply suggestions from code review Co-authored-by: Leo Feyer <github@contao.org>
Description ----------- | Q | A | -----------------| --- | Fixed issues | Fixes contao/core-bundle#1613 | Docs PR or issue | contao/docs#465 _Note:_ this PR depends and is based on #1829. It will be rebased, once #1829 got merged. This is the alternative version of #1469, based on the [Symfony Mailer Component](https://symfony.com/doc/4.4/mailer.html) instead of the Swiftmailer Bundle. It makes the configured `framework.mailer.transports` selectable in the back end. Example: ```yml # config/config.yml framework: mailer: transports: app: smtps://app@example.org:foobar@example.org:465 page: smtps://page@example.org:foobar@example.org:465 forms: smtps://forms@example.org:foobar@example.org:465 newsletter: smtps://newsletter@example.org:foobar@example.org:465 contao: mailer: transports: page: ~ forms: ~ newsletter: ~ ``` <img src="https://user-images.githubusercontent.com/4970961/84607561-e3a06d00-aea5-11ea-9f89-daac495b8a85.png" alt="mailer_transport_01" width="576"> _Note:_ only the transports configured in `contao.mailer.transports` will be available for selection. You can also provide translations: ```yml # translations/mailer_transports.en.yml page: 'Page' forms: 'Forms' newsletter: 'Newsletters' ``` <img src="https://user-images.githubusercontent.com/4970961/84607577-f7e46a00-aea5-11ea-9cd1-59271843609b.png" alt="mailer_transport_02" width="576"> And you can override the `From` address for each transport in the Contao configuration: ```yml contao: mailer: transports: page: from: Contao Page <page@example.org> forms: from: Contao Forms <forms@example.org> newsletter: from: Contao Newsletter <newsletter@example.org> ``` <img src="https://user-images.githubusercontent.com/4970961/84607478-670d8e80-aea5-11ea-9bdd-1cb2b090fd5a.png" alt="mailer_transport_03" width="576"> _Note:_ only the transports configured in `contao.mailer.transports` will be available for selection. Using the Symfony Mailer Component for this seems more elegant to me, since it requires no change whatsoever in the `\Contao\Email` class ([see the comparison](fritzmg/contao@feature/symfony-mailer...feature/available-symfony-mailers)). With the Symfony Mailer Component, the transport to be used is simply chosen with an `X-Transport` header in the email message itself. This PR decorates the `mailer` service and automatically sets an `X-Transport` header based on the website root settings - and automatically overrides the `From` address based on the chosen transport. Commits ------- fd3da56a switch to symfony/mailer 6c21d672 change MAILER_DSN back to MAILER_URL eeaea321 dynamically add default mailer 6ad300c4 add \Swift_Mailer fallback 71a5553a use MAILER_DSN with MAILER_URL fallback cc348243 remove Email deprecation 8c2480a7 increase symfony/mailer dependency 39267663 switch to symfony/mailer 3fd2799c dynamically add default mailer 43aa11c3 provide mailer transport selection and from override c38e8646 add missing model property 8cee6db5 fix AvailableTransportsTest 08c9b201 fix code style a8d9b591 fix yml style ca478014 only show configured mailer transports within Contao e4f774f6 change translation domain 1722e810 restore previous version requirement 21b55d24 code style fix 1abfc387 rename mailer_transport DCA field to mailerTransport af8563c3 use Annotations for mailerTransport options callback 058da895 implement some early outs 4585e9dd add missing model methods a2da52c8 fix code style f8020035 Merge remote-tracking branch 'origin/master' into feature/available-symfony-mailers a5d7c747 add more unit tests 94203d73 use assertSame 38c3de95 improve testAnnotatedCallbacks test 3ca8e024 Rearrange the form fields in the back end 33f38c43 add missing methods b7159fe0 change wording to 'mailer transport' ba4f4232 merge with master b8ffb367 Apply suggestions from code review Co-authored-by: Leo Feyer <github@contao.org>
Description ----------- | Q | A | -----------------| --- | Fixed issues | Fixes #1613 | Docs PR or issue | contao/docs#465 _Note:_ this PR depends and is based on #1829. It will be rebased, once #1829 got merged. This is the alternative version of #1469, based on the [Symfony Mailer Component](https://symfony.com/doc/4.4/mailer.html) instead of the Swiftmailer Bundle. It makes the configured `framework.mailer.transports` selectable in the back end. Example: ```yml # config/config.yml framework: mailer: transports: app: smtps://app@example.org:foobar@example.org:465 page: smtps://page@example.org:foobar@example.org:465 forms: smtps://forms@example.org:foobar@example.org:465 newsletter: smtps://newsletter@example.org:foobar@example.org:465 contao: mailer: transports: page: ~ forms: ~ newsletter: ~ ``` <img src="https://user-images.githubusercontent.com/4970961/84607561-e3a06d00-aea5-11ea-9f89-daac495b8a85.png" alt="mailer_transport_01" width="576"> _Note:_ only the transports configured in `contao.mailer.transports` will be available for selection. You can also provide translations: ```yml # translations/mailer_transports.en.yml page: 'Page' forms: 'Forms' newsletter: 'Newsletters' ``` <img src="https://user-images.githubusercontent.com/4970961/84607577-f7e46a00-aea5-11ea-9cd1-59271843609b.png" alt="mailer_transport_02" width="576"> And you can override the `From` address for each transport in the Contao configuration: ```yml contao: mailer: transports: page: from: Contao Page <page@example.org> forms: from: Contao Forms <forms@example.org> newsletter: from: Contao Newsletter <newsletter@example.org> ``` <img src="https://user-images.githubusercontent.com/4970961/84607478-670d8e80-aea5-11ea-9bdd-1cb2b090fd5a.png" alt="mailer_transport_03" width="576"> _Note:_ only the transports configured in `contao.mailer.transports` will be available for selection. Using the Symfony Mailer Component for this seems more elegant to me, since it requires no change whatsoever in the `\Contao\Email` class ([see the comparison](fritzmg/contao@feature/symfony-mailer...feature/available-symfony-mailers)). With the Symfony Mailer Component, the transport to be used is simply chosen with an `X-Transport` header in the email message itself. This PR decorates the `mailer` service and automatically sets an `X-Transport` header based on the website root settings - and automatically overrides the `From` address based on the chosen transport. Commits ------- fd3da56a switch to symfony/mailer 6c21d672 change MAILER_DSN back to MAILER_URL eeaea321 dynamically add default mailer 6ad300c4 add \Swift_Mailer fallback 71a5553a use MAILER_DSN with MAILER_URL fallback cc348243 remove Email deprecation 8c2480a7 increase symfony/mailer dependency 39267663 switch to symfony/mailer 3fd2799c dynamically add default mailer 43aa11c3 provide mailer transport selection and from override c38e8646 add missing model property 8cee6db5 fix AvailableTransportsTest 08c9b201 fix code style a8d9b591 fix yml style ca478014 only show configured mailer transports within Contao e4f774f6 change translation domain 1722e810 restore previous version requirement 21b55d24 code style fix 1abfc387 rename mailer_transport DCA field to mailerTransport af8563c3 use Annotations for mailerTransport options callback 058da895 implement some early outs 4585e9dd add missing model methods a2da52c8 fix code style f8020035 Merge remote-tracking branch 'origin/master' into feature/available-symfony-mailers a5d7c747 add more unit tests 94203d73 use assertSame 38c3de95 improve testAnnotatedCallbacks test 3ca8e024 Rearrange the form fields in the back end 33f38c43 add missing methods b7159fe0 change wording to 'mailer transport' ba4f4232 merge with master b8ffb367 Apply suggestions from code review Co-authored-by: Leo Feyer <github@contao.org>
…tao#1830) Description ----------- | Q | A | -----------------| --- | Fixed issues | Fixes contao/core-bundle#1613 | Docs PR or issue | contao/docs#465 _Note:_ this PR depends and is based on contao#1829. It will be rebased, once contao#1829 got merged. This is the alternative version of contao#1469, based on the [Symfony Mailer Component](https://symfony.com/doc/4.4/mailer.html) instead of the Swiftmailer Bundle. It makes the configured `framework.mailer.transports` selectable in the back end. Example: ```yml # config/config.yml framework: mailer: transports: app: smtps://app@example.org:foobar@example.org:465 page: smtps://page@example.org:foobar@example.org:465 forms: smtps://forms@example.org:foobar@example.org:465 newsletter: smtps://newsletter@example.org:foobar@example.org:465 contao: mailer: transports: page: ~ forms: ~ newsletter: ~ ``` <img src="https://user-images.githubusercontent.com/4970961/84607561-e3a06d00-aea5-11ea-9f89-daac495b8a85.png" alt="mailer_transport_01" width="576"> _Note:_ only the transports configured in `contao.mailer.transports` will be available for selection. You can also provide translations: ```yml # translations/mailer_transports.en.yml page: 'Page' forms: 'Forms' newsletter: 'Newsletters' ``` <img src="https://user-images.githubusercontent.com/4970961/84607577-f7e46a00-aea5-11ea-9cd1-59271843609b.png" alt="mailer_transport_02" width="576"> And you can override the `From` address for each transport in the Contao configuration: ```yml contao: mailer: transports: page: from: Contao Page <page@example.org> forms: from: Contao Forms <forms@example.org> newsletter: from: Contao Newsletter <newsletter@example.org> ``` <img src="https://user-images.githubusercontent.com/4970961/84607478-670d8e80-aea5-11ea-9bdd-1cb2b090fd5a.png" alt="mailer_transport_03" width="576"> _Note:_ only the transports configured in `contao.mailer.transports` will be available for selection. Using the Symfony Mailer Component for this seems more elegant to me, since it requires no change whatsoever in the `\Contao\Email` class ([see the comparison](fritzmg/contao@feature/symfony-mailer...feature/available-symfony-mailers)). With the Symfony Mailer Component, the transport to be used is simply chosen with an `X-Transport` header in the email message itself. This PR decorates the `mailer` service and automatically sets an `X-Transport` header based on the website root settings - and automatically overrides the `From` address based on the chosen transport. Commits ------- fd3da56 switch to symfony/mailer 6c21d67 change MAILER_DSN back to MAILER_URL eeaea32 dynamically add default mailer 6ad300c add \Swift_Mailer fallback 71a5553 use MAILER_DSN with MAILER_URL fallback cc34824 remove Email deprecation 8c2480a increase symfony/mailer dependency 3926766 switch to symfony/mailer 3fd2799 dynamically add default mailer 43aa11c provide mailer transport selection and from override c38e864 add missing model property 8cee6db fix AvailableTransportsTest 08c9b20 fix code style a8d9b59 fix yml style ca47801 only show configured mailer transports within Contao e4f774f change translation domain 1722e81 restore previous version requirement 21b55d2 code style fix 1abfc38 rename mailer_transport DCA field to mailerTransport af8563c use Annotations for mailerTransport options callback 058da89 implement some early outs 4585e9d add missing model methods a2da52c fix code style f802003 Merge remote-tracking branch 'origin/master' into feature/available-symfony-mailers a5d7c74 add more unit tests 94203d7 use assertSame 38c3de9 improve testAnnotatedCallbacks test 3ca8e02 Rearrange the form fields in the back end 33f38c4 add missing methods b7159fe change wording to 'mailer transport' ba4f423 merge with master b8ffb36 Apply suggestions from code review Co-authored-by: Leo Feyer <github@contao.org>

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.ymleinrichten.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?
The text was updated successfully, but these errors were encountered: