ist es möglich, den Digest-Zeitraum pro tausend Community-Mitglieder zu optimieren? Jeden Montag versendet Discourse einige tausend E-Mails innerhalb von 1–2 Sekunden, was bei unserem benutzerdefinierten Mailserver zu SPAM-Problemen führt.
Was sind deine Ideen? Der Server sendet einfach Briefe an die Zielorte, wo sie unseren Brief in den SPAM-Ordner verschieben. Ich würde dasselbe tun, wenn mir jemand 2.000 Briefe in einer Sekunde schicken würde.
Verwenden Sie einen seriösen E-Mail-Versanddienst.
Wenn Sie Ihren eigenen SMTP-Server betreiben, laufen Sie Gefahr, in die üblichen damit verbundenen Fallstricke zu tappen. E-Mail-Dienstleister wie Mailgun und SendGrid setzen eine Reihe von Techniken ein, um sicherzustellen, dass ihre Server vertrauenswürdig sind und von den Zielnetzwerken als seriös eingestuft werden. Deshalb empfiehlt die Dokumentation, einen dieser Dienste anstelle eines selbst gehosteten Servers zu nutzen.
Genau – auch wenn Sie diese Nachrichten nur in Spitzenzeiten versenden, können seriöse Drittanbieter zuverlässig Hunderttausende von E-Mails pro Stunde in Postfächer von Drittanbietern liefern.
Leider können wir keine Unterstützung bieten, wenn Sie darauf bestehen, Ihren eigenen Mailserver zu betreiben. Wenn Sie sich entscheiden, die Empfehlungen nicht zu befolgen, übernehmen Sie die damit verbundene zusätzliche Komplexität.
Alles ist in Ordnung mit SMTP, einschließlich DMARC, SPF und DKIM. Ich nutze seit dem Jahr 2005 meinen eigenen SMTP-Server. Damals gab es noch keine nutzlosen „Geldmaschinen“-Dienste. Stellen wir uns vor, dass jemand morgen versucht, für die Luft zu verlangen…
Kommen wir also zurück zum Problem. Ich weiß, dass der einfachste Weg für einen Senior-Tester darin besteht, mich irgendwohin oder zu einem kostenpflichtigen Dienst weiterzuleiten. Könnte mir jemand helfen, einen kritischen Fehler in Discourse zu beheben? Ich bin immer noch der Meinung, dass Discourse nicht 10.000 E-Mails pro Sekunde versenden sollte. Es sollte ein Rotationsservice oder Ähnliches geben, der den „last_digest_timestamp“ zwischen den Konten normalisiert.
Ich bin nicht bei CDCK angestellt und habe auch kein finanzielles Interesse daran, Sie auf Drittanbieterdienste hinzuweisen.
Wenn Sie die Empfehlung und die Dokumentation nicht befolgen möchten, liegt das bei Ihnen. In diesem Fall führt das Sie jedoch vom Pfad der kostenlosen Unterstützung ab, die wir hier der Community bieten. Ihre einzige andere Option ist dann, einen Berater über das Marketplace zu kontaktieren.
Dies ist kein Discourse-Problem; das Problem liegt darin, dass Ihre Mailserver-IP nicht als vertrauenswürdig eingestuft wird. Wir können Ihnen dabei nicht helfen, dies zu beheben, und Sie lehnen es ab, die dafür verfügbaren Optionen in Betracht zu ziehen.
Ja, ich arbeite mit Communities, die das Zehnfache dieses Aufkommens versenden. Viele derjenigen, die große Communities leiten, operieren in diesem oder sogar einem noch größeren Maßstab.
Ihr Bedarf an E-Mail scheint nun Ihre Expertise bezüglich des Protokolls zur zuverlässigen Massenversendung von E-Mails zu übersteigen. Genau dafür gibt es diese Transaktions-E-Mail-Dienste. Niemand hier wirbt für ‘große E-Mail’-Lösungen – es geht schlicht um die Herausforderung, E-Mails in hohem Volumen zuverlässig zuzustellen.
Ihr Mailserver kann die E-Mails zwischenspeichern und die Zustellung über einen längeren Zeitraum verteilen. Dies ist in erster Linie eine Frage Ihres Mailservers und nicht von Discourse. Ich habe von Anfang der 1990er-Jahre bis etwa 2005 Mailserver betrieben, als Spam es zu schwierig machte. Heute ist es noch viel schwieriger.
Ich habe bestimmte Ratenbegrenzungen. Wenn Sie das nicht einmal tun, verfügen typische SMTP-Server über vorkonfigurierte Einstellungen für Sie. Die Mailserver sind heutzutage intelligenter und können Ihre Verzögerung zwischen den Nachrichten leicht erkennen.
Ja, weil sie den Dienst nutzen, den Sie zuvor erwähnt haben. Sie verstehen immer noch nicht den Unterschied zwischen diesen Diensten und dem persönlichen SMTP-Dienst. Sie nutzen einen riesigen Pool von IP-Adressen und simulieren verschiedene Absender. Dies ist eine gute Technik für Unternehmen, die „harten
Laut den oben genannten Antworten des Discourse-Teams sehen sie keine Probleme mit Discourse. Ich habe dieses Problem auf eine schmutzige Weise durch direktes Hacking der Datenbank gelöst. Hier ist meine Lösung:
cd /var/discourse
./launcher enter app
rails c
Topic.exec_sql("UPDATE users SET last_emailed_at = now() + interval '30' second * id WHERE last_emailed_at > ('2020-03-14'::date) AND last_emailed_at < ('2020-03-17'::date)")
Bitte aktualisieren Sie den Bereich für last_emailed_at in der SQL-Abfrage. Am 16. März hatte ich 4.000 Einträge für last_emailed_at an einem Tag. Daher wurden nun alle Benutzer auf 3 Tage mit einem Intervall von 30 Sekunden optimiert.
Discourse ist nicht dafür ausgelegt, mit einem persönlichen SMTP-Dienst verwendet zu werden. Entschuldigung, dass das nicht klar erklärt wurde; es kann definitiv funktionieren, aber für eine Community mit regelmäßiger E-Mail-Aktivität ist es keine gute Idee. Dies ist eine Einschränkung des aktuellen Zustands der E-Mail, und wir reagieren alle so gut wir können.