Journal Les emails par Neuf…

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
14
16
mai
2012

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  . É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  (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  . É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  . É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  (site web personnel) . Évalué à 4.

          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)

          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  (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  . Évalué à 3.

        il en vient 2 fois plus des US que de Chine…

        C'est déjà beaucoup trop.

        • [^] # Re: SPAM

          Posté par  . É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  (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  . É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  (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  . É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  (site web personnel) . Évalué à 6.

        C'est normal. Google utilise DKMS, ce qui permet d'éviter le

        DKIM …

        • [^] # Re: Autre exemple tout con

          Posté par  . É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  (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  (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

      • refus à la réception
      • mise en boite a SPAM
      • mise dans le boite de réception

      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  . É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  (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  . Évalué à 4.

          refuser un spam, c'est lourd, parce que bien souvent, l'e-mail de l'expéditeur est un autre compte à spamer…

          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 rejected avec SPF.

      • [^] # Re: C'est pas si simple l'email.

        Posté par  (site web personnel) . Évalué à 2.

        Oui mais quoiqu'il arrive un mail accepté DOIT être délivre.

        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)

        et dans SMPT il y a simple

        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  (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  (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é )

            3 semaines de rétention des milliers de spams de millier de machine chinoises (ou autre), c'est beaucoup, vraiment beaucoup…

            Tu trouves normal qu'un mail anormalement détecté comme spam ne soit pas livré ?

            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)

            Le mail DOIT être délivré, et rangé dans spam…

            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.

            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 !

            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  . Évalué à 4.

            Le mail DOIT être délivré, et rangé dans spam…
            Je pense que tu n'as pas la moindre idée du volume que le spam représenterait s'il n'était pas filtré à plusieurs niveaux. Si tu penses que c'est gérable, c'est peut-être que tu ne reçois que 0.1% des spams qui te sont adressés, le reste étant filtré avant que ça n'arrive dans ta boîte mail?

      • [^] # Re: C'est pas si simple l'email.

        Posté par  (site web personnel) . Évalué à 7.

        Oui mais quoiqu'il arrive un mail accepté DOIT être délivre.

        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..

        et dans SMPT il y a simple

        Hahaha, excellent ! T'as jamais du configurer un Sendmail toi…

        • [^] # Re: C'est pas si simple l'email.

          Posté par  . É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  (site web personnel) . Évalué à -2.

            chez moi si le serveur sendmail dit qu'il accepte, j'attends de lui qu'il livre le mail.

            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.

            Si il répond un code 2 ou 3, je suis en droit de penser que le mail a été transmis.

            Non : que le mail a été accepté par le serveur. Libre ensuite à lui d'en faire ce qu'il veut.

            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é.

            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  . Évalué à 3. Dernière modification le 16 mai 2012 à 16:35.

              Non : que le mail a été accepté par le serveur. Libre ensuite à lui d'en faire ce qu'il veut.

              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  (site web personnel) . Évalué à 0.

                C'est assez malhonnete comme attitude

                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  . É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 :

                  The relay server may accept or reject the task of relaying the mail in the same
                     way it accepts or rejects mail for a local user.  If it accepts the
                     task, it then becomes an SMTP client, establishes a transmission
                     channel to the next SMTP server specified in the DNS (according to
                     the rules in section 5), and sends it the mail.  If it declines to
                     relay mail to a particular address for policy reasons, a 550 response
                     SHOULD be returned.
                  
                      When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
                     message in response to DATA), it is accepting responsibility for
                     delivering or relaying the message.  It must take this responsibility
                     seriously.  It MUST NOT lose the message for frivolous reasons, such
                     as because the host later crashes or because of a predictable
                     resource shortage.
                  
                     If there is a delivery failure after acceptance of a message, the
                     receiver-SMTP MUST formulate and mail a notification message.  This
                     notification MUST be sent using a null ("<>") reverse path in the
                     envelope.  The recipient of this notification MUST be the address
                     from the envelope return path (or the Return-Path: line).  However,
                     if this address is null ("<>"), the receiver-SMTP MUST NOT send a
                     notification.  Obviously, nothing in this section can or should
                     prohibit local decisions (i.e., as part of the same system
                     environment as the receiver-SMTP) to log or otherwise transmit
                     information about null address events locally if that is desired.  If
                     the address is an explicit source route, it MUST be stripped down to
                     its final hop.
                  
                  

                  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  (site web personnel) . Évalué à 1.

                    Donc bloquer le spam oui, mais pas n'importe comment.

                    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  . É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  (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  . Évalué à 4.

                  C'est assez malhonnete comme attitude

                  Clair que les spammeurs sont honnêtes…

                  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  . Évalué à 3.

              que le mail a été accepté par le serveur. Libre ensuite à lui d'en faire ce qu'il veut.

              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

              4.2.1.  Reply Code Severities and Theory
              
                 The three digits of the reply each have a special significance.  The
                 first digit denotes whether the response is good, bad, or incomplete.
                 An unsophisticated SMTP client, or one that receives an unexpected
                 code, will be able to determine its next action (proceed as planned,
                 redo, retrench, etc.) by examining this first digit.  An SMTP client
                 that wants to know approximately what kind of error occurred (e.g.,
                 mail system error, command syntax error) may examine the second
                 digit.  The third digit and any supplemental information that may be
                 present is reserved for the finest gradation of information.
              
                 There are four values for the first digit of the reply code:
              
                 2yz  Positive Completion reply
                    The requested action has been successfully completed.  A new
                    request may be initiated.
              
                 3yz  Positive Intermediate reply
                    The command has been accepted, but the requested action is being
                    held in abeyance, pending receipt of further information.  The
                    SMTP client should send another command specifying this
                    information.  This reply is used in command sequence groups (i.e.,
                    in DATA).
              
                 4yz  Transient Negative Completion reply
                    The command was not accepted, and the requested action did not
                    occur.  However, the error condition is temporary, and the action
                    may be requested again.  The sender should return to the beginning
                    of the command sequence (if any).  It is difficult to assign a
                    meaning to "transient" when two different sites (receiver- and
                    sender-SMTP agents) must agree on the interpretation.  Each reply
                    in this category might have a different time value, but the SMTP
                    client SHOULD try again.  A rule of thumb to determine whether a
                    reply fits into the 4yz or the 5yz category (see below) is that
                    replies are 4yz if they can be successful if repeated without any
                    change in command form or in properties of the sender or receiver
                    (that is, the command is repeated identically and the receiver
                    does not put up a new implementation).
              
                 5yz  Permanent Negative Completion reply
                    The command was not accepted and the requested action did not
                    occur.  The SMTP client SHOULD NOT repeat the exact request (in
                    the same sequence).  Even some "permanent" error conditions can be
                    corrected, so the human user may want to direct the SMTP client to
                    reinitiate the command sequence by direct action at some point in
                    the future (e.g., after the spelling has been changed, or the user
                    has altered the account status).
              
              

              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  . É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  (site web personnel) . Évalué à -2.

                Lorsqu'il répond 2, il indique clairement que c'est fait, et requested action c'est pas 'fout le dans /dev/null'

                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  . Évalué à 4.

                  bon ben si faut tout te prémâcher

                  4.2.5.  Reply Codes after DATA and the Subsequent <CRLF>.<CRLF>
                  
                     When an SMTP server returns a positive completion status (2yz code)
                     after the DATA command is completed with <CRLF>.<CRLF>, it accepts
                     responsibility for:
                  
                     o  delivering the message (if the recipient mailbox exists), or
                  
                     o  if attempts to deliver the message fail due to transient
                        conditions, retrying delivery some reasonable number of times at
                        intervals as specified in Section 4.5.4.
                  
                     o  if attempts to deliver the message fail due to permanent
                        conditions, or if repeated attempts to deliver the message fail
                        due to transient conditions, returning appropriate notification to
                        the sender of the original message (using the address in the SMTP
                        MAIL command).
                  
                     When an SMTP server returns a temporary error status (4yz) code after
                     the DATA command is completed with <CRLF>.<CRLF>, it MUST NOT make a
                     subsequent attempt to deliver that message.  The SMTP client retains
                     responsibility for the delivery of that message and may either return
                     it to the user or requeue it for a subsequent attempt (see
                     Section 4.5.4.1).
                  
                  

                  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  (site web personnel) . Évalué à -1.

                    bon ben si faut tout te prémâcher

                    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.

                    mais si tu es d'aussi mauvaise foi face à tes client je ne suis pas certain qu'il reviennent.

                    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  . É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  (site web personnel) . Évalué à -1.

                        Le serveur peut très bien renvoyer un code 5.

                        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  . É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  (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  . É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  (site web personnel) . Évalué à 1. Dernière modification le 18 mai 2012 à 07:47.

                                Avec SMTP, on s'assure que le mail est bien accepté

                                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  . É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  (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.

                                    Si tu trouve ça normal, alors rappelle moi de ne jamais te confier un réseau ou tout autre système distribué.

                                    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  . Évalué à 3.

                                      Rappel : on parle de mails dont on est sûr que c'est du spam.

                                      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  (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  . Évalué à 2.

                                      Et donc, quand l'anti-spam de l'utilisateur efface le mail, il faudrait aussi avertir l'autre… Bizarrement, personne ne le fait.

                                      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.

                                      Idem. Ca dépend vraiment du point de vue…

                                      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.

                                      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.

                                      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  (site web personnel) . Évalué à 2.

                    it accepts responsibility for:

                    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  (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  (site web personnel) . Évalué à 0.

                      C'est clairement contraire à la RFC, mais on est dans un cas où respecter la RFC causerait une nuisance grave à plein de monde.

                      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  (site web personnel) . Évalué à 3.

            chez moi si le serveur sendmail dit qu'il accepte

            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  (site web personnel) . Évalué à 2.

            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é.

            </mode tontons = no>
            
            

            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  (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  . Évalué à 1.

              Ben s'il y a une bombe dans le colis j'espère qu'elle va pas le livrer…

              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  (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  (site web personnel) . Évalué à 1.

                quelle le jette en m'envoyant une notification comme quoi c'est ok, ça c'est pas normal.

                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  (site web personnel) . Évalué à 4.

            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 colis pour le benner dès que j'ai le dos tourné.

            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  . É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  (site web personnel) . Évalué à 2.

                tu confonds le concierge avec l'antispam.

                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)

                Moi j'ai pas demandé à mon fournisseur de mal de faire le tri à ma place.

                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  . Évalué à 1.

                  faut dire que c'est de la dépense inutile aussi.

                  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  (site web personnel) . Évalué à 1.

                    En fait non, car en pratique en auto-hébergement (…) En fait, la dépense inutile c’est de centraliser l’hébergement des courriels du monde entier

                    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  (site web personnel) . Évalué à 1.

                Tout comme la concierge qui se prendra une avoinée

                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  (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  (Mastodon) . Évalué à 7.

            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.

            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  (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  (site web personnel) . Évalué à 2.

            bah si je gère des sendmail depuis 1995 donc je connais assez bien comment ça marche.

            On dirait pas.

            mais peut être manque tu encore un peu d expérience dans le domaine.

            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  (site web personnel) . Évalué à 2.

              T'es mal tombé pour faire le mariole vu que j'ai 2 décennies d'expérience de plus que toi…

              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  (site web personnel) . Évalué à 5.

              T'es mal tombé pour faire le mariole vu que j'ai 2 décennies d'expérience de plus que toi…

              Qui a la plus grosse ?

  • # Ma vie: pas spécifique à Neuf / à la Chine

    Posté par  (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  (site web personnel) . Évalué à 1.

      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),

      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  (site web personnel) . Évalué à 1.

        attendre que Free veuille bien les retirer, 10 heures plus tard

        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  (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  . É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  . É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  . É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  (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  . É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  . Évalué à 4.

          seul défaut de lister les @IP résidentielles

          C'est un tout petit peu rédhibitoire, non?

          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 :)

          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  (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  (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  . Évalué à 3.

            seul défaut de lister les @IP résidentielles
            

            C'est un tout petit peu rédhibitoire, non?

            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  (site web personnel) . Évalué à 5.

          Merci, je ne connaissais pas cette rbl.

          On pourrait aussi imaginer une "anti RBL" à base de whitelistage,

          Un truc comme ça ?
          http://www.dnswl.org/

          J'aime bien les discussions constructives… ;)

    • [^] # Re: Spam chinois

      Posté par  (Mastodon) . Évalué à 1.

      Avec FDN, je suis tranquille : je sais que si quelqu'un vient se plaindre à FDN d'un abonné qui spamme

      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  . É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  . É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  . É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  . Évalué à 2.

          mais va à l'encontre des rfc et de la nétiquette (ça existe encore ça ?)

          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  . Évalué à 3.

      Ça donne envie de s'autohéberger…

      • [^] # Re: Spam chinois

        Posté par  . É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  (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 ------------------------

          3.194M  Bytes accepted                           3,349,240
          2.496M  Bytes sent via SMTP                      2,617,350
          
          

          723.768K Bytes delivered 741,138
          ======== ==================================================

             78   Accepted                                    41.05%
            112   Rejected                                    58.95%
          
          

            190   Total                                      100.00%
          
          

          ======== ==================================================

             40   5xx Reject HELO/EHLO                        35.71%
              1   5xx Reject unknown user                      0.89%
             63   5xx Reject RBL                              56.25%
              8   5xx Reject header                            7.14%
          
          

            112   Total 5xx Rejects                          100.00%
          
          

          ======== ==================================================

            254   4xx Reject sender address                  100.00%
          
          

            254   Total 4xx Rejects                          100.00%
          
          

          ======== ==================================================

           1668   Connections             
           1331   Connections lost (inbound) 
           1668   Disconnections          
             70   Removed from queue      
             48   Delivered               
             23   Sent via SMTP           
              9   Resent                  
          
             72   RBL lookup errors       
              3   SMTP dialog errors      
             32   Hostname verification errors 
              1   Restarts due to lookup table change 
          
          

          ---------------------- Postfix End -------------------------

    • [^] # Re: Spam chinois

      Posté par  . Évalué à 3.

      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.

      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  . Évalué à 3.

        En blacklistant une ip, on blackliste peut-être un réseau mobile entier, ou une chaine d'hôtel, etc …

        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  . É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  (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.