Sympa ton article sur “les dessous du mail”, la démarche est tout à fait louable et les explications assez claires, mais je voulais te signaler quelques oublis ou erreurs. Ne prends pas mal la chose, c'est strictement dans un but d'amélioration.
1) dans les paragraphes 1 et 2, tu évoques ce que le mail peut transporter (texte, html, pièces jointes, etc.) mais tu ne parles pas du tout du format MIME. C'est peut-être dans un but de simplification (ou ça fera l'objet d'un autre article ?), mais en tout cas ça va de pair avec l'encodage base64 que tu évoques pour les pièces jointes…
2) dans le paragraphe 5 et le paragraphe 9.2, tu évoques DKIM et tu dis qu'il permet d'authentifier le serveur et le domaine d'émission d'un message, mais ce n'est pas la seule fonction: DKIM permet aussi d'assurer l'intégrité d'un message et permet de vérifier qu'il n'a pas été altéré entre le serveur d'émission (là où il est signé) et le serveur du destinataire et/ou son outil de messagerie (où il est vérifié). L'intégrité du message est calculée sur la base du corps du message ainsi que de certains en-têtes (qui peuvent par exemple être le Subject, le Message-id, et aussi le From, tout ça se configure). Bon, on est d'accord, contrairement à GPG, la signature n'est pas réalisée dès le départ mais uniquement sur le serveur d'expédition, cela dit ça protège quand-même le mail en intégrité sur la portion la plus “à risque” du trajet (le grand méchant Internet ;-) )…
3) Dans le paragraphe 7.1, tu parles du greylisting et d'un temps d'attente de 5 minutes. D'expérience, je peux te dire que peu de serveurs utilisant cette technique te permettent de retenter un envoi au bout de 5 minutes. En règle générale on cale le délai à 25 minutes, car la majorité des serveurs de mail sont configurés pour traiter la queue de mails non envoyés toutes les ½ heures. Du coup, un serveur “légitime” qui retentera au bout de 30 minutes pourra envoyer son mail, en revanche un spammeur un peu trop pressé qui va insister comme un gros relou toutes les 5 minutes va se faire tèj. J'ajoute que le greylisting est de moins en moins employé car certains FAI le pénalisent, notamment en allongeant énormément les délais de délivrance: en effet, si je mets du greylisting chez moi, que je suis un gros site qui reçoit un volume de mail important, et que des FAI essaient de m'en envoyer, la 1ère fois ils vont de faire jeter de toute façon, donc en quelque sorte, je reporte chez eux une certaine charge (les mails qui restent en queue chez eux). Du coup, Orange, par exemple, ne retentait la délivrance qu'au bout de 24 heures à une époque (je ne sais pas ce qu'il en est maintenant). Chez Free, c'était pire: on avait parfois droit à un code 5xx, qui signale une erreur permanente et provoque le renvoi du mail à l'expéditeur ! Ca peut paraître débile d'augmenter la durée de rétention du message, puisque ça augmente encore le nombre de messages à retenir dans le spool, mais à mon avis c'est clairement une stratégie à plus long terme, pour décourager l'utilisation du greylisting, justement. Et toujours d'expérience, même si je suis d'accord avec toi quand tu dis que le mail ne garantit pas la délivrance en un temps défini, dans les faits, tes utilisateurs râlent très vite quand ça traîne, donc le greylisting, moi, j'ai abandonné (comme plein d'autres).
4) dans le paragraphe 7.2, qui parle des vérifications effectuées par le serveur mail de réception, tu dis que les serveurs DNSBL vérifient ton nom de domaine et l'IP du serveur de réception. Je pense qu'il s'agit d'une erreur, puisque c'est justement le serveur de réception qui interroge les DNSBL, inutile donc de faire une requête sur sa propre IP ! :-) En revanche, ce qui est vérifié, c'est l'adresse IP du serveur d'émission (et pas son nom de domaine car le mécanisme de DNSBL est mis en oeuvre avant la transmission de cette info). On fait donc une requête DNS vers un serveur DNSBL, concernant l'IP du serveur d'émission et on réagit en fonction de la réponse. Ce sont les seules infos échangées… Il n'y a aucune fuite d'info puisque de toute façon, l'IP du serveur d'émission est connue du serveur de réception puisqu'il s'y connecte… ;-)
5) tu places la vérif SPF en paragraphe 9, après le 8 (logique jusque là ;-) ) qui parle de la fin d'émission du courrier. Or, SPF est mis en oeuvre juste au début du dialogue SMTP, après la vérif DNSBL, et surtout, avant l'envoi du corps du message, donc tu aurais peut-être dû en parler juste après le paragraphe sur les DNSBL, justement. Toujours à propos de SPF, tu parles d'une potentielle fuite d'infos là aussi, en disant: “Le serveur DNS peut donc deviner que votre domaine à envoyer un mail à tel autre domaine”. Ta conclusion est erronée: il n'y a pas de fuite d'info là non plus, si ce n'est la liste des serveurs autorisés à émettre un mail pour le domaine considéré. Si je prends par exemple ton domaine:
$ dig lord.re txt +short
“v=spf1 a ip4:62.210.201.160/32 a ip4:195.154.97.5 -all”
Je vois que seules les machines 62.210.201.160 (le /32 est inutile, d'ailleurs) et 195.154.97.5 sont autorisées à véhiculer des mails en @lord.re, mais je ne peux pas pour autant savoir à qui tu as envoyé des mails depuis ce domaine ! ;-)
6) dans le paragraphe 9.3, tu inclus sous la dénomination “antispam bayésien” tout un tas de techniques (vérification de la date, de certains autres en-têtes, etc.). Or, le filtrage bayésien concerne exclusivement le calcul de la note de “spamitude” d'un message, basée sur la probabilité d'occurrence des mots du message testé, dans un message de type spam ou de type ham. Je ne suis pas en train de dire que les autres techniques ne sont pas utilisées, mais elles n'entrent pas dans la catégorie “bayésienne”.
Concernant la sous-traitance de cette fonctionnalité d'antispam: c'est de plus en plus le cas… Quelques sociétés se sont positionnées sur le créneau, mais en règle générale, cela ne concerne que l'antispam en entrée, donc de toute façon, comme il s'agit déjà de mails provenant de l'extérieur, on ne peut pas considérer qu'ils soient réellement confidentiels (ou alors si c'est le cas, il faut les chiffrer !).
7) dans le paragraphe 12, où tu récapitules le trajet d'un mail entre 2 MUA, tu en “remets une couche” concernant des supposées fuites de données via le DNS, mais honnêtement, encore une fois, je ne vois pas vraiment ce qui peut fuiter à ce niveau… Je suis prêt à en discuter, bien entendu, comme d'ailleurs de tout le reste de mes affirmations.
Voilà. Encore une fois, je parais très critique, mais c'est du perfectionnisme, en fait. La base de ton article est bonne il faut juste préciser ou corriger certains trucs, et surtout, il y a trop peu de gens qui prennent la peine de tenter de transmettre leurs connaissances… ;-)
Bonne soirée, je reste à ta disposition pour discuter de toutes mes remarques au besoin.
Tout d'abord merci d'avoir lu avec autant d'attention et merci de me remonter autant de commentaires !
1) J'ai pas parlé de MIME pour simplifier l'article qui était déjà trop long. Je l'ai supprimmé du premier brouillon à vrai dire.
2) C'est complètement vrai, je pense éditer l'article pour évoquer l'intégrité qu'apporte dkim. Excellente idée.
3) J'ai l'impression que le greylisting était en perte de vitesse mais qu'il est revenu à la mode ces derniers temps et même des mails depuis orange arrivent relavitement vite sur mes installs. (pas testé depuis free).
J'ai insisté sur la non-garantie de vitesse des mails pour justement que les gens arrêtent de penser que l'instantannéité est normale (j'ai le droit de rêver).
4) Effectivement c'est l'adresse IP du serveur d'émission (et non de réception qui est transmise. Et tu as également raison sur le fait que le domaine n'est pas envoyé, je vais rectifier ça également.
Par contre si, j'estime qu'il y a une fuite d'info possible : un hébergeur de DNSBL va voir une requête en provenance de a.b.c.d pour savoir si b.c.d.e est autorisé à envoyer du mail, donc potentiellement le DNSBL sait que ces deux machines (tentent) de s'échanger des mails.
Celui qui contrôle le DNS peut voir des infos (floues certes).
La fuite n'est pas auprès du serveur de réception qui comme tu le dis est au courant légitimement.
5) Pour l'ordre de placement de SPF je suis pas spécialement d'accord mais en vrai ça va dépendre de l'implémentation du serveur de réception.
SPF pourrait être vérifié dès réception du MAIL FROM au niveau SMTP mais ce n'est pas le cas pour postfix en tout cas.
Et encore une fois la fuite de données est bien présente, le serveur DNS sera au courant que la personne émettant la requête DNS reçoit un mail depuis tel domaine.
Ça peut permettre au serveur DNS de savoir que lord.re a envoyé un mail à a.b.c.d.
Donc encore une fois si a.b.c.d n'est pas un gros fournisseur de mail à la gmail/hotmail mais un ptit serveur d'une ptite entreprise, une asso, un mail auto-hébergé… bref il y a un potentiel assez élevé de faire un lien.
6) Ouai là j'ai complètement merdé. J'ai zappé le filtre bayesien et j'ai parlé que des analyses antispam classiques, je vais rajouter un paragraphe et réorganiser un peu ce point.
Alors tout d'abord, merci d'avoir pris certaines de mes remarques en compte !
Pour les fuites de données, ok, je n'avais pas compris que tu te plaçais au niveau du serveur DNSBL ou du serveur DNS sur lequel se trouve l'enregistrement SPF, et là en effet tu as raison, ce serveur peut savoir qui cause avec qui. Dans le 2e cas, on peut limiter la casse en s'auto-hébergeant aussi pour la partie DNS (c'est le cas de pas mal de boîtes), mais pour le listing DNSBL, là, c'est mort en effet.
Pour le greylisting: il y a peut-être eu du mieux récemment, mais pour moi, c'est définitivement un truc dans lequel je n'ai plus confiance, vu les entourloupes que les serveurs m'ont faites par le passé… :-)
Et pour le SPF, ce type de filtrage n'a vraiment de sens que si tu le fais dès le départ, avant que le mail soit envoyé: tu as toutes les infos à ce moment-là, inutile d'attendre plus longtemps pour prendre une décision… Et je peux t'assurer que même sur postfix, ça le fait, en tout cas avec “postfix-policyd-spf-python”, qui est le filtre SPF que j'utilise. Tu te fais virer dès le “RCPT TO:” (oui, il attend de savoir à qui le mail est destiné pour savoir s'il y a des règles particulières genre exceptions pour certains destinataires qui seraient moins regardants), mais c'est clair qu'avec ce filtre, tu n'atteins pas le “DATA”…
Qu'est-ce que tu utilises, de ton côté ? Je trouve extrêmement bizarre qu'une implémentation d'un filtre SPF attende d'avoir reçu tout le message avant de décider quoi en faire, c'est un non-sens. :-)
Je n'utilise pas policyd, je suis sur : postfix/postscreen/rspamd/sisyphus.
Du coup la vérif SPF est faite pas rspamd en même temps que le dkim, bayesien et compagnie. Mais effectivement au niveau de policyd ça permet de virer au plus tôt.
Globalement celui qui a la main sur les résolveur du serveur de réception aura possibilité de récupérer pas mal d'infos concernant les mails tout en étant “transparent”.
Ok pour rspamd et sisyphus… Mais c'est zarbi comme implémentation. La logique voudrait que les tests (et les refus éventuels qui en résultent) soient faits dès que possible, et de préférence avant la phase DATA, ce qui permet d'une part d'économiser des ressources, et d'autre part de refuser le mail d'emblée, au lieu de l'accepter d'abord puis d'envoyer une DSN ensuite, surtout que dans le cas des virus ou de spams, l'expéditeur est systématiquement faux, donc une DSN a toutes les chances d'aboutir chez quelqu'un qui n'a rien demandé…
Les contrôles protocolaires (par exemple sur HELO/EHLO, MAIL FROM:, RCPT TO:, etc.), ainsi que DNSBL et SPF peuvent avoir lieu avant la phase DATA, pourquoi s'en priver ? :-)
Après, que quelqu'un ait la main sur le résolveur du serveur de réception, ça m'inquiète moins. Normalement, ce sont les mêmes que ceux qui gèrent le serveur lui-même… :-)
Postscreen écrème déjà la très grande majorité du spam avec ses différents tests et son greylisting avant même tout traitement donc j'ai toujours trouvé policyd un poil overkill à moins d'avoir une installation vraiment très conséquente avec une grosse quantité de mail.
C'est clairement intéressant de faire ce genre de test avant de passer au bayesien et lda dès lors que la volumétrie est importante.
Bonsoir !
Sympa ton article sur “les dessous du mail”, la démarche est tout à fait louable et les explications assez claires, mais je voulais te signaler quelques oublis ou erreurs. Ne prends pas mal la chose, c'est strictement dans un but d'amélioration.
1) dans les paragraphes 1 et 2, tu évoques ce que le mail peut transporter (texte, html, pièces jointes, etc.) mais tu ne parles pas du tout du format MIME. C'est peut-être dans un but de simplification (ou ça fera l'objet d'un autre article ?), mais en tout cas ça va de pair avec l'encodage base64 que tu évoques pour les pièces jointes…
2) dans le paragraphe 5 et le paragraphe 9.2, tu évoques DKIM et tu dis qu'il permet d'authentifier le serveur et le domaine d'émission d'un message, mais ce n'est pas la seule fonction: DKIM permet aussi d'assurer l'intégrité d'un message et permet de vérifier qu'il n'a pas été altéré entre le serveur d'émission (là où il est signé) et le serveur du destinataire et/ou son outil de messagerie (où il est vérifié). L'intégrité du message est calculée sur la base du corps du message ainsi que de certains en-têtes (qui peuvent par exemple être le Subject, le Message-id, et aussi le From, tout ça se configure). Bon, on est d'accord, contrairement à GPG, la signature n'est pas réalisée dès le départ mais uniquement sur le serveur d'expédition, cela dit ça protège quand-même le mail en intégrité sur la portion la plus “à risque” du trajet (le grand méchant Internet ;-) )…
3) Dans le paragraphe 7.1, tu parles du greylisting et d'un temps d'attente de 5 minutes. D'expérience, je peux te dire que peu de serveurs utilisant cette technique te permettent de retenter un envoi au bout de 5 minutes. En règle générale on cale le délai à 25 minutes, car la majorité des serveurs de mail sont configurés pour traiter la queue de mails non envoyés toutes les ½ heures. Du coup, un serveur “légitime” qui retentera au bout de 30 minutes pourra envoyer son mail, en revanche un spammeur un peu trop pressé qui va insister comme un gros relou toutes les 5 minutes va se faire tèj. J'ajoute que le greylisting est de moins en moins employé car certains FAI le pénalisent, notamment en allongeant énormément les délais de délivrance: en effet, si je mets du greylisting chez moi, que je suis un gros site qui reçoit un volume de mail important, et que des FAI essaient de m'en envoyer, la 1ère fois ils vont de faire jeter de toute façon, donc en quelque sorte, je reporte chez eux une certaine charge (les mails qui restent en queue chez eux). Du coup, Orange, par exemple, ne retentait la délivrance qu'au bout de 24 heures à une époque (je ne sais pas ce qu'il en est maintenant). Chez Free, c'était pire: on avait parfois droit à un code 5xx, qui signale une erreur permanente et provoque le renvoi du mail à l'expéditeur ! Ca peut paraître débile d'augmenter la durée de rétention du message, puisque ça augmente encore le nombre de messages à retenir dans le spool, mais à mon avis c'est clairement une stratégie à plus long terme, pour décourager l'utilisation du greylisting, justement. Et toujours d'expérience, même si je suis d'accord avec toi quand tu dis que le mail ne garantit pas la délivrance en un temps défini, dans les faits, tes utilisateurs râlent très vite quand ça traîne, donc le greylisting, moi, j'ai abandonné (comme plein d'autres).
4) dans le paragraphe 7.2, qui parle des vérifications effectuées par le serveur mail de réception, tu dis que les serveurs DNSBL vérifient ton nom de domaine et l'IP du serveur de réception. Je pense qu'il s'agit d'une erreur, puisque c'est justement le serveur de réception qui interroge les DNSBL, inutile donc de faire une requête sur sa propre IP ! :-) En revanche, ce qui est vérifié, c'est l'adresse IP du serveur d'émission (et pas son nom de domaine car le mécanisme de DNSBL est mis en oeuvre avant la transmission de cette info). On fait donc une requête DNS vers un serveur DNSBL, concernant l'IP du serveur d'émission et on réagit en fonction de la réponse. Ce sont les seules infos échangées… Il n'y a aucune fuite d'info puisque de toute façon, l'IP du serveur d'émission est connue du serveur de réception puisqu'il s'y connecte… ;-)
5) tu places la vérif SPF en paragraphe 9, après le 8 (logique jusque là ;-) ) qui parle de la fin d'émission du courrier. Or, SPF est mis en oeuvre juste au début du dialogue SMTP, après la vérif DNSBL, et surtout, avant l'envoi du corps du message, donc tu aurais peut-être dû en parler juste après le paragraphe sur les DNSBL, justement. Toujours à propos de SPF, tu parles d'une potentielle fuite d'infos là aussi, en disant: “Le serveur DNS peut donc deviner que votre domaine à envoyer un mail à tel autre domaine”. Ta conclusion est erronée: il n'y a pas de fuite d'info là non plus, si ce n'est la liste des serveurs autorisés à émettre un mail pour le domaine considéré. Si je prends par exemple ton domaine:
Je vois que seules les machines 62.210.201.160 (le /32 est inutile, d'ailleurs) et 195.154.97.5 sont autorisées à véhiculer des mails en @lord.re, mais je ne peux pas pour autant savoir à qui tu as envoyé des mails depuis ce domaine ! ;-)
6) dans le paragraphe 9.3, tu inclus sous la dénomination “antispam bayésien” tout un tas de techniques (vérification de la date, de certains autres en-têtes, etc.). Or, le filtrage bayésien concerne exclusivement le calcul de la note de “spamitude” d'un message, basée sur la probabilité d'occurrence des mots du message testé, dans un message de type spam ou de type ham. Je ne suis pas en train de dire que les autres techniques ne sont pas utilisées, mais elles n'entrent pas dans la catégorie “bayésienne”. Concernant la sous-traitance de cette fonctionnalité d'antispam: c'est de plus en plus le cas… Quelques sociétés se sont positionnées sur le créneau, mais en règle générale, cela ne concerne que l'antispam en entrée, donc de toute façon, comme il s'agit déjà de mails provenant de l'extérieur, on ne peut pas considérer qu'ils soient réellement confidentiels (ou alors si c'est le cas, il faut les chiffrer !).
7) dans le paragraphe 12, où tu récapitules le trajet d'un mail entre 2 MUA, tu en “remets une couche” concernant des supposées fuites de données via le DNS, mais honnêtement, encore une fois, je ne vois pas vraiment ce qui peut fuiter à ce niveau… Je suis prêt à en discuter, bien entendu, comme d'ailleurs de tout le reste de mes affirmations.
Voilà. Encore une fois, je parais très critique, mais c'est du perfectionnisme, en fait. La base de ton article est bonne il faut juste préciser ou corriger certains trucs, et surtout, il y a trop peu de gens qui prennent la peine de tenter de transmettre leurs connaissances… ;-)
Bonne soirée, je reste à ta disposition pour discuter de toutes mes remarques au besoin.
Wow que dire !?
Tout d'abord merci d'avoir lu avec autant d'attention et merci de me remonter autant de commentaires !
1) J'ai pas parlé de MIME pour simplifier l'article qui était déjà trop long. Je l'ai supprimmé du premier brouillon à vrai dire.
2) C'est complètement vrai, je pense éditer l'article pour évoquer l'intégrité qu'apporte dkim. Excellente idée.
3) J'ai l'impression que le greylisting était en perte de vitesse mais qu'il est revenu à la mode ces derniers temps et même des mails depuis orange arrivent relavitement vite sur mes installs. (pas testé depuis free). J'ai insisté sur la non-garantie de vitesse des mails pour justement que les gens arrêtent de penser que l'instantannéité est normale (j'ai le droit de rêver).
4) Effectivement c'est l'adresse IP du serveur d'émission (et non de réception qui est transmise. Et tu as également raison sur le fait que le domaine n'est pas envoyé, je vais rectifier ça également. Par contre si, j'estime qu'il y a une fuite d'info possible : un hébergeur de DNSBL va voir une requête en provenance de a.b.c.d pour savoir si b.c.d.e est autorisé à envoyer du mail, donc potentiellement le DNSBL sait que ces deux machines (tentent) de s'échanger des mails. Celui qui contrôle le DNS peut voir des infos (floues certes). La fuite n'est pas auprès du serveur de réception qui comme tu le dis est au courant légitimement.
5) Pour l'ordre de placement de SPF je suis pas spécialement d'accord mais en vrai ça va dépendre de l'implémentation du serveur de réception. SPF pourrait être vérifié dès réception du MAIL FROM au niveau SMTP mais ce n'est pas le cas pour postfix en tout cas. Et encore une fois la fuite de données est bien présente, le serveur DNS sera au courant que la personne émettant la requête DNS reçoit un mail depuis tel domaine. Ça peut permettre au serveur DNS de savoir que lord.re a envoyé un mail à a.b.c.d. Donc encore une fois si a.b.c.d n'est pas un gros fournisseur de mail à la gmail/hotmail mais un ptit serveur d'une ptite entreprise, une asso, un mail auto-hébergé… bref il y a un potentiel assez élevé de faire un lien.
6) Ouai là j'ai complètement merdé. J'ai zappé le filtre bayesien et j'ai parlé que des analyses antispam classiques, je vais rajouter un paragraphe et réorganiser un peu ce point.
Bon ma réponse est bien plus courte ;-)
Re :-)
Alors tout d'abord, merci d'avoir pris certaines de mes remarques en compte !
Pour les fuites de données, ok, je n'avais pas compris que tu te plaçais au niveau du serveur DNSBL ou du serveur DNS sur lequel se trouve l'enregistrement SPF, et là en effet tu as raison, ce serveur peut savoir qui cause avec qui. Dans le 2e cas, on peut limiter la casse en s'auto-hébergeant aussi pour la partie DNS (c'est le cas de pas mal de boîtes), mais pour le listing DNSBL, là, c'est mort en effet.
Pour le greylisting: il y a peut-être eu du mieux récemment, mais pour moi, c'est définitivement un truc dans lequel je n'ai plus confiance, vu les entourloupes que les serveurs m'ont faites par le passé… :-)
Et pour le SPF, ce type de filtrage n'a vraiment de sens que si tu le fais dès le départ, avant que le mail soit envoyé: tu as toutes les infos à ce moment-là, inutile d'attendre plus longtemps pour prendre une décision… Et je peux t'assurer que même sur postfix, ça le fait, en tout cas avec “postfix-policyd-spf-python”, qui est le filtre SPF que j'utilise. Tu te fais virer dès le “RCPT TO:” (oui, il attend de savoir à qui le mail est destiné pour savoir s'il y a des règles particulières genre exceptions pour certains destinataires qui seraient moins regardants), mais c'est clair qu'avec ce filtre, tu n'atteins pas le “DATA”…
Qu'est-ce que tu utilises, de ton côté ? Je trouve extrêmement bizarre qu'une implémentation d'un filtre SPF attende d'avoir reçu tout le message avant de décider quoi en faire, c'est un non-sens. :-)
Bonne soirée !
Je n'utilise pas policyd, je suis sur : postfix/postscreen/rspamd/sisyphus.
Du coup la vérif SPF est faite pas rspamd en même temps que le dkim, bayesien et compagnie. Mais effectivement au niveau de policyd ça permet de virer au plus tôt.
Globalement celui qui a la main sur les résolveur du serveur de réception aura possibilité de récupérer pas mal d'infos concernant les mails tout en étant “transparent”.
Ok pour rspamd et sisyphus… Mais c'est zarbi comme implémentation. La logique voudrait que les tests (et les refus éventuels qui en résultent) soient faits dès que possible, et de préférence avant la phase DATA, ce qui permet d'une part d'économiser des ressources, et d'autre part de refuser le mail d'emblée, au lieu de l'accepter d'abord puis d'envoyer une DSN ensuite, surtout que dans le cas des virus ou de spams, l'expéditeur est systématiquement faux, donc une DSN a toutes les chances d'aboutir chez quelqu'un qui n'a rien demandé…
Les contrôles protocolaires (par exemple sur HELO/EHLO, MAIL FROM:, RCPT TO:, etc.), ainsi que DNSBL et SPF peuvent avoir lieu avant la phase DATA, pourquoi s'en priver ? :-)
Après, que quelqu'un ait la main sur le résolveur du serveur de réception, ça m'inquiète moins. Normalement, ce sont les mêmes que ceux qui gèrent le serveur lui-même… :-)
Postscreen écrème déjà la très grande majorité du spam avec ses différents tests et son greylisting avant même tout traitement donc j'ai toujours trouvé policyd un poil overkill à moins d'avoir une installation vraiment très conséquente avec une grosse quantité de mail.
C'est clairement intéressant de faire ce genre de test avant de passer au bayesien et lda dès lors que la volumétrie est importante.