Nous avons un flux de travail où nous utilisons Discourse comme archive d’e-mails. Nous avons une adresse e-mail de groupe, et nos agents mettent cette adresse en copie lorsqu’ils commencent un fil de discussion avec un client.
Cela fonctionne très bien jusqu’à ce qu’un client réponde spécifiquement à l’agent, en ignorant toutes les en-têtes Cc et même Reply-To. L’agent devrait alors renvoyer l’e-mail (reenvoyer) à l’adresse e-mail du groupe. Le renvoi est la méthode préférée ici, afin que Discourse archive l’e-mail original, y compris toutes les en-têtes originales, les horodatages, etc.
Le renvoi d’un e-mail se fait en copiant le message exact, et en ajoutant les en-têtes Resent-From et Resent-To. Celles-ci sont malheureusement ignorées par Email::Receiver. Il devrait simplement ajouter tous les Resent-* aux champs réguliers respectifs.
J’ai commencé à implémenter cela, et je suis arrivé à faire en sorte que create_incoming_email prenne en compte les champs. J’ai ensuite pu voir les e-mails, y compris les destinataires tirés de Resent-To, dans la liste des e-mails entrants dans Discourse.
Cependant, ce que je ne parviens pas à faire, c’est que get_all_recipients respecte également les champs Resent-*. J’ai ajouté resent-to resent-cc resent-bcc au tableau %i() des champs de courrier, mais cela ne semble toujours pas renvoyer les destinataires de ces champs.
Toute aide est la bienvenue, afin que je puisse faire une PR pour ce changement !
Cela semble être une fonctionnalité assez dangereuse et sujette à l’usurpation d’identité. Comment proposez-vous d’authentifier le réexpéditeur ?
Avec l’en-tête Resent-From. Mais cela n’a en fait aucune importance ; la partie intéressante est de savoir si l’expéditeur d’origine peut être authentifié, pas le réexpéditeur.
De plus, Discourse a déjà un traitement existant pour les e-mails transférés.
Uniquement pour les transferts cités. Cela présente plusieurs problèmes :
Il n’archive pas le mail d’origine, seulement une copie citée de son corps
Il n’y a pas de support pour les messages transférés en pièce jointe (avec les en-têtes complets)
C’est incomplet (il repose sur un préfixe spécial dans l’objet pour reconnaître un e-mail transféré)
Et comment cela se passe-t-il exactement ? Et si le renvoyeur mentait simplement et fabriquait complètement un e-mail qui était censé lui être envoyé uniquement ?
Et comment cela se passe-t-il exactement ? Et si le réexpéditeur mentait et fabriquait complètement un e-mail qui aurait été envoyé uniquement à lui ?
Il pourrait tout aussi bien omettre tout le contenu Resent- et falsifier l’e-mail dès le départ, sans prétendre qu’il lui a été envoyé en premier.
Je pense que vous avez une mauvaise conception de ce que font les en-têtes Resent- - qui en fait ne font absolument rien. Ils ne sont pas non plus pris en compte lorsque les serveurs de messagerie vérifient SPF ou DKIM, donc falsifier un e-mail réexpédié est aussi difficile que falsifier l’e-mail d’origine.
Dans mon cas, un e-mail réexpédié par un étranger serait bloqué par le filtre anti-spam pour violation de SPF. La raison pour laquelle mon scénario avec des agents réexpédiant des e-mails à Discourse fonctionne est qu’ils sont exemptés de ces vérifications après s’être authentifiés auprès de notre serveur de messagerie.
Permettre à Discourse d’utiliser l’en-tête Resent-To n’est donc rien de plus qu’une fonctionnalité de commodité, car c’est ainsi que les clients de messagerie ordinaires créent une copie falsifiée d’un e-mail qu’ils ont reçu précédemment. Cela ne change rien à l’authentification.