jdh a écrit:Tu y vas fort Mr Arapaho ! Moi je manquerais d'objectivité ?
Ha non non ! J'ai mis un smiley et tout !
A aucun moment j'ai voulu émettre un quelconque jugement sur ton message. Je voulais plus dire: l'objectivité/subjectivité est totalement une question de point de vue.
M. Jdh: que tu le prennes mal m'attristerait.
jdh a écrit:La PME travaille beaucoup avec des indiens (India).
Les entreprises locales utilisent un FAI qui bloque d'après RBL sans avertir quiconque !
Or W. a de multiples serveurs dont un certain nombre blacklistés régulièrement.
Conclusion : de nombreux mails partent bien mais ne sont pas reçus ALORS qu'ils sont légitimes !
Aussi, j'essaye de te donner un autre point de vue: un blocage d'après les RBLs qui génère aucun rejet ou avertissement, ce soit le SMTP qui est mal configuré, soit le filtre de contenu utilisé. Dans les deux cas, l'environnement de traitement est mal configuré. RBL ou pas, il n'est pas possible de prédire si le courrier va correctement être livré par cette plate-forme. Donc que faire ?
jdh a écrit:Ma réflexion :
- Le FAI indien utilise des RBL SANS AUCUN DISCERNEMENT i.e. "stupidement".
- W. n'a pas de techniciens suffisamment rapides pour déblacklister ses serveurs smtp. (Ne devrait-il pas se mettre en relation avec les blacklists pour ne JAMAIS être blacklisté ?).
Je note parfaitement le "SANS AUCUN DISCERNEMENT". Je vais le reprendre plus tard ;p (smiley)
jdh a écrit:Mon opinion : (j'ai à internaliser une messagerie de 120 boites dans l'année)
- je vais installer un relais mail sous Debian/Postfix avec du grey-listing et sans RBL
Je ne te connais pas personnellement ni professionnellement, et à la vue de tes interventions sur les forums, ce serait une grosse surprise que tu utilises le greylisting "SANS AUCUN DISCERNEMENT" (wai, il est là).
Donc tu vas bien faire attention aux pools de serveurs des infras du style AvantHMail ou encore ChautMail (entres milliers d'autres). Il va falloir opérer pour ces derniers des adaptations assez précises afin d'éviter, pour les courriers en provenance de ces infra, un retard trop important dans la livraison voir même une annulation de celle-ci.
Voir même, une fois le ras-le-bol de tes clients/utilisateurs bien rabâché, carrément envisager de mettre sur liste blanche ces infras. Et donc finir par faire ton "propre" système liste blanche, grise et noire.
Car une fois un triplet greylisté pour une de ces infras, rien ne permet de déterminer que les essais ou envois suivants seront fait avec le même triplet. Donc une boucle qui peut aller assez loin.
jdh a écrit:Les blacklists, il en existe des centaines. C'est une méthode efficace pour faire tout et n'importe quoi !
La légimité d'un mail N'EST PAS parfaitement liée à son domaine ou à son adresse ip MÊME SI il peut y avoir un rapport. Cette dernière phrase est hélas incontestable ...
Le greylisting est également très imparfait s'il est mal utilisé. Un compromis me semble plus judicieux. Les deux solutions obligent à mettre _correctement_ les mains dans le cambouis et doivent être adaptée quasiment sans cesse. Mais ni l'un ni l'autre ne doivent être considérés comme critère intransigeant.
Il est, en effet, absolument ridicule de mettre autant de RBL que l'on peut. Et vu que la légitimité du mail ne peut reposer sur l'ip émetteur, le greylisting, avec son triplet @ip, @émetteur, @destinataire, se met tout autant dans l'impasse (bon ok, celle-là était facile).
Et ne pas oublier filtres bayésiens et autres procédés.
Cumuler les resultats de différentes techniques et les pondérer me parait plus approprié. Ca fait un boulot monstre mais c'est bien fait.
Et attention, je ne dis pas de jeter ne serait-ce qu'un mail, mais de faire bien attention à leur provenance.
jdh a écrit:Comme le spam, le mail devrait suivre avec la mention [RBL] et non être balancé sans procès ... comme la plupart du temps. Ou être redirigé vers une boite mails de tri.
Ok. C'est une idée qu'elle est bonne. Mais cela dépend largement de ta bande passante, de ton domaine d'activité, du nombre de boîtes ou d'aliases, entre autres.
Tu montes une infra de 120 boites et faire "suivre" de manière taggée est réalisable dans ce cas. Une des infras que je gère est équivalente en terme de boites (105 comptes, hors aliases)et ce procédé de suivit est appliqué. TOUS les mails sont livrés aux destinataires, et les comportement de RBL et autres procédés sont simulés. Cela répond à un besoin très précis des utilisateurs de ce domaine. Je te présente quelques chiffres, relevé par les outils de stats; c'est un instant T, correspondant à 24 heures. Seul le greylisting est actif et très affiné. Seulement deux RBL, mais choisies pour leur pertinence.
- Code: Tout sélectionner
269 received
516 delivered
0 forwarded
23 deferred (489 deferrals)
2 bounced
10149 rejected (95%)
0 reject warnings
0 held
0 discarded (0%)
message reject detail
---------------------
RCPT
Helo command rejected: 554 BadSender1 (total: 72)
Helo command rejected: 554 BadSender3 (total: 8)
Helo command rejected: need fully-qualified hostname (total: 2461)
Recipient address rejected: Greylisted (total: 5762)
Recipient address rejected: User unknown in relay recipient table (total: 31)
Sender address rejected: Domain not found (total: 47)
Sender address rejected: need fully-qualified address (total: 4)
blocked using rbl xxxxxx.org (total: 234)
blocked using rbl xxxxxx.org (total: 1530)
message reject warning detail: none
message hold detail: none
message discard detail: none
Conditions strictement identiques, mais 4 jours plus tard
- Code: Tout sélectionner
1426 received
3589 delivered
0 forwarded
33 deferred (462 deferrals)
18 bounced
36467 rejected (91%)
0 reject warnings
0 held
0 discarded (0%)
message reject detail
---------------------
RCPT
Helo command rejected: 554 BadSender1 (total: 77)
Helo command rejected: 554 BadSender3 (total: 31)
Helo command rejected: need fully-qualified hostname (total: 10015)
Recipient address rejected: Greylisted (total: 14369)
Recipient address rejected: User unknown in relay recipient table (total: 74)
Relay access denied (total: 1)
Sender address rejected: Domain not found (total: 98)
Sender address rejected: need fully-qualified address (total: 1)
blocked using rbl xxxxxx.org (total: 133)
blocked using rbl xxxxxx.org (total: 11644)
cleanup
header (total: 24)
message reject warning detail: none
message hold detail: none
message discard detail: none
Les stats sont relevées avec une modification (lourde) interne de pflogsumm.
Les utilisateurs traitent et trient quotidiennement l'intégralité des mails, mais commencent largement à être saoulés par ces pertes de temps monumentales. Surtout que l'intégralité des mails passés au simulateur de RBL sont non légitimes.
Ceci juste pour montrer qu'un compromis est forcément obligatoire.
Une autre infra que je gère est, elle, composée de 2600 boites et est rudement "exposée" aux contenus non sollicités. La quantité de courriers gérée est pharamineuse, autant te dire que l'ensemble des utilisateurs ne trient absolument PAS les mails postés en boites de tri. Et je ne te parle pas des coûts de traitement et de bande passante. (Cela reste définitivement ridicule en comparaison des infra d'un W../O..)
En conclusion de ce message, je dirais qu'il est important d'adapter les solutions en fonction des besoins et des paramètres extérieurs (cout, attentes, charge, confort, etc) et je me dit qu'il est relativement dommage de se limiter dans l'utilisation des armes de défense contre le SPAM et les manier avec prudence et parcimonie.