Un journal coup de gueule. Vous êtes prévenu, même si je reste calme.
J'habite en Chine (personne n'est parfait) et depuis deux mois mes parents (qui ont leurs emails chez leur FAI, neuf —je vous le répète, personne n'est parfait) ne reçoivent plus mes emails.
J'ai supposé que cela venait du fait que je m'autohéberge, et que ce petit serveur de mail était refusé par neuf… Pourtant si je demande un statut sur la livraison du mail, j'ai bien un retour de neuf indiquant qu'il a été livré dans la boite email de mes parents. Comme il n'y est pas, je leur demande de regarder dans les spams, mais la encore, introuvable. Plusieurs essais ont donné le même résultat. Mes emails sont livrés, et supprimés sans en informer le destinataire.
De passage en Chine, ils ont utilisé depuis chez moi le webmail de Neuf pour lire et envoyer des emails. Et bien plusieurs emails n'ont jamais atteint leurs destinataires (chez Orange entre autres).
Mon autohébergement ne peut plus être incriminé puisque ces emails ne sont pas passés par ce serveur, mais directement sur le webmail de Neuf.
Est-ce que Neuf veut aider les autorités chinoises avec leur grande muraille numérique en empêchant les internautes chinois d'utiliser un outil simple comme l'email ?
Les emails envoyés à d'autres utilisateurs de Neuf sont passés… Veulent-ils que leurs clients n'utilisent que Neuf, ou veulent-ils les pousser ailleurs ? Ou leur vendre un service de mail qui marche après avoir volontairement pourri le service ?
# SPAM
Posté par coïn . Évalué à -10.
en même temps, si moins de spam venait de chine, il n'y aurait pas ce problème.
MORT AUX SPAMS !
[^] # Re: SPAM
Posté par FDF (site web personnel) . Évalué à 9.
Tu justifies qu'un fournisseur de service supprime des emails sans même les mettre dans la boite spam, et ceci à l'insu de l'utilisateur ? Juste pour ne pas avoir de spam, alors que le basculement vers la boite spam suffirait à assurer ta tranquillité.
C'est pour le moins surprenant.
[^] # Re: SPAM
Posté par arnaudus . Évalué à 10.
Certes, mais après avoir posé la question aux admins de mon domaine, il semble que ce que tu reçois dans ta boîte à spams est peanuts par rapport aux gigatonnes de spam triés par liste noire au niveau du serveur mail de l'institution. Moi aussi je trouvais douteux l'idée de te priver d'accéder à l'intégralité de tes messages, mais j'ai l'impression qu'il est facile de sous-estimer l'ampleur du fléau que le spam représenterait s'il n'était pas pré-filtré à plusieurs niveaux.
[^] # Re: SPAM
Posté par Kaane . Évalué à 10.
Tu justifies qu'un fournisseur de service supprime des emails sans même les mettre dans la boite spam, et ceci à l'insu de l'utilisateur ? Juste pour ne pas avoir de spam, alors que le basculement vers la boite spam suffirait à assurer ta tranquillité.
C'est un peu plus compliqué que çà.
Le truc qui ne va pas du tout dans la situation décrite est que les serveurs SFR devraient envoyer une erreur pour signaler que le mail n'a pas été acheminé. Le fait qu'ils acceptent le mail puis le détruisent silencieusement est clairement irresponsable.
Maintenant il existe des clients qui recoivent tellement de spam tous les jours qu'il ne pourraient méccaniquement pas les recevoir avec la bande passante dont ils disposent (et j'ai des clients dans ce cas là). On parle d'hotels, d'agence de voyages ou de services de relations publiques qui ont leurs emails très largement diffusés et qui recoivent plusieurs centaines de milliers de spam par jour. (Sur un domaine je reçois en moyenne plus d'un million de spam par jour, avec des pointes à 2,5 millions - à 3ko le mail en moyenne je vous laisse faire le calcul).
Dans ce genre de cas deux solutions
a) On respecte la nettiquette à fond et on transmet tous les mails - mais alors les boites sont noyées de spam et inutilisables. De plus il faut les vider quotidiennement pour ne pas exploser les quotas (une personne par en vacances et dès le trosième jour sa boite est en erreur)
b) On met en place des blacklists et un système de whitelist/greylist.
Personellement j'utilise la SBL de spamhaus.org exclusivement, parce que il faut vraiment avoir déconné gravement pour se retrouver dessus. Mais j'informe l'emetteur de la raison pour laquelle son mail est refusé. Ca me permet de filtrer près de 90% des spams avec aucun faux positif (les IP dans la SBL n'envoient jamais de mails légitimes - en tout cas en trois ans je n'ai jamais eu une plainte)
Par dessus ça je rajoute une greylist sur certains utilisateurs avec un délai de retry très court (de l'ordre de 5 minutes) mais non annoncé. Donc si un mail "urgent" n'arrive pas, il suffit d'appeler pour demander à ce qu'il soit réenvoyé et le deuxième essai passe toujours. Sinon la plupart des gros fournisseurs réessayent d'acheminer le mail au bout de 10 à 30 minutes, donc le mail arrive en retard certes, mais il arrive dans un délai raisonnable. Avec ces deux systèmes j'arrive à éliminer 97% du spam et j'ai très très peu de problèmes (majoritairement des serveurs exchange mal configurés qui n'essayent pas de réenvoyer les emails au bout d'un certains temps quand ils tombent sur la greylist, ils font 3 essais à 10 secondes d'intervalle avant de baisser les bras.)
Mais je ne mets ce système en place que pour les utilisateurs qui ont des soucis avec le spam et j'explique à mes clients les inconvennients, mais généralement ils sont ravis de ne pas avoir 150 000 nouveaux messages dans leur boite quand ils arrivent le matin. Maintenant il est vrai aussi que je gère un petit millier de boite mail sur une vingtaine de domaines, je ne sais pas si le système scale bien pour plusieurs millions de boites (mais je ne vois pas pourquoi il ne scalerait pas)
[^] # Re: SPAM
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Ben, c'est sûr que si les gens qui veulent t'écrire ne peuvent pas te contacter, t'es pas prêt de recevoir leurs plaintes !
[^] # Re: SPAM
Posté par Hobgoblins Master (Mastodon) . Évalué à 4.
Sauf que d’après les stats publiées régulièrement (et les baisses constatées à chaque fermeture de botnet ou de datacenter), il en vient 2 fois plus des US que de Chine…
[^] # Re: SPAM
Posté par coïn . Évalué à 3.
C'est déjà beaucoup trop.
[^] # Re: SPAM
Posté par hercule_savinien . Évalué à 8.
Et donc, concrètement, tu proposes de blacklister tous les USA ?
Le FN est un parti d'extrême droite
# Autre exemple tout con
Posté par gnumdk (site web personnel) . Évalué à 3.
Je suis abonné à un ml hébergée chez Yahoo…
Je suis abonné avec mon @ gmail mais j'envoie via mon SMTP perso…
Ca n'arrive jamais, je n'ai aucun message d'erreur de la part de yahoo sur la non distribution du mail…
Si je passe par gmail, ca fonctionne :-/
[^] # Re: Autre exemple tout con
Posté par claudex . Évalué à 6.
C'est normal. Google utilise DKMS, ce qui permet d'éviter le spam en signant les mails pour prouver qu'ils sont bien passé par une machine Google et que ce n'est pas un spammer qui utilise une adresse qu'il ne possède pas. Les mails qui sont non-signé alors que les enregistrement dns signalent qu'il est possiblent qu'ils le soient sont potentiellement du spam/phishing. Et comme il n'y a pas de boite à spam sur les listes de diffusion.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Autre exemple tout con
Posté par gnumdk (site web personnel) . Évalué à 2.
Autre exemple, je poste aussi avec mon @ gmail sur un ml liste gmail en passant pas mon serveur SMTP et cela fonctionne sans problème, donc ca fonctionne avec Google…
[^] # Re: Autre exemple tout con
Posté par claudex . Évalué à 3.
Google est moins regardant que Yahoo sur le spam de leur mailing list, ou ils filtrent autrement.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Autre exemple tout con
Posté par Joris Dedieu (site web personnel) . Évalué à 6.
DKIM …
[^] # Re: Autre exemple tout con
Posté par claudex . Évalué à 3.
je confonds toujours /o\
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# C'est pas si simple l'email.
Posté par Raoul Volfoni (site web personnel) . Évalué à 4.
Imagines un peu qu'en fonction de ton résolveur DNS tu ais des machines différentes.
C'est ce que faisait Wanadoo il y a une dizaine d'années. Des smtp internes et d'autres pour les internautes en ballade.
Bref des configs tout à fait différentes aussi…
Alors maintenant avec la généralisation de DKIM et autres SPF et vu que les compétences des admins de ces grands groupes ne se sont pas vraiment améliorées, l'email si tu les gères pas toi-même c'est de plus en plus aléatoire.
[^] # Re: C'est pas si simple l'email.
Posté par SauronDeMordor (site web personnel) . Évalué à 2.
Oui mais quoiqu'il arrive un mail accepté DOIT être délivre.
Si c est un SPAM alors il est traité comme tel
Le mail c'est très simple, pas facile à mettre en place, ou a gérer mais les règles sont simple et dans SMPT il y a simple
[^] # Re: C'est pas si simple l'email.
Posté par claudex . Évalué à 6.
Le problème de dire au spammeur qu'on sait qu'il est un spammeur/phisheur, c'est qu'il change de machine pour spammer. Du coup, ton information pour détecter le spam n'est plus valide. Il est clair que c'est embêtant mais c'est sans doute une des moins mauvaise solution.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est pas si simple l'email.
Posté par GG (site web personnel) . Évalué à 3.
Bonjour,
refuser un spam, c'est lourd, parce que bien souvent, l'e-mail de l'expéditeur est un autre compte à spamer…
Pour le spam, le plus simple et de l'envoyer vers /dev/null et voilà. Éventuellement bloquer la machine expéditrice ou mettre en place d'autres mécanismes.
Tu peux aussi prévenir tes destinataires que tu ne leur envoies plus d'e-mail, parce que la politique anti-spam de leur prestataire est trop simpliste, et taille trop large.
J'ai aussi des contacts, auprès de différents FAI, qui m'envoient du courrier, mais mes réponses ne leur arrivent pas. J'ai le cas avec hotmail, sfr, neuf, parfois Orange/Wanadoo. Après un certain nombre d'échange à sens unique, ça se débloque. Pour hotmail, j'ai créé deux comptes hotmail, et j'ai échangé du courrier entre eux deux avec mon adresse e-mail perso en copie… et ça marche.
A+
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: C'est pas si simple l'email.
Posté par neil . Évalué à 4.
Refuser un spam, ça n'est pas le retourner à l'expéditeur (bien que ça soit souvent fait de façon implicite par le serveur d'envoi), c'est juste répondre un message d'erreur lors de la transaction SMTP. Par exemple
550 5.7.1 <@.>: Sender address rejectedavec SPF.[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 2.
Non.
On ne va pas dépenser 10x plus d'espace disque que nécessaire juste pour te faire plaisir.
Oui, c'est chiant, oui cette solution n'est pas propre, mais non on ne sait pas faire autrement pour le moment sans charger inutilement (pour 99.999% des mails, qui sont des spams) la machine.
Propose une solution qui prenne en compte la charge machine (CPU et disque) avant de dire "DOIT" (non, garder tous les mails n'est pas financièrement acceptable)
Simple pour le protocole de transfert (SMTP, le T veut dire "Transfert", le P à la fin veut dire "Protocol"). Ca n'a absolument rien à voir avec la gestion des mails arrivés, c'est complètement HS comme phrase.
[^] # Re: C'est pas si simple l'email.
Posté par ze_lionix (site web personnel) . Évalué à 2.
Ce n'est pas justement pour cela que le dossier spam a un nettoyage automatique contrairement à l'inbox ? ( genre au bout de 3 semaines le mail est supprimé )
Et que fais tu des faux semblant ?
Tu trouves normal qu'un mail anormalement détecté comme spam ne soit pas livré ?
Encore récemment j'ai eu l'exemple d'un mail contenant un reçu fiscal ô combien important que j'attendais impatiemment… au bout de deux jours j'ai tiqué et suis allé le récupéré dans le répertoire spam !
S'il avait été supprimé je peux te dire que j'aurais gueulé comme un putois sur des innocents !
Le mail DOIT être délivré, et rangé dans spam…
Fuse : j'en Use et Abuse !
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 2.
3 semaines de rétention des milliers de spams de millier de machine chinoises (ou autre), c'est beaucoup, vraiment beaucoup…
En théorie (c'est beau la théorie), ne sont virés que les mails dont on est certains que c'est du spam. Je n'ai jamais dit que tout spam devait être viré.
Bref, en pratique :
- Mail légitime ou léger doute : faire "normalement"
- Mail avec gros doute : mettre dans la boite "spam"
- Mail sûr que c'est un gros spam : silencieusement viré (oui, silencieux, car envoyer un mail à l'expéditeur est juste pourrir une messagerie qui ne t'a rien fait)
Tant que tu ne me résous pas le problème de dimensionnement (réseau, disque, CPU), non, ou tu t'amuses toi-même avec ton serveur qui va se prendre une bonne grosse charge.
Tu l'as reçu, oui. Mail avec gros doute, pas sûr que ce soit un spam, donc pas silencieusement viré. Normal. La, il y a peut-être un problème sur le réglage, mais ça ne remet pas en cause le principe (tant que tu file pas la solution miracle à ce qui fait chier des milliers d'admins moins intelligent que toi qui a la solution…)
[^] # Re: C'est pas si simple l'email.
Posté par arnaudus . Évalué à 4.
[^] # Re: C'est pas si simple l'email.
Posté par Raoul Volfoni (site web personnel) . Évalué à 7.
Accepté ça veut dire quoi pour toi ? L'enveloppe est OK donc tu délivres sans contrôler les en-têtes ? Et ben, joli gaspillage de ressources, je te laisserai pas administrer une de mes machines..
Hahaha, excellent ! T'as jamais du configurer un Sendmail toi…
[^] # Re: C'est pas si simple l'email.
Posté par fearan . Évalué à 5.
chez moi si le serveur sendmail dit qu'il accepte, j'attends de lui qu'il livre le mail. S'il n'en veut pas il répond un code 4 ou 5.
Le code 4 (retry later) bloque généralement plus de 90% des spams venant d'une adresse, et le code 5 100% (mail purement refusé)
Si il répond un code 2 ou 3, je suis en droit de penser que le mail a été transmis. Manquerai plus que lorsque j'aille a une poste pour envoyer un colis, l'hôtesse de caisse me dit oui pas de problème, prenne mon coli pour le benner dès que j'ai le dos tourné.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à -2.
Tu peux attendre ce que tu veux, ça ne change pas qu'il fait ce que lui veux. Normal, c'est son serveur, pas le tiens, c'est l'adresse mail de son client, tu n'es pas son client.
Non : que le mail a été accepté par le serveur. Libre ensuite à lui d'en faire ce qu'il veut.
Mélanger réalité physique et virtuelle n'est pas très probant : tu as déjà eu des paquets dont 999 sur 1000 sont des merdes? L'hôtesse aurait vite fait de les jeter aussi si elle pense que c'est sur que ces des conneries et pas un paquet pour toi. C'est gratuit les colis de la vraie vie?
Perso, je remercie mon hébergeur de mail de faire un minimum de tri, c'est le service que j'attend de lui. Que ceux à qui ça ne plait pas prennent un hébergeur qui vantera de laisser passer les spams (pas sûr qu'il ai beaucoup de succès).
[^] # Re: C'est pas si simple l'email.
Posté par flagos . Évalué à 3. Dernière modification le 16 mai 2012 à 16:35.
A partir du moment où un code d'erreur existe, le serveur destinataire n'a pas a lui mentir en lui retournant un code "OK". C'est assez malhonnete comme attitude, surtout si les code de statut sont clairement spécifiés.
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 0.
Clair que les spammeurs sont honnêtes…
Mais : en quoi est-ce malhonnête? Le serveur dit juste que le mail est transmis correctement, et qu'il va le gérer. Il ne dit pas ce qu'il va en faire, c'est pas tes oignons (il accuse réception du transfert, avec des codes de transfert! SMTP = Transfert Protocol!). Après, c'est plus ton problème (il peut le stocker, le virer, le transférer sur Mars si il en as envie). Si le transfert est OK, il répond OK, point barre. Et avec un spam, ben c'est OK (le transfert).
Vous voulez faire faire à SMTP autre chose que du transfert…
[^] # Re: C'est pas si simple l'email.
Posté par Kaane . Évalué à 3. Dernière modification le 16 mai 2012 à 20:27.
_Si le transfert est OK, il répond OK, point barre. Et avec un spam, ben c'est OK (le transfert).
Vous voulez faire faire à SMTP autre chose que du transfert…_
Nous on s'en fout, mais la RFC est assez claire :
Donc le mail tu l'aimes ou tu l'aimes pas, mais si tu l'aimes pas tu DOIS faire beurk.
De même si un relais et/ou un backup MX accepte le mail et n'arrive pas à le transmetre au bout de quelques jours, il DOIT avertir l'utilisateur qu'il laisse tomber si le reply to: existe.
Donc bloquer le spam oui, mais pas n'importe comment.
[^] # Re: C'est pas si simple l'email.
Posté par Raoul Volfoni (site web personnel) . Évalué à 1.
Perso je ne considère pas que balancer un DISCARD au lieu d'un REJECT à un spammeur c'est faire n'importe quoi (man header_checks pour postfix). Tu économises ta bp et en plus le spammeur est content (enfin son robot) et ne va pas tenter à nouveau de te renvoyer sa merde pendant 3 jours. Maintenant si t'es pas effectivement sur à 100% un REJECT c'est mieux.
[^] # Re: C'est pas si simple l'email.
Posté par Kaane . Évalué à 4.
Perso je ne considère pas que balancer un DISCARD au lieu d'un REJECT à un spammeur c'est faire n'importe quoi (man header_checks pour postfix). Tu économises ta bp et en plus le spammeur est content (enfin son robot) et ne va pas tenter à nouveau de te renvoyer sa merde pendant 3 jours.
C'est contraire à la RFC. Maintenant pour les spammers qui insistent vraiment (et il y en a) j'ai un milter qui va bien : il accepte la connexion, attend vignt neuf secondes pui envoie un caractère par seconde pendant 30 minutes avant de faire un reset. Mais il sert rarement, la plupart des spammers ne réessayent pas, il y a tellement de smtp mal configurés qu'ils ne vont pas perdre de temps avec un serveur qui a une RBL configurée, même déjà un greylist ca repousse la majorité d'entre eux.
[^] # Re: C'est pas si simple l'email.
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
Tu pourrais nous dire lequel ?
[^] # Re: C'est pas si simple l'email.
Posté par Kaane . Évalué à 2.
C'est un poil du fait maison pas très propre. Mais si ca interresse vraiment du monde, je peux tenter de nettoyer le code et de le rendre un peu plus user friendly.
[^] # Re: C'est pas si simple l'email.
Posté par Rémi Laurent (site web personnel) . Évalué à 2.
Merci,
en lisant le fil j'avais en même temps l'envie et la flemme de trouver la RFC qui mettrait les points sur les "i"; merci donc de la fournir et par la même occasion enfin craquer l'allumette destinée à flamber tous ces admins hérétiques qui configurent leur MX pour accepter du mail et ensuite le jeter vers /dev/null …
Ayant déjà rencontré de pareilles situations et de pareils interlocuteurs dans le cadre de mon boulot, je ne peux que me délecter de ces quelques lignes de RFC
hérétiiiiques, comme dirait l'autre
[^] # Re: C'est pas si simple l'email.
Posté par 2PetitsVerres . Évalué à 4.
Sauf que comme ils répondent pareil aux spammeurs et aux non spammeurs, ça fait des réponses malhonnêtes à des non spammeurs honnêtes.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: C'est pas si simple l'email.
Posté par fearan . Évalué à 3.
Il y a un protocole, et des codes retours. Si on peut dialoguer sur internet, c'est justement parce que les serveurs ne font pas ce qu'ils veulent mais respectent les protocoles. On a tendance à râler ici lorsqu'un site affiche ie6 only, ou utilise des hack immondes et ne passe que sous certains navigateur, c'est a peut près le même genre de problème.
Lorsqu'il ne veut pas s'occuper d'un courrier suspect, il peut très bien dire j'en veut pas. Là il faut oui oui, ok, pas de problème avant de le jeter.
Tiens cadeau la RFC
Lorsqu'il répond 2, il indique clairement que c'est fait, et requested action c'est pas 'fout le dans /dev/null'
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est pas si simple l'email.
Posté par flagos . Évalué à 3.
Je donne le lien vers la RFC si ca interesse des gens. lien . Moi j'avoue la, j'arrive pas a voir si le contexte de cette spec s'applique bien a du spam, ca me saute pas aux yeux quoi…
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à -2.
Et si il l'envoie sur Mars, il répond un code précis?
Il répond 2 car il a fait ce que… "The requested action has been successfully completed"!
Ben oui. L'action est de filer le mail au serveur, c'est fait. Après, le serveur fait ce qu'il veut, ne t'en déplaise.
Foutre dans le user agent de l'utilisateur ou dans /dev/null ou ailleurs, ce n'est pas le problème de SMTP!
Tu as ta traduction bizarre de la RFC, fait-toi plaisir, les autres font ce que dis la RFC (répondre 2yz quand le mail est bien traité et ils en font ce qu'ils veulent après)
[^] # Re: C'est pas si simple l'email.
Posté par fearan . Évalué à 4.
bon ben si faut tout te prémâcher
Je ne sais pas comment tu gères tes contrats, mais si tu es d'aussi mauvaise foi face à tes client je ne suis pas certain qu'il reviennent.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à -1.
Il a été délivré (et automatiquement mis dans dev/null)
J'imagine que tu engueules de la même manière le SMTP qui forwarde le mail car ce con n'aurait pas délivré le message exactement vers le destinataire? N’importe quoi, je n'y peux rien si tu lis les RFC comme ça t'arrange.
Mes clients (si j'étais fournisseur de mail) sont contents de ne pas télécharger 1 Go de spam quand ils se connectent, pour mettre 2 heures avant de pouvoir lire leur mails légitimes. Ils sont content que je ne sois pas un bourrin avec des principes inadaptés à la réalité.
Désolé, mais mes clients me demandent de réfléchir un peu, et son contents que je n'applique pas bêtement une RFC et leur pourri ainsi la vie. Désolé, mais perso je n'aimerai pas être ton employeur si tu as des principes tels que les conséquences sont de faire fuir les clients. Perso, je ne suis pas sûr que tes clients reviennent avec une prestation aussi pourrie que de balancer tous les spams.
[^] # Re: C'est pas si simple l'email.
Posté par fearan . Évalué à 2.
Mais je ne t'interdis pas de refuser des mails! Et je n'ai jamais prétendu qu'il fallait tout relayer.
Je trouve anormal de dire ok j'ai livré le mail, et le jeter ensuite. Le serveur peut très bien renvoyer un code 5.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à -1.
Ce n'est pas le rôle du code 5 que je lis. Encore une fois, le transfert est bon (donc code 2). T de SMTP.
[^] # Re: C'est pas si simple l'email.
Posté par Batchyx . Évalué à 1.
C'est bizarre, je croyait que c'était TCP qui était chargé du transport …
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 0.
Euh… Sérieux? A quoi correspond le T de SMTP d'après toi?
TCP = transport des octets
SMTP = transport du contenu
L'un utilise l'autre.
[^] # Re: C'est pas si simple l'email.
Posté par flagos . Évalué à 4.
Et justement le M de SMTP il signifie quoi ?
On parle bien d'un transfert de mail. Le transport tel que tu le limite aux octets, c'est bien le role de TCP ca pour le coup.
Donc au final, ca en devient assez logique:
- Avec TCP, on s'assure que les paquets sont bien arrives
- Avec SMTP, on s'assure que le mail est bien accepté (=> interprétation des octets recus par la couche transport)
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 18 mai 2012 à 07:47.
Je traduis peut-être mal, mais un serveur SMTP qui trashe le mail qui est pourri s'est bien assuré qu le mail est bien accepté et donc une réponse 2 est valide.
Tout comme il répond 2 si il fait un forward derrière…
Bref, il répond qu'il prend en charge le mail, ce qu'il fait, pas d'erreur (il obéit à son patron ensuite pour savoir qu'en faire)
[^] # Re: C'est pas si simple l'email.
Posté par Batchyx . Évalué à 3. Dernière modification le 18 mai 2012 à 22:11.
SMTP n'est pas un protocole de transport de contenu. Tu n'a pas besoin de protocole au dessus de TCP pour transporter du contenu, un netcat suffit largement (Si tu veut simplement transférer des octets, n'utilise pas TCP).
SMTP est un protocole transactionnel qui garanti le transfert de responsabilité de la livraison du message entre différents serveurs. Pour que ça marche, il faut bien entendu que à tout instant, les protagonistes aient la même vision de la transaction. Les codes de réponses SMTP ne servent pas à dire si le transfert est bon ou pas (TCP est largement suffisant. Si le serveur arrive au point ou il doit envoyer le code de réponse, c'est que le transfert est forcément bon), mais à indiquer l'état de la transaction.
Si tu peux/veux pas commiter et que tu dit que le commit est bon, t'est juste en train de casser la transaction et de rendre le système incohérent. Si ça te fait plaisir de faire ton byzantin, il faudra pas s'étonner que les autres arrêtent de te causer, et il faudra accepter que les autres fassent leur byzantin quand tu leur envoie des messages. Si tu trouve ça normal, alors rappelle moi de ne jamais te confier un réseau ou tout autre système distribué.
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à -1.
Et donc, quand l'anti-spam de l'utilisateur efface le mail, il faudrait aussi avertir l'autre… Bizarrement, personne ne le fait.
Tu n'as pas répondu au problème d'informer que le SMTP fait un forward plutôt (qui est pareil que mettre dans /dev/nul, sauf que c'est un autre path)
Je ne vois pas en quoi la transaction est cassée : la réponse est "OK, je m'en occupe", et c'est vrai.
Idem. Ca dépend vraiment du point de vue… Mais pour moi hors de question de perdre des ressources à informer un spammeur qu'on l'a détecté. Rappel : on parle de mails dont on est sûr que c'est du spam. Et personnellement, je remercie mon hébergeur de mail de penser comme moi plutôt que de me polluer avec des spams que je devrais traiter avec mon client mail.
En fait, il y a la belle théorie (tout le monde est gentil) et la pratique (tout le monde file vers /dev/nul ces merdes et n'avertissent pas, ça en fait du monde à qui tu ne confie pas ton réseau qui stocke du spam)
[^] # Re: C'est pas si simple l'email.
Posté par fearan . Évalué à 3.
Gni??? Le posteur du journal se plains justement que ses mails sont refusés. A moins de le traiter de spammeur ce que tu dis est faux.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à -1. Dernière modification le 19 mai 2012 à 07:59.
Il y a un problème effectivement avec son mail. Ca ne fait pas qu'on jette tout ce qui est fait pour lutter contre le spam.
C'est juste du réglage. Encore une fois, après si pour ce "loupé", vous voulez garder tous les spams, vous pouvez chercher un hébergeur (ou faire vous-même) un truc qui coûte plus cher qui garde tout. Après le réceptionnaire peut faire un effort pour ceux dont il y a un doute, oui, et c'est fait (pas tout noir ou blanc). Juste que les hébergeurs normaux continueront à faire ce tri, et que les utilisateurs normaux en seront toujours contents.
[^] # Re: C'est pas si simple l'email.
Posté par Batchyx . Évalué à 2.
Hors sujet: L'utilisateur (ou son antispam) n'efface pas son mail avec SMTP.
Et si il efface le mail, c'est son problème. Du point de vue du protocole, il à reçu le message, et il ne peut affirmer le contraire.
Mais si tu répond que tu accepte d'assumer la responsabilité de transmettre le mail jusqu'à son destinataire mais que tu jette le mail, tu est juste malhonnête. Et tu casse la transaction, puisqu'il n'y à plus personne pour s'assurer que le mail soit transmis.
la RFC ne prévoit pas que tu puisse choisir ton point de vue comme tu en a envie. Si tu n'est pas d'accord avec la RFC, alors utilise un autre protocole et vire ton MX et ton serveur SMTP.
Tu n'a rien détecté du tout, tu ne fait que des suppositions vagues. SMTP ne standardise aucun moyen pour détecter le spam, et encore moins de valider la transaction tout en jetant le mail, même si ta méthode foireuse est soit disant sure à 100%. Tout ce que tu fait n'est autre qu'une violation du protocole.
En plus, ça te coûterai moins cher de répondre un 542 Zenitram hates you avant même que tu reçoivent le mail plutôt que de gaspiller la capacité de ton lien pour recevoir de la merde.
[^] # Re: C'est pas si simple l'email.
Posté par GaMa (site web personnel) . Évalué à 2.
Pour moi, ça veut dire "t’inquiète je gère. T'as fait le boulot comme il faut"
"it accepts responsibility for" != "it WILL do one of :"
Après je suis d'accord avec toi, c'est un peu osé de virer des messages directement sans avertissement (même si je comprend les raisons techniques). C'est au client du serveur de pousser une gueulante, mais smtp est respecté.
Le postier n'est pas concerné par le fait que ta boite aux lettres soit en fait une poubelle. Il a mit la lettre dans la boite aux lettres qui va bien, terminé!
De la même façon, si tu pars en vacance et que ta boite se remplie, le postier peut plus mettre la lettre dans la boite => message d'erreur. (et que ce soit du courrier légitime ou du spam, rien a f***)
Matthieu Gautier|irc:starmad
[^] # Re: C'est pas si simple l'email.
Posté par Buf (Mastodon) . Évalué à 5.
On est clairement ici dans un cas couvert par le troisième point (le serveur SMTP l'a accepté, mais il ne peut pas le déposer dans la boite du destinataire parce qu'un antispam l'en empêche), il faudrait donc envoyer une notification à l'expéditeur.
Problème : on a quasiment 100% de chances que l'adresse de l'expéditeur soit fausse. Envoyer une notification n'est donc pas seulement inutile, ça contribuerait également à amplifier le problème du spam. Du coup, personne ne le fait. C'est clairement contraire à la RFC, mais on est dans un cas où respecter la RFC causerait une nuisance grave à plein de monde.
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 0.
C'est peut-être une impression, mais tout le monde étant en phase la dessus, personne ne s’embête à modifier le petit point de vocabulaire d'une RFC qu'on pourrait considérer "pas top" aujourd'hui. Perso, je ne suis même pas sûr que ce soit "contraire" à la RFC (ça dépend comment on la lit non?)
En tous cas, non, je ne veux pas recevoir les mails "vous avez envoyé un spam/virus", le premier serveur qui (re)fait ça est catalogué direct comme spammeur (car il me spamme, je n'ai pas envoyé le virus, je lui ai rien demandé)
[^] # Re: C'est pas si simple l'email.
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
Il y a plusieurs phases dans la réception d'un email. Tu peux très bien accepter le DATA suite à un EHLO et un FROM d'une machine correctement configurée (ce qu'on appelle l'enveloppe) puis tout balancer après des entêtes toutes pourries.
Je ne vois franchement pas l'intérêt de gaspiller de la bande passante et de l'espace disque. Mais bon, tant qu'on respecte les RFC chacun configure ses MX comme il veut hein.
[^] # Re: C'est pas si simple l'email.
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Ben s'il y a une bombe dans le colis j'espère qu'elle va pas le livrer…
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 0.
fearan s'attend à ce que si, elle file la bombe dans le colis même en sachant que c'est un bombe, c'est clair c'est son boulot de livrer, elle n'a pas le droit de ne pas livrer (c'est fearan qui le dit, je n'y peux rien, c'est sa prose, l’hôtesse doit livrer TOUT).
Bref, c'est du n'importe quoi, mais il y en a qui aiment critiquer le boulot des autres sans faire attention aux impacts…
[^] # Re: C'est pas si simple l'email.
Posté par fearan . Évalué à 1.
Non j'espère surtout qu'elle ne prétendra pas l'avoir livré. Qu'elle le jette, c'est tout à fait acceptable; quelle le jette en m'envoyant une notification comme quoi c'est ok, ça c'est pas normal.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 1.
Au bout du millionième dossier de "bombe" remplie, le client lui dira qu'elle a autre chose à foutre et qu'elle le vire le colis et puis c'est tout.
Encore une fois : ce n'est pas ton problème. Le colis est arrivé, après qui fait le tri n'est pas tes oignons.
[^] # Re: C'est pas si simple l'email.
Posté par Raoul Volfoni (site web personnel) . Évalué à 1.
Donc tu proposes de prévenir les spammeurs avec un code de rejet sur l'analyse des entêtes ??? C'est ton choix mais pour moi c'est clairement du gaspillage de ressources (CPU et bande passante) et je ne crois pas qu'un seul FAI agirai de la sorte.
[^] # Re: C'est pas si simple l'email.
Posté par GaMa (site web personnel) . Évalué à 4.
En même temps l’hôtesse c'est TON serveur smtp. Encore heureux qu'il te dise oui et qu'il l'envoie.
Le serveur smtp du destinataire, c'est sa concierge. Si le mec demande à sa concierge de jeter les prospectus publicitaire et qu'elle se plante et jette tes colis, c'est leur problème pas le tien.
Matthieu Gautier|irc:starmad
[^] # Re: C'est pas si simple l'email.
Posté par fearan . Évalué à 2.
tu confonds le concierge avec l'antispam.
Le dernier relai c'est le postier, et s'il ne le met pas dans la boite au lettre parce qu'elle vient de chine, crois moi, si ça se sait, il restera pas en poste. Tout comme la concierge qui se prendra une avoinée le jour où l'habitant va la voir jeter ses lettre légitimes sous prétexte qu'elle viennent d'Algérie.
Moi j'ai pas demandé à mon fournisseur de mal de faire le tri à ma place.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 2.
Tu confonds bien spam et colis.
Non, il ne confond pas : tu te mêles des affaires des autres (le destinataire de ton mail, qui a autre chose à foutre que de stocker des millions de spams, et c'est sa concierge, pas la tienne)
Change de fournisseur de mail si ça ne te plait pas. Mais va falloir chercher ou le faire toi-même, parce que quasi-personne ne fait ce que tu as envie. faut dire que c'est de la dépense inutile aussi.
[^] # Re: C'est pas si simple l'email.
Posté par jyes . Évalué à 1.
En fait non, car en pratique en auto-hébergement (au sens de s’héberger soi-même, je t’épargne ta diatribe sur le courriel sur ADSL que je connais déjà très bien), le problème du spam est incomparable avec celui des gros hébergeurs. Sur mon serveur qui tourne depuis plusieurs années, les RBL et le greylisting sont pour le moment cosmétiques car au regard des logs du serveur les tentatives de spam restent vraiment très rares (je vois surtout des tentatives d’envois pour l’utiliser comme open-relay, ce qu’il n’est évidemment pas). C’est vrai que c’est un tout petit serveur, mais il reste de la marge avant que ces méthodes antispam les plus simples soient dépassées.
En fait, la dépense inutile c’est de centraliser l’hébergement des courriels du monde entier sur quelques gros domaines qui peuvent alors être massivement spammés et nécessitent des règles de filtrage de plus en plus complexes pour isoler le pouillème de courrier légitime qu’ils reçoivent.
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 1.
C'est sûr, c'est tellement mieux de dépenser du temps (ou de l'argent) en administration de machine… Les gens ont autre chose à faire que de dépenser de du temps ou de l'argent comme ça.
Désolé, mais non, ce n'est pas quelque chose de faisable à l'echelle de l'être humain normal. La dépense est loin d'être inutile, elle est même moins dépensière.
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 1.
Non, car tous les habitants de l'immeuble à part toi sont bien contents qu'il fasse ce boulot. Et ce concierge n'a pas envie de se faire chier à conserver tes données (son logement est trop petit pour les conteneurs entiers, donc à part si tu lui offre un 200 m2…) ni même te mémoriser que toi tu veux pas faire comme ça.
Et comme on est pas dans un immeuble, tu es même libre de déménager virtuellement si tu n'es pas content.
Met-toi ça bien dans le crâne : quasi-tout le monde est très content du comportement de ce concierge que tu engueules. Offres-lui un 200m2, et il sera sans doute heureux de faire une exception pour toi, en attendant le 200m2 ben… Tu fais comme les autres.
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 1.
Je n'arrivais pas à trouver la bonne réponse à ce genre d'exemple, merci beaucoup.
J'ai l'impression que les gens veulent toujours imposer aux autres ce qu'ils pensent être bon, même quand ce n'est pas à eux de décider.
Dans le même genre, Un mec voulait imposer aux autres sa gestion d'un serveur SSH. On critique la religion qui fait du prosélytisme et voudrait t'imposer sa façon de voir, mais la c'est pareil, il y a des gens qui veulent imposer une sertaines config à des serveurs dont ils n'ont aucunement la responsabilité et aucun contrat avec l'admin à ce sujet (c'est le destinataire qui a le contrat, pas l'envoyeur).
[^] # Re: C'est pas si simple l'email.
Posté par Buf (Mastodon) . Évalué à 7.
En général (en tout cas sur les grosses infrastructures), ce n'est pas le serveur SMTP lui-même qui délivre le courrier dans la boite de l'utilisateur. Donc on peut très bien se trouver dans une situation où le SMTP visible sur Internet va accepter le message (il voit passer de tels volumes qu'il ne peut pas se permettre de faire plus que quelques vérifications très sommaires), puis va essayer de le transmettre plus loin, à un serveur qui aura les ressources nécessaires pour faire une analyse plus poussée, où le message pourra être rejeté. Oups, trop tard pour envoyer un 4xx ou 5xx au client initial…
La pratique correcte serait d'envoyer une notification à l'expéditeur pour lui signaler que son message n'a pas été délivré, mais vu que dans plus de 90% des cas, ça sera du spam avec une adresse expéditeur fausse, on ne le fait pas (ça se faisait il y a quelques années, mais vu le pourcentage de spam actuel, c'est complètement irresponsable aujourd'hui)
[^] # Re: C'est pas si simple l'email.
Posté par SauronDeMordor (site web personnel) . Évalué à 1.
bah si je gère des sendmail depuis 1995 donc je connais assez bien comment ça marche.
milter aussi. pour les refus cela sse fait a la connexion du serveur via des RBL, ou bien par des milter (SPF,DKIM,spamassassin,greylist,…)
pour le protocole smtp je te renvois ver la rfc.
accepter un mail ca veut dire quelque chose, comme le refuser, bounce et autre vocabulaire lié au mail.
accepter un mail ne veut pas dire que ton lecteur de mail l accepte. mais peut être manque tu encore un peu d expérience dans le domaine.
[^] # Re: C'est pas si simple l'email.
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
On dirait pas.
T'es mal tombé pour faire le mariole vu que j'ai 2 décennies d'expérience de plus que toi…
[^] # Re: C'est pas si simple l'email.
Posté par Zenitram (site web personnel) . Évalué à 2.
Ce n'est pas vraiment un argument. 2 décennies avant 1995, il n'y avait pas vraiment de spam à l'horizon, pas du tout les mêmes problématiques.
[^] # Re: C'est pas si simple l'email.
Posté par Juke (site web personnel) . Évalué à 5.
Qui a la plus grosse ?
# Ma vie: pas spécifique à Neuf / à la Chine
Posté par Sylvain Briole (site web personnel) . Évalué à 5.
J'ai régulièrement ce problème avec mes destinataires @free.fr avec des emails en provenance de serveurs de T-Online (un gros et très officiel FAI allemand), pourtant serveurs discutant en SSL/TLS dédiés à l'envois d'emails depuis la plateforme Web du FAI (et donc nécessitant la souscription d'un compte tout ce qu'il y a de plus officiel chez le FAI…: pas vraiment adapté aux pollueurs à grande échelle).
Au bout d'une semaine, je recois un message que l'email n'a pas été délivré, le serveur ayant été mis sur liste noire. Cela dure généralement quelques jours, puis je suis tranquille pour 3 mois.
La seule solution trouvée jusqu'alors pour garantir l'envoi/réception d'emails que je juge importants: utiliser les services de free.fr pour envoyer un email à free.fr, ceux de t-online.de pour envoyer un email à t-online.de, ….
Une sorte de Email 2.0 à la sauce Facebook: ne pas sortir du réseau pour pouvoir communiquer.
[^] # Re: Ma vie: pas spécifique à Neuf / à la Chine
Posté par Zenitram (site web personnel) . Évalué à 1.
Je te rassure, pas la peine d'être chez T-Online. Mon SMTP est celui d'OVH (on va dire que c'est pas une toute petite boite de merde qui gère 3 emails par jour), et il m'est déjà arrivé d'avoir le serveur SMTP d'OVH blacklisté par Free. Fort quand même. Seule solution dans la réponse d'OVH à mon ticket : attendre que Free veuille bien les retirer, 10 heures plus tard (de grosse entreprise française à grosse entreprise française!)
Free, ils frappent un peu fort…
[^] # Re: Ma vie: pas spécifique à Neuf / à la Chine
Posté par Sylvain Briole (site web personnel) . Évalué à 1.
Même expérience, en comptant en plus qu'utilisateur lambda de T-Online (comprendre, client privé), le ticket mettra au mini 48h pour être traité par T-Online. Le temps qu'ils comprennent de quoi il en retourne (envoi à la personne compétente pour discuter serveur d'emails), le/les serveurs de T-Online auront été retirés de la liste noire….
Depuis ces épisodes (récents: cela a commencé il y 2 ans environ), je n'ai plus du tout confiance dans l'email (je ne connaissais cela que qd. j'étais auto-hébergé avec une belle adresse @monserveur.dyndns.org).
[^] # Re: Ma vie: pas spécifique à Neuf / à la Chine
Posté par GG (site web personnel) . Évalué à 2.
Bonjour,
cela me fait penser qu'une fois l'hébergeur Lautre.net s'est fait blacklister parce qu'un membre renvoyait (avec son logiciel mail) automatiquement tout le spam qu'il recevait de son compte chez Lautre.net vers un de ses e-mail chez Free.fr
Les admin-sys de Free a bloqué Lautre.net parce qu'il avait mal regardé les en-têtes… ça arrive parfois. Cette fois-là, il a fallu plus d'une semaine (je crois).
A +
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Ma vie: pas spécifique à Neuf / à la Chine
Posté par hercule_savinien . Évalué à 4.
Hello,
Ça m'est arrivé aussi.
Je suis contactable par une adresse associative a forte audience.
L'email de contact est publique et largement publié.
Il n'est pas rare de recevoir des dizaines ou des centaines de spams par jour.
Au tout début, il n'en était rien, c'est venu petit à petit (mais très vite quand même).
Au bout d'un moment, free a tout simplement décrété que les serveurs mails de l'asso étaient de vilains spameurs.
Depuis je reçois mes mails directement sur mon serveur à moi et c'est paradoxalement plus simple.
Le FN est un parti d'extrême droite
[^] # Re: Ma vie: pas spécifique à Neuf / à la Chine
Posté par fearan . Évalué à 0. Dernière modification le 18 mai 2012 à 22:46.
je vois pas pourquoi tu te plais, selon toi, ils ont fait leur job, ils ont livré ton courrier dans /dev/null
Note bien eux pensent à te prévenir.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Spam chinois
Posté par Grunt . Évalué à 10.
Je vais te parler de la Chine, du point de vue d'un utilisateur et administrateur d'un serveur mail auto-hébergé qui n'héberge qu'un seul compte mail : le mien.
Au début, j'ai installé un postfix avec une config de base pour mon domaine, et mis aucun filtre antispam. J'ai attendu de voir à quoi ressemblait le spam que je recevrai (et qui avait toutes les chances d'être différent de celui envoyé, par exemple, à une adresse @gmail.com), afin de mettre en place les contre-mesures appropriées.
Plus de la moitié de la merde que j'ai reçue venait de Chine. Des spams totalement génériques (viagra, grosse bite), parfois rédigés en anglais voire en chinois.
J'ai commencé par contacter systématiquement l'adresse abuse liée à l'@IP émettrice. Ce qui est bien avec un serveur mail que je gère, c'est que je suis certain que l'IP d'origine n'a pas été falsifiée :)
Hé bien, absolument aucun FAI chinois ne m'a répondu. Aucun. Alors qu'ils sont (et même en tenant compte de la taille respectable de la Chine) la plus grosse cause de spam, en tout cas pour moi.
Du coup, j'ai blacklisté les @IP chinoises à chaque nouveau spam reçu.
Ensuite, dans un genre similaire, il y a eu du spam envoyé depuis l'Afrique, l'Amérique du Sud.. et là, pareil : abuse@ n'en a rien à branler. Donc, blacklistage des @IP.
Il y a également le spam franco-français, envoyé pour le compte de margoulins aussi divers que : SFR, France Créance, MSC Croisières, OPUS Développement.. alors que je n'ai jamais inscrit cette adresse mail sur un quelconque service commercial et jamais donné d'accord pour recevoir leur prospection.
J'ai commencé par contacter abuse : on tombe sur une plateforme de prospection, qui répond poliment qu'ils ne font que relayer des mails et qu'il faut voir avec leur client pour être retiré des listes. Un joli montage technico-juridique pour protéger ces margoulins. Du coup, blacklistage des plateformes de prospection.
Il y a également les hébergeurs à Kevin, particulièrement OVH : Kevin loue un dédié chez OVH, le dédié spamme (soit parce que Kevin l'a administré comme un manche, soit parce que Kevin se lance dans le spam), et OVH laisse faire et ne répond pas à abuse@
Plus intéressant, j'ai reçu trois spams envoyés par des abonnés résidentiels français : un Orange pro, un Free, et un Numericable.
Ni Orange ni Free n'ont répondu quand j'ai signalé le mail sur abuse@. Même pas un accusé de réception pour dire "ouais, on va s'en occuper". Toutefois un seul spam a été envoyé dans chaque cas, ce qui m'incite à penser que les spammeurs sont traqués et pourchassés chez ces FAI.
Numericable a pris la peine de répondre, mais la réponse est à côté de la plaque : j'ai demandé un droit d'accès et de rectification sur les données personnelles (mon adresse mail) traitées par leur client, ils ont répondu comme si c'était eux qui stockaient ces données. Ben non andouilles, c'est votre client, et vu que vous êtes mon seul point de contact avec lui c'est à vous que je m'adresse…
Globalement, les FAI, les hébergeurs n'en ont rien à branler des spammeurs. En Chine c'est énorme, parce que non seulement ils s'en foutent, mais en plus ils ne font rien pour limiter le volume.
Du coup, je pense que tu devrais voir la question avec un peu de recul, et te demander d'abord : le FAI que j'ai choisi pour me connecter à Internet, est-ce que c'est un gros connard qui protège les spammeurs, ou bien est-ce qu'il fait preuve de respect envers les autres internautes ?
Si tu choisis de passer par un FAI qui attribue des @IP dynamiques (compliquant le travail de blacklistage), qui n'inquiète pas ses clients spammeurs, et qui ne répond pas à abuse, c'est un peu logique que tu sois bloqué de partout : tu ne fournis aucun moyen de faire la différence entre le mail que tu envoies et une saleté de spam.
Avec FDN, je suis tranquille : je sais que si quelqu'un vient se plaindre à FDN d'un abonné qui spamme, l'abonné sera notifié. Je sais que si je me mets à emmerder tout Internet en envoyant du spam, on me tiendra tout de suite au courant et je prendrai les dispositions nécessaires (et présenterai mes excuses les plus confuses). Et c'est aussi ce que j'aime chez FDN. À mon sens, un grand pouvoir implique de grandes responsabilités. Le grand pouvoir d'envoyer des mails à tout le monde sans être blacklisté, sans se voir imposer le serveur SMTP du FAI, devrait impliquer d'être responsable si on envoie du spam aux gens.
Alors, je sais, y'a une aberration culturelle sur Internet qui veut que ce soit à la victime de se protéger, en gaspillant du CPU et de la RAM pour filtrer le spam qu'elle reçoit. C'est un point de vue, mais je ne suis pas certain que ceux qui le soutiennent se rendent compte de ce qu'il implique vraiment. Ça signifie que, si je reçois un spam d'un internaute français, je peux tenter de retrouver son adresse et lui péter la gueule à coup de batte : après tout, si j'avais qu'à mettre un antispam pour me protéger de son spam, il avait qu'à mettre un casque pour se protéger de la batte.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Spam chinois
Posté par Raoul Volfoni (site web personnel) . Évalué à 5.
Ton message me donne une idée: y a-t-il ici des personnes intéressées pour créer et maintenir une RBL franco-française de tous ces connards ?
[^] # Re: Spam chinois
Posté par Grunt . Évalué à 6.
Faudrait éviter de réinventer la roue. Y'a http://spam-rbl.fr/ qui est pas mal, avec le seul défaut de lister les @IP résidentielles (ouf, FDN n'est pas dedans). On pourrait peut-être filer un coup de main à son auteur ?
En tout cas je serais intéressé, oui. On pourrait aussi imaginer une "anti RBL" à base de whitelistage, je trouverais l'idée sympa : des gens qui s'engagent à ne pas spammer, à respecter un certain nombre de pré-requis (réponse sur abuse@, moyen de contact disponible sur le serveur..) et seraient sur une liste blanche de confiance :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Spam chinois
Posté par Larry Cow . Évalué à 4.
C'est un tout petit peu rédhibitoire, non?
J'aime beaucoup, même si c'est du boulot. Une structure associative pourrait-elle gérer ce genre de choses? Avec si possible un volet pédagogique.
En tous cas, si quelqu'un se lance, comptez-moi.
[^] # Re: Spam chinois
Posté par GaMa (site web personnel) . Évalué à 1.
Dans le même genre, au sujet des antispams collaboratifs, les antispams classiques (que je connait) sont les filtres bayésiens. Ces filtres fonctionnent sur une base d'apprentissage qui se complète à chaque fois qu'on classe un mail dans spam (ou son contraire).
Gmail a un antispams qui fonctionne plutôt bien (voir très bien). Je ne sais pas si il utilise des filtres bayésiens mais si c'est le cas, je pense que la quantité de mail qu'il analyse doit aider à avoir une base d'apprentissage qui dépote.
Je me demandais donc si il serait possible de faire (ou qu'il existe déjà) une bdd collaborative qui serait mis à jour avec les info des milliers (voir millions) de classements manuels de mail/spam journalier.
Ça permettrait d'avoir un filtre antispams sur son pc client (ou serveur) grandement efficace, et ce, sans attendre que la bdd soit suffisamment fournie.
Matthieu Gautier|irc:starmad
[^] # Re: Spam chinois
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
Non ça n'existe pas pour la bonne raison que ce que tu considère comme un spam est peut-être un courrier légitime pour quelqu'un d'autre.
Mais si tu veux je dois avoir un bon To de Spams dont les 1ers datent de 95 (l'année pas l'os hein ;)
[^] # Re: Spam chinois
Posté par Grunt . Évalué à 3.
Oui, mais cette liste est optionnelle. Leur RBL propose plusieurs filtres, tu peux décider de ne pas filtrer les @IP résidentielles. Le seul pb c'est qu'elles ne sont pas discriminées : si tu signales à cette RBL une @IP résidentielle précise qui spamme, le service te répond que, de toute façon, c'est une @IP résidentielle, donc t'as qu'à l'ajouter à tes filtres.
D'un autre côté, ça peut se comprendre : à ma connaissance, aucun FAI ne fournit de moyen de savoir si leurs @IP sont attribuées de façon dynamiques ou pas, ni de savoir si une de leur @IP a été affectée à un autre abonné. Du coup, prétendre tenir à jour une liste des spammeurs résidentiels ressemble à une mission impossible :(
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Spam chinois
Posté par Raoul Volfoni (site web personnel) . Évalué à 5.
Merci, je ne connaissais pas cette rbl.
Un truc comme ça ?
http://www.dnswl.org/
J'aime bien les discussions constructives… ;)
[^] # Re: Spam chinois
Posté par Psychofox (Mastodon) . Évalué à 1.
En même temps, à moins que le monde entier soit en ipv6, ils sont bien obligés de fournir de l'ipv4 dynamique.
[^] # Re: Spam chinois
Posté par Grunt . Évalué à 4.
J'ai pas compris le rapport.. et les @IPv4 sont fixes chez FDN :)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Spam chinois
Posté par Kaane . Évalué à 9.
Le gros gros problemes des abuse@ …
Sur mes petits serveurs j'ai aussi plusieurs abuse@, mais bon
a) L'imense majorité de ce que je reçois sur ces adresses sont des spams. Toutes les adresses "publiques" sont noyées de spam, sans distinction - et abuse ne coupe pas à la règle. Postmaster prend cher aussi.
b) Sur ce qu'il reste (très très peu) la plupart sont pour se plaindre de mails que je n'ai jamais envoyés, de la même façon que toutes les adresses mails publiques sont spammées, toutes les adresses mails publiques sont aussi massivement utilisées dans les reply-to: et autres from: des spams. Donc la personne qui reçoit ces mails se plaint au mauvais abuse.
c) Une petite partie est envoyée par des spammeurs qui trouvent intolérables que je refuse leurs mails et qui me menacent de différentes choses, allant du procès à l'attaque par déni de service en passant par un bon vieux cassage de genoux à la barre à mine.
d) les 4 mails qui restent (sur un peu plus 50 000) étaient effectivement des abus qui m'ont obligé à tirer les oreilles de mes clients.
Si c'est pareil chez les gros FAI ca doit juste être ingérable et je comprend que les abuse ne soient pas pris en compte au final. Je sais que Google et OVH ont une interface pour les plaintes qui oblige à donner tout le source du message pour faire une requète abuse, mais c'est loin d'être installé partout et ca demande un peu trop de technique pour que madame Michu s'en serve sereinement.
[^] # Re: Spam chinois
Posté par jms . Évalué à 2.
Tiens, penses-tu que ceci puisse être une bonne idée ?
Lors du "rcpt to" abuse@, le serveur refuse l'email avec
une erreur 5xx et un message: "pour les plaintes, passez
par http://plainte.example.com", site proposant un formulaire,
etc.
Ceci pourrait filtrer pas mal les spams sur les abuse@, mais
va à l'encontre des rfc et de la nétiquette (ça existe encore
ça ?)
[^] # Re: Spam chinois
Posté par Grunt . Évalué à 2.
Ne pas répondre également. Et ta solution est moins pire qu'une absence de réponse.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Spam chinois
Posté par ribwund . Évalué à 3.
Ça donne envie de s'autohéberger…
[^] # Re: Spam chinois
Posté par Grunt . Évalué à 10.
Ben oui, ça permet de se rendre compte de la réalité des choses. De sortir un peu de l'attitude "boarf, le spam c'est pas si méchant" des users lambdas, qui n'en reçoivent peu, que parce que leur fournisseur de mail fait le boulot à leur place (et, parfois, refuse des mails légitimes).
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Spam chinois
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
Tout à fait. Voici pour info la partie concernée de mon logwatch de ce matin sur un serveur petit familial.
Habituellement les RBL envoient bouler 70% en moyenne des réceptions…
--------------------- Postfix Begin ------------------------
723.768K Bytes delivered 741,138
======== ==================================================
======== ==================================================
======== ==================================================
======== ==================================================
---------------------- Postfix End -------------------------
[^] # Re: Spam chinois
Posté par Big Pete . Évalué à 3.
Avec la raréfaction des @IP v4, surtout dans les pays comme la chine, il faut garder a l'esprit que lorsqu'on blackliste une adresse IP, ce n'est pas forcémement, voire même raremement, une seule machine que l'on blackliste, mais carrêment tout un réseau naté derrière. Comme certains FAI ont des pratiques similaire à la tienne, c'est pas étonnant que ça merdouille quand on voyage en chine. En blacklistant une ip, on blackliste peut-être un réseau mobile entier, ou une chaine d'hôtel, etc …
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Spam chinois
Posté par Grunt . Évalué à 3.
Dans ce cas, il ne tient qu'à l'opérateur mobile, ou à la chaîne hôtelière, de répondre dans un délai raisonnable quelque chose comme "Oui, désolé, on avait un spammeur sur notre réseau, on lui a tiré les oreilles, et maintenant cette @IP est de nouveau propre."
Ceci dit, je ne blackliste pas @IP par @IP, je blackliste toute la plage IP concernée quand le FAI ne répond pas.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Spam chinois
Posté par Maclag . Évalué à 3.
Il faut aussi garder à l'esprit que les FAI chinois sont des entreprises d'Etat et que le mec qui réceptionne les emails de l'adresse abuse est le petit cousin du pote du directeur, que la seule qualification qu'on lui a demandé pour prendre le poste c'est "t'aimes bien les ordinateurs?", que la preuve de cette qualification a dû être "j'ai installé Windows et Office crackés à mes parents" et qu'il y a de grandes chances qu'il ne soit pas capable de lire un mail en Anglais.
Moi j'ai dû expliquer au FAI de ma boite (à l'époque où j'étais en Chine) que leur enregistrement DNS était foireux, et j'ai même dû leur envoyer la ligne correcte pour qu'ils la mettent dans leur fichier!
# Ils bloquent des mots...
Posté par niclone (site web personnel) . Évalué à 1.
Salut,
Il m'est arrivé un problème du même genre il y a un peu plus d'un an avec des gens chez SFR qui ne recevaient pas les mails d'un domaine particulier d'un de mes serveurs SMTP. Le SMTP de SFR répondait pourtant correctement et acceptait le mail. Après de nombreux tests, il se trouvait que c'était le mot "blabla." dans l'adresse expediteur du mail qui posait problème. "blabla." faisait bien sur partit du domaine. Il semble que SFR jette silencieusement des mails selon une liste de mot qui apparaitrait dans l'adresse expéditeur. Après plusieurs mails avec le service client, j'ai fini par faire débloquer "blabla." mais tu est peut être tombé sur un mot qui ne leur plait pas.
Bonne chance !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.