Bonjour cher Journal,
Si je viens écrire aujourd'hui, c'est que je ne suis pas très joice... En effet je suis confronté à un problème des plus déplaisant:
Depuis de nombreux mois nous nous attachons (en tant qu'ISP) à sécuriser notre architecture mail, et notamment les flux mails sortants. Le but étant de réduire au minimum les émissions de spam (véritable gaz à effet de serre du mail!). Le chantier est vaste car la situation de départ n'est pas jojo mais à force d'efforts on arrive à quelque chose franchement acceptable.
Tout y passe: SPF, inscription aux feedback loop de différents MSP, rating control sur le relais sortant (merci postfix), Authentification, TLS, séparation des différents types de trafic mails, jusqu'au blocage du port 25 (un mal nécessaire)) depuis les clients de type dialup.
Le nombre de plaintes que nous recevons via les feedback loop chute alors grandement et je rentres me coucher avec le sentiment d'avoir contribuer à un internet un peu plus propre.
Seulement voilà malgré tout le boulot exposé ci-dessus, nous avons régulièrement des remontés de clients nous signalant qu'un mail qu'ils ont envoyé n'est pas parvenu au destinataires. Motif: rejet pour blacklist par Barracuda!
La fréquence de ces rejet et le nombre d'IP concerné nous font rapidement nous demander ce qu'il se passe. nous testons alors la blacklist barracuda sur tous nos subnets. Et là surprise: sur ~40000 IP testée, ~8000 se trouvent dans leur blacklist. Panique à bord. on refait le test sur une autre blacklist, à priori de renom: spamhaus. Résultat chez spamhaus: sur ~40000 IP testée 50 sont listées (dans la liste xbl).
De 50 à 8000 il y a un rapport démesuré qui sous-entends un problème quelques part.
Nous contactons alors Barracuda, ce qui n'est déjà pas facile étant donné que les mail restent systématiquement sans réponse. Lorsque nous réussissons enfin à avoir quelqu'un par téléphone (aux USA), celui ci nous apprend que nous sommes client Barracuda... Ah ça devrait faciliter les choses!
Et là tout devient plus clair: précédemment (lire l'admin précédent, avant que j’arrive, que je ne connais pas... oui je sais c'est moche de taper sur les prédécesseurs) des boitiers barracuda était utilisé en mode outbound pour relayer les mails de nos clients (avant la mise en place de toutes les sécurités exposées plus haut) et ce sympathique boitier envoyait chez barracudacentral la liste des ip (de nos clients) derrière lesquelles se trouvait des bot qui envoyait du spam! Voilà ce qui s'appelle scier la branche sur laquelle on est assis!
Au passage je tiens tout de même à signaler que ce comportement n'est absolument documenté ou du moins présenté par le revendeur. Pour une boite qui embarque du libre en veux tu en voilà (postfix + spamassassin pour les passerrelles mail et LVS pour les load-balancer) c'est tout de même un peu fort... bref.
Le truc c'est que ce setup date d'il y a plus de 3 ans, et que les barracuda ont bien vite été abandonné au profit de serveurs postfix tout aussi efficace pour relayer du mail et bien plus paramétrable.Or depuis 3 ans les IP dynamiques qui ont été enregistrées chez barracuda n'ont jamais expiré! Le support Barracuda nous confirme bien que c'est ce qui est à l'origine du blacklistage démesuré (et obsolète) dont nous sommes victime.
Nous fournissons donc nos subnets IP ainsi qu'un listing individuel de chaque IP à Barracuda, et demandons un déblacklistage "global" (de toute façon si la blackliste est efficace les IP qui doivent y figurer y seront ré-inscrites).
Et là d'un coup, nous ne sommes plus clients barracuda (les serveurs ayant été éteind et le support ayant expiré depuis 3 ans), et le support nous répond (une dernière fois) de bien vouloir procéder nous même au déblacklistage manuel via le formulaire en ligne... avec captcha et confirmation... bref du boulot pour un CDD pendant 1 mois (sans pause café)!
Alors bien sûr il n'est pas très malin de s'auto-blacklister de cette façon, mais je trouve irresponsable de blacklister de façon définitive des adresses IP (v4 qui plus est). De même, acquiescer un problème et dire ouvertement que rien ne sera fait pour le résoudre est tout simplement un manque de professionnalisme évident (et assumé vraisemblablement).
Je supposes que certains ici utilisent ce genre de boitiers tout prêt, et ne seront certainement pas d'accord. Il n'empêche les pratique que j'expose ici sont plus que limite!
Journal fachisme des blacklists (Barracuda)
9
sept.
2010
# blacklist
Posté par BAud (site web personnel) . Évalué à -1.
Si je comprends bien, tu as fait le choix de ne pas acheminer certains mails, dont des faux-positifs, tu l'assumes.
Ensuite, tu délègues ce choix d'identifier ce que tu achemines à quelqu'un d'autre à ta place et ensuite tu te plains de ne pas pouvoir assumer ton choix ? (ou tenter de reporter sur ton mauvais choix initial d'assumer les faux-positifs, lié à ta délégation de leur identification àmha).
Je me trompe ? Pourquoi avoir choisi de filtrer l'envoi de mails légitimes ? (ou en tout cas faire reposer la gestion sur quelqu'un d'autre, sans maîtrise ou contrôle). Tu dois avoir quelques clients mécontents, je suppose...
[^] # Re: blacklist
Posté par Chapellon Alexandre . Évalué à 8.
Ensuite les boitiers barracuda avait était placé en mode outbound, avec l'antispam désactivé (mais pas le système de reporting): En fait l'antispam ne peut pas être désactivé, il peut juste être configurer pour ne pas bloquer les emails (donc pas de faux positifs) par contre s'il détecte un spam les IP clientes sont reportés (silencieusement) vers barracudacentral. Une option cachée derrière le doux nom de "système de réputation".
Heureusement le fait d'avoir bloquer le port 25 oblige les client à passer par nos relais SMTP (heureusement pas blacklisté eux) ce qui minimise l'impacte client.
Par contre autre absurdité barracuda: il est possible de configurer les checks de blacklists pour toutes les adresses IP présentes dans les entêtes "Received" des mails! Choses que l'administrateur neuneu, s'empressent de faire en lisant le nom de l'option: "deep scanning"... ouah ca sonne vraiment trop cool!
# Surprise surprise!
Posté par maxix . Évalué à 2.
Par contre, je suis d'accord, adresse leur un chaleureux remerciement pour leur souplesse en matière de résolution de problème massif.
[^] # Re: Surprise surprise!
Posté par Chapellon Alexandre . Évalué à 4.
De plus là le propriétaire des IP n'avait pas demandé grand chose, sinon à un revendeur barracuda de lui vendre un boitier avec une formation. Formation durant laquelle cette problématique n'a pas été abordées apparemment.
# Acronyme ...
Posté par gnuarchibald . Évalué à 1.
Je connais la signification d'ISP mais pas de MSP. Qu'entend tu par la stp ?
Et autre question tu dit que tu t'inscrit au "feedback loop de différents MSP".
Tu t'inscrit ou et surtout qu'elle sont les avantages que tu en retire ?
Ou alors MSP pour toi est égal au RBL comme spamhaus ?
[^] # Re: Acronyme ...
Posté par Chapellon Alexandre . Évalué à 2.
tu t'inscris chez Yahoo!, AOL... plus les ARF (Abuse Report Format) de Abusix, Hostalia, junkmailfilter, spamcop etc...
L'avantage est que tu peux voir les mails (ou au moins leurs entetes) qui ont genere des plaintes et donc remonter jusqu'aux utilisateurs (generalement infectes par un bot).
--
qwerty kbd -> dsl pour les accents :)
[^] # Re: Acronyme ...
Posté par herodiade . Évalué à 8.
Mail Service Provider.
Par exemple Yahoo, Hotmail, Gmail ne sont pas des ISP mais envoient/recoivent beaucoup de mails.
Ils sont importants dans ce contexte parce que :
o Ils ont beaucoup d'abonnés et sont très utilisés (ils sont importants).
o A la différence des ISP (qui ne rejettent généralement pas de mails à destination de leurs abonnés, spam ou pas) ce sont surtout des webmails, qui peuvent se permettre de qualifier un mail de "spam", l'accepter, mais ne pas l'afficher dans l'inbox principale des destinataires (le ranger dans la spambox et l'effacer automatiquement au bout de quelques jours). Ce qui produit pour les utilisateurs finaux à peut près le même résultat qu'un rejet silencieux.
o Ils qualifient les mails (en spam ou ham) en s'intéressant en grande partie à l'IP de l'emeteur (est-elle censée emetre pour le domaine indiqué dans le return-path ? est-elle blacklistée ? quel est la proportion moyenne usuelle de mails acceptés/rejettés parmis ceux émis par cette IP ? quelle est la réputation de cette IP ? ...).
o Il est donc impensable, pour un opérateur relayant/envoyant du mail, d'ignorer l'appreciation de ces gros fournisseurs de services. Ce serait bien pire (en volume de mails concernés que les utilisateurs risque de "ne pas recevoir" (ne pas voir en fait)) que d'être totalement blacklisté par Orange.
o Ils fournissent aux opérateurs (à ceux qui envoient ou relayent) - ou bien ils recourent à des prestataires tiers qui fournissent aux opérateurs pour eux - des informations permettant de connaitre la réputation de leurs IPs
o Ils fournissent aux emetteurs des retours (des bounces) (au format standardisé, eg. Abuse Feedback Reporting Format) permettant de jauger des raisons d'un rejet précis et d'agir en conséquence (ce qui permet d'éviter, notamement, une dégradation de la réputation des IPs).
> Tu t'inscrit ou et surtout qu'elle sont les avantages que tu en retire ?
http://en.wikipedia.org/wiki/Feedback_Loop_%28email%29
http://www.returnpath.net/internetserviceprovider/feedback/
Lorsqu'on envoie ou relaye un large volume de mails, il est donc opportun de s'attacher à traiter sérieusement les retours (bounces, click sur le bouton "ceci est un spam" ou "unsubscribe" d'un webmail par l'utilisateur final, etc.) et de surveiller la réputation de IPs qu'on utilise pour le mail sortant.
Cela dit, de nos jours, les MSP utilisent de plus en plus le comportement de leurs utilisateurs pour évaluer finement la qualité des mails reçus pour une IP donnée, justement parce qu'en étant essentiellement des webmails, ils peuvent collecter beaucoup plus d'infos qu'un ISP qui fournit du POP3. Les mails en question sont-ils ouverts par le destinataire ? combien de temps sont-ils restés ouverts ? sont-ils immédiatement effacés ? est-ce que l'utilisateur a écrit ou répondu à l'expediteur du mail ? etc. Et, au dela de la qualification "spam" (=> mail jamais lu par l'utilisateur), on voit poindre des "classement/placement plus ou moins accessible dans l'inbox principale selon la probabilité que l'utilisateur ai envie de lire le mail".
Ce qui fait que la règle de plus en plus prévalente à faire entendre aux as du marketing de masse, c'est "cessez d'envoyer de la merde peu ciblée à des gens qui s'en tapent, sous peine de, bientot, avoir une réputation tellement nulle que vous ne pourrez plus emettre quoi que ce soit vers les plus gros MSP, ou n'aurez plus une chance que vos mails soient ouverts par les destinataires".
[^] # Re: Acronyme ...
Posté par Sano . Évalué à 1.
Pour rappel, un acronyme doit pouvoir se prononcer "naturellement" (OVNI, GNU, LASER, etc...), sinon c'est un simple sigle, même si la confusion est courante.
*Sano*
# Forcer à passer par un relais aggrave le problème
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
En effet, si les clients peuvent envoyer du courrier directement, dès que l'un d'entre eux envoie du spam, il peut être bloqué individuellement par les destinataires.
En revanche, s'ils ne peuvent pas envoyer de courrier directement, ils doivent passer par les relais du FAI. Relais qui, du coup, se retrouvent à relayer beaucoup beaucoup de messages, dont proportionnellement beaucoup de spam. Cela rend leur gestion difficile pour le FAI, qui doit y appliquer des techniques poussées pour réduire ce taux de spam afin de ne pas se les faire bloquer. Mais côté destinataire, cela empêche un blocage fin : à la réception de spam, on ne peut plus que bloquer les relais en question, et subséquemment l'ensemble des clients de ce FAI.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par neerd . Évalué à 4.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par Gniarf . Évalué à 2.
ça déresponsabilise les clients ala Madame Michu qui ne sait même pas ce que ça veut dire, ou ça déresponsabilise le FAI qui prétendra ne rien pouvoir faire et en pratique refusera de bouger son gros cul pour arrêter de polluer la planète ?
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par dave . Évalué à 6.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par Chapellon Alexandre . Évalué à 2.
Je ne suis pas, à la base, un fervent défenseur des filtrages et autres blocages, mais en tant qu'admin ma vie est bien plus simple et ma boite mail bien moins chargée depuis que le port 25 n'est plus accessible pour les bots installés sur le ouinouin de Mme Michu (celle la si je la chope...). Si tu sécurises correctement ton serveur de relais il est peu probable qu'il se retrouve blacklisté, et si cela viens à se produire tu n'as qu'un nombre limité d'IP à "ausculter".
Pour l'"auscultation", il est bien plus efficace de parcourir des logs SMTP (tu vas directement à l'essentiel) que de se coltiner des rapports d'analyse de trafic et de les confronter à des bases d'accounting Radius.
Enfin pour être tout à fait pragmatique, grâce au blocage du port 25, à l'heure actuelle les seuls spams qui sortent de notre réseau de client DSL sont envoyé par des bots capables de s'authentifier après avoir initialisé une session SMTP-TLS, et ceux qui s'attaquent directement aux webmails (notamment celui d'AOL), autant dire pas la majorité des bots (à l'heure actuelle). Enfin pour rester pragmatique il nombre de clients qui ce sont plainds de ce blocage a était quasi nul,et la communication faite à priori auprès des professionnels de la profession a eu un très bon écho.
Enfin cela ne limite en rien le client qui peut toujours envoyer des mails en utilisant notre relais ou un relais externe via un port alternatif. Sauf évidemment s'il essaie d'envoyer en direct des mails depuis une IP dynamique... choses à ne pas faire avec ou sans blocage du port SMTP.
Donc non forcer à passer par un relais n'aggrave pas le problème
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Pas forcément. On parle de lutte contre le spam, pas d'administration.
Voyons-le du côté du destinataire :
— s'il reçoit des spams depuis 42.0.2.168.rev.adsl.orange.fr et 12.0.2.168.rev.adsl.orange.fr, il peut appliquer une mesure très simple : bloquer tout courrier en provenance de ces adresses ;
— s'il reçoit des spams depuis smtp.orange.fr, il ne peut pas bloquer cette machine sans gros effets secondaires, et doit trouver quelque chose de plus compliqué.
Voyons-le du côté de l'opérateur :
— si un de ses abonnés envoie directement du spam, et qu'il reçoit un signalement sur abuse@orange.fr, il peut écrire à l'abonné responsable de cela, l'avertir, puis au besoin le déconnecter ;
— si un de ses abonnés envoie du spam en passant par son serveur relais, cela peut amener le serveur relais à être bloqué, et s'il reçoit un signalement, il doit chercher dans ses logs l'abonné responsable pour pouvoir l'avertir et au besoin le bloquer.
Si tu sécurises correctement ton serveur de relais il est peu probable qu'il se retrouve blacklisté
Je ne crois pas. Les serveurs relais d'Orange sont utilisés par des millions d'internautes qui l'utilisent pour relayer tout leur courrier. Ça doit faire des dizaines de millions de messages par jour. Si seulement un millième de ces messages est du spam, cela fait dix mille spams par jour. Largement de quoi se faire bloquer.
Pour l'"auscultation", il est bien plus efficace de parcourir des logs SMTP (tu vas directement à l'essentiel) que de se coltiner des rapports d'analyse de trafic et de les confronter à des bases d'accounting Radius.
Gné ? À la réception d'un signalement de spam, il suffit de regarder dans les en-têtes du message d'origine le premier champ Received, pour avoir l'adresse IP, donc l'identité, de l'abonné responsable…
Donc non forcer à passer par un relais n'aggrave pas le problème
Si, ça l'aggrave. Aujourd'hui le relais SMTP d'Orange est bloqué par Darty, pour une raison tout à fait légitime : il envoie plein de spam. Ils vont devoir le débloquer, et donc affaiblir leur niveau de lutte contre le spam.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par Chapellon Alexandre . Évalué à 2.
Bloquer une adresse dynamique IP suite à la reception d'un spam ne doit pas arriver souvent car une adresse ip dynamique est souvent bloqué par les MX à la connexion en se basant sur le reverse dns ou en utilisant des dnsbl specialisées.
"si un de ses abonnés envoie directement du spam, et qu'il reçoit un signalement sur abuse@orange.fr, il peut écrire à l'abonné responsable de cela, l'avertir, puis au besoin le déconnecter"
Une deco qui interviendra donc bien apres que le bot ait terminé d'envoyer ces 700000 mails. le pc zombie sera abandonné par le botnet master le temps de calmer le jeu puis dans quelques semaines ca recommencera... je doutes de l'efficacité de ce genre demesure (pour l'avoir pratiqué avant de passer au blocage). Si au contraire le client est relayer par un serveur il est facile de le bloquer dès la detection du problème sans risquer de créer un mécontentement justifié (il vaut mieux se faire couper son relais SMTP que sa connexion complète!)
"il suffit de regarder dans les en-têtes du message d'origine le premier champ Received, pour avoir l'adresse IP, donc l'identité, de l'abonné responsable…"
La encore ce n'est pas vrai avec une ip dynamique.. tu dois confronter l'IP à l'accounting Radius. Sans compter que ca peut tres bien être une IP extrene qui relaye en utilisant des credentials "volés". Le moyen le plus sur de retrouver les traces ... c'est effectivement dans les entetes smtp, mais le messageID....
Pour les serveurs d'orange... je concede que sur des tres gros volume une portion infime de spam peut suffir à etre listé... peut etre que multiplier les serveurs sur diferrents reseaux pourrait aider dans ce cas...
Pour conclure dans mon cas bien précis, la quantité de plaintes reçu depuis le blocage du port 25 a chuté de 80%, et la seules liste où les serveurs de relais se sont retrouvé sont des listes de backscater émis par des clients qui s'amuse à bouncer le spam... Je trouve que la situation n'est pas pire qu'avant au contraire.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ce qui, pour le coup, s'il s'agit de quelqu'un qui avait des raisons d'utiliser son serveur, nuit vraiment à la lutte contre le spam. En effet il ne peut alors plus publier de politique SPF efficace, par exemple.
ou un relais externe via un port alternatif
Super, mon FAI me fournit une sous-connexion donc je dois faire un tunnel vers un service que je loue ailleurs et qui a une vraie connexion. Youpi ?
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par Chapellon Alexandre . Évalué à 1.
En quoi le fait de bloquer le port 25 empêche de publier une politique SPF efficace??
Par contre envoyer ses mails depuis une IP dynamique sans passer pa un relais fixe ca oui ca empêche de publier une politique SPF efficace!
"je dois faire un tunnel vers un service que je loue"
What the ...?
Qui a parlé de tunnelé quoique ce soit... je te parles d'utiliser le port de submission, ce que devrait faire tous les MUA en lieu et place du port 25... tel que défini dans la RFC 4409!
Lis bien les posts avant de répondre.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Sans blocage, je mets une politique qui dit que seule mon adresse IP est autorisée à poster pour mon nom de domaine.
Avec blocage, je ne peux rien mettre de mieux qu'une politique autorisant tous les clients de mon FAI à poster pour mon nom de domaine.
Qui a parlé de tunnelé quoique ce soit... je te parles d'utiliser le port de submission, ce que devrait faire tous les MUA en lieu et place du port 25... tel que défini dans la RFC 4409!
Oui, bien sûr. Mais on parlait de : mon FAI m'interdit de poster directement, donc je prends un service externe pour le faire. En ce sens, l'envoi à un relais externe sur connexion sécurisée et identifiée n'est rien d'autre qu'un tunnel de contournement d'une restriction arbitraire de mon FAI.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
Oui, pardon, j'oubliais ça, il s'agit d'adresses dynamiques. Dans ce cas, rien à redire au relais, c'est la seule solution à un problème plus profond : l'attribution dynamique, c'est mal, ça déresponsabilise les gens.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par Chapellon Alexandre . Évalué à 4.
Sans rancune.
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Je voudrais pas faire mon informaticien ici (et je met volontiers ta phrase hors contexte) mais il me semble que du point de vue de la complexité, cette "évidence" n'est pas si facile à défendre. Je me trompe peut être mais en centralisant on rends souvent le problème plus complexe autrement dit on passe de n+n à n*n.
C'est hors propos mais ça me fait tellement ch*er d'entendre à tout bout de champs qu'un aéroport / hôpital / université et autre décheterie géant c'est mieux que plusieurs petits ou qu'un NAS gigantesque c'est mieux qu'une flopée de petits filers, qu'un énorme serveur avec plein de vm c'est plus efficace que de petites machines en nombre, qu'un seul OS c'est mieux que plein de différents ... que j'ai pas pu résister
Mes deux cents
Joris
[^] # Re: Forcer à passer par un relais aggrave le problème
Posté par Chapellon Alexandre . Évalué à 2.
Je préfères aussi avoir une floppée de machines plutôt qu'un gros bousin pour fournir un service tel que SMTP.
Dans ce cas il s'agit surtout de canaliser des flux.
C'est effectivement off-topic... et 'ailleurs c'est pour ça que je réponds! pour que la discussion parte dans tous les sens.
'cevis patem quid meliora'... non ça veut rien dire mais je trouves que ça boucle bien!
# bienvenue dans le monde réel
Posté par solsTiCe (site web personnel) . Évalué à 5.
je vois que le fait d'être une entreprise n'y change rien. Y'a une justice ?
# Mechanical Türk
Posté par JoeltheLion (site web personnel) . Évalué à 3.
C'est triste à dire, mais si vous ne trouvez rien de mieux, peut-être que mechanical türk peut-être une solution bon marché?
[^] # Re: Mechanical Türk
Posté par Kerro . Évalué à 3.
Ca devrait aller vite pour 80% des adresses. Celles qui restent, à la mimine.
[^] # Re: Mechanical Türk
Posté par Chapellon Alexandre . Évalué à 2.
"Cher client, voilà on a fait une boulette y'a quelques années et du coup si vous pouviez nous filer un coup de main.... ça serait vachement sympa... au fait cela n'ouvre pas de droit à une baisse tarifaire :-D"
Sinon c quoi Mechanical Türk, comment ça peux m'aider?
[^] # Re: Mechanical Türk
Posté par Chapellon Alexandre . Évalué à 2.
"Cher client, voilà on a fait une boulette y'a quelques années et du coup si vous pouviez nous filer un coup de main.... ça serait vachement sympa... au fait cela n'ouvre pas de droit à une baisse tarifaire :-D"
Sinon c quoi Mechanical Türk, comment ça peux m'aider?
[^] # Re: Mechanical Türk
Posté par solsTiCe (site web personnel) . Évalué à 3.
A moins que ça ai changé depuis ?
Ou alors passer par l'intermédiaire de crowdflower.com ?
# À propos de réécriture d'adresse pour lutter contre le backscattering
Posté par llaxe . Évalué à 2.
http://archives.neohapsis.com/archives/postfix/current/0205.(...)
Il oblige à smtp-auth, et veut réécrire toutes les adresses sortantes qui ne sont pas enregistrées comme appartenant à l'identifiant sasl avec l'adresse par défaut compte utilisé pour s'authentifier.
Autrement dit, il veut faire de la réécriture d'adresse sur le même mode que gmail, en laissant la possibilité d'utiliser des adresses alternatives, et en ne refusant sur le mode reject-sender-login-mismatch, ce qui serait trop violent pour ses utilisateurs.
Merci :)
[^] # Re: À propos de réécriture d'adresse pour lutter contre le backscatte
Posté par Chapellon Alexandre . Évalué à 2.
Son but, semble t'il est de faire en sorte que chacun recupere la merde qu'il a genere...
Il parle de backscatter mais a mon sens ce n'est pas vraiment son probleme. Son probleme c'est qu'il emet des mails qui genere des backscatters...(ces serveurs ne devrait pas se faire liste pour ca d'ailleurs)
Les reponses qui lui sont donnees vont toutes plus ou moins dans le sens de "fix the right problem".
En resume, si j'ai bien compris, il souhaite recevoir lui meme les backscatters genere par les serveurs qui recoivent de sa part des truc pourris... Il sait qu'il envoit des choses pas nettes (quel ISP ne le fait pas?) mais il se dit "si les retours n'arrivent que chez moi, personne ne le verra"... bizarre.
Son problemes c'est peut etre tout simplement les serveurs distants qui bounce les pams/virus au lieu de les discard.
Pas sur d'avoir tout pige.. ca me semble un peu flou.
[^] # Re: À propos de réécriture d'adresse pour lutter contre le backscatte
Posté par llaxe . Évalué à 2.
Ce que j'ai compris :
Il est FAI, il est obligé de faire open-relay, et donc accepte de la poubelle. Du coup certains (suffisamment trop) mails qu'il accepte génèrent des bounces, mais il les a acceptés, et se sent obligé d'envoyé un accusé de non-réception à l'adresse d'émission. Seulement dans les adresses d'émission de la poubelle, c'est aussi souvent pas beau à voir, du coup il génère du backscatter.
Et là il se dit: Si jamais toutes les adresses d'envoi des mails que j'accepte sont réécrites avec l'adresse de l'authentifié sauf exception spécifiée, eh ben seuls les expéditeurs de mon réseau qui spamment vont se prendre du backscatter.
Donc oui, il doit avoir affaire à des serveurs distants qui font du filtrage pre queue et bouncent à la fin du date, mais je pense aussi qu'il accepte plein d'adresses indélivrables pour avoir ce problème.
Moi sa solution me paraît une bonne idée. Mais comme je suis pas à la place d'un FAI et que je suis pas omniscient, je sais pas forcément d'avance quels peuvent être les défauts à sa méthode.
[^] # Re: À propos de réécriture d'adresse pour lutter contre le backscatte
Posté par llaxe . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.