Die Dokumentation zu SSO macht deutlich, dass die E-Mail-Validierung vorab auf Seiten des SSO-Anbieters erfolgen sollte und dass ein anderes Vorgehen nicht ratsam ist. Das ergibt Sinn.
Allerdings kann sich dieser Validierungsstatus im Nachhinein ändern. Beispielsweise könnte der SSO-Anbieter zu viele Hard-Bounces der E-Mails, die er an diesen Benutzer sendet, FBLs usw. festgestellt haben. Was ist in einem SSO-Kontext der beste Weg, damit Discourse ebenfalls (nur vorübergehend) aufhört, E-Mails an die E-Mail-Adresse eines einzelnen Benutzers zu senden?
Ich habe Vorschläge gesehen, E-Mails für ein Konto zu stoppen, indem alle E-Mail-bezogenen Einstellungen des Kontos so gesetzt werden, dass keine E-Mails gesendet werden. Das wäre jedoch dauerhaft oder zumindest schwer rückgängig zu machen. Ich suche nach einer vorübergehenden Lösung, bis der SSO-Anbieter die Adresse erneut validiert.
Da Discourse Möglichkeiten hat, das Senden von E-Mails zu stoppen, wenn die Anzahl der E-Mail-Bounces einen bestimmten Schwellenwert überschreitet, wäre es möglich, mit diesen Daten zu spielen, um E-Mails zu unterbrechen? Ich habe die API geprüft, aber nichts gefunden, um dies zu ändern, aber ich habe es vielleicht übersehen.
Kurz gesagt: Wie kann man verhindern, dass ein bestimmtes SSO-Konto E-Mails sendet?
Entschuldigung, falls dies bereits irgendwo beantwortet wurde, aber ich konnte nichts finden.
Wir haben keine direkte API zum Festlegen der Absprungrate (Bounce Score). Ich vermute, das ist das, was Sie hier tun möchten. Ich stehe einer PR offen gegenüber, die die Unterstützung hinzufügt, damit Administratoren die Absprungrate eines Benutzers manuell auf einen beliebigen Wert setzen können.
Es kann neben E-Mail-Rückschlägen weitere Gründe geben, E-Mails für ein bestimmtes Konto zu stoppen: E-Mail-Feedback-Schleifen, rechtliche Anfragen im Rahmen der DSGVO, private Daten nicht (vorübergehend) zu verwenden; es können weitere rechtliche oder geschäftliche Gründe für den SSO-Anbieter bestehen, dies zu benötigen.
Ich habe erwähnt, dass man mit der Rückschlag-Bewertung experimentieren könnte, da dies ein Weg sein könnte, dies zu erreichen, obwohl es vielleicht eine Art Workaround ist. Wenn nichts anderes zur Verfügung steht, würde ich das nutzen.
Aber wenn dies noch nicht verfügbar ist, wäre es dann sinnvoll, stattdessen ein Benutzerfeld in Betracht zu ziehen, mit dem alle E-Mails für ein Konto global aktiviert oder deaktiviert werden können? Dieses Feld könnte nicht nur über die API, sondern vielleicht auch durch Mitarbeiter gesteuert werden. Ich weiß nicht, ob dies eine zu große Änderung bedeuten würde oder ob es einen zentralen Ort im Code gibt, an dem dies geprüft werden kann. Ich denke jedoch, dass dies ein generischerer Ansatz wäre, der in mehr Anwendungsfällen genutzt werden könnte als der Weg über die Rückschlag-Bewertung, um E-Mails für ein Konto zu stoppen.