Das Folgende ist etwas, das ich durch Ausprobieren beobachtet habe, wofür ich aber weder Dokumentation noch eine Warnung oder Fehlermeldung gefunden habe.
Auf unserer von Discourse gehosteten Seite (wofür wir sehr dankbar sind!) scheint das Einrichten einer benutzerdefinierten eingehenden E-Mail-Adresse für eine Kategorie nur zu funktionieren, wenn die E-Mail-Adresse mit „foo+“ beginnt (wobei „foo“ der allgemeine Slug unserer Seite ist).
Genauer gesagt, richte ich oft eine neue Kategorie ein, lege eine meiner Meinung nach intuitive E-Mail-Adresse dafür fest, sende eine Test-E-Mail an diese Adresse und erhalte nie eine Unzustellbarkeitsnachricht (Bounce) noch sehe ich sie in den Empfangs- oder Ablehnungsprotokollen unserer Seite erscheinen. Dann erinnere ich mich schließlich an meine früheren Erfahrungen, setze die Adresse auf foo+\u003csome name\u003e, führe einen weiteren Test durch und es funktioniert sofort.
Wenn ich es mir nicht einbilde, scheint dies als Mittel für Discourse verständlich zu sein, um E-Mails, die für eine gehostete Seite bestimmt sind, von denen für eine andere zu unterscheiden, aber ich wollte überprüfen, ob ich richtig liege. Oder, falls nicht, sehen, ob es andere Erklärungen dafür gibt, warum meine anfänglichen E-Mail-Adressen an /dev/null zu gehen scheinen.
[quote=„BradCray, Beitrag:1, Thema:371380″]
Das Festlegen einer benutzerdefinierten eingehenden E-Mail-Adresse für eine Kategorie scheint nur zu funktionieren, wenn die E-Mail-Adresse mit „foo+“ (wobei ‚foo‘ der allgemeine Slug für unsere Website ist) vorangestellt ist.
[/quote]
Es mag einfach/reduktiv erscheinen, es laut auszusprechen, aber die benutzerdefinierte E-Mail-Adresse funktioniert nur, wenn sie tatsächlich an die Website geliefert wird.
Sie können also nicht einfach irgendetwas dort einfügen, die Adresse muss an die Website geliefert werden, damit sie eine Chance hat zu funktionieren.
Es gibt keine Möglichkeit für Discourse, diese Adresse zu überprüfen, um sicherzustellen, dass dies geschieht. Daher liegt es in der Verantwortung des Administrators, sicherzustellen, dass dies geschieht.
Auf unserem Hosting empfehle ich die Nutzung einiger Adressen, die wir vorab arrangiert haben, um sie an Ihre Website zu liefern:
Für unsere (gehostete) Seite war mir nicht klar, dass …@{OUR PREFIX}.discoursemail.com eine Option ist, und ich habe immer nur versucht, …@discoursemail.com als Hostnamen zu verwenden, weil das die Standardadresse für „eingehende E-Mails akzeptieren“ ist (und ich habe meine ursprüngliche Anfrage oben aktualisiert, um dies zu verdeutlichen, da ich den Hostnamen in der ursprünglichen Frage weggelassen hatte). Das werde ich ausprobieren, danke für den Tipp!
Obwohl ich verstehe, dass Discourse E-Mail-Adressen für selbst gehostete Discourse-Instanzen nicht verifizieren kann, wäre es möglich, dass die gehosteten Instanzen eine Warnung oder einen Fehler generieren, wenn die E-Mail-Adresse nicht dem erwarteten Format entspricht? (oder einem erwarteten Format bei Verwendung einer …discoursemail.com-Adresse?
Ich denke, Sie haben meinen Verdacht bestätigt, dass dies ein Problem ist, das spezifisch für gehostete Discourse-Sites wie unsere ist. Ich weiß nicht, welcher Aufwand erforderlich wäre, um solche Sites zu verifizieren, dass die in diesem Feld eingegebenen …discoursemail.com-Adressen gültig sind, aber eine solche Funktion hätte mir in den letzten Jahren, in denen ich neue Mailinglisten und Aliase eingerichtet habe und mich fragte, warum sie nicht funktionieren, eine ganze Menge Zeit und Frustration erspart. Ich stelle mir vor, dass es auch anderen helfen würde.
Alternativ würde schon ein kleiner Tooltip in diesem Feld für eine gehostete Site, der darauf hinweist, dass eine gültige Adresse slug+...@discoursemail.com oder ...@slug.discoursemail.com sein muss, viel bewirken. Ich weiß jedoch nicht, ob es diesen Ansatz unbrauchbar macht, wenn dieser Tipp spezifisch für gehostete Discourse-Sites ist.
Das stimmt nicht – die Einschränkung besteht darin, dass die E-Mail an eine dieser Adressen zugestellt werden muss (nicht adressiert sein), damit sie funktioniert. Ein Beispiel ist die folgende Einrichtung, die wir und viele unserer Kunden verwenden:
(in Discourse) Kategorie „Postings“ so konfigurieren, dass eingehende E-Mails an postings@contoso.com akzeptiert werden
(auf dem Mailserver von contoso.com) postings@contoso.com so konfigurieren, dass an {ANYTHING}@contoso.discoursemail.com weitergeleitet wird
Endergebnis: E-Mails, die an postings@contoso.com adressiert sind, werden an die Kategorie „Postings“ gesendet
Dies funktioniert effektiv genauso wie:
(in Discourse) Kategorie „Postings“ so konfigurieren, dass eingehende E-Mails an postings@contoso.discoursemail.com akzeptiert werden
Endergebnis: E-Mails, die an postings@contoso.discoursemail.com adressiert sind, werden an die Kategorie „Postings“ gesendet
@supermathie — Guter Punkt, dass die Lieferadresse relevanter ist als die, an die die E-Mail adressiert ist.
Wenn ich meine vorherige Anfrage verfeinere, denke ich, dass eine Warnung beim Versuch, eingehende E-Mail-Adressen einzugeben, die den Mustern @discoursemail.com oder @*.discoursemail.com entsprechen, aber nicht mit slug+… beginnen oder mit @slug.discoursemail.com enden, immer noch wertvoll wäre, um vor ihnen zu warnen, wenn Communities von Discourse gehostet werden.
Dies würde immer noch Ihren ersten Fall zulassen (da er nicht discoursemail.com als Suffix hat), während er mich immer noch davor warnt, eine Adresse wie slug-users@discouresmail.com einzurichten, was die Art von Muster ist, nach der ich immer gegriffen habe und dann verwirrt war, als E-Mails dorthin stillschweigend fallen gelassen wurden.
(Beachten Sie, dass Ihr zweiter Fall ebenfalls keine Warnung generieren würde, vorausgesetzt, contoso ist der Slug Ihrer Community).