Feature Requests: Separates E-Mail-Konto für Digests

Beitragen Merkmal
1

Von einem Einsteiger: Heute hatten wir die Erfahrung, dass praktisch alle unsere E-Mails abgeschaltet wurden. Nutzer konnten sich nicht registrieren, Passwörter wiederherstellen oder per E-Mail anmelden, weil der wöchentliche Newsletter nach einer Migration eines Legacy-Forums gestartet wurde und sich über 300.000 E-Mails in der Sidekiq-Warteschlange befanden. Daher erhielt niemand, der versuchte, sich per E-Mail anzumelden, sich zu registrieren oder sein Passwort wiederherzustellen, eine E-Mail und war am Arsch (wie man so sagt).

Das Problem bestand darin, dass wir GMAIL als E-Mail-Relay verwenden, und das (kostenlose) GMAIL setzt Grenzen für diese Art von SMTP-Weiterleitung. Daher hat uns GMAIL für den Tag gesperrt.

Ich möchte diese Funktion in Zukunft vorschlagen (es sei denn, es gibt eine andere Möglichkeit, dies zu lösen).

Vorschlag

Eine weitere Reihe von app.yml-Variablen hinzufügen, mit denen Administratoren einen anderen E-Mail-Relay für Newsletter einrichten können.

Während des Einrichtungsprozesses könnte das Dialogfenster folgende Frage stellen: “Möchten Sie einen anderen SMTP-Server für Newsletter einrichten?”. Der Nutzer könnte dann denselben SMTP-Relay verwenden, falls gewünscht.

Begründung

Für große Foren mit vielen Newsletter-Aktivitäten wäre es gut, eine Option zu haben, diese Newsletter-E-Mails über einen anderen SMTP-Relay zu senden als den, der für wichtige Aufgaben wie Passwortwiederherstellung, Anmeldung und Registrierung verwendet wird.

Derzeit haben wir alle Newsletter deaktiviert. Wir haben gesehen, dass es eine Möglichkeit gibt, dies auf die letzten X Tage zu beschränken. Der Standardwert, als ich es heute überprüft habe, betrug 365 Tage. Aus irgendeinem Grund hat unser migrierter Server über 300.000 Nachrichten in die Warteschlange gestellt.

Diskussion

Es ist kein riesiges Problem, aber ich denke, es wäre gut, Newsletter von kritischen E-Mails zu trennen; denn selbst wenn die Warteschlangenpriorität für kritische E-Mails höher ist, werden diese ebenfalls blockiert, wenn der SMTP-Relay aufgrund einer übermäßigen Anzahl von Newslettern blockiert wird.

Außerdem könnten einige Foren eine ähnliche Situation erleben und nicht wissen, warum ihre SMTP-E-Mails nicht funktionieren; tatsächlich wurden sie aus dem oben genannten Grund blockiert.

Vielen Dank für Ihre sorgfältige Prüfung.

TangentialDuck

2 „Gefällt mir“
2

Bitte beachten Sie, dass die Verwendung von kostenlosem Gmail zum Versenden von E-Mails über Discourse nicht unterstützt wird. Dies liegt erneut an den Nutzungsbedingungen von Google. Die Nutzung von Gmail auf diese Weise grenzt an eine unsupported-install.

Es ist schwer zu verstehen, wie diese Feature-Anfrage sinnvoll implementiert werden könnte. Hätten Sie einen unterstützten E-Mail-Mechanismus verwendet, wäre dieser Vorfall nicht passiert.

3

Das ist nicht richtig.

Wir verfügen über eine Google-Domain, und kostenlose E-Mail-Adressen werden seit vielen Jahren unterstützt und werden es auch weiterhin.

Hab etwas Verständnis, nachdem ich ein Forum seit 20 Jahren betreibe… Wir sind nicht erst gestern aus dem Ei geschlüpft, @Stephen

1 „Gefällt mir“
4

Das ist absolut der Fall. Communities, die unseren E-Mail-Leitfaden ignorieren, stoßen regelmäßig darauf.

Google erlaubt keine Transaktions-E-Mails von Gmail-Konten aus zu versenden, und wir haben bereits gesehen, dass Communities ihre Konten dauerhaft verloren haben, als sie dies versuchten. Auch bei kostenpflichtigen GSuite-Konten gibt es harte Limits für die Anzahl der Transaktions-E-Mails pro Tag. Sie sind nicht die erste Person in dieser Situation, und wir können Ihnen nicht dabei helfen, die von Google umgesetzten Bedingungen technisch zu umgehen.

1 „Gefällt mir“
5

Ich habe mich gerade in unser GSuite-Konto eingeloggt und die Nutzungsbedingungen geprüft. Was Sie sagen, ist nicht wahr:

@Stephen, Sie sind viel zu schnell mit dem Finger auf andere zu zeigen. Ich habe nicht nach einer Funktion gefragt, um „Googles Nutzungsbedingungen zu umgehen“, also bitte ich Sie, mir keine Worte in den Mund zu legen.

Sie sind viel zu schnell mit dem Finger auf andere zu zeigen und unterstellen Leuten zu Unrecht, @Steven. Vielleicht sollten Sie andere Personen bitten, auf meine Anfragen zu antworten, die nicht so schnell mit dem Finger zeigen?

6

Es gibt hier einige Widersprüche in dem, was du sagst:

Gmail ist nicht G-Suite. Bezahlte G-Suite-Accounts haben die folgenden Grenzen:

Grenztyp Grenze
Nachrichten pro Tag
Tägliches Sendelimit* 2.000 (500 für Testaccounts)

Kostenlose Gmail-Accounts haben immer das Limit von 500 E-Mails.

Das sind die Google-Nutzungsbedingungen (TOS), das hat nichts mit dem Obigen zu tun. Es gibt definitiv einen Unterschied zwischen „es hat bisher funktioniert

1 „Gefällt mir“
7

Ja, das wusste ich alles, bevor ich @Steven gepostet habe.

Du solltest wirklich davon absehen, das Wissen jemandes zu unterschätzen, der schon online war, bevor es den Mosaic-Browser gab, und darauf achten, wie du antwortest. Nimm den Spaß an Discourse und der Technik im Allgemeinen nicht, indem du andere beschuldigst.

Zuerst hast du mir gesagt: „Es gibt KEIN kostenloses GMAIL

8

Das deutet darauf hin, dass du Gmail und nicht GSuite verwendest, was gegen die Regeln verstößt. Viele Menschen, insbesondere solche, die nicht wissen, was Systemadministration ist, versuchen, Gmail zu nutzen, was einen Verstoß gegen die Nutzungsbedingungen darstellt. Das den Leuten zu sagen, ist eine gute Idee und nicht gemein oder unhöflich.

Aber du verwendest GSuite, was völlig in Ordnung ist. Das war aus deinem ursprünglichen Beitrag nicht ersichtlich. Deshalb scheint es, als würdest du so ungerecht behandelt.

Allerdings funktioniert GSuite auf einem Forum mit viel Verkehr, wie du beschreibst, nicht wirklich. Du bittest um eine neue Funktion, damit Discourse irgendwie mit einem Mail-Dienst funktioniert, der dich auf 2500 Nachrichten pro Tag begrenzt.

Es ist möglich, aber nicht sehr einfach, ein Plugin zu erstellen, das dies leistet. Ich vermute, dass dies mehrere Arbeitstage für jemanden erfordern würde, der mit der Discourse-Entwicklung vertraut ist.

Die Lösung besteht darin, einen Mail-Dienst zu verwenden, der die Menge an E-Mails liefern kann, die du senden musst.

2 „Gefällt mir“
9

Nur zur Nachfrage: Dieses Thema ist ein Duplikat. Die Anforderung für mehrere SMTP-Dienste wurde bereits zuvor gestellt:

Der Anwendungsfall hier ist etwas anders, aber das Problem entstand durch eine fehlerhafte Konfiguration des Digests. Unix.com hat 138.062 Benutzer. Ein Limit von 2.000 E-Mails pro Tag, selbst für mission-kritische Aufgaben wie Passwort-Resets, würde bedeuten, dass nur 1,8 % dieser Benutzer täglich interagieren könnten.

Edit: Korrigiert von 2.500 auf 2.000, um das tatsächliche Limit widerzuspiegeln.

1 „Gefällt mir“
10

Deswegen, @pfaffman, ist es für alle Online-Teilnehmer am besten, nicht zu voreilig beschuldigende Aussagen über andere bezüglich Technologie und/oder deren Motive zu machen. Normalerweise sollten wir Fragen stellen, bevor wir den Abzug betätigen und unser Gewehr abfeuern, LOL.

Ja, ich habe GMAIL statt GSUITE geschrieben, aber als ich diese Domain vor Jahrzehnten erstellt habe, gab es noch kein GSUITE, es hieß einfach nur GMAIL. Außerdem habe ich keine Präzision verwendet, weil meine Feature-Anfrage NICHTS MIT GMAIL ZU TUN HAT. Das ist eine völlig tangential Diskussion.

Wenn ich wollte (oder du wolltest), könnten wir zu jedem Server gehen, wie viele hier können, und apt install postfix oder apt install sendmail eingeben, und in 15 Minuten oder weniger hätten wir unseren eigenen SMTP-Relay zum Laufen gebracht.

Bitte ändern wir nicht das Thema der Verlagerung des hohen Aufkommens von einem Digest-Prozess zu einer GMail v. GSuite v. Blah Blah-Diskussion. apt install postfix ist trivial.

Das Problem ist eines der Zuverlässigkeit. Es ist grundlegendes 101-Wissen.

Das Betreiben von missionkritischer E-Mail auf demselben SMTP-Relay wie Digests ist nicht die Art, wie ich Dinge laufen lassen möchte, daher habe ich diese Feature-Anfrage gestellt.

Lass uns dies bitte auf das Thema konzentrieren, was ich anfrage, da ich weiß, wovon ich spreche, wenn es um den Aufbau von missionkritischen Apps geht.

Hier ist es noch einmal:

Ich möchte meine missionkritische E-Mail nicht auf demselben SMTP-Relay wie Digest-E-Mail haben, und ich denke, das ist eine gute Idee und macht das System robuster.

Lass uns die sehr tangential Diskussion über GMAIL oder GSuite oder MonkeyMail… blah blah beenden. Es tut mir leid, dass ich es überhaupt erwähnt habe, weil der E-Mail-Server für meine Feature-Anfrage nicht relevant ist.

Langsam werden. Sei freundlich zu anderen… Wenn jemand etwas postet und du etwas nicht verstehst oder verwirrt bist, dann frage; schieße nicht auf Leute, @Steven.

Ich kann in 10 Minuten einen SMTP-Relay aufbauen. Wir alle können. apt install postfix erledigt… Wenn ich GSuite oder postfix oder Donkey Kong Mail verwenden möchte, liegt das bei mir, nicht bei anderen. Wie ich sagte…

Der Hauptpunkt … (noch einmal)

Es ist zuverlässiger, missionkritische E-Mail auf einem anderen Server zu haben als auf einem Digest-Kanal. Das ist nur grundlegendes Wissen für einen sehr ausgelasteten Server.

apt install postfix erstellt einen SMTP-Relay. Ich bitte um eine Funktion, die es erlaubt, dass missionkritische E-Mail (Passwort-Resets, Registrierungs-E-Mails, E-Mail-Login) aus Zuverlässigkeits- und Leistungsgründen auf einem anderen Kanal als Digests liegt.

11

@Steven

Das ist nicht der Punkt. Das ist nebensächlich.

Nebenbemerkung: Tatsächlich hatten wir früher über 500.000 Nutzer, aber ich habe sie bereinigt :slight_smile:

Ich spreche davon, missionkritische E-Mails über einen anderen Kanal (SMTP-Relay) als den Digest-Verkehr zu versenden.

Sicherlich ist dieses einfache Konzept leicht zu verstehen, warum zwei Kanäle besser sind?

Diese Diskussion dreht sich völlig weg von der ursprünglichen Idee hinter meiner Feature-Anfrage.

Tut mir leid, dass ich überhaupt gepostet und gefragt habe… :frowning:

Diese Diskussion nach meinem ursprünglichen Beitrag war meiner Meinung nach völlig am Thema vorbei.

12

Du solltest niemanden von denen unterschätzen, die versuchen, dir zu helfen. Niemand ist gegen dich.

3 „Gefällt mir“
13

Dies ist mein letzter Beitrag zu diesem Thema.

Zum Thema GSuite (was überhaupt nicht der Kern meiner Feature-Anfrage ist):

  • Die maximale Anzahl an Nachrichten, die ein Benutzer innerhalb eines 24-Stunden-Zeitraums senden kann, beträgt 10.000. Dies kann jedoch variieren, je nach Anzahl der Benutzerlizenzen in Ihrem G Suite-Konto.
  • Ein registrierter G Suite-Benutzer kann innerhalb eines 24-Stunden-Zeitraums keine Nachrichten an mehr als 10.000 eindeutige Empfänger weiterleiten.

Ref: Route outgoing SMTP relay messages through Google  |  Set up & manage services  |  Google Workspace Help

Für mich ist dies jedoch völlig vom Thema ablenkend; denn selbst wenn GSuite 1000 Millionen+ E-Mails pro Tag über SMTP-Relay erlauben würde, würde ich dennoch einen separaten SMTP-Relay-Kanal für kritische E-Mails im Vergleich zu Zusammenfassungse-Mails bevorzugen.

Das ist der Punkt.

Vielen Dank. Bitte berücksichtigen Sie dies in einem zukünftigen Update. Ich denke, es ist relativ einfach, dies hinzuzufügen.

Diese Feature-Anfrage handelt nicht von Persönlichkeit und auch nicht von den Vorzügen oder Details von E-Mail-Anbietern.

Meine Feature-Anfrage betrifft die Zuverlässigkeit und die Trennung von kritischen E-Mails vom Zusammenfassungs-Kanal.

Über und aus… :slight_smile:

14

Die Entwickler von Discourse haben funktionierende Mail-Systeme. Sie werden keine Funktion für Nutzer hinzufügen, die mehrere unzuverlässige Mail-Systeme verwenden möchten. Falls Sie das wünschen, können Sie ein Plugin entwickeln. Das wird jedoch schwierig zu entwickeln und mühsam zu warten sein.

Postfix mag zwar einfach zu installieren sein, aber einen funktionierenden Mail-Server zu betreiben, ist heute weitaus schwieriger als damals, als ich Sendmail und uucp auf Linux portiert habe. Wenn der Betrieb eines Mail-Servers einfach wäre, hätten Sie bereits einen funktionierenden Mail-Server und würden nicht nach zwei suchen.

Das ist nicht meine Meinung, aber Sie könnten sich viel besser mit der Entwicklung von Discourse-Plugins auskennen als ich.

3 „Gefällt mir“
15

Eine einfache Lösung besteht darin, Digest-E-Mails global zu „deaktivieren“, wenn dies so viele Probleme verursacht. Die besten Vorschläge wurden möglicherweise bereits gemacht. Ich kann nur empfehlen, einen E-Mail-Anbieter zu nutzen, der keine Limits auferlegt, z. B. Mailgun. Auf diese Weise wird jeder zufrieden sein (es sei denn, Sie haben Einschränkungen, die Sie aus irgendeinem Grund auf die Nutzung eines bestimmten E-Mail-Anbieters beschränken).

4 „Gefällt mir“
16

Ich stimme zu, es gibt viele Widersprüche in dem, was @neounix ursprünglich gepostet hat, und viele Details ändern sich in den nachfolgenden Antworten.

Die Hervorhebung stammt von mir. Die Einschränkungen für kostenlose Accounts sind an anderer Stelle in diesem Thema bereits dokumentiert. Auch vererbte ‘kostenlose’ GSuite-Accounts unterliegen diesen Limits. Sollte es sich um einen kostenpflichtigen GSuite-Account handeln, ist der obige Kommentar irreführend und erklärt meine Antwort.

Auch hier bist du nicht klar, welchen Dienst du genau verwendest. Wenn es sich um die Legacy-Google-Apps in der kostenlosen Stufe handelt, dann bist du auf 500 Empfänger pro Tag pro Benutzer begrenzt, genau wie beim kostenlosen Gmail-Produkt. Wenn du einen kostenpflichtigen GSuite-Account verwendest, solltest du den Google SMTP-Relay-Dienst nutzen. Die Limits liegen bei 10.000 pro Tag pro Benutzer – besser, aber immer noch nicht großartig, besonders mit über 130.000 Benutzern, die ein Passwort zurücksetzen müssen. Es ist gut zu hören, dass du bei der Migration einige Benutzer entfernt hast, obwohl ich nicht sicher bin, wie relevant das wirklich ist.

Ich kann verstehen, dass du frustriert bist; deine Tests haben die Digests, die in die Warteschlange gelangt wären, nicht erkannt. Das führte zu einer Zeit der effektiven Nichtverfügbarkeit für alle, die ihr Passwort zurücksetzen und wieder in ihre Accounts gelangen wollten.

Ein paar Mal hast du oben angedeutet, ich würde dir Worte in den Mund legen, aber soweit ich sehen kann, entsprechen die Antworten den Informationen, die du bereitgestellt hast. Entschuldigung, falls du anderer Meinung bist, aber beim erneuten Durchlesen der Beiträge ist immer noch nicht ganz klar, welches Produkt genau du verwendest.

Übrigens bin ich @Stephen, nicht @Steven – du markierst und benachrichtigst damit einen völlig anderen Benutzer.

3 „Gefällt mir“
17

Wenn das der Fall ist, kannst du gerne eine Finanzierung beantragen, indem du im Marketplace mit einem Budget postest. Außerdem gibt es oben einige wirklich gute Vorschläge :index_pointing_up: zur Reduzierung des E-Mail-Aufkommens. Ich empfehle, diese zu nutzen.

3 „Gefällt mir“
18

Derzeit haben wir Digests einfach komplett deaktiviert; hier ist die aktualisierte Hintergrundgeschichte:

Wir haben auch einen Staging-Server, und da Discourse standardmäßig wöchentliche Digests (mit einem 365-Tage-Fenster) aktiviert, hat dieser Staging-Server am letzten Wochenende ebenfalls einen Digest ausgelöst (was wir nicht erwartet hatten), LOL.

Also, bevor ich wusste, dass dies passieren würde (oder passieren könnte), habe ich versucht, ein Backup auf dem Staging-Server zu erstellen, und das System hat dies verweigert und einen Fehler ausgegeben. Ich habe die genaue Fehlermeldung in der Admin-Konsole vergessen, aber ich erinnere mich, dass es einen Hinweis auf die Mail-Warteschlange gab.

Mit diesem Hinweis habe ich nun nach sidekiq gesucht – und tatsächlich befanden sich über 300.000 Digest-Nachrichten in der Warteschlange, verursacht durch die Standard-Digest-Konfiguration mit „aktiviert

1 „Gefällt mir“
19

Ich würde normalerweise empfehlen, Mailhog zwischen eine Staging-Instanz und die Außenwelt zu setzen. In diesem Szenario ist es hervorragend geeignet.

4 „Gefällt mir“
20

Ich werde DISCOURSE_DISABLE_DIGEST_EMAILS zu meinen Staging-Instanzen hinzufügen. Aber mit der Einstellung „E-Mails deaktivieren“ nur für Nicht-Mitarbeiter ist dies kein großes Problem.

2 „Gefällt mir“