Mailqueue

[blickfang]

Hi,

webEdition verschickt Emails heute über php oder smtp direkt. Viele Mailboxen haben Beschränkungen und kommt eine Email bei php Versand nicht an, ist die Email (z.B. Kontaktformular) verloren.

Mit der Einführung einer Mailqueue könnte man den Mailversand protokollieren und steuern. Hierüber könnten Redakteure nachvollziehen, welche Mails wann an wen verschickt wurden. Aus dem Protokoll heraus könnte es eine "resend" Funktion geben, um den Versand eines bereits verschickten Emails erneut auszulösen.

Über allgemeine Einstellungen könnte die Abarbeitung der Queue konfiguriert werden, welche mit dem triggerTask cronjob erfolgen könnte. Unter Berücksichtigung, dass das Newslettermodul aktualisiert werden soll, könnte die Queue auch zentral dafür genutzt werden und eine Konfiguration getroffen werden n-Mails in Periode xy zu versenden.

Gruß, Timo

[haydi]

Hello und Guten Morgen,

wenn du über SMTP versendest, dann kümmert sich doch der Mailserver um die Queue.
Und wenn ein Versand nicht hat erfolgen können, dann kommt ein entsprechender Bounce zurück.

Ein Versand über php Mail (sendmail) ist nicht zu empfehlen ... schon gar nicht für Newsletter.
Hier besteht die Gefahr, dass Mails als Spam gesehen werden - der Webserver auf Blacklisten gesetzt wird.
Es sollte einfach nicht mehr sein, dass Mails über sendmail versendet werden.

Eine Queue über webEdition halte ich für ziemlich kompliziert... mmh... das auf die Schnelle meine Gedanken.

Grüßchen
Heidi

[blickfang]

Hi,
mit korrekten SPF-Records soltle der Versand über sendmail kein Problem darstellen. Aber auch bei Konfiguration über SMTP ist es für den administrativen Redakteur immer wieder sinnvoll zu sehen, was die Applikation denn so verschickt hat und die Möglichkeit zu haben, ein Mail erneut zu versenden.

Sonderlich kompliziert sehe ich die Umsetzung nicht. Man setzt die zu versendenen Mails in eine Tabelle und ein cronjob arbeitet die Tabelle ab.

Besonders im Hinblick auf Provider-Limits kann mit einer Queue verhindert werden, dass der Mail account gesperrt wird, wenn man zu viele Mails in z.B. 1h verschickt (über Postfach oder Webserver ist bei den meisten Providern dabei egal). Wer Massenmails (Newsletter oder Notification-Mails) verschickt, kann dafür als SMTP-Relay auch einen der bekannten Dienste einsetzen (z.B. AmazonS3 oder andere...), was in webEdition ja ohne Probleme auch hinterlegbar wäre.

Eine Queue hat zudem den Vorteil einer schedule Möglichkeit. Gibt man beim setzen der Mail in die Queue mit, zu wechem Zeitpunkt das Mail verschickt werden soll, kann man damit auch Marketingaktionen etc. steuern.

[ThomasGoebe]

Eine Warteschlange für E-Mails halte ich auch generell für sinvoll und ist in manch anderem System bereits Standard. Die Anwendungsfälle die Timo skizziert hat, sehe ich auch alle.

[haydi]

Hello,

Asche auf mein Haupt... Ich hab das mit der Mail-Queue am Schluss komplett vermischt mit einer anderen Geschichte bei der es um den Mail-Abruf noch zusätzlich ging!

Also... mal unabhängig davon, dass ich den Versand über sendmail problematisch finde - aber das wäre nicht unser Bier...
Eine Mail-Queue finde ich super und absolut notwendig -> für das Newsletter-Modul. Dachte aber, da hätten wir sowas schon?

Eine generelle Mail-Queue finde ich überflüssig.
Sollte dies dann für alle Mails gelten? Also bei über <we:sendmail> und über <we:form type="formmail"> und <we:addDelNewsletterEmail /> ... was noch?

Haben wir dann nicht auch ein DSGVO-Thema? Wir müssten Mail-Inhalte die bspw. über ein Kontaktformular abgeschickt werden speichern. Darf man das? Wie lange? ...

Viele Grüße
Haydi

[adrian]

Hallo zusammen, ich halte einen Mail-Queue auch für sinnvoll und die von Timo beschrieben Fälle tauchen im Agenturalltag immer wieder auf.

[ThomasGoebe]

@Haydi: die Queue hat erst einmal nichts mit der Versandmethode zu tun. Ob die Mails aus der Queue dann per sendmail, php mail() smtp oder (vielleicht irgendwann mal?) einem Anbieter wie mailgun etc. versendet werden ist davon erst einmal unabhängig. Die dsgvo Thematik ist aber durchaus relevant.
Wenn es eine queue gibt, dann nur wahlweise und mit Einstellmöglichkeiten, wie lange die Daten gespeichert werden.

[ArminSchulz]

Wo eine Queue nicht hilft:
Wenn z.B. der Empfangsserver nicht zurückmeldet, dass er die Mail nicht mag, erfährst du nie ob es angekommen ist oder nicht
Man geht davon aus, das es empfangen wurde.

Das ist bei vielen Systemen die Standardeinstellung (annehmen, nicht melden und dann verwerfen) bei Problemen mit SPF, Viren, nicht erlaubten Anhängen,... da hilft eine Queue dann eben doch nicht

Für den Cron-Job bräuchte man halt eine Seite die die Queue verwaltet an Ansprungpunkt.
Glaube aber nicht das es realisitisch ist Cron-Jobs über WE tatsächlich zu verwalten

[ThomasGoebe]

Wo eine Queue nicht hilft:
Wenn z.B. der Empfangsserver nicht zurückmeldet, dass er die Mail nicht mag, erfährst du nie ob es angekommen ist oder nicht
Man geht davon aus, das es empfangen wurde.

Richtig, da hilft die Queue nicht, aber das soll sie ja auch gar nicht. Das Problem ist ja auch ohne Queue vorhanden.

[mokraemer]

Hier laufen auch Sachen durcheinander:
die Mailqueue würde es der Reihe nach abarbeiten - ein erneuter Versand wäre damit nicht möglich - sie ist ja weg wenn sie versendet wurde.
Queue hin oder her, muß eine Mail auch verworfen werden, wenn unzustellbar (sofern das überhaupt ermittelt werden kann).
phpmail liefert die Mail an den lokalen Mail-Server - der eigentlich genau die Funktion der Queue hat. Ihm übergibt man erst mal alle Mails - er kümmert sich danach um den Versand, behandelt Fehler (wie Zielserver (temporär) nicht erreichbar, Sendefrequenz, ...)
Und ob man nun die Mails per phpmail oder SMTP einreicht ist der Unterschied nur wo der Mail-Server liegt. Bei phpmail muß er lokal liegen (oder zumindest ein Relay-Server sein)

Bei Postfix geht das bspw. wie es hier beschrieben ist:
https://stackoverflow.com/questions/509 ... ll-domains

Die Lösung liegt hier in einem richtig konfigurierten Mail-Server der genau das bietet. Mit einer Mail-Queue bauen wir in schlechter das nach, was es am Markt bereits seit 30 Jahren gibt.

[ThomasGoebe]

Nur das leider in der Real World viele Hoster phpmail nicht mehr unterstützen und fordern, dass SMTP Versand (selbst nicht im php konfiguriert) genutzt werden soll. Damit ist das seit 30 Jahren vorhandene leider nicht nutzbar.

[mokraemer]

doch, weil es eigentlich auch für SMTP gilt - die Einreichung per SMTP auf dem lokalen Server sollte eigentlich nur die Beschränkung haben, das nur extrem viele Mailings abgelehnt werden (Fehlfunktion) - das regelt bspw. das Newsletter Modul bereits.

[haydi]

Wir müssen hier unterscheiden und mit den Begrifflichkeiten aufpassen... Ich habe das Gefühl, dass hier von verschiedenen Sachen gesprochen wird...

Eine Mail-Queue eines Mailservers der je nach Rückmeldung nochmals versendet ... was er auch tut bzw. tun sollte und nicht unser Bier ist.
Wir verschicken die Mail... sie ist raus. Damit erledigt. Meine Meinung.

Was mir noch gar nicht klar ist... für welche Fälle wäre denn der Resend-Knopf gedacht?
Für <we:sendmail> usw. ebenso? Das halte ich für problematisch, denn dann müssten wir Mails abspeichern in einer Datenbank -> DSGVO
Davon abgesehen, dass es ansonsten etliche Masken benötigt, Berechtigungen, usw. ...

Eine Mail-Versende-Queue für den Einsatz eines Newsletters ... Versende nur x Mails pro Zeitraum y - das halte ich für den Versand von Newslettern für sinnvoll und wichtig. Aber das haben wir doch bereits?

Dann meine ich Timo auch noch so zu verstehen, dass eine Art Protokoll geführt werden soll, welche Mail wann an wen geschickt wurde. Hier haben wir wieder das Thema DSGVO.

[mokraemer]

"Was mir noch gar nicht klar ist... für welche Fälle wäre denn der Resend-Knopf gedacht?"
Theoretisch, wenn es nicht ankam; aber das können wir idr. gar nicht feststellen (die Rückmeldung des Mailservers bekommen wir ja nicht)

"Davon abgesehen, dass es ansonsten etliche Masken benötigt, Berechtigungen, usw. ..."
ja, so einfach wie Timo es skizziert ist es nicht, die Masken, Filter, Zugriffe etc. braucht es schon - die müssen dann alle gebaut werden.

"Dann meine ich Timo auch noch so zu verstehen, dass eine Art Protokoll geführt werden soll, welche Mail wann an wen geschickt wurde. Hier haben wir wieder das Thema DSGVO."

Richtig - und das kann man bei vielen Hostern (bspw. auch bei hetzner) einfach im Log nachschauen.
Speicherung ist durchaus ein Problem der DSGVO - aber wenn es kurzfristig ist und technischen Zwecken dient, wieder kein Problem (und mit dem Versand der Mail hat er einer Verarbeitung des Daten eh zugestimmt)

[ThomasGoebe]

Die Mailqueue würde z.B. beim SMTP Versand (aber auch bei phpmail, wo z.B. bei dF in den altern Tarifen teilweise mehr als 200 mail pro Stunde nicht zugelassen und weitere dann einfach verworfen wurden) ein Limit des Anbieters abfedern. Macht webEditon im Newslettermodul im Grunde bereits genau so (wie viele E-Mail pro Stunde / Minute verschicken, wie viel Wartezeit etc.).

Erneut senden kann auch sinnvoll sein, wenn jemand sagt "habe ich nicht bekommen oder aus versehen gelöscht".