Es gibt jedoch auch einige Probleme mit Elastic Email: Add IsTransactional:true to SMTP Mail Headers to satisfy ElasticEmail - #8 by pfaffman
Jay, danke, dass du das angesprochen hast. Lass mich das besser verstehen:
Worauf du hinweist, ist: Wenn E-Mails von Elastic Email zugestellt werden, erhalten die Empfänger einen sehr auffälligen Link und können einseitig die E-Mail-Zustellung abbestellen, ohne dass Discourse davon erfährt? Du als SA bliebst dann im Unklaren?
Ich habe keine eigene Erfahrung damit.
Es klingt so, als würden sie einen Abmeldelink einfügen und ein spezieller Header erforderlich ist, um diesen zu entfernen. Ich weiß nicht, ob es eine Möglichkeit gibt, Elastic Email mit einem Webhook zu nutzen, um Discourse über Abmeldungen zu benachrichtigen, aber sie sind nicht in Configure VERP to handle bouncing e-mails aufgeführt.
Ich denke, wenn du AWS zum Laufen bringen kannst, ist das wahrscheinlich die beste Lösung, aber das ist keine gute Lösung für Leute, die hierherkommen, um zu lernen, wie man E-Mails einrichtet.
Mailgun ist wirklich einfach.
Danke.
Für mich ist das eher irrelevant, und ich erkläre Ihnen warum: SparkPost hat genau das Gleiche gemacht – wobei ich zugeben muss, dass ich nie überprüft habe, ob es Hooks gab, die ich hätte nutzen können (dummerweise, denn die gab es, und es ist 2019 FGS).
In diesem Fall bin ich nur darauf aufmerksam geworden, weil die betroffene Website meine lokale Gemeinde versorgt und ich zufällig auf den Mann gestoßen bin, der versehentlich auf den Abmeldelink in der von SparkPost zugestellten E-Mail geklickt hatte und sich beschwerte, keine E-Mails zum Zurücksetzen des Passworts mehr zu erhalten. SparkPost verfügt jedoch über eine Prüfpfad-Funktion dafür und die Möglichkeit für Administratoren, jemanden erneut zu abonnieren (offensichtlich sollte man dies sparsam einsetzen!). Sobald ich also von dem Problem erfahren hatte, war eine einfache Lösung möglich. Beim nächsten Mal werde ich meine E-Mail-Konfiguration besser einstellen.
Sie bewegen mich jedoch nun eher zu Mailgun, danke!
Ich wünschte wirklich, es gäbe eine allgemeinere Möglichkeit für Discourse, Webhook-E-Mail-Rückläufer zu verarbeiten. Unser bevorzugter Anbieter (Postmark) steht ebenfalls nicht auf der Liste, was bedeutet, dass wir weiterhin E-Mails an Personen senden, deren Adresse zurückgewiesen wurde.
Eine Art magischer, generischer JSON-Webhook-Parser für Webhooks zu zurückgewiesenen E-Mails wäre fantastisch!
Du meinst wohl, dass ein „magischer Standard für JSON-Webhooks
Ja, ich dachte gerade, dass es, wenn man annimmt, dass über 90 % der eingehenden Bounce-Daten im JSON-Format oder einem anderen per Regex verarbeitbaren Format vorliegen, möglich sein könnte, über eine Einstellung anzugeben, welches JSON-Feld die zurückgewiesene E-Mail-Adresse darstellt und möglicherweise auch ein weiteres Feld für den Bounce-Typ (hard, soft usw.).
Man könnte es als „generischen Regex-Parser für eingehende Bounce-E-Mail-Webhooks
In einem anderen Thread kannst du den zusätzlichen ElasticMail-Abmelde-Link ebenfalls entfernen, indem du angibst, wo sich der von Discourse befindet: Indem du ihn speziell als {unsubscribe:{https://.....}} annotierst (ich empfehle, dies vor dem Einreichen eines Pull Requests mit dem Support abzustimmen).
Das ließe sich wahrscheinlich durch Bearbeiten der Übersetzungen erreichen?
Ich habe auch Sparkpost für meine Discourse-Instanzen genutzt und kürzlich diese Benachrichtigung von Sparkpost erhalten.
Also habe ich nach einer Alternative gesucht.
Ich habe SendGrid eingerichtet, und das scheint bisher gut zu funktionieren. Ich nutze den Basic-Plan für 15 $ pro Monat.