votre FAI

[jdh]

Cela m'intéresse d'en savoir plus sur "les spams qui se seraient adaptés au greylisting" ...
(Je peux imaginer que les troyens-générateurs de spam n'embarquent pas un serveur smtp conforme i.e. gérant la retransmission).

Il est clair que quand je mettrais en route mon serveur mail relais, je veillerais à bien regarder le résultat.

Néanmoins, tu ne réponds pas à ce que le greylisting n'effectue AUCUN TEST concernant ni le domaine ni l'ip, ce qui me semble un avantage ENORME par rapport à une RBL. Avantage qui n'a AUCUN coût ni effet pervers ! (Je ne vois pas bien pourquoi il y aurait un problème possible avec ApresFMail ou PasfroidMail).

Je n'ai pas expérimenté le MX interne dans les petites structures que je gère (ou j'ai géré) ... parce que, pour moins de 40 boites, je préfère faire du fetchmail à partir des boites chez l'hébergeur (sans compter qu'il faut s'assurer de la dispo 365/365 et du MX2).

[Franck78]

http://www.rfc-ignorant.org/

pour ceux qui douteraient de la complexité du système mail ou de l'existence de rbl variées.

[arapaho]

Cela m'intéresse d'en savoir plus sur "les spams qui se seraient adaptés au greylisting" ...
(Je peux imaginer que les troyens-générateurs de spam n'embarquent pas un serveur smtp conforme i.e. gérant la retransmission).

As-tu jamais remarqué que certains contenus non sollicités arrivent en double, triple ou plus, et ce dans un laps de temps très court ? Si le cas, inspecte les entêtes et tu remarques de troublantes redondances.

Néanmoins, tu ne réponds pas à ce que le greylisting n'effectue AUCUN TEST concernant ni le domaine ni l'ip, ce qui me semble un avantage ENORME par rapport à une RBL. Avantage qui n'a AUCUN coût ni effet pervers !

Tout respectueux du protocole qu'il puisse être, le greylisting ne prend pas TOUT A FAIT en compte la réalité de la production.

Le coût est, à mon avis, vraiment dépendant de l'environnement. Je vais prendre un cas concret relativement répandu.
Un serveur MX, Postfix parfaitement configuré et effectuant du greylisting via Postgrey. Le service devenant critique, il faut redonder ce MX primaire en haute disponibilité. Sauf que les BerkeleyDB utilisées par Postgrey ne sont pas du tout faites pour ça. Il faut donc changer le système de greylisting (trivial) et mettre en place un SGBDR en réseau (et évidemment le redonder). Le coût technique d'un accès réseau à un daemon de base de données et le coût financier viennent de largement augmenter. Et ce cher MX secondaire, si loin dans son nodal différent ? Tant qu'à faire, si jamais il vient à être utilisé, il aura totalement autre chose à faire que d'encaisser le spam. Il faut donc lui réserver le même sort. Et on se retrouve à faire du push/pull de base de donnée. Autant dire que les coûts financiers et techniques viennent tout simplement d'imploser.


Les effets pervers:
Mon infra envoie un mail vers la tienne qui fait un greylisting dessus. C'est moi qui supporte le coût de ta politique antispam. Merci
Certains daemons SMTP historiques ne supporte que la RFC 821. Lorsqu'ils rencontrent une impossibilité de livraison, ils n'essayeront pas de nouveau et remettront un avis de non livraison à l'expéditeur.
Faire comprendre, simplement, aux utilisateurs que SMTP ne garanti pas le délai de livraison, et cela à longueur de journée.
Et un dernier pour la route, complètement subjectif (et surtout parce que les Iles Pacifiques mènent actuellement face aux XV bleus): qmail gère les queues 'deferred' à l'image de la bouse intersidérale qu'il est.

(Je ne vois pas bien pourquoi il y aurait un problème possible avec ApresFMail ou PasfroidMail).

Ce type d'infrastructure utilise des pools de serveurs d'envois assez important et les queues de gestion sont réparties et distribuées.
Lorsqu'un mail est envoyé depuis AvantHMail, il passe évidemment par un de ces serveur d'envois, arrive chez toi et se fait greylister. Tu enregistres un triplet. Lors de la ré-émission du courrier, aucune prédiction ne peut être être quant au serveur d'envoi qui sera utilisé. La plupart du temps, c'est un autre serveur d'envoi qui est utilisé: un nouveau triplet chez toi, le mail n'étant toujours pas arrivé. Etc ...

Tout cela pour dire que le greylisting, tout comme l'usage des RBLs, est une belle piste bien lisse .... enduite de savon noir.

[jdh]

(Ce qui est intéressant c'est qu'il y a des arguments !)


Bien sur, je reçois, comme tous, des mails "multi-destinataires". Cela devrait faire quelques triplets supplémentaires, non ? Néanmoins, on peut aussi considérer qu'il y a un nombre maxi de destinataires par message (pour postfix, ce doit être le paramètre default_destination_recipient_limit ?).

Quel est le problème ? Ces triplets ne sont pas destinés à être stockés pendants un temps très long : le temps est réglable : on conseille 15 minutes, je crois. La taille de cette base doit être adaptée au nombre de mails reçus multiplié par un nombre maxi de destinataires (raisonnablement 10 ou 15). La non utilisation d'alias collecteur devrait aussi limiter la liste de destinataires à la liste réelle. Cela revient aux éternels problèmes de "garbage collecteur".

Bien évidemment, tu pousses le raisonnement à l'extrême (et non "relativement répandu"). Je ne gère pas des dizaines (centaines, milliers) de milliers de boites (avec le tuyau qui va avec). Ce n'est pas le sujet de ce forum. Les méthodes et outils de FAI leur sont propres (et nous échappent).

Un traitement light (greylisting ou RBL) doit/devrait être réalisé sur un relais smtp et sûrement pas sur un serveur mail "standard".

La rfc 821 est bien vieille (1982 ! et remplacée par la RFC 2821 en 2001) mais elle mentionne néanmoins quand même les codes 4xx :

4yz Transient Negative Completion reply

The command was not accepted and the requested action did not occur. However, the error condition is temporary and the action may be requested again. [...] the sender-SMTP is encouraged to try again

Concernant

Mon infra envoie un mail vers la tienne qui fait un greylisting dessus. C'est moi qui supporte le coût de ta politique antispam. Merci

ton infra respecte la rfc : elle doit donc gérer la file d'attente ! Faut-il préférer gérer une retransmission à un blacklistage sans procès ?

Il est bien connu qu'il n'y a aucune garantie en temps d'arrivée avec smtp. (Dans les petites structures, j'ai du mal à faire comprendre que l'on ne peut fetcher les mails à moins de 5', d'ailleurs avec Windows SBS qui intègre un "fetchmail", au contraire d'Exchange, est réglé à 15').

Je suis aussi d'accord avec "Tout cela pour dire que le greylisting, tout comme l'usage des RBLs, est une belle piste bien lisse .... enduite de savon noir".

Je regrette cependant que beaucoup croient aux RBL et refuse le greylisting ... alors qu'il n'a pas du tout les inconvénients des RBL !


(Le 15 au coq a gagné : Postfix est-il meilleur que qmail ??)

[arapaho]

(Ce qui est intéressant c'est qu'il y a des arguments !)

Je parle quand même rarement sans arguments Mais ça m'arrive ! (et j'aime ça)

Bien sur, je reçois, comme tous, des mails "multi-destinataires". Cela devrait faire quelques triplets supplémentaires, non ? Néanmoins, on peut aussi considérer qu'il y a un nombre maxi de destinataires par message (pour postfix, ce doit être le paramètre default_destination_recipient_limit ?).

Je ne parle pas d'une multiple présence dans les destinataires. Je parle vraiment d'une gestion de ré-émission effectuée par certain bots: evidemment, ce n'est pas une gestion intelligente. Simplement une ré-émission périodique.

Quel est le problème ? Ces triplets ne sont pas destinés à être stockés pendants un temps très long : le temps est réglable : on conseille 15 minutes, je crois. La taille de cette base doit être adaptée au nombre de mails reçus multiplié par un nombre maxi de destinataires (raisonnablement 10 ou 15). La non utilisation d'alias collecteur devrait aussi limiter la liste de destinataires à la liste réelle. Cela revient aux éternels problèmes de "garbage collecteur".

Avant de répondre à cette phrase, j'aimerais que tu détaille sur quel point précédent tu te bases pour rédiger cette réponse. Ca me permettra de ne pas répondre n'importe quoi, n'importe comment.

Bien évidemment, tu pousses le raisonnement à l'extrême (et non "relativement répandu"). Je ne gère pas des dizaines (centaines, milliers) de milliers de boites (avec le tuyau qui va avec). Ce n'est pas le sujet de ce forum. Les méthodes et outils de FAI leur sont propres (et nous échappent).

Relis bien: je parle d'un cas concret (postfix / posgrey), et par la suite, le service _devient_ critique. Le nombre de boites gérées n'est pas un facteur déterminant dans la prise en compte du côté critique du service. Le domaine d'activité de la structure, le marché, et plusieurs autres paramètres que je me garderai bien de lister exhaustivement font qu'un service SMTP *peut* devenir critique. Même pour 10 comptes.
Alors forcément, le rapport entre 10 et 10000 boites est extrêmement important. Reste qu'entre monter une archi de pinpin qui répond à un besoin d'un instant 'T ' (MTA/MDA/MSA sur la même machine) ou une archi qui s'adaptera dans le temps (MTA/MDA/MSA distribués) sans la remettre en cause dans son intégralité à chaque évolution, le rapport est identique (10 / 10000).

La rfc 821 est bien vieille (1982 ! et remplacée par la RFC 2821 en 2001) mais elle mentionne néanmoins quand même les codes 4xx :

4yz Transient Negative Completion reply

The command was not accepted and the requested action did not occur. However, the error condition is temporary and the action may be requested again. [...] the sender-SMTP is encouraged to try again

A un mois près (octobre 2008): RFC 5321.
Evidemment que la rfc 821 prévoyait ce genre. Aussi, je peux t'assurer que les daemons de cette époque n'implémentaient absolument pas cette gestion, l' "encouragement", n'étant que optionnel (je te certifie qu'il existe encore sur le Net des daemons de ce type). Par ailleurs, dans les dernières mise à jour, l' "encouragement" est remplacé par Each reply in this category might have a different time value, but the SMTP client SHOULD try again. Ce qui est une large différence.

Concernant

Mon infra envoie un mail vers la tienne qui fait un greylisting dessus. C'est moi qui supporte le coût de ta politique antispam. Merci

ton infra respecte la rfc : elle doit donc gérer la file d'attente ! Faut-il préférer gérer une retransmission à un blacklistage sans procès ?

Bien sûr qu'elle gère les files d'attentes. Mais pour de vraies indisponibilités. Pas pour un semblant d'indisponibilité qui ne sert qu'à vérifier si je respecte ton message 4xy et que je ne suis pas un spammer. Le fait que tu fasses semblant de ne pas être dispo me fait _supporter_ le coût de ta lutte antispam, que je respecte ou pas les RFCs.
Qui plus est, mon infra respectant la RFC, si je la passe en relais ouvert, ou que je fais de l'emailing de masse avec, ton greylisting ne te servira rien, je te submergerai de manière importante.

Il est bien connu qu'il n'y a aucune garantie en temps d'arrivée avec smtp. (Dans les petites structures, j'ai du mal à faire comprendre que l'on ne peut fetcher les mails à moins de 5', d'ailleurs avec Windows SBS qui intègre un "fetchmail", au contraire d'Exchange, est réglé à 15').

Je ne reviendrai pas là-dessus, surtout dans la manière de penser de notre pays: "oui les autres" et ses variantes. Depuis bien longtemps, je propose aux utilisateurs et décideurs d'appeler leur correspondant pour qu'ils vérifient que leur mail est bien arrivé. Une infinitésimale part de ces personnes note le caractère absurde de cette solution.

Je regrette cependant que beaucoup croient aux RBL et refuse le greylisting ... alors qu'il n'a pas du tout les inconvénients des RBL !

Et moi je regrette que les RBLs soient refusées en bloc en y opposant le greylisting (sans aucune attaque à ton encontre).

(Le 15 au coq a gagné : Postfix est-il meilleur que qmail ??)

Oui beaucoup de ballons échappés cependant.
Si la question est sérieuse, je ne peux que te conseiller de travailler un temps avec Postfix ou Exim et un temps avec qmail. Tu auras ton propre avis sur la question. Le mien, je pense que maintenant tu le connais

[jdh]

Il est évident que je suis supporter du 15 (parce que j'y ai joué pendant quelques années).

Il est évident que je suis supporter de Postfix qui a remplacé très vite les Exim de mes Debian. Je n'ai aussi aucune envie de me mettre à Qmail et encore moins à Sendmail.

Pour les RBL, je pense qu'il faut en user oui mais par pincée, alors que le greylisting peut/doit l'être par brassée.
Ce que je regrette, c'est les ceusse qui refusent le greylisting sans en avoir même compris le principe ! (et il y en a beaucoup)
Et les ceusse qui ne jurent que par les RBL (et les munltiplie) sans même évaluer ... ce qu'ils ont perdus ! (il est évident que ton avis éclairé n'est pas dans ces catégories !)

Donc on ne peut pas dire que nous soyons éloignés !

En fait, je pense que le greylisting n'est pas vu comme un dispositif simple, très léger, sans gène, et est décrié, alors que les RBL qui coupent comme la faucheuse (nationale) serait le dispositif efficace et n°1 !


Concernant les RFC, les MAY, MIGHT, COULD, WOULD, SHOULD du début de la plupart sont très clairs !
Nous sommes bien d'accord sur la différence entre tous ces mots !


Supporter le coup de ma politique antispam : la première fois, oui ! Mais il y a, en principe 2 timers : 15' d'attente "primaire" puis 6h de white-list. Avec 1 message par jour de ton domaine vers le mien, c'est clair ... et ce n'est pas le problème.


Je confirme qu'il est juste de dire qu'une fois en white list, tout est accepté, et la submersion peut commencer !
Sur ce point, il faut regarder la grande similitude et différence des outils :
- le greylisting : je refuse temporairement le mail (car je peux le faire dans la rfc) et après je prends : AUCUN rapport quelconque avec le contenu MAIS pas de refus systématique !
- les rbl : je refuse parce tu n'a pas une bonne ip ou un bon nom dns : AUCUN rapport quelconque avec le contenu MAIS refus sélectif !
Et on parle de lutter contre le spam qui signifie que le contenu est pourri (aka un pourriel) ! Retenez la leçon, lecteurs, on agit selon la forme et non le contenu !


Sur la méthode de fonctionnement du greylisting, le principe est de stocker des triplets pour gérer des timeout. Passé un temps de refus, il y a un (autre) temps de white-list. Le système doit utiliser une base dont on peut statistiquement évaluer la taille. Cette base doit être rapide et fiable. Il est prévu de nettoyer automatiquement cette base (action identique au "garbage collector" qui récupérait la mémoire libre dans le vieux langage LISP).

Je peux croire qu'il y a des optimisations à faire d'ailleurs : par exemple, une fois un triplet accepté, cela devrait débloquer tous les triplets ayant la même ip ! Ou encore passer à du C et non du perl (cas de postgrey ?).


Concernant l'architecture, la taille et les quantités/volumes déterminent beaucoup de choses : par exemple, pour 120 boites, je compte utiliser une SDSL 2M, un serveur relais (postfix) neuf, et un serveur mail interne, peut-être 2 (car 2 sites). J'ai du mail à imaginer ce qui serait nécessaire pour 2000 boites, 200000 boites ou 10M de boites. Je note que O. semble utiliser 9 ip pour son MX, qu'il y a ensuite le passage par AV/AS puis l'arrivée dans un smtp "de stockage". Mais combien y a-t-il de réelles machines derrière ? (Prenez une feuille, vous avez 2 heures !)