Contraintes sur l'"adresse e-mail entrante personnalisée" (pour les sites hébergés seulement, peut-être ?)

Bonjour Communauté Discourse —

Ce qui suit est une observation que j’ai faite par essais et erreurs, mais pour laquelle je n’ai trouvé aucune documentation ni rencontré d’avertissement ou d’erreur.

Sur notre site, qui est hébergé par Discourse (ce dont nous sommes très reconnaissants !), la configuration d’une adresse e-mail entrante personnalisée pour une catégorie ne semble fonctionner que si l’adresse e-mail est précédée de “foo+” (où ‘foo’ est le slug général de notre site).

Plus précisément, je configure souvent une nouvelle catégorie, j’y associe ce que je considère être une adresse e-mail intuitive, j’envoie un e-mail de test à cette adresse, et je ne reçois jamais de message de non-remise ni ne le vois apparaître dans les journaux d’e-mails reçus ou rejetés de notre site. Puis je me souviens finalement de mes expériences précédentes, je définis l’adresse sur foo+<some name>, j’effectue un autre test et cela fonctionne immédiatement.

Si je ne me trompe pas, cela semble compréhensible comme un moyen pour Discourse de distinguer les e-mails destinés à un site hébergé d’un autre, mais je voulais vérifier si j’avais raison. Ou, si ce n’est pas le cas, voir s’il existe d’autres explications pour lesquelles mes choix initiaux d’adresse e-mail semblent aller à /dev/null.

Merci !
-Brad

1 « J'aime »

Il peut sembler simple/réducteur de le dire à voix haute, mais l’adresse e-mail personnalisée ne fonctionne que si elle est effectivement livrée au site.

Vous ne pouvez donc pas y mettre n’importe quoi, l’adresse doit être livrée au site pour avoir une chance de fonctionner.

Il n’y a aucun moyen pour Discourse de vérifier cette adresse pour s’assurer que cela se produit, la responsabilité incombe donc à l’administrateur de s’en assurer.

Sur notre hébergement, je recommande d’utiliser quelques adresses que nous avons pré-arrangées pour être livrées sur votre site :

  • {ANYTHING}@{YOUR PREFIX}.discoursemail.com
  • {ANYTHING}@{your.site.hostname}
2 « J'aime »

Merci @supermathie

Pour notre site (hébergé), je n’avais pas réalisé que …@{OUR PREFIX}.discoursemail.com était une option et n’ai toujours essayé d’utiliser que …@discoursemail.com comme nom d’hôte parce que c’est ce que l’adresse par défaut “accepter les emails entrants” utilise (et j’ai mis à jour ma requête originale ci-dessus pour essayer de clarifier cela puisque j’avais omis le nom d’hôte dans la question originale). Je vais essayer cela, merci pour le conseil !

Bien que je comprenne que Discourse ne puisse pas vérifier les adresses email pour les instances auto-hébergées de Discourse, serait-il possible que les instances hébergées génèrent un avertissement ou une erreur si l’adresse email n’était pas d’un format attendu ? (ou un format attendu lors de l’utilisation d’une adresse …discoursemail.com ?)

Merci encore,
-Brad

1 « J'aime »

Il n’y a pas de limite au « format attendu » autre que « adresse e-mail valide », donc ce n’est pas réalisable.

Ce pourrait être quelque chose que nous pourrions faire.

3 « J'aime »

Merci encore pour votre réponse !

Je pense que vous avez confirmé mon soupçon que ce problème est spécifique aux sites Discourse hébergés comme le nôtre. Je ne sais pas quel niveau d’effort serait requis pour que de tels sites vérifient que les adresses …discoursemail.com saisies dans ce champ sont valides, mais une telle fonctionnalité m’aurait fait gagner beaucoup de temps et de frustration au cours des dernières années de mise en place de nouvelles listes de diffusion et d’alias, en me demandant pourquoi ils ne fonctionnaient pas. J’imagine que cela aiderait aussi d’autres personnes.

Alternativement, même une petite info-bulle sur ce champ pour un site hébergé indiquant qu’une adresse légale doit être slug+...@discoursemail.com ou ...@slug.discoursemail.com serait d’une grande aide. Bien que je ne sache pas si le fait de rendre cette astuce spécifique aux sites Discourse hébergés rend cette approche irréalisable.

-Brad

Ce n’est pas vrai — la contrainte est que l’e-mail doit être livré (pas adressé) à l’une de ces adresses pour fonctionner. Un exemple est la configuration suivante que nous et bon nombre de nos clients utilisons :

  • (dans Discourse) configurer la catégorie Postings pour accepter les e-mails entrants envoyés à postings@contoso.com
  • (sur le serveur de messagerie contoso.com) configurer postings@contoso.com pour transférer vers {ANYTHING}@contoso.discoursemail.com
  • résultat final : les e-mails adressés à postings@contoso.com sont envoyés à la catégorie Postings

Cela fonctionne de manière effective comme :

  • (dans Discourse) configurer la catégorie Postings pour accepter les e-mails entrants envoyés à postings@contoso.discoursemail.com
  • résultat final : les e-mails adressés à postings@contoso.discoursemail.com sont envoyés à la catégorie Postings
1 « J'aime »

@supermathie — Excellente remarque sur le fait que l’adresse de livraison est plus pertinente que celle à laquelle le courrier est adressé.

Pour affiner ma demande précédente, je pense qu’un avertissement lors de la tentative de saisie d’adresses e-mail entrantes qui correspondent aux modèles @discoursemail.com ou @*.discoursemail.com, mais qui ne commencent pas par slug+… ou ne se terminent pas par @slug.discoursemail.com, serait toujours utile pour avertir les communautés hébergées par Discourse.

Cela permettrait toujours votre premier cas (puisqu’il n’a pas discoursemail.com comme suffixe) tout en m’avertissant de la tentative de configuration d’une adresse slug-users@discouresmail.com, qui est le type de modèle auquel je me suis toujours tourné et que j’ai ensuite trouvé déroutant lorsque les e-mails qui lui étaient destinés étaient silencieusement ignorés.

(Notez que votre deuxième cas ne générerait pas non plus d’avertissement, en supposant que contoso soit le slug de votre communauté).

  • Brad

Ce sujet a été automatiquement fermé après 2 jours. Les nouvelles réponses ne sont plus autorisées.