Merci pour ces réponses François. Le 6 octobre 2010 23:46, Francois Petillon <fan...@proxad.net> a écrit :
> On 10/06/2010 07:44 PM, Marc De Saya wrote: > >> Merci Thomas, si tu en as d'autre je suis preneur. >> Pour le reste je partage totalement l'avis de Pierre, une fois que tu es >> inscrit à une mailing-list tu signifies clairement ton acceptation. C'est >> pourquoi TOUTE liste de diffusion DOIT prévoir un mécanisme automatique de >> désincription (avec un minimum de vérification). Si ça n'est pas le cas, >> pour les liste française, la répression des fraudes et la CNIL sont la >> pour >> ça. >> > > Ça, c'est la version bisounours. Si un serveur (entreprise, emailer ou > assimilé) balance un mail (autre qu'une unique demande de confirmation > d'inscription) sur une adresse mail dont je sais qu'elle n'a jamais fait la > moindre demande et encore moins confirmé l'inscription, c'est blacklistage > direct. > > C'est typique des newsletters qui utilisent des listes d'email commerciales > voir, dans des cas plus rare, ne font pas de double-optin (il y a quelques > petits malins qui trouvent spirituel de s'inscrire comme > postmas...@free.fr/r...@free.fr/etc.) En même temps c'est la version RFC5321 ! Après c'est exactement ce que j'ai dit plus haut : un mécanisme d'inscription/désincription sérieux (avec un minimum de vérification -lire mail de confirmation- avec cookie/captcha) et la tout de suite il y a moins de blacklistage :) > > > Ma question reste ouverte au sujet des seuil de req/s, syn/s, >> SMPT EHLO /s etc ... qu'un opérateur/gros maileur est en droit de limiter >> pour une mailing liste totalement légitime. >> > > Le problème est que ce genre de seuil n'a strictement aucun interet (à la > limite, c'est plutôt l'évolution dans le temps qui pourrait être pris en > compte). La réponse que je fait lorsqu'on me pose ce genre de question est > d'être server-friendly. En gros, vous pouvez balancer autant de mail que > vous voulez mais en ouvrant un nombre raisonnable de connexions simultanées. > Si les serveurs sont chargés, votre débit sera effectivement faible (et > c'est dans ce cas que je trouve la limite req/s absurde : si vous êtes en > deça de la limite, vous allez vous retrouver à ouvrir d'autant plus de > connexions alors que le serveur est déjà à la rue). > > > Cependant, si quelqu'un commence à bombarder un serveur à plus 1000 req/s sur plusieurs port depuis une IP à mon avis il y a un reverse quelque part qui risque de faire au moins du rate limiting et voir me un IPS qui bloque dans la foulée. Cela dit je partage votre avis sur l'évolution dans le temps mais être serveur friendly implique que l'opérateur expose ces données de suivi de monitoring de la charge pour s'y adapter. > Un des premier éléments de réponse mis en évidence par Thomas, est de load >> balancer les mails sur un pool d'IP en sortie ceci permet d'éviter la >> propagation d'une IP dans les RBL. >> > > Il m'est déjà arrivé d'aller chercher les raisons pour lesquelles nos MXes > étaient à la rue. Lorsque je tombe sur un pool de serveurs utilisés en // > pour envoyer rapidement un grand nombre de mails, j'ai tendance à shooter > les IPs assez rapidement (j'ai souvenir d'être tombé une fois sur deux > expediteurs qui nous balançaient, en pleine heure de pointe, plus de 80 > mails/s chacun en multipliant les connexions depuis quelques dizaines d'IP > différentes). > > Effectivement c'est la remarque que j'ai fait plus haut, si le pool d'IP appartient au même registrant mieux encore s'il est membre d'une /24 il devient aisé de shooté tout ou parti du bloc. Ce mécanisme ne fait que ralentir une propagation dans les RBL à mon sens. > François > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > /Marc
