La lutte contre le spam est un domaine où les certitudes (souvent assénées avec conviction) sont plus fortes que les faits. Prenez n'importe quel forum, en ligne ou ailleurs, où on discute des mesures qui pourraient limiter les conséquences du spam, vous y lirez et entendrez des affirmations radicales, par exemple sur l'efficacité du greylisting, sans que les affirmateurs ne se soucient d'appuyer leurs déclarations sur des mesures concrètes, faites dans la réalité. Comme le note le tout nouveau RFC 6647, le greylisting est largement déployé, depuis de nombreuses années, marche bien et n'a pas d'inconvénient grave, mais il reste rejeté, sans raisons valables, par de nombreux « experts ». Ce RFC a mis du temps à sortir (il est courant à l'IETF que le texte de la norme vienne très longtemps après le déploiement) mais il changera peut-être cette perception.
- Analyse en français http://www.bortzmeyer.org/6647.html
- Le RFC http://www.rfc-editor.org/rfc/rfc6647.txt
# Ce que je constate
Posté par chimrod (site web personnel) . Évalué à 5.
Je m'autohéberge et j'ai mis en place des serveurs MX sur mon DNS au cas où ma connexion internet tombe, pour ne pas perdre de mails. Ces MX pointent vers des alias qui redirigent vers des compte mails externes (yahoo, gmail…)
Ce que je constate, c'est qu'en cas de Greylisting, le serveur MX est directement contacté par le spammeur, sans attendre. C'est alors le filtre de gmail, yahoo qui fait le trie et s'occupe de mettre le spam de côté.
Par contre, dans le cas d'un mail légitime (envoyé par une personne physique, ou par un service commercial : amazon, paypal…) le serveur est davantage respectueux et va attendre un moment avant de renvoyer le mail.
Ça me convient très bien, le spam est envoyé sur les boites externes (sauf quelques rares exceptions), et les mails que je reçoit directement sont le plus souvent légitime.
Par contre, je n'ai pas cherché à mettre en place un vrai système de greylisting + serveur de secours configuré par mes soins, mais je pense qu'on touche là aux limites du greylisting : comment va se comporter l'expéditeur si tous les serveurs contactés annoncent une indisponibilité ? Comment synchroniser les temps d'attente entre les différents serveurs mail ?
C'est un beaucoup plus compliquer à mettre en place que dans le cas d'un seul serveur tournant sur une seule machine…
[^] # Re: Ce que je constate
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 5.
J'ai l'impression que vous utilisez un vocabulaire non-standard. Vous voulez dire que vous avez plusieurs enregistrements MX (il y en a toujours au moins un), pointant vers des serveurs différents ? Si c'est le cas, c'est en général une mauvaise idée pour un petit site http://www.bortzmeyer.org/mx-secondaire.html
Et le fait que les spammeurs attaquent en premier le MX de plus faible priorité a été souvent observé.
Sinon, le cas de plusieurs MX est couvert dans les articles cités.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à -3.
Quoi ??? Mais tu dis n'importe quoi !! :)
C'est le concept même d'avoir plusieurs enregistrements MX: avoir plusieurs serveurs aptes à réceptionner le flux de email.
Ainsi si ton MX primaire est cassé, le secondaire (qui DOIT être un autre serveur) réceptionnera l'email en attendant que le primaire revienne à la vie.
Les arguments avancés dans ton post de blog sont absolument farfelus et sans fondements.
Oui, avoir plusieurs MX distincts présentent quelques difficultés supplémentaires concernant la lutte antispam… et alors ????
Plutôt que de te creuser la tête et de solutionner ces problèmes, tu préfères faire l'impasse sur un MX2 en prétendant qu'il est inutile … foutaises!
Et pour le problème du greylisting et des multiples MX, il suffit simplement d'utiliser un service de greylisting te permettant la réplication des bases de données: MySQL master/master ou Rsync de fichiers plats ….
[^] # Re: Ce que je constate
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Aucun intérêt. Les serveurs expéditeurs le feraient de toute façon, en réessayant périodiquement pendant cinq jours.
Non.
Et alors c'est un argument, qui n'est ni farfelu ni sans fondement.
Non. Il fait l'impasse sur un second MX parce que, sauf dans les deux cas précis qu'il mentionne à la fin, il est inutile.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 6.
L'intérêt d'un MX secondaire, c'est qu'il gardera les mails plus de 5 jours, lui …
Ca peut paraitre en effet inutile pour des vrais archi de mails (j'entend un serveur dans un datacenter avec un vraie connexion internet) ou il y a rarement plus de 5 jours de downtime.
Par contre dans le cas d'un serveur MX primaire sur une ADSL, l'utilité d'un MX secondaire me parait tout de suite plus pertinente (bein ouai, ton ADSL peut parfaitement rester cassé plus de 5j … oui, je connais le refrain de l'auto-hébergeur: ça tombe jamais en panne, blabla … jusqu'au jour ou…).
Autre argument en faveur d'un MX secondaire: les délais entre chaque tentative augmente généralement avec le temps … ainsi, après 1 ou 2 jours de downtime, les mails les plus anciens ne seront réémis que tardivement.
Sur un MX secondaire, tu forces le flush, c'est parti, tout tes mails arrivent dans l'heure, même les plus ancien.
Dernier argument pour démontrer l'utilité d'un MX secondaire: le délai de 5j est celui conseillé par la RFC.
Mais il ne s'agit en aucun cas d'une valeur codée en dure dans le MTA. De ce fait (et j'ai déjà vu faire) certains admins n'hésitent pas à réduire ce délai, afin d'éviter de pourrir leurs queue mail avec les mails des autres…
Et sinon, désolé, mais à mes yeux, un argument se basant sur "la difficulté" et, grosso modo, "la fainéantise" pour faire l'impasse sur un élément de base de la sécurité et fiabilité d'une infrastructure (quelle qu'elle soit) est sans fondement.
Une impossibilité technique, oui. La flemme, non.
[^] # Re: Ce que je constate
Posté par lesensei . Évalué à 3.
Je pense que tu n'as pas bien compris le sens de l'argument.
La question posée par Stéphane (on est sur le net, on est donc tous copains, je me permets) n'est pas en premier lieu celle de la complexité, mais celle de la pertinence: son avis (qui, comme il le dit, n'engage que lui), c'est que pour la plupart des auto-hébergements, on peut se satisfaire d'un downtime de quelques jours sans drame lié à la perte du service mail. Auquel cas, on peut mettre en regard la complexité de configurer un MX secondaire et l'utilité de le faire. C'est le seul argument qu'il me semble poser. Et je dois dire que c'est aussi ce que je pense. Sauf à avoir des besoins de haute-disponibilité du serveur mail, le MX secondaire est probablement superflu. On pourra d'ailleurs regretter que Stéphane parle d'entreprises dans son billet, puisque pour elles, un service mail aux abonnés absents est souvent bien plus problématique. Mais bref.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 1.
Oui mais c'est justement là ou je ne suis pas d'accord … si il y a un bien un domaine ou le MX2 me parait relativement essentiel, c'est l'auto-hébergement!!!
Dixit les arguments ci dessus, en réponse à Tanguy.
[^] # Re: Ce que je constate
Posté par chimrod (site web personnel) . Évalué à 6.
Tout à fait, et il n'y a pas que les problèmes liés à la connexion internet qui peuvent empêcher de récupérer les mail; ma plus longue indisponibilité fut de 2 semaines, suite à une panne d'alimentation…
Heureusement que les mails ont continué de me parvenir pendant ce temps !
[^] # Re: Ce que je constate
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
Gniii ? Tu as plusieurs serveurs sur le net quand tu t'auto-héberges ?
Foutaises aussi…
Pour de petits domaines le 2ème MX c'est une machine que tu ne maîtrise pas (ex ton registrar ou ton hébergeur) donc spam++
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 5.
Bein non … le deuxième ça pourrait être toi, Tanguy, n'importe quel autre "auto-hebergé" avec qui je me serai mis d'accord sur un échange de bon procédé …
(A l'époque ou je faisais de l'auto-hébergement, c'est comme ça que je procédais).
[^] # Re: Ce que je constate
Posté par Raoul Volfoni (site web personnel) . Évalué à 1.
Faut quand même avoir une sacrée confiance dans la personne…
[^] # Re: Ce que je constate
Posté par barmic . Évalué à 2.
Tu fais plus confiance aux PME comme Orange ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ce que je constate
Posté par ckyl . Évalué à 6.
Une grosse boite pourra analyser tes mails pour vendre de la pub et ce genre de choses mais se foutra totalement de ce qui va intéresser ton pote geek qui va lire tes mails (pour chopper tes passwords, des détails croustillants ou autre).
A toi de choisir ce que tu préfères, mais tu ne t'exposes pas vraiment aux mêmes risques dans les deux cas.
C'est exactement pour ca que tu as moins confiance dans l'admin de ta PME, que dans celui qui gère 10 000 postes et que tu n'as jamais vu.
[^] # Re: Ce que je constate
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
C'est exactement ce que je voulais dire. ;)
[^] # Re: Ce que je constate
Posté par barmic . Évalué à 4.
Sauf quand un employé de ce genre de boite veux s'amuser et se met à regarder d'un peu près quelques compte. Il y avait eu une histoire comme ça avec facebook.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ce que je constate
Posté par ckyl . Évalué à 2.
Y'a des contres exemples à tout, tu enfonces des portes ouvertes…
La différence est entre l'intérêt personnel et de l'analyse automatisée. Tu peux répondre qu'on peut faire des pas sympa avec de l'analyse automatisée si tu veux en enfoncer une deuxième ;)
[^] # Re: Ce que je constate
Posté par barmic . Évalué à 5.
Je le concède, mais grosso modo, si je demande une personne physique d'héberger mes mails c'est que j'ai confiance en cette personne. Si elle déconne ça se saura vite et ça se réglera aussi vite. Se retourner contre une personne physique est plus simple que de le faire face à un géant national ou multinational.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ce que je constate
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Nan j'ai jamais eu à faire avec eux pour de l'hébergement (sauf un client à une époque lointaine). Je pensais plutôt à ovh, online, etc..
Et oui je pense (peut-être ai-je tort) que ces hébergeurs ont autre chose à faire que d'aller lire mes emails.
[^] # Re: Ce que je constate
Posté par jyes . Évalué à 1.
Alors pourquoi mettre en place en MX2 ? Tu peux très bien le mettre en place seulement une fois que tu as perdu ta connexion, et ton copain Tanguy récupèrera tes mails. En attendant, quand tu n’as pas 5 jours de coupure, tu t’en sors tout seul et c’est très bien.
[^] # Re: Ce que je constate
Posté par William Steve Applegate (site web personnel) . Évalué à 4.
Bah oui : le primaire est dans mon salon, le deuxième est dans un datacenter loin d'ici. Et ça n'enlève rien au fait que je m'auto-héberge en partie (d'ailleurs, le deuxième pourrait très bien être dans une résidence secondaire si j'en avais).
Pas du tout, je suis root dessus, et la conf' est exactement comme je la souhaite. Jamais eu de spam supplémentaire par ce biais. Cet argument ne tient pas, sauf si on entend par « petits domaines » les domaines mono-site gérés par un admin fainéant qui ne veut configurer qu'une machine, ou grippe-sou au point de ne pas vouloir prendre un VPS ailleurs pour son MX2.
Envoyé depuis mon PDP 11/70
[^] # Re: Ce que je constate
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
Un MX secondaire c'est aussi des emmerdes. Il est indispensable de synchroniser sur le backup les recipients autorisés (pour éviter de backscatter ce qui est très MAL) et peu de service backup le propose.
Sur un auto herbergement je préferais un MX en secours chez un pote (inactif) qu'on active à la main (en jouant sur les DNS) quand y'a un gros problème.
Ça fait belle lurette que je n'ai plus ni ne sert de backup.
les pixels au peuple !
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 1.
Encore un autre faux problème …
Je m'appuie sur du postfix avec de la base de données MySQL pour mes domaines virtuels…
Donc le MX2 n'a qu'à (au choix):
1/ Répliqué la base de données.
2/ Faire un dump dans un fichier plat toutes les XX minutes.
Effectivement, si on utilise des services lambda de backup de MX, alors oui, ça se fait pas simplement. Mais en s'arrangeant avec d'autres auto-hébergés, pas de soucis ma bonne dame!
Après, c'est sûr que si on prend la problématique de l'hébergement par dessus la jambe, alors on peut s'affranchir de MX2, mettre son MX principal sur une ligne 56k, etc…
Mais pour moi, si on veut du boulot bien fait, alors on met un MX2 synchronisé avec le primaire… ça coute qq dizaines de minutes à mettre en place et quand ton alim ou ton disque dur cramera 1 jour où ton découvert autorisé t'empêchera de le renouveller de suite, bein tu seras content de t'être pris la tête 10 minutes pour avoir un MX2 propre.
[^] # Re: Ce que je constate
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Y'a qu'à, évidemment. C'est un tout petit peu contraignant comme procédure, même en évitant la complexité généralement inutile d'une base MySQL et en choisissant de simples fichiers à la place. Surtout face à la solution alternative tout à fait acceptable qui consiste à ne pas avoir de MX secondaire.
Va trouver un autre auto-hébergé prêt à mettre en place un serveur rsync en écriture pour que tu lui envoie ta base de données et qu'il la remonte régulièrement. Bonne chance.
Si ce que tu as chez toi, c'est une connexion 56 kb/s, alors oui, c'est suffisant pour héberger ton serveur de courrier. Pour une raison très simple :
Si ça passe dans le premier cas, ça passe dans le second. CQFD.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 1.
Rolalal … je reste dubitatif devant tant de mauvaise foi (à moins que ce sois un manque de compétence ou d'imagination) !!!
Cette solution acceptable à tes yeux car du fait de l'hébergement amateur.
Elle ne l'est pas à mes yeux (je fais aussi de l'amateur, mais j'ai choisi de le faire bien).
Soit, chacun ses opinions. Mais ce qui me fait sauter au plafond, c'est de lire qu'un MX2 est déconseillé …. c'est n'importe quoi!!
Bein si c'est pas Rsync, si c'est pas MySQL, tu peux tout aussi bien exporter cette liste sur un httpd que ton copain "auto-hébergeur de MX2" récupérera via un bête wget dans une crontab…. waow … trop PUISSANT !
[^] # Re: Ce que je constate
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Bon, donc si je comprends bien je suis un amateur qui fait de la merde. Merci, j'apprécie le compliment. Maintenant, si ça ne te dérange pas, je te laisse avec tes multiples serveurs de courrier à configurer, j'ai autre chose à faire, moi.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 1.
Bein écoute, quelqu'un qui héberge des mails sur une ADSL en disant "pffiou … un MX2 ça sert à rien", oui je considère que c'est faire de la merde.
Après tu sais, faut pas se vexer, c'est encore une fois un échange de point de vue et je n'ai en aucun cas l'omniscience…
[^] # Re: Ce que je constate
Posté par barmic . Évalué à 2.
Tu es doué en troll. Tu te bat pour avoir du MX en HTTP et tu explique que ne pas en avoir pour SMTP est tout a fait acceptable :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ce que je constate
Posté par Antoine . Évalué à 4.
HTTP est un service critique permettant de transmettre les like Facebook. SMTP est plutôt anecdotique à côté.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à -4.
Ah et j'oubliais une chose … "En jouant avec les DNS" … mais LOL quoi … t'as entendu parler du temps de propagation DNS ?
Par exemple, sur ton domaine, le TTL pour les enregistrements MX est de 86400… ça peut vite prendre du temps la propagation.
Sincèrement, qu'on me parle pas d'hébergement de mail si c'est pour faire des bidouilles comme celle-ci….
[^] # Re: Ce que je constate
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Ça se règle ça.
Par exemple, tu l'as réglé à une valeur moins délirante. Genre trois heures.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à -4.
Oui ça se règle.
Mais à quoi bon se lancer dans ce genre de bidouilles quand des barbus très compétents y ont déjà pensé depuis des décennies en créant un système fiable et bien pensé, j'ai nommé "MX Secondaire" ?
[^] # Re: Ce que je constate
Posté par Larry Cow . Évalué à 5.
Si tu considères qu'un réglage des tes entrées DNS (un entier à changer) est une "bidouille" par rapport au fait de devoir monter un second MX, tu n'as effectivement pas "l'omniscience".
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 1.
Euh non… c'est pas tout à fait ça le bidouillage ….
Le monsieur disait plus haut:
Si je comprend bien, c'est pas vraiment juste changer le TTL de la zone, mais plus changer le MX primaire "à l'arrache". Excuse moi, mais je trouve que c'est sale.
[^] # Re: Ce que je constate
Posté par Patrick Lamaizière (site web personnel) . Évalué à 1.
C'est simple et ça fait le job: stocker les mails en attendant d'avoir réparé. C'est pas plus sale qu'un MX backup.
(je dis ça…)
les pixels au peuple !
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 7.
Mais vous êtes sérieux là ????
P*tain mais c'est hallucinant….
Faut vraiment que je démonte tout vos arguments moisis un à un ?
Bon ok…
Alors tu fais quoi si ton MX primaire tombe en carafe qd t'es en vacances rando en Corse sans connexion internet ? Tu perds simplement tes mails ?
ET si c'est ton pote qui est en vacances ? Tu rootes son serveur ?
Le MX de backup, c'est fait pour ça, ça marche tout seul, t'as rien à faire.
Là sincèrement, je vous comprend vraiment pas …
Et pour infos, ça fait pas le job … car les mails vont être "delivered" sur le serveur de son pote … donc après, comment tu fais pour les rapatrier sur ton serveur à toi ?
Un scp ? Une copie d'imap à imap ?
Encore des bidouilles crades et inutiles….
J'suis peut être pas des plus "condescendant" dans mon ton, mais j'tente d'amener des arguments techniques à mes assertions…. je me fais systèmatiquement descendre en flèche, donc je préfère abandonner et vous laisser avec vos lignes ADSL et vos bidouilles de gorets.
Je tiens juste un petit truc que j'ai déjà entendu: "un bon admin sys va travailler pendant quelques mois dans l'objectif de ne plus rien avoir à faire ensuite".
Allé, ciao :)
[^] # Re: Ce que je constate
Posté par ckyl . Évalué à 2.
Mais rien ne te dis que les gens de l'internet tiendront compte de la valeur du TTL. Tu ne peux pas savoir quand ta nouvelle valeur sera propagée, les gens font des trucs sales.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à -2.
Les gens font des choses sales, certes.
Mais là, ce genre de chose, c'est faites par Bind & co automatiquement.
Comment ça marche ?
En gros un serveur DNS (disons celui de free.fr qui veut d'ailleurs t'envoyer un mail) a l'enregistrement concernant ton MX en cache. Il regarde depuis combien de temps il l'a et si il est expiré (le fameux TTL).
Si il est expiré, alors il effectuera une requête auprès des serveurs de nom faisant autorité sur ton domaine pour avoir le nouvel enregistrement, et le mettra en cache.
Cette explication est très "simplifiée". Il y a en effet plusieurs valeurs importantes au niveau DNS (refresh/retry/expire/negative cache ttl) utilisés dans différents cas de figure (DNS primaire cassé, etc…).
Mais grosso modo, ça marche comme ça.
Donc pour le coup, c'est "relativement" infaillible: le temps de propagation DNS sera au pire égale à celui de ton TTL.
Après, si le serveur de free.fr n'a pas l'IP de ton MX en cache, alors il la demandera aussitôt, et de ce fait, la propagation sera "instantanée"!
[^] # Re: Ce que je constate
Posté par ckyl . Évalué à 2.
Merci de m'expliquer l'eau tiède. Maintenant bienvenue dans le monde réel ou les gens font des choses sales.
Java par exemple cache infiniment les adresses IP (cf.
networkaddress.cache.ttl). Tu as aussi des dizaines d'implémentations qui ne respectent pas correctement les TTL. J'en ai encore trouvé une dans les DNS utilisés dans les clusters d'ATT qui servent à de proxy web. Il y a 3 semaines, un ingé de chez Google m'a confirmé qu'ils voyaient très régulièrement des comportements déviants, et que baser une solution sur un TTL DNS court, ca ne marche pas. Après si tu es dans un environement ou tu maitrises les services ou que tu estimes pouvoir prendre le risque c'est autre chose. Mais supposer que tout les serveurs et logiciels vont se comporter correctement c'est faux.[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 2.
Je sais pas si tu t'en rends compte, mais tu viens de donner des arguments supplémentaires à mon avis de base: bidouiller ses enregistrements DNS pour re-router son flux de mail vers "le serveur d'un pote" c'est sale.
Sinon l'objectif n'était pas d'expliquer l'eau tiède… mais je garde toujours en tête que si toi tu connais bien le concept de TTL etc… ce n'est peut être pas le cas de tout le lectorat linuxfr et que de ce fait, une petite explication ne fait pas mal.
[^] # Re: Ce que je constate
Posté par ckyl . Évalué à 2.
Heu moi j'ai rien dit d'autre dans la discussion que baser un service sérieux sur un TTL DNS court pour migrer c'était pas une très bonne idée. Donc ne me classe pas dans un camp ou dans l'autre.
Maintenant si tu veux mon avis à 2 centimes sur le sujet du thread, je suis d'accord avec toi. Et c'est ce que j'utilisais quand j'auto-hébergeait mon MX il y a 10 ans. C'est fait pour, ca marche nickel, et ca répond parfaitement au besoin des auto-hébergés (et oui mon serveur est souvent tombé sans que je sois dispo pour faire quelque changement que ce soit avant des jours).
[^] # Re: Ce que je constate
Posté par William Steve Applegate (site web personnel) . Évalué à 2.
Mauvais MTA, changer MTA.
Envoyé depuis mon PDP 11/70
[^] # Re: Ce que je constate
Posté par Hobgoblins Master (Mastodon) . Évalué à 4.
La seule réelle utilité que j’ai trouvée à avoir un MX backup, c’est de nourrir les bases d’apprentissage des filtres bayésiens.
[^] # Re: Ce que je constate
Posté par fcartegnie . Évalué à 2.
Il y a possibilité de couper le spam avant même avoir recours à la procédure de GreyListing: Un serveur est censé avoir un MX correctement déclaré et un reverse DNS correct.
Pour QMail, SpamDyke gère le greylisting et un ensemble de règles très utiles.
Stats sur MTA sans greylisting:
Pas de false positive constaté(*), les logs montrent bien que ce ne sont que des MX senders pourris qui envoient vers des adresses forgées.
(*)Les messages d'erreur SMTP étant configurables, un renvoi vers un formulaire HTML est souhaitable.
[^] # Re: Ce que je constate
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Ça, c'est très, très con, pour une raison toute simple : ne pas avoir de nom DNS, ce n'est pas la faute de l'administrateur du serveur mais de son FAI. Suspecter quelqu'un d'être un spammeur parce que son FAI ne lui fournit pas de nom DNS inverse correct n'est pas raisonnable.
Là, tu as des statistiques en IPv4, je parie. Et en IPv6, ça donnerait quoi ? Combien de faux positifs en IPv6 ? Je penche pour plus de 50%.
[^] # Re: Ce que je constate
Posté par oinkoink_daotter . Évalué à 1.
Surtout que c'est loin d'être une nouveauté. Ca ne faisait partie d'un truc nommé kit Jussieu ou un truc du genre à la grande époque de l'utilisation de sendmail fin des années 90 ?
[^] # Re: Ce que je constate
Posté par fcartegnie . Évalué à 3.
C'est pourtant lui qui choisit d'héberger un MX sur une IP "dont il n'a pas le contrôle"…
De plus c'est reculer pour mieux sauter, les filtres de spam augmenteront la note dans ce cas. Autant rejeter explicitement avec un message qui sera dans le mail plutôt qu'accepter le mail pour le mettre dans la poubelle plus tard.
[^] # Re: Ce que je constate
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Qu'est-ce que c'est, avoir le contrôle de son adresse IP ? Être son propre FAI, faire du BGP ? Vachement élitiste quand même.
Nawak. Un bon filtre antispam, ça juge le contenu du message ou le comportement du client qui soumet le message. Un antispam qui classerait des messages comme spam parce que le FAI du client qui a soumis le message a une sale gueule, ou parce que le nom DNS inverse laisse croire que c'est une ADSL ou je ne sais quoi, c'est un antispam de merde.
[^] # Re: Ce que je constate
Posté par LaBienPensanceMaTuer . Évalué à 2.
Méfie toi du reverse DNS … A une époque j'avais mis en place les restrictions que tu cites, mais j'ai du faire machine arrière à cause de laposte.net qui avait mal configuré le PTR pour ses serveurs de mails. Résultat, je refusais tout ce qui venait de chez eux (et mes hébergés étaient pas très content …)
Méfiance donc …
# Cluster
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Un des soucis avec le greylisting, c'est que certains serveurs en face ne renvoi pas avec le même serveur car ils utilisent un cluster (google par exemple mais pas seulement). Donc si vous avez vous même un cluster en entrée, il faut tenir une base de données du greylisting partagée entre les serveurs entrant. Bref, un peu lourd à mettre en place…
[^] # Re: Cluster
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Ce problème est connu et longuement décrit dans les documents cités (avec les solutions).
[^] # Re: Cluster
Posté par ArnY (site web personnel) . Évalué à 3.
Un système bien conçu tiendra justement compte de cela et les spools seront propres à chaque serveur smtp ou a un petit nombre de serveurs smtp pour éviter justement le soucis du greylisting chez le destinataire. C'est un cas qui est relativement rare et le seul fournisseur avec qui nous rencontrons le problème actuellement est OVH qui semble avoir fait son truc en ignorant complètement cette problématique.
En effet, un mail sortant de chez ovh est réémit à partir d'un serveur différent à chaque fois et OVH semble avoir un très grand nombre de serveurs smtp sortant. Nous avons toujours l'option au niveau de nos serveurs de greylisting d'associer le domaine de l’expéditeur et la classe C du serveur smtp pour pouvoir accepter ensuite le même courrier provenant d'un autre serveur situé sur le même réseau. Sauf qu'OVH a eu la super idée d'avoir presque un serveur smtp par classe C, donc même cette solution ne fonctionne pas avec eux. La seule solution serait de whitelister tous les smtp d'OVH et donc d'accepter aveuglement les courriers sortant d'OVH et vu la réputation d'OVH en la matière…
J'ai eu beau chercher dans les RFC si la question de la réémission via la même adresse était abordée, je n'ai jamais rien trouvé de précis.
[^] # Re: Cluster
Posté par LaBienPensanceMaTuer . Évalué à -2.
Vrai/Faux problème …. en 4j de temps, tu devrais bien revoir passer le même SMTP source, et donc accepter le mail :)
Par ailleurs, il suffit que le tuple destinataire/expediteur/IP (ou classe C) ai été vu une fois pour qu'ensuite, les mails passent directement.
Donc à moins de flusher ta base tout les jours, tu devrais avoir des problèmes de délais sur les premiers emails provenant de ce genre d'infra, mais les suivants passeront comme une lettre à la poste.
[^] # Re: Cluster
Posté par ArnY (site web personnel) . Évalué à 3.
Cela doit effectivement fonctionner la plupart du temps puisque j'en avais pas entendu parler jusqu'au jour où une personne n'a pas reçu un mail qu'elle attendait. C'est en regardant dans les logs que j'ai vu que le mail avait été réémit pendant les 4 jours à partir de serveurs différents et sur des classes C différentes du mail d'origine jusqu'à expiration du mail dans le spool d'OVH. Le pire est qu'apparemment l’expéditeur, que j'ai pu contacter, n'a pas reçu de courrier comme quoi son mail n'avait pas pu être livré…
[^] # Re: Cluster
Posté par Grunt . Évalué à 5.
Sans vouloir être méchant, ça ne serait pas lié à la relative complaisance d'OVH envers les spammeurs plus ou moins gros (du Kevin vérolé au vrai pro du spam) qui hantent ses serveurs ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Cluster
Posté par Antoine . Évalué à 4.
Disons que c'est certainement parce que les plages d'adresses des serveurs SMTP sont régulièrement blacklistées, que les serveurs SMTP sont désormais sur des plages distinctes :-)
(Nerim fait / faisait un truc similaire, mais en restant sur la même plage d'adresses, et avec 7 adresses différentes je crois)
[^] # Re: Cluster
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
A noter que pour éviter certains problèmes, je n'activais pas le greylisting si le serveur en face avait activé et configuré SPF. Cela résolvait le cas Google. En effet, aucun intérêt à faire attendre un courriel qui provient d'une machine validé dans le champs SPF d'un serveur DNS.
Mais SPF a été oublié et pas mal de serveur DNS sont mal configuré aujourd'hui… Pourtant c'était simple, peu couteux en terme de ressource et quand même pas mal efficace ;-(
[^] # Re: Cluster
Posté par Grunt . Évalué à 3.
Oui mais SPF casse certaines choses (comme les mailings lists, le renvoi automatique de mails d'une adresse vers l'autre), non ?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Cluster
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Sur une liste, le message arrive de la liste et non de la personne. SPF ne casse rien normalement. Pour les renvois de type redirection, c'est bien possible mais est-ce que ce genre de chose est vraiment un mal ? Ne vaudrait'il pas mieux faire du forward avec changement du champs From et ajout du champs ReplyTo si celui-ci n'existait pas déjà ?
[^] # Re: Cluster
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Non, SPF travaille sur le MAIL FROM. Mais de fait, un renvoi propre, ça ajoute un champ Resent-From.
# Merci
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à -1. Dernière modification le 18 juin 2012 à 11:27.
Comme d'habitude, merci pour ces analyses et cette vulgarisation de RFC !
Une petite nimage de circonstance :
[^] # Re: Merci
Posté par moules . Évalué à 8.
Franchement, cela commence à bien faire ces images de cyborgs n'ayant aucun rapport avec quoi que ce soit de libre. Cautionner le cyborg objet ne rend pas ce site meilleur. Alors certes on n'est pas obligé de cliquer, certes, on a le droit d'aimer les cyborgs, mais je ne pense pas que ce site ait à gagner quoi que ce soit là dedans. Cela donne une image de nerd n'ayant jamais vu un cyborg de prêt qu'en 2D.
Il y a de plus certainement de très bon sites de ce type qui apprécieraient ces Nimages à leur jute valeur.
C'était un message du comité contre les Nimages.
[^] # Re: Merci
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
'taing, je ne m'étais jamais rendu compte que le nom « Borg » pouvait venir de « cyborg »… Merci de m'ouvrir les yeux !
[^] # Re: Merci
Posté par Gof (site web personnel) . Évalué à 1.
Tu t'avances beaucoup. Ils sont peut-être libres.
[^] # Re: Merci
Posté par 2PetitsVerres . Évalué à -1.
Je préfèrerais qu'elles soient libres.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Merci
Posté par Frank-N-Furter . Évalué à 1.
C’est quand même beaucoup six borgs pour un seul homme.
Depending on the time of day, the French go either way.
[^] # Re: Merci
Posté par Christophe . Évalué à 4.
Vulgarisation, je n'irai pas jusque là: après avoir lu le journal, je ne sais toujours pas ce qu'est le Greylisting…
[^] # Re: Merci
Posté par LaBienPensanceMaTuer . Évalué à 10.
Le greylisting c'est simple: soit un mail qui arrive sur ton MX:
Le mail : "Salut, j'viens de X.X.X.X, expédié par t@c.com pour machin@tondomain, tu prends ?" (Aka EHLO PLOP\nMAIL FROM:t@c.com\nRCPT TO: machin@tondomain)
Ton serveur : "Euh … je te connais pas. Dégage et reviens dans 3 minutes". (Aka 450 Try again later)
Les robots de spams auront tendance à ne pas revenir dans 3 minutes, ne respectant pas la RFC.
Alors qu'un vrai serveur SMTP réessayera.
C'est donc une technique pour lutter contre le spam balancé à coup de robot, mais au détriment d'un léger délai lors de premier échange de mail avec un nouvel expéditeur.
Ensuite, le service de greylisting conserve le tuple expéditeur/serveur/destinataire pour accepter directement le mail.
[^] # Re: Merci
Posté par Christophe . Évalué à 2.
Ok, Merci !
# Il faut toutefois un gros travail d'information
Posté par Julien L. . Évalué à 5.
Je lis:
> Le courrier électronique a toujours été « au mieux », c'est-à-dire qu'une distribution immédiate ne fait pas partie du cahier des charges. Si des gens comptaient sur une délivrance instantanée, c'est qu'ils n'avaient pas compris le principe du courrier.
Et bien pas facile à faire comprendre en pratique. Car même si c'est comme ça que c'est prévu, le fait que, dans la vaste majorité des cas et depuis longtemps, ça fonctionne bien et quasi de façon instantané (it just works!), fait que les habitudes et croyances sont autres.
Je perds parfois un temps fou à prouver aux utilisateurs que si tel e-mail arrive 30 min après son envoi ça peut être normal (et de vérifier que cela ne vient pas de nos serveurs quand même) ou que si tel e-mail n'arrive pas et que je ne le vois pas en entré sur nos serveurs c'est qu'il est probablement perdu et qu'il faut demander à son l'expéditeur de l'envoyer à nouveau.
Aussi combien de personnes envoient des e-mails très important et ne vérifient pas qu'ils sont bien arrivés (d'autant plus quand ils attendent une réponse et qu'ils n'ont pas de nouvelles). Si c'est vraiment important, il faut prendre d'autres mesures, genre décrocher son téléphone et appeler sont interlocuteur. Et si c'est parce que c'était urgent et important, envoyer un e-mail et doubler par un recommandé par exemple etc…
J'avais abandonné le greylisting il y a un moment car, pour mon cas, les contraintes étaient plus importantes que les bénéfices mais ton article me donne envie de m'y "replonger".
Merci!
[^] # Re: Il faut toutefois un gros travail d'information
Posté par ckyl . Évalué à 4.
Bha si, il suffit de déployer Lotus Notes ! Les gens vont très vite comprendre.
[^] # Re: Il faut toutefois un gros travail d'information
Posté par fearan . Évalué à 2.
Ceci était une réponse du BOFH ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.