La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Free => 
Actus Free => Discussion démarrée par: Marco POLO le 23 janvier 2016 à 21:06:30
-
Salut à tous,
Ce soir, souhaitant récupérer mes identifiant/mot de passe, voici le message que j'ai trouvé sur le site de Wannonce:
Note pour ceux qui utilisent des adresses emails @free.fr ou @aliceadsl.fr : Ces 2 noms de domaines ne sont plus autorisés pour les emails sur Wannonce, car ces services suppriment les emails des sites qui dépassent un certain quota sur 24h, et vous ne recevrez jamais nos emails. Inutile de contacter notre support technique si vous ne recevez pas l'email de récupération du mot de passe : vous ne recevrez jamais notre réponse. Vous pouvez toutefois vous plaindre auprès de Free.fr ou Aliceadsl.fr pour la médiocrité de leur service et leur demander d'autoriser les emails en provenance de Wannonce (IP: 188.165.15.58).
(https://lafibre.info/images/smileys/rires/Rires_018.gif) (https://lafibre.info/images/smileys/@GregLand/ep.gif)
-
Arf :-/
Faut voir de leur côté aussi quel SMTP ils utilisent. Si c'est vrai que cette IP balance 99% de spam, pas étonnant qu'elle soit blacklistée. Après, que chez Free ..?
-
Pure invention.
1) Free ne supprime pas les emails, mais les refuse.
2) Il n'y a pas de limite numérique par domaine ni par IP.
3) Je ne connais pas le débit envoyé par ce site mais il est invraisemblable qu'il èmette plus qu'un grand FAI.
4) L'IP 188.165.15.58 est blacklistée pour une duré de 356712s (too many spams received from this IP, rejecting mail)
-
Spam : Free n’a pas le droit de bloquer les emails
Au nom de la neutralité de l'Internet
Dans une ordonnance de référé limpide du 20 janvier 2016, le tribunal de commerce de Paris a ordonné à Free de débloquer les adresses emails …@free.fr de clients de la société Buzzee, que le FAI avait rendu inaccessibles pour lutter contre le spamming. Le tribunal remarque d’abord qu’aucune disposition législative ou réglementaire n’autorise l’opérateur à supprimer de sa propre initiative, et suivant ses critères, des messages qu’il qualifierait lui-même de spam et qui sont destinés à des clients d’une société. De plus, rien dans ses conditions générales n’est prévu à cet effet. Par ailleurs, l’article L. 34-5 du code des postes et télécommunications qui impose l’opt-in en matière de spams n’est applicable qu’aux données des personnes physiques. Or, rien ne prouve que Buzzee s’adressait à des individus. Buzzee est une société spécialisée dans la gestion pour professionnels de courriers électroniques de masse et d’organisations de conférences électroniques. Et quand bien même, le tribunal retient que « la société Free n’est pas chargée de veiller au respect de ces dispositions et que, quand bien même le voudrait-elle, elle n’en a pas les moyens puisqu’elle ne peut être informée du consentement du client destinataire, ni ne peut vérifier les possibilités de révocation de ce consentement, sauf à prendre connaissance du contenu des messages qu’elle achemine, ce qui lui est interdit par l’article L32-3 du code des postes et communications électroniques ». Le tribunal poursuit en remarquant par ailleurs que Free ne justifie d’aucune plainte d’abonnés concernant les messages de Buzzee. Enfin, il conclut que « l’accès à un réseau et la transmission de messages par internet est un droit qui s’impose aux opérateurs de télécommunications ». En vertu de l’article D. 98-5 du code des PCE en effet, l’opérateur doit assurer ses services sans discrimination, quelle que soit la nature des messages transmis et doit assurer leur intégrité. Le fait de les supprimer de mauvaise foi est du reste une infraction pénale en application de l’article 226-15 du code pénal.
Source : Legalis.net (http://www.legalis.net/spip.php?page=breves-article&id_article=4877)
-
Tribunal de commerce de Paris, ordonnance de référé du 20 janvier 2016
Pour les motifs énoncés en son assignation Introductive d’instance en date du 18 novembre 2015, signifiée à une personne habilitée à laquelle il conviendra de se reporter quant à l’exposé des faits, la Sarl Buzzee France nous demande de :
Vu l’article 873 du Code de Procédure Civile,
Faire injonction à la Société Free, sous astreinte de 10.000 € par jour de retard à compter de la date de la décision à intervenir, de procéder au déblocage du range d’IP de 80.239.174.128 à 80.239.174.191, correspondant aux serveurs de messagerie de la Société Buzzee France, blocage qui interdit à la Société Buzzee France de rendre destinataire de ses courriels ses prospects ou clients disposant d’une adresse <@free.fr>, en l’absence de toute injonction ou demande contraire d’une autorité administrative ou judiciaire.
Condamner la Société Free à lui payer une somme de 50.000 € à titre de provision sur dommages et intérêts.
Condamner la Société Free à lui payer la somme de 5.000 € en application de l’article 700 du CPC outre les dépens de l’instance.
La Sas Free se fait représenter par son conseil et dépose des conclusions motivées dans lesquelles elle nous demande, dans le dernier état de ses écritures de :
Juger la société Buzzee France irrecevable et mal fondée en ses demandes et les rejeter
A titre reconventionnel,
Interdire à la société Buzzee France d’adresser des courriers non sollicités aux abonnés de la société Free ;
Assortir cette Interdiction d’une astreinte de 1.000 euros par infraction constatée ;
Juger que chaque infraction constatée sera constituée par chacun des courriers électroniques/mails envoyé à chacun des titulaires d’une adresse électronique "@free" ;
Condamner la société Buzzee France à lui payer la somme de 20.000 euros au titre de l’article 700 du cadre de procédure civile et à tous les dépens.
Nous constatons que les parties se présentent à l’audience du 16 décembre 2015 par leur conseil respectif. A notre demande, l’audience est renvoyée au 5 janvier 2016, audience à laquelle les parties se présentent. Après avoir écouté leurs explications, nous avons clos les débats, mis l’affaire en délibéré et annoncé que l’ordonnance serait mise à leur disposition le 20 janvier 2016.
DISCUSSION
Nous relevons que la société Buzzee France a une activité de gestion de courriers internet de masse, et d’organisation de conférences téléphoniques ; par nature, cette activité s’adresse à des professionnels, même si les conférences téléphoniques peuvent aussi intéresser, parfois, des particuliers ;
Qu’il est constant que la société Free, à plusieurs reprises, et de façon définitive depuis juillet ou octobre dernier, bloque les courriels adressés à ceux de ses clients qui ont une adresse de type .... @free.fr en provenance des serveurs qu’elle a identifiés par leur adresse IP comme étant ceux de Buzzee ; que ce faisant, elle interdit à Buzzee de communiquer par courriel avec toute personne ayant une adresse de ce type, quand bien même serait-elle un de ses clients habituels ;
1. Sur te fond de la demande de Buzzee.
Nous retenons que la demanderesse qualifie ce comportement de Free comme un trouble manifestement illicite permettant au président du tribunal "même en présence d’une contestation sérieuse, [de] prescrire en référé /es mesures conservatoires ou de remise en état qui s’imposent, soit pour prévenir un dommage imminent, soit pour faire cesser un trouble manifestement illicite » en application de l’article 873 du code de procédure civile ;
Nous retenons que la licéité du contenu des messages adressés par Buzzee n’est pas en cause et que le blocage ne résulte d’aucune injonction ou demande d’une autorité administrative habilitée ou judiciaire en application de dispositions du code des postes et communications électroniques ou du code pénal ;
Nous constatons que la société Free, qui ne conteste pas la situation, justifie son comportement par la nécessité de lutter contre les spams, en expliquant que :
- d’une part, un certain nombre de prestataires spécialisés identifient Buzzee comme une société envoyant des spams ;
- d’autre part, Buzzee s’adresse nécessairement aussi à des particuliers puisque ses conditions générales de vente parlent de « commandes reçues ... qu’elles émanent de professionnels, de commerçants de sociétés ou de particuliers » et que les adresses de type .... @free.fr sont des adresses de particuliers puisqu’en général les entreprises ont un nom de domaine propre ; que s’agissant des destinataires personnes physiques, les courriels adressés par Buzzee, notamment pour des campagnes de prospection commerciale, ne satisfont pas aux dispositions de l’article L34-5 du code de la poste et des communications électroniques destinées à protéger la vie privée des utilisateurs de réseaux et services de communication électroniques ;
Que Free ajoute que les spams encombrent inutilement les réseaux de télécommunications et, par leur volume croissant, rendent plus difficile, ou plus coûteux, le maintien de la continuité et de la qualité de service que lui impose le code des postes et communications électroniques ;
Nous retenons cependant que la notion de « spams » ne découle d’aucune définition juridique et que Free n’invoque aucune disposition législative ou réglementaire qui l’autoriserait, de sa propre initiative et suivant des critères qu’elle définirait, à supprimer des messages ainsi qualifiés par elle-même de « spams » et destinés à ses clients ;
Nous constatons également que la société Free, que nous avons spécifiquement interrogée à ce sujet, reconnaît qu’aucune clause de ses conditions générales de vente à ses clients, ou contrats types, ne la mandate pour filtrer, directement ou indirectement, les messages destinés à ses clients, de manière générale ou selon des critères que préciseraient ces conditions ;
Nous notons qu’il est possible que certains messages de prospection commerciale de Buzzee, envoyés à partir de fichiers d’adresses achetés ou loués à cette fin, soient adressés à des personnes physiques et ne respectent pas les dispositions de l’article L34-5 du code des postes et communications électroniques, qui Interdit « la prospection directe au moyen de système automatisé de communications électroniques eu sens du 6° de l’article L. 32. d’un télécopieur ou de courriers électroniques utilisant les coordonnées d’une personne physique, abonné ou utilisateur, qui n’a pas exprimé préalablement son consentement à recevoir des prospections directes par ce moyen », interdiction dont la mise en oeuvre se traduit par le double principe que la personne physique destinataire du message doit avoir donné son accord préalable pour le recevoir (régime de l’ « opt-in ») et doit pouvoir revenir de manière simple, à tout moment, sur ce consentement (régime de l’ « opt-out ») ;
Nous retenons cependant que la société Free n’est pas chargée de veiller au respect de ces dispositions et que, quand bien même le voudrait-elle, elle n’en a pas les moyens puisqu’elle ne peut être informée du consentement du client destinataire, ni ne peut vérifier les possibilités de révocation de ce consentement, sauf à prendre connaissance du contenu des messages qu’elle achemine, ce qui lui est interdit par l’article L32-3 du code des postes et communications électroniques ;
En outre, nous relevons que Free ne justifie pas, ni même n’allègue, que sa décision de ne pas distribuer tes messages en provenance des serveurs de Buzzee est consécutive à des réclamations de certains de ses clients qui se sont plaints de recevoir des messages non sollicités et indésirables de la part de Buzzee ;
De manière plus générale, nous retenons que l’article 098·5 du code des postes et communications électroniques dispose que « l’opérateur prend les mesures nécessaires pour garantir la neutralité de ses services vis-à-vis du contenu des messages transmis sur son réseau et le secret des correspondances. A cet effet, l’opérateur assure ses services sans discrimination quelle que soit la nature des messages transmis et prend les dispositions utiles pour assurer l’intégrité des messages » et qu’ainsi l’opérateur n’a pas la liberté de ne pas acheminer certains messages de sa propre initiative et selon des critères d’appréciation qui lui sont propres ; qu’en outre, si la mauvaise foi est établie, « le fait, commis de mauvaise foi, d’ouvrir, de supprimer, de retarder ou de détourner des correspondances arrivées ou non à destination et adressées à des tiers » est une infraction pénale en application de l’article 226-15 du code pénal ;
En conséquence, retenant qu’en l’absence d’infractions spécifiques, l’accès à un réseau et la transmission de messages par internet est un droit qui s’impose aux opérateurs de télécommunications,
Nous ordonnerons à la société Free de procéder au déblocage des serveurs d’adresses IP 80.239.128 à 80.239.191, et de les maintenir accessibles aux clients d’adresse ...@free.fr, pour l’envoi comme pour la réception de courriels, sauf injonction ou demande contraire d’une autorité administrative habilitée ou judiciaire, dans les 15 jours de la signification de la décision à venir, et ce sous astreinte de 5.000 € par jour de retard pendant une durée provisoire de 30 jours à l’issue de laquelle if sera éventuellement dit droit à nouveau, déboutant pour le surplus de la demande
2. Sur les dommages et intérêts demandés par Buzzee.
Nous constatons que Buzzee réclame 50.000 € de dommages et intérêts, mais que la demanderesse, au-delà de l’affirmation qu’elle a perdu des clients et que certains de ses investissements ont été anéantis, n’apporte aucune justification, même sommaire du quantum du préjudice allégué ;
Qu’ainsi ne sont pas remplies les conditions de l’article 873 deuxième alinéa du code de procédure civile, qu’invoque Buzzee, et selon lesquelles le président du tribunal « dans les cas où l’existence de l’obligation n’est pas sérieusement contestable, peut accorder une provision au créancier » ;
En conséquence,
Nous débouterons la société Buzzee France de sa prétention que la société Free lui verse la somme de 50.000 € à titre de dommages et intérêts.
3. Sur les autres demandes des parties.
Compte tenu de la décision principale, nous débouterons Free de sa prétention qu’il soit fait interdiction à Buzzee, sous astreinte, d’adresser des courriels non sollicités à ses abonnés ;
Relevant que le demandeur, pour faire valoir ses droits, a dû engager des frais irrépétibles qu’il serait inéquitable de laisser à sa charge,
Nous condamnerons la société Free à verser à la société Buzzee France la somme de 5.000 € en application de l’article 700 du code de procédure civile.
Et relevant que la société Free succombe, nous la condamnerons aux dépens de l’instance.
DECISION
Statuant par ordonnance rendue de façon contradictoire et en premier ressort, nous :
Vu l’article 873, alinéa 2, CPC.
• Ordonnons à la SAS Free de procéder au déblocage des serveurs d’adresses IP 80.239.128 à 80.239.191, et de les maintenir accessibles aux clients d’adresse ... @free.fr pour l’envoi comme pour la réception de courriels, sauf injonction ou demande contraire d’une autorité administrative habilitée ou judiciaire, dans les 15 jours de la signification de la présente décision, et ce sous astreinte de 5.000 € par jour de retard pendant une durée provisoire de 30 jours à l’issue de laquelle il sera éventuellement dit droit à nouveau, déboutant pour le surplus de la demande ;
• Déboutons la Sarl Buzzee France de sa prétention que la SAS Free lui verse la somme de 50.000 € à titre de dommages et intérêts ;
• Rejetons la demande de la SAS Free qu’il soit fait interdiction à la SARL Buzzee France, sous astreinte, d’adresser des courriels non sollicités aux abonnés de la SAS Free ;
• Condamnons la Sas Free à verser à la Sarl Buzzee France la somme de 5.000 € en application de l’article 700 du code de procédure civile ;
• Condamnons en outre la Sas Free aux dépens de l’instance, dont ceux à recouvrer par le greffe liquidés à la somme de 48,74 € TTC dont 7,90 € de TVA.
La présente décision est de plein droit exécutoire par provision en application de l’article 489 CPC.
Le tribunal : Patrick Jeanjean (président), Laurence Baali (greffier)
Avocats : Me Firas Mamoun, Me Olivier lteanu, Me Yves Coursin
Source : legalis.net (http://www.legalis.net/spip.php?page=jurisprudence-decision&id_article=4875)
-
Ordonnons à la SAS Free de procéder au déblocage des serveurs d’adresses IP 80.239.128 à 80.239.191, et de les maintenir accessibles aux clients d’adresse ...
Il manque comme une partie dans l'IP... du coup free n'a rien à ouvrir ?
-
si je monte une boite, je l’appelle 'hottemail' par exemple..., je mets un serveur chez OVH et que je vend (ou donne) des comptes emails a des gens et que je bloque la reception des IP de Buzzee , je suis condamnable en justice ?! je n'ai pas le droit de faire ce que je veux avec mon serveur email donc (quitte a perdre mes clients si je filtre trop ou si je revend leur emails) ? Il y a donc un legislation sur la gestion d'un service d'emails, des devoirs et droits que ca implique ? Cette juridiction est-elle liée au domain (hottemail.fr) ou a l'emplacement du serveur (DC en France) ou celui des clients ?
Ca n'est pas clair et net cette décision et un dangereux précédent non ?
Si je suis Orange ou Free et que je bloque les IP de Buzzee sur mon réseau, au niveau routage, la c'est autre chose. mais ca n'a pas l'air d'être la situation ici.
y'a pas une confusion entre un opérateur de réseau et un opérateur de serveur de messagerie la ?
-
Il manque comme une partie dans l'IP... du coup free n'a rien à ouvrir ?
S'il veut jouer à faire de la mauvaise foi caractérisée et prétendre qu'il n'a pas remarqué et tenu compte qu'il s'agissait d'une erreur de forme non substantielle, qu'en outre il n'a pas vu la plage entière citée plus haut dans le jugement ainsi que certainement de nombres fois lors de procédure, et par ailleurs retrouvable en un temps trivial de recherche (elle est clairement identifiée comme « serveurs [que Free] a identifiés par leur adresse IP comme étant ceux de Buzzee »), il peut.
Mais ça ne sera probablement pas bien vu par le juge ou la jurisprudence (à moins qu'il ne puisse justifier de problèmes de compréhension écrite).
Il y a donc un legislation sur la gestion d'un service d'emails, des devoirs et droits que ca implique ?
L'article D98-5 (http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000025703451&cidTexte=LEGITEXT000006070987) du CPCE est cité.
L'opérateur prend les mesures nécessaires pour garantir la neutralité de ses services vis-à-vis du contenu des messages transmis sur son réseau et le secret des correspondances.
A cet effet, l'opérateur assure ses services sans discrimination quelle que soit la nature des messages transmis et prend les dispositions utiles pour assurer l'intégrité des messages.
L'article D98-3 (http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000006464069&cidTexte=LEGITEXT000006070987) du CPCE définit la portée de l'article D98-5.
[Les] règles mentionnées au I et aux 1 et 2 du II de l'article D. 98-5 et à l'article D. 98-13 [ne] s'appliquent qu'aux fournisseurs de services de communications électroniques au public
L'article L32 (http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000031010761&cidTexte=LEGITEXT000006070987) du CPCE apporte les définitions nécessaires :
1° Communications électroniques.
On entend par communications électroniques les émissions, transmissions ou réceptions de signes, de signaux, d'écrits, d'images ou de sons, par voie électromagnétique.
6° Services de communications électroniques.
On entend par services de communications électroniques les prestations consistant entièrement ou principalement en la fourniture de communications électroniques. Ne sont pas visés les services consistant à éditer ou à distribuer des services de communication au public par voie électronique.
15° Opérateur.
On entend par opérateur toute personne physique ou morale exploitant un réseau de communications électroniques ouvert au public ou fournissant au public un service de communications électroniques.
=> Si tu fournis de la réception d'écrits par voie électromagnétique au public, tu es concerné par la loi. L'interprétation et la contextualisation de cette dernière sémantique en est laissée au corps judiciaire.
je mets un serveur chez OVH et que je vend (ou donne) des comptes emails a des gens
On peut noter le prérequis que ces gens soient « le public ».
Cette juridiction est-elle liée au domain (hottemail.fr) ou a l'emplacement du serveur (DC en France) ou celui des clients ?
Dans les trois cas, pas de raison. C'est le fait que tu opères le service, et que tu sois sujet à la loi française qui te rend concerné.
-
Ca n'est pas clair quand meme.
Donc tout opérateur de serveur emails en France ne devrait pas activer RBL/Spamhaus et autre sur ces machines ? j'en connais un paquet...
-
Donc tout opérateur de serveur emails en France ne devrait pas activer RBL/Spamhaus et autre sur ces machines ?
Si l'autorité judiciaire a envie de le comprendre comme ça, oui autrement non. Cette juridiction est suffisamment vague pour lui laisser appliquer la marge de son libre arbitre à un domaine dont elle ne connaît pas le fonctionnement.
-
Ca n'est pas clair quand meme.
C'est de la justice expéditive, de la justice de juges qui ne font pas d'efforts, de la mauvaise justice.
On ne comprend rien, mais il parait que même en Cassation, on ne comprend rien. Peut être un problème général en France de capacité à formuler un raisonnement juridique.
-
Pour moi, hormis des mails mal formatés RFC822 mon fournisseur d'e-mail doit tout me renvoyer, c'est son taf...
Apres il bounce les gros mails supérieurs à 8mo
ou les possibles "small mail of the death" via greylist mais c'est un minimum de sécurité.
-
Ah oui, et donc même si une IP source bourrine les connexions et tente tout le dictionnaire comme destinataires, il faut continuer à supporter ça?
(Non que j'accuse la société ayant porté plainte de pratiquer ce genre de choses.)
-
Ah oui, et donc même si une IP source bourrine les connexions et tente tout le dictionnaire comme destinataires, il faut continuer à supporter ça?
Rien n'est indiqué de tout ca dans la plainte.... on dirait preque que FREE a attaqué un gros spammeur épivala.
-
Le jugement est juste consternant, on ne comprend RIEN. En ça confirme un peut ce qu'on pouvait penser de ce genre de justice qui ne va pas au fond des choses, si tant est que les juristes soient capable de comprendre l'informatique, la réalité ou bien le droit.
Déjà, pourquoi parler de suppression de messages? Depuis quand Free supprime les messages?
-
Marco POLO ne reçoit plus les notifications de LaFibre.info depuis quelques jours.
J'ai tout de suite pensé à un blacklistage de mon IP par Free, mais cela ne semble pas le cas, j'ai testé avec une adresse mail Free en simulant une perte de mot de passe et j'ai bien reçu le mail pour réinitialiser mon mot de passe.
Voici les log postfix, avec les mails envoyés (j'ai remplacé sa véritable adresse mail @free.fr en marcopolo@free.fr : je ne vois pas de différence entre la période où il recevait les mails et celle où les mails sont supprimés par Free : on note que les mails sont envoyés immédiatement vu que la suppression du mail coté serveur lafibre.info est réalisé immédiatement (ce qui signifie que pour le serveur lafibre.info les mails ont été reçus par le serveur mx1.free.fr)
cat mail.log | grep -A 1 marcopolo@free.fr
Jan 25 09:26:34 lafibre postfix/smtp[12685]: 14C73A0DC2: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.58, delays=0.07/0/0.09/0.42, dsn=2.0.0, status=sent (250 OK)
Jan 25 09:26:34 lafibre postfix/qmgr[1364]: 14C73A0DC2: removed
--
Jan 25 13:19:18 lafibre postfix/smtp[23508]: CFD12A0EB6: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.35, delays=0.06/0/0.08/0.21, dsn=2.0.0, status=sent (250 OK)
Jan 25 13:19:18 lafibre postfix/qmgr[1364]: CFD12A0EB6: removed
--
Jan 25 14:31:03 lafibre postfix/smtp[4869]: 44743A0EFC: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.44, delays=0.06/0/0.09/0.29, dsn=2.0.0, status=sent (250 OK)
Jan 25 14:31:03 lafibre postfix/qmgr[1364]: 44743A0EFC: removed
--
Jan 25 15:28:23 lafibre postfix/smtp[22999]: 3571FA0F21: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.39, delays=0.1/0.06/0.08/0.15, dsn=2.0.0, status=sent (250 OK)
Jan 25 15:28:23 lafibre postfix/qmgr[1364]: 3571FA0F21: removed
--
Jan 25 15:47:18 lafibre postfix/smtp[21754]: 8E50AA0F4C: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, conn_use=2, delay=0.54, delays=0.09/0.24/0.02/0.19, dsn=2.0.0, status=sent (250 OK)
Jan 25 15:47:18 lafibre postfix/qmgr[1364]: 8E50AA0F4C: removed
--
Jan 25 15:59:49 lafibre postfix/smtp[4362]: 96A2DA0F47: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.34, delays=0.06/0/0.08/0.2, dsn=2.0.0, status=sent (250 OK)
Jan 25 15:59:49 lafibre postfix/qmgr[1364]: 96A2DA0F47: removed
--
Jan 25 16:41:28 lafibre postfix/smtp[6966]: E7CB2A0F61: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.56, delays=0.06/0/0.23/0.27, dsn=2.0.0, status=sent (250 OK)
Jan 25 16:41:28 lafibre postfix/qmgr[1364]: E7CB2A0F61: removed
--
Jan 25 18:56:00 lafibre postfix/smtp[9156]: 3B090A106E: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.78, delays=0.05/0.31/0.08/0.34, dsn=2.0.0, status=sent (250 OK)
Jan 25 18:56:00 lafibre postfix/qmgr[1364]: 3B090A106E: removed
--
Jan 25 20:34:34 lafibre postfix/smtp[15432]: 4D7CFA10F1: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.27, delays=0.06/0/0.08/0.13, dsn=2.0.0, status=sent (250 OK)
Jan 25 20:34:34 lafibre postfix/qmgr[1364]: 4D7CFA10F1: removed
--
Jan 25 22:04:15 lafibre postfix/smtp[28272]: 8210FA11A6: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.27, delays=0.05/0/0.09/0.13, dsn=2.0.0, status=sent (250 OK)
Jan 25 22:04:15 lafibre postfix/qmgr[1364]: 8210FA11A6: removed
--
Jan 25 23:00:47 lafibre postfix/smtp[15954]: BBD10A1270: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.34, delays=0.05/0/0.15/0.13, dsn=2.0.0, status=sent (250 OK)
Jan 25 23:00:47 lafibre postfix/qmgr[1364]: BBD10A1270: removed
--
Jan 26 01:43:17 lafibre postfix/smtp[9941]: 4E43DA02AC: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.25, delays=0.06/0/0.08/0.11, dsn=2.0.0, status=sent (250 OK)
Jan 26 01:43:17 lafibre postfix/qmgr[1364]: 4E43DA02AC: removed
--
Jan 26 08:48:55 lafibre postfix/smtp[20966]: 34AB6A0DA4: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.45, delays=0.07/0/0.08/0.3, dsn=2.0.0, status=sent (250 OK)
Jan 26 08:48:55 lafibre postfix/qmgr[1364]: 34AB6A0DA4: removed
--
Jan 26 11:50:10 lafibre postfix/smtp[9871]: 9C033A0E59: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.79, delays=0.05/0/0.37/0.37, dsn=2.0.0, status=sent (250 OK)
Jan 26 11:50:10 lafibre postfix/qmgr[1364]: 9C033A0E59: removed
--
Jan 26 14:29:48 lafibre postfix/smtp[24137]: 095DDA0ED3: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=1, delays=0.07/0/0.08/0.89, dsn=2.0.0, status=sent (250 OK)
Jan 26 14:29:48 lafibre postfix/qmgr[1364]: 095DDA0ED3: removed
--
Jan 26 18:45:48 lafibre postfix/smtp[29306]: D2DD2A107E: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.35, delays=0.06/0/0.08/0.21, dsn=2.0.0, status=sent (250 OK)
Jan 26 18:45:48 lafibre postfix/qmgr[1364]: D2DD2A107E: removed
--
Jan 27 12:00:26 lafibre postfix/smtp[9476]: D4C30A0EF1: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=1.2, delays=0.09/0/0.16/0.98, dsn=2.0.0, status=sent (250 OK)
Jan 27 12:00:26 lafibre postfix/qmgr[1364]: D4C30A0EF1: removed
--
Jan 27 12:03:22 lafibre postfix/smtp[9481]: D7C5CA0ED2: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=34, delays=0.06/0/33/0.74, dsn=2.0.0, status=sent (250 OK)
Jan 27 12:03:22 lafibre postfix/qmgr[1364]: D7C5CA0ED2: removed
--
Jan 27 15:11:31 lafibre postfix/smtp[14329]: A1B4CA0F75: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.55, delays=0.05/0/0.11/0.39, dsn=2.0.0, status=sent (250 OK)
Jan 27 15:11:31 lafibre postfix/qmgr[1364]: A1B4CA0F75: removed
--
Jan 27 20:42:59 lafibre postfix/smtp[25646]: A4524A11FA: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.63, delays=0.06/0.29/0.08/0.2, dsn=2.0.0, status=sent (250 OK)
Jan 27 20:42:59 lafibre postfix/qmgr[1364]: A4524A11FA: removed
--
Jan 28 05:56:42 lafibre postfix/smtp[15279]: 9E6CEA08C0: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.45, delays=0.04/0/0.2/0.2, dsn=2.0.0, status=sent (250 OK)
Jan 28 05:56:42 lafibre postfix/qmgr[1364]: 9E6CEA08C0: removed
--
Jan 28 09:31:06 lafibre postfix/smtp[17675]: E1427A0E4A: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=3.9, delays=0.07/0/3.6/0.24, dsn=2.0.0, status=sent (250 OK)
Jan 28 09:31:06 lafibre postfix/qmgr[1364]: E1427A0E4A: removed
--
Jan 28 09:43:07 lafibre postfix/smtp[567]: 35661A0E5A: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=2.6, delays=0.06/0.34/0.08/2.1, dsn=2.0.0, status=sent (250 OK)
Jan 28 09:43:07 lafibre postfix/qmgr[1364]: 35661A0E5A: removed
--
Jan 28 12:40:48 lafibre postfix/smtp[25139]: 9E208A0F04: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=32, delays=0.05/0/31/0.82, dsn=2.0.0, status=sent (250 OK)
Jan 28 12:40:48 lafibre postfix/qmgr[1364]: 9E208A0F04: removed
--
Jan 28 16:52:22 lafibre postfix/smtp[3503]: 50411A1011: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.3, delays=0.07/0/0.08/0.15, dsn=2.0.0, status=sent (250 OK)
Jan 28 16:52:22 lafibre postfix/qmgr[1364]: 50411A1011: removed
--
Jan 29 09:24:02 lafibre postfix/smtp[4784]: 72785A0E50: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.34, delays=0.06/0/0.08/0.19, dsn=2.0.0, status=sent (250 OK)
Jan 29 09:24:02 lafibre postfix/qmgr[1422]: 72785A0E50: removed
--
Jan 29 13:30:06 lafibre postfix/smtp[30646]: 01BB6A0F40: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.79, delays=0.07/0.46/0.08/0.19, dsn=2.0.0, status=sent (250 OK)
Jan 29 13:30:06 lafibre postfix/qmgr[1422]: 01BB6A0F40: removed
--
Jan 29 18:40:42 lafibre postfix/smtp[28501]: C5D81A10B5: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=30, delays=0.05/0/30/0.22, dsn=2.0.0, status=sent (250 OK)
Jan 29 18:40:42 lafibre postfix/qmgr[1422]: C5D81A10B5: removed
--
Jan 29 19:15:06 lafibre postfix/smtp[20653]: D51B9A112F: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.29, delays=0.06/0/0.08/0.15, dsn=2.0.0, status=sent (250 OK)
Jan 29 19:15:06 lafibre postfix/qmgr[1422]: D51B9A112F: removed
--
Jan 29 19:22:35 lafibre postfix/smtp[1607]: 63DBAA110D: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.31, delays=0.05/0/0.1/0.16, dsn=2.0.0, status=sent (250 OK)
Jan 29 19:22:35 lafibre postfix/qmgr[1422]: 63DBAA110D: removed
--
Jan 30 13:54:18 lafibre postfix/smtp[6511]: 24228A0F15: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.39, delays=0.06/0/0.13/0.21, dsn=2.0.0, status=sent (250 OK)
Jan 30 13:54:18 lafibre postfix/qmgr[1422]: 24228A0F15: removed
--
Jan 30 18:46:45 lafibre postfix/smtp[906]: 2D9F0A1072: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.27, delays=0.05/0/0.08/0.13, dsn=2.0.0, status=sent (250 OK)
Jan 30 18:46:45 lafibre postfix/qmgr[1422]: 2D9F0A1072: removed
--
Jan 30 19:41:17 lafibre postfix/smtp[5739]: 5522BA10AC: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.41, delays=0.06/0/0.17/0.18, dsn=2.0.0, status=sent (250 OK)
Jan 30 19:41:17 lafibre postfix/qmgr[1422]: 5522BA10AC: removed
--
Jan 30 20:09:36 lafibre postfix/smtp[15139]: DD63CA10D4: to=<marcopolo@free.fr>, relay=mx1.free.fr[212.27.48.7]:25, delay=0.29, delays=0.06/0/0.08/0.15, dsn=2.0.0, status=sent (250 OK)
Jan 30 20:09:36 lafibre postfix/qmgr[1422]: DD63CA10D4: removed
Par contre, j'ai bien reçu mail de test (là aussi j'ai modifié l'adresse mail) :
Jan 29 22:04:39 lafibre postfix/smtp[1258]: 567B7A12C0: to=<mail-test.vivien@free.fr>, relay=mx1.free.fr[212.27.48.6]:25, delay=0.24, delays=0.07/0/0.08/0.09, dsn=2.0.0, status=sent (250 OK)
Jan 29 22:04:39 lafibre postfix/qmgr[1422]: 567B7A12C0: removed
-
free.fr MX preference = 20, mail exchanger = mx2.free.fr
free.fr MX preference = 10, mail exchanger = mx1.free.fr
mx1.free.fr internet address = 212.27.48.7
mx1.free.fr internet address = 212.27.48.6
mx2.free.fr internet address = 212.27.42.58
mx2.free.fr internet address = 212.27.42.59
Autrement dit le SMTP est en IPv4, donc à partir de l'adresse : 46.227.16.8
http://postmaster.free.fr/showipstate.pl
Mon IP est elle bloquée ?
L'IP 46.227.16.8 n'est pas listée.
-
Pour ma part, j'ai
Mon IP est elle bloquée ?
L'IP 127.0.0.1 n'est pas listée.
C'te blague! et pourtant, en envoyant un mail sur Thunderbird depuis un compte mail free, j'obtiens :
Merci Free :)
-
Pour ma part, j'ai
Mon IP est elle bloquée ?
L'IP 127.0.0.1 n'est pas listée.
C'te blague!
Il faut utiliser le formulaire sur la page d'accueil, le serveur attend des données POST avec cette URL.
-
Même message avec mon IP, je suis toujours non listé, mais le SMTP doit pas m'aimer apparement puisque je reçois les mails, mais impossible d'en envoyer depuis un client, sur mon ancienne IP ça fonctionnait parfaitement.
-
Pour ma part, j'aiC'te blague! et pourtant, en envoyant un mail sur Thunderbird depuis un compte mail free, j'obtiens :
Merci Free :)
Pardon? Tu peux nous décrire en détail ce que tu fais?
-
Marco POLO ne reçoit plus les notifications de LaFibre.info depuis quelques jours.
Est-ce qu'il a vérifié dans les spams?
Est-ce qu'il est sous Zimbra?
Est-ce qu'il a activé le filtrage des spams?
-
Pardon? Tu peux nous décrire en détail ce que tu fais?
Je rédige un mail à n'importe quelle adresse (en fait on s'en moque, le but est d'envoyer quelque chose au serveur), Thunderbird me renvoie directement cette alerte. En ayant obtenu une nouvelle IP chez OVH car j'ai migré de serveur, j'ai cette erreur, alors qu'auparavant depuis 188.165.X.X l'envoi fonctionnait (sans avoir touché aux paramètres du client entre temps).
Donc ceci est la preuve que Free implique un blocage manuel (et arbitraire puisque je n'envois aucun SPAM), je vais tenter des captures wireshark pour avoir plus d'infos.
-
Mais comment fais-tu pour envoyer le message? C'est ça que je ne comprends pas!
-
Marco POLO ne reçoit plus les notifications de LaFibre.info depuis quelques jours.
J'ai tout de suite pensé à un blacklistage de mon IP par Free, mais cela ne semble pas le cas, j'ai testé avec une adresse mail Free en simulant une perte de mot de passe et j'ai bien reçu le mail pour réinitialiser mon mot de passe.
vivien, as-tu vérifié sur www-data@lafibre.info?
-
Est-ce qu'il a vérifié dans les spams?
Est-ce qu'il est sous Zimbra?
Est-ce qu'il a activé le filtrage des spams?
Pour mon test, qui est passé, je n'avais pas migré sous Zimbra (je viens de faire la demande, je ne saispas combien de jour cela prend) et j'étais avec les options par défaut.
-
SMF pose de gros soucis à certains MX... il faudrait étudier l'en-tete...
Return-Path: <www-data@lafibre.info>
=> y'a quoi dans cette boite mail ????
-
Pour mon test, qui est passé, je n'avais pas migré sous Zimbra (je viens de faire la demande, je ne saispas combien de jour cela prend) et j'étais avec les options par défaut.
Je confirme, ça marche avec un score de :
X-ProXaD-SC: state=HAM:SocialNetwork score=30
(compte Free pas sous Zimbra)
-
SMF pose de gros soucis à certains MX... il faudrait étudier l'en-tete...
Oui les messages sont délirants ce que j'ai signalé déjà à de nombreuses reprises :
X-Mailer: SMF
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="SMF-83edc28892565604d5db5bb1be2358f8"
Content-Transfer-Encoding: 7bit
Une réponse a été postée par corrector1 sur un sujet que vous surveillez.
Voir la réponse :
https://lafibre.info/free-les-news/ah-ce-free/new/?topicseen#new
D'autres réponses ont pu être postées, mais vous ne recevrez pas d'autres e-mails de notification tant que vous n'aurez pas lu le sujet.
Pour vous désabonner de ce sujet, utilisez ce lien :
https://lafibre.info/free-les-news/ah-ce-free/?action=notify
Cordialement,
L'équipe La Fibre.
C'est QUOI ce format moisi?
-
Il va y avoir un de plus "relay access denied" Darklight chez free à cause de toi ;-)
Parmis mes domaines, certains utilisent une délégation de MX chez Google, pour diverses raisons, d'autres ont directement un sendmail, ou un postfix.
Je reçois bien tous les mails chez Free, quelle que soient les domaines utilisés et les adresses IP utilisées pour cela.
Alors,
Free ne supprime pas de mails, j'ai encore une BAL du temps des accès modem 56k.
Je reçois bien les notifs de lafibre sur ma Bal Zimbra.
La justice n'a pas les moyens de ses actions, un expert aurait dû être mandaté pour faire un éclaircissement sur ce dossier avant jugement.
-
Oui les messages sont délirants ce que j'ai signalé déjà à de nombreuses reprises :
Le format MIME est ajouté car il doit y avoir une possibilité d'ajouter un logo ou une ***** du genre (comme si les sysadmins adoraient incredimail)
On permet et gere du MIME, UNICODE dans les messages...
Maintenant pour eviter les saturations, les mailer-daemons ne repondent plus pourquoi ils rejettent hormis quand les adresses sont pas bonnes....
-
Le format MIME est ajouté car il doit y avoir une possibilité d'ajouter un logo ou une ***** du genre (comme si les sysadmins adoraient incredimail)
On permet et gere du MIME, UNICODE dans les messages...
Maintenant pour eviter les saturations, les mailer-daemons ne repondent plus pourquoi ils rejettent hormis quand les adresses sont pas bonnes....
Je ne te parle pas de MIME.
Je te parle de "
Une réponse a été postée par Marin sur un sujet que vous surveillez"
Tu peux m'expliquer à quoi ça correspond?
-
Une réponse a été postée par Marin sur un sujet que vous surveillez"
Tu peux m'expliquer à quoi ça correspond?
ça ? ;)
http://www.eteks.com/tips/tip3.html
PS: ici c'est parsé par le serveur ca marche pas ;)
-
Je ne te parle pas de MIME.
Je te parle de "
Une réponse a été postée par Marin sur un sujet que vous surveillez"
Tu peux m'expliquer à quoi ça correspond?
--SMF-00096d1b9a26ff2fc92a2113acdfe18f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
VW5lIHLDqXBvbnNlIGEgw6l0w6kgcG9zdMOpZSBwYXIgdW5kZXJncm91bmQ3OCBzdXIgdW4gc3Vq
ZXQgcXVlIHZvdXMgc3VydmVpbGxlei4KClZvaXIgbGEgcsOpcG9uc2UgOgpodHRwczovL2xhZmli
cmUuaW5mby9mcmVlLWxlcy1uZXdzL2FoLWNlLWZyZWUvbmV3Lz90b3BpY3NlZW4jbmV3CgpEJ2F1
dHJlcyByw6lwb25zZXMgb250IHB1IMOqdHJlIHBvc3TDqWVzLCBtYWlzIHZvdXMgbmUgcmVjZXZy
ZXogcGFzIGQnYXV0cmVzIGUtbWFpbHMgZGUgbm90aWZpY2F0aW9uIHRhbnQgcXVlIHZvdXMgbidh
dXJleiBwYXMgbHUgbGUgc3VqZXQuCgpQb3VyIHZvdXMgZMOpc2Fib25uZXIgZGUgY2Ugc3VqZXQs
IHV0aWxpc2V6IGNlIGxpZW4gOgpodHRwczovL2xhZmlicmUuaW5mby9mcmVlLWxlcy1uZXdzL2Fo
LWNlLWZyZWUvP2FjdGlvbj1ub3RpZnkKCkNvcmRpYWxlbWVudCwKTCfDqXF1aXBlIExhIEZpYnJl
Lg==
--SMF-00096d1b9a26ff2fc92a2113acdfe18f--
-
ça ? ;)
Depuis quand ces choses ont leur place dans un email?
-
--SMF-00096d1b9a26ff2fc92a2113acdfe18f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
VW5lIHLDqXBvbnNlIGEgw6l0w6kgcG9zdMOpZSBwYXIgdW5kZXJncm91bmQ3OCBzdXIgdW4gc3Vq
ZXQgcXVlIHZvdXMgc3VydmVpbGxlei4KClZvaXIgbGEgcsOpcG9uc2UgOgpodHRwczovL2xhZmli
cmUuaW5mby9mcmVlLWxlcy1uZXdzL2FoLWNlLWZyZWUvbmV3Lz90b3BpY3NlZW4jbmV3CgpEJ2F1
dHJlcyByw6lwb25zZXMgb250IHB1IMOqdHJlIHBvc3TDqWVzLCBtYWlzIHZvdXMgbmUgcmVjZXZy
ZXogcGFzIGQnYXV0cmVzIGUtbWFpbHMgZGUgbm90aWZpY2F0aW9uIHRhbnQgcXVlIHZvdXMgbidh
dXJleiBwYXMgbHUgbGUgc3VqZXQuCgpQb3VyIHZvdXMgZMOpc2Fib25uZXIgZGUgY2Ugc3VqZXQs
IHV0aWxpc2V6IGNlIGxpZW4gOgpodHRwczovL2xhZmlicmUuaW5mby9mcmVlLWxlcy1uZXdzL2Fo
LWNlLWZyZWUvP2FjdGlvbj1ub3RpZnkKCkNvcmRpYWxlbWVudCwKTCfDqXF1aXBlIExhIEZpYnJl
Lg==
--SMF-00096d1b9a26ff2fc92a2113acdfe18f--
On est d'accord qu'aucun client email ne tient compte de la partie que j'ai citée?
On est d'accord qu'aucun client email ne sait décoder la partie que j'ai citée?
-
si je monte une boite, je l’appelle 'hottemail' par exemple..., je mets un serveur chez OVH et que je vend (ou donne) des comptes emails a des gens et que je bloque la reception des IP de Buzzee , je suis condamnable en justice ?! je n'ai pas le droit de faire ce que je veux avec mon serveur email donc (quitte a perdre mes clients si je filtre trop ou si je revend leur emails) ? Il y a donc un legislation sur la gestion d'un service d'emails, des devoirs et droits que ca implique ? Cette juridiction est-elle liée au domain (hottemail.fr) ou a l'emplacement du serveur (DC en France) ou celui des clients ?
Ca n'est pas clair et net cette décision et un dangereux précédent non ?
Oui mais c'est toute la loi française qui est une daube immonde. Notamment cette histoire du "secret des correspondances" QUI N'A PAS DE SENS POUR UNE CARTE POSTALE. IL FAUT QUE LE JUGE SE FASSE GREFFER UN CERVEAU.
Bon sur le fond il y a un vrai problème de fond : les clients ne sont pas avertis du fait qu'il y ait un filtrage.
Le spam est un plaie et l'antispam est une plaie secondaire.
-
Si l'autorité judiciaire a envie de le comprendre comme ça, oui autrement non. Cette juridiction est suffisamment vague pour lui laisser appliquer la marge de son libre arbitre à un domaine dont elle ne connaît pas le fonctionnement.
Bah la conclusion est qu'il ne faut surtout pas avoir de siège en fRance, de représentation juridique en fRance, bref être un fantôme...
-
Pour moi, hormis des mails mal formatés RFC822 mon fournisseur d'e-mail doit tout me renvoyer, c'est son taf...
Et donc s'il voit passer
- un phishing authentifié
- une PJ en PDF avec un exploit connu
- une PJ contenant un virus
tu veux que ton FSI laisse passer?
:o
-
Je te parle de "
Une réponse a été postée par Marin sur un sujet que vous surveillez"
Tu peux m'expliquer à quoi ça correspond?
J'ai édité les fichiers de traduction pour les mails et j'ai supprimé tous les accents pour éviter cette transformation en code HTML (vu que je n'ai pas trouvé comment désactiver la transformation en html pour les mails)
-
On est d'accord qu'aucun client email ne tient compte de la partie que j'ai citée?
On est d'accord qu'aucun client email ne sait décoder la partie que j'ai citée?
A ce sujet je reste pragmatique.
Je vois à peu prêt ce qu'il se passe,de là à regarder si c'est du little ou du big indian,que ce soit codé sur 7 ou 8 bits que l'on utilise de l'UTF-8 ou de l'unicode, du plain-text ou de l'html cela va pas changer la face du monde.
Avec un peu de chance Outlook devrai le lire, un autre client pas nécessairement.
J'ai été confronté à ce dilemne, de faire le choix de savoir, quel est le rôle de "la poste" savoir si tout le courrier doit être transférer tel quel ou de filtrer du courrier à ses propres critères.
La conclusion à mon sens est bien de faire transiter la totalité des informations quelles quelles soient, ce n'est pas à la poste de savoir, si ce qu'elle fais transiter est de bon aloi ou pas, c'est au destinataire final de s'en préoccuper.Il faut exonérer le transporteur de toute responsabilité à ce sujet.
-
Depuis quand ces choses ont leur place dans un email?
vu dans ce sens là, ok je suis d'accord... soucis de traduction, peut-etre que le charset par defaut quand on active le FR est toujours en UTF7 ? donc pour passer "le plus partout" meme si c'est pas logique il a switché en HTML ?
-
Et donc s'il voit passer
- un phishing authentifié
- une PJ en PDF avec un exploit connu
- une PJ contenant un virus
tu veux que ton FSI laisse passer?
:o
En fait il le devrait.... ce qu'il est censé faire au minimum c'est se proteger contre DDoS et "small mail of the death" quand pour ce dernier c'est d'une évidence....
maintenant il est admis que de placer un AV en pré-process mail n'est pas si mal et devient un minimum de QoS alors que normalement c'est pas le devoir de l'ISP.
-
vu dans ce sens là, ok je suis d'accord... soucis de traduction, peut-etre que le charset par defaut quand on active le FR est toujours en UTF7 ? donc pour passer "le plus partout" meme si c'est pas logique il a switché en HTML ?
Hein? Quoi? UTF7? Où ça?
-
maintenant il est admis que de placer un AV en pré-process mail n'est pas si mal et devient un minimum de QoS alors que normalement c'est pas le devoir de l'ISP.
Mais si on ne protège pas les madames Michu (et les messieurs aussi), où va-t-on?
Sérieusement, c'est quand même sur les serveurs du fournisseur. Il n'a pas à relayer des malwares et des arnaques. (Pour prendre une analogie forcèment très moisie, la Poste n'a pas l'obligation de prendre en charge les colis qui font tic-tac. De même les pages perso de Free ne sont pas faites pour héberger les malwares. Même pas à des fins d'étude et d'analyse. C'est interdit, point.)
Et puis à un moment, si on veut sérieusement parler du secret des correspondances et de la vie privée sur le net, il faut sérieusement se mettre au chiffrement généralisé, et pas au chiffrement dans une poignée de cas (seulement quelques uns des services qui demandent une authentification : sites de banque/finance en ligne, accès à une BAL, envoi des emails, et lafibre.info) sur un périmètre très limité (chiffrement entre le client et le serveur email mais au delà tout est en clair).
Donc chiffrement entre client et serveur webmail/POP/IMAP/SMTP pour protéger les identifiants de connexion et les méta-données, et chiffrement des messages email. Bah oui mais c'est pas compatible avec le principe du webmail!
Donc il faut réaliser que dès qu'on parle de Webmail, on renonce au secret de la correspondance. On demande à un tier de traiter ses documents. Je ne sais pas si le jujoïde de cette affaire est seulement capable de conceptualiser ça!
Mais c'est déjà le cas en POP/IMAP. Le destinataire d'un email est bel et bien LE SERVEUR. Ici FREE.
Point final.
Circulez!
-
vivien, as-tu vérifié sur www-data@lafibre.info?
Delivery to the following recipient failed permanently:
www-data@lafibre.info
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain lafibre.info by mx1.ovh.net. [213.186.33.29].
The error that the other server returned was:
550 sorry, no mailbox here by that name [mail106] (#5.1.1)
Ouille!
-
il n'y a pas d'adresse mail www-data. Comme tu l'imagines, c'est le nom du compte Unix de Apache2.4, qui fait tourner SMF.
J'ai un peu de mal à comprendre pourquoi cela se retrouve dans l'en-tête.
-
il n'y a pas d'adresse mail www-data.
C'est un tort.
J'ai un peu de mal à comprendre pourquoi cela se retrouve dans l'en-tête.
Parce que c'est l'auteur des courriels, évidemment.
-
Hein? Quoi? UTF7? Où ça?
ca désolé: Content-Transfer-Encoding: 7bit
-
Ouuuuiiii.... et donc?
Il n'y a rien dans le message qui ressemble de très loin à de l'UTF7 ou de l'UTF n'importe quoi.
-
il n'y a pas d'adresse mail www-data. Comme tu l'imagines, c'est le nom du compte Unix de Apache2.4, qui fait tourner SMF.
J'ai un peu de mal à comprendre pourquoi cela se retrouve dans l'en-tête.
J'imagine que Apache lance un module dynamique PHP qui fork une commande sendmail avec son UID, et que sendmail utilise automatiquement le nom correspondant à cet UID comme source.
-
il n'y a pas d'adresse mail www-data. Comme tu l'imagines, c'est le nom du compte Unix de Apache2.4, qui fait tourner SMF.
J'ai un peu de mal à comprendre pourquoi cela se retrouve dans l'en-tête.
Tu passe bien par un smtp authentifié pour l'envoi de mail ?
Ca doit se trouver ici :
/index.php?action=admin;area=mailqueue;sa=settings;
https://www.knthost.com/smf/configure-smtp-email-simple-machines-forum
-
Je ne passe pas par un client SMTP, PHP envoie directement les e-mails.
Maintenant, SMF permet de passer par un serveur SMTP, peut-être tenter de passer en SMTP par 127.0.0.1 ?
Je suis en mode PHP et non SMTP. L'aide du paramétrage :
Cette option vous permet d'utiliser soit le réglage par défaut de PHP ou de l'outrepasser en utilisant le protocole SMTP. PHP ne supporte pas l'authentification (que plusieurs FAI requièrent maintenant) donc vous devriez vous renseigner avant d'utiliser cette option. Notez que SMTP peut être plus lent que sendmail et que certains serveurs ne prendront pas en compte les identifiants et mot de passe.
Vous n'avez pas à renseigner les informations SMTP si vous utilisez la configuration par défaut de PHP.
-
Le + propre à mes yeux c'est le smtp authentifié. Tu fais une adresse forum@lafibre.info et tu utilises le smtp de ton domaine avec login + pwd
-
Je suis en mode PHP et non SMTP. L'aide du paramétrage :
Cette option vous permet d'utiliser soit le réglage par défaut de PHP ou de l'outrepasser en utilisant le protocole SMTP. PHP ne supporte pas l'authentification (que plusieurs FAI requièrent maintenant) donc vous devriez vous renseigner avant d'utiliser cette option. Notez que SMTP peut être plus lent que sendmail et que certains serveurs ne prendront pas en compte les identifiants et mot de passe.
Vous n'avez pas à renseigner les informations SMTP si vous utilisez la configuration par défaut de PHP.
J'ai RIEN compris!
-
En tout cas j'ai supprimé le "Return-Path" qui apparaît dans l'en-tête du mail en commentant la ligne dans le code. (Return-Path indique à quelle adresse doivent être envoyées les réponses automatiques du serveur comme "no delivery" par exemple et est donc optionnel).
-
Ouuuuiiii.... et donc?
Il n'y a rien dans le message qui ressemble de très loin à de l'UTF7 ou de l'UTF n'importe quoi.
le corps du message n'est pas traité par les validateurs ou autres frontals MX.... c'est les headers qui sont intéréssants... par exemple pas de champ "FROM" ca doit etre poubelle direct
-
Le + propre à mes yeux c'est le smtp authentifié. Tu fais une adresse forum@lafibre.info et tu utilises le smtp de ton domaine avec login + pwd
La j'ai mes yeux qui piquent.....
-
J'ai RIEN compris!
Pour envoyer des messages, SMF utilise la cfg de PHP dans les parametres sendmail ou trucdugenre: soit les mails sont envoyés via un relais SMTP open ou soit par le SMTP du serveur.
tout depend de la config de PHP....
-
J'ai commenté la ligne avec "Return-Path:" (qui normalement met l'adresse de l'administrateur) et "Return-Path:" apparait toujours dans les en-têtes => c'est donc un autre logiciel qui rajoute le "Return-Path:" mais j'ai rien trouvé dans les options PHP
Le bout de code modifié :
// Construct the mail headers...
$headers = 'From: "' . $from_name . '" <' . (empty($modSettings['mail_from']) ? $webmaster_email : $modSettings['mail_from']) . '>' . $line_break;
$headers .= $from !== null ? 'Reply-To: <' . $from . '>' . $line_break : '';
//$headers .= 'Return-Path: ' . (empty($modSettings['mail_from']) ? $webmaster_email : $modSettings['mail_from']) . $line_break;
$headers .= 'Date: ' . gmdate('D, d M Y H:i:s') . ' -0000' . $line_break;
if ($message_id !== null && empty($modSettings['mail_no_message_id']))
$headers .= 'Message-ID: <' . md5($scripturl . microtime()) . '-' . $message_id . strstr(empty($modSettings['mail_from']) ? $webmaster_email : $modSettings['mail_from'], '@') . '>' . $line_break;
$headers .= 'X-Mailer: SMF' . $line_break;
-
La j'ai mes yeux qui piquent.....
Et pourquoi donc ? Tu préfères la solution d'envoyer un email en disant que tu es xxx@yyy.com sans prouver que tu es xxx@yyy.com ?
-
le corps du message n'est pas traité par les validateurs ou autres frontals MX.... c'est les headers qui sont intéréssants... par exemple pas de champ "FROM" ca doit etre poubelle direct
Hein? Le contenu des courriels pas analysés par les frontaux? Donc pas de détection de spam avant acceptation du message?
Tu plaisantes j'espère?
-
Et pourquoi donc ? Tu préfères la solution d'envoyer un email en disant que tu es xxx@yyy.com sans prouver que tu es xxx@yyy.com ?
Hein?
De quelle preuve veux-tu parler?
En quoi la méthode d'envoi des notifications de lafibre ne convient pas?
-
En tout cas j'ai supprimé le "Return-Path" qui apparaît dans l'en-tête du mail en commentant la ligne dans le code. (Return-Path indique à quelle adresse doivent être envoyées les réponses automatiques du serveur comme "no delivery" par exemple et est donc optionnel).
Return-Path: <www-data@lafibre.info>
Received: from lafibre.info (lafibre.info. [46.227.16.8])
by mx.google.com with ESMTP id e63si9162406wme.95.2016.01.31.06.23.49
for <_____@gmail.com>;
Sun, 31 Jan 2016 06:23:49 -0800 (PST)
Tu ne PEUX PAS enlever le return-path!
C'est l'information la plus basique d'un courriel : l'adresse d'expéditeur!
-
Pour envoyer des messages, SMF utilise la cfg de PHP dans les parametres sendmail ou trucdugenre: soit les mails sont envoyés via un relais SMTP open ou soit par le SMTP du serveur.
tout depend de la config de PHP....
En l'occurrence les messages sont tous envoyés par le serveur lafibre.info!
-
Je ne passe pas par un SMTP, PHP envoi directement la mail.
Maintenant, SMF permet de passer par un serveur SMTP, peut-être tenter de passer en SMTP par 127.0.0.1 ?
Je suis en mode PHP et non SMTP. L'aide du paramétrage :
Cette option vous permet d'utiliser soit le réglage par défaut de PHP ou de l'outrepasser en utilisant le protocole SMTP. PHP ne supporte pas l'authentification (que plusieurs FAI requièrent maintenant) donc vous devriez vous renseigner avant d'utiliser cette option. Notez que SMTP peut être plus lent que sendmail et que certains serveurs ne prendront pas en compte les identifiants et mot de passe.
Vous n'avez pas à renseigner les informations SMTP si vous utilisez la configuration par défaut de PHP.
Je pense avoir compris :
- ou bien tu utilises "le réglage par défaut de PHP" qui doit être de passer à un sendmail local (qui peut être un vrai service de courier, ou juste envoyer sur un relais)
- ou bien tu actives un client SMTP intégré qui doit être synchrone (sans file d'attente) donc potentiellement lent et qui envoie juste sur un relais, possiblement avec authentification login+pw
-
J'ai commenté la ligne avec "Return-Path:" (qui normalement met l'adresse de l'administrateur) et "Return-Path:" apparait toujours dans les en-têtes => c'est donc un autre logiciel qui rajoute le "Return-Path:" mais j'ai rien trouvé dans les options PHP
Une session de rattrapage sur les sessions SMTP s'impose...
Ce "Return-Path" INFORME le destinataire du message où aurait été envoyé le "bounce" SI le message AVAIT été rejeté (s'il voit le message c'est bien que ce n'est PAS le cas).
Il y a forcèment un champs "où dois-je envoyer les bounces".
Si le message NE DOIT JAMAIS générer un bounce QUOI QU'IL ARRIVE (notamment si le message EST un bounce) alors l'adresse DOIT être <>.
Bon, si tu m'expliquais ce que tu essaies de faire plutôt...
-
Tu passe bien par un smtp authentifié pour l'envoi de mail ?
NON
Et pourquoi donc ? Tu préfères la solution d'envoyer un email en disant que tu es xxx@yyy.com sans prouver que tu es xxx@yyy.com ?
Est-ce que tu n'as JAMAIS examiné un message de SMF?
Received: from lafibre.info (lafibre.info. [46.227.16.8])
by mx.google.com with ESMTP id s8si9262564wmf.111.2016.01.31.06.48.48
for <MOI@gmail.com>;
Sun, 31 Jan 2016 06:48:48 -0800 (PST)
Received-SPF: pass (google.com: domain of www-data@lafibre.info designates 46.227.16.8 as permitted sender) client-ip=46.227.16.8;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of www-data@lafibre.info designates 46.227.16.8 as permitted sender) smtp.mailfrom=www-data@lafibre.info
Received: by lafibre.info (Postfix, from userid 33)
id D0066A0F2C; Sun, 31 Jan 2016 15:48:47 +0100 (CET)
-
Je pense avoir compris :
- ou bien tu utilises "le réglage par défaut de PHP" qui doit être de passer à un sendmail local (qui peut être un vrai service de courier, ou juste envoyer sur un relais)
- ou bien tu actives un client SMTP intégré qui doit être synchrone (sans file d'attente) donc potentiellement lent et qui envoie juste sur un relais, possiblement avec authentification login+pw
Je viens de basculer sur le SMTP "localhost" sur le port 25.
-
Cela fonctionne : plus de "Return-Path: <www-data@lafibre.info>"
C'est bien "Return-Path: <ne-pas-repondre@lafibre.info>"
Les autres lignes modifiées dans le header :
Avant :
Received: by lafibre.info (Postfix, from userid 33)
id EA442A100B; Sun, 31 Jan 2016 18:51:39 +0100 (CET)
X-PHP-Originating-Script: 1000:ScheduledTasks.php
Après :
Received: from localhost (localhost [127.0.0.1])
by lafibre.info (Postfix) with SMTP id C630EA101D
for <mail.vivien@mondomaine.fr>; Sun, 31 Jan 2016 19:02:57 +0100 (CET)
J'ai supprimées les lignes présentes avant / après.
Je vois que SMF ne gère pas l'envoi de mail en IPv6 ("localhost" devrait privilégier l'IPv6 ::1 et non 127.0.0.1)
-
Ca n'est pas clair et net cette décision et un dangereux précédent non ?
C'est la notion même de secret de la correspondance transmise en clair qui est une connerie monstrueuse.
C'est typique de la "pensée juridique" qui est une absence de pensée. C'est dans le Code donc ça existe.
Ben non, c'est pas comme ça que le monde réel marche.
Sinon, cela veut dire que je peux envoyer en SMTP en clair un email non chiffré sur un Wifi ouvert et être protégé? Ben non, n'importe qui peut entendre.
De même pour le secret médical, ça ne marche pas comme ça.
Enfin pour ce dernier cas, je pense que même le plus con de juristoïdes comprendra que si quelqu'un hurle dans le métro qu'il a telle maladie les gens ne sont pas obligés de se boucher les oreilles.
-
Pour moi, hormis des mails mal formatés RFC822 mon fournisseur d'e-mail doit tout me renvoyer, c'est son taf...
Et si le rapport ham:spam est de 1:2? De 1:5? De 1:10? De 1:50?
-
Cela fonctionne : plus de "Return-Path: <www-data@lafibre.info>"
Comment ça? Qu'est-ce que tu essayes de faire?
-
Je confirme, ça marche avec un score de :
X-ProXaD-SC: state=HAM:SocialNetwork score=30
(compte Free pas sous Zimbra)
Cela fonctionne : plus de "Return-Path: <www-data@lafibre.info>"
Bravo, tu as réussi à atteindre le score 51 chez Free.
Fais encore quelques efforts, et tes emails seront tous rejetés.
-
Tu passe bien par un smtp authentifié pour l'envoi de mail ?
Tu te rends que tu parles d'un domaine lui appartenant? ???
-
Bravo, tu as réussi à atteindre le score 51 chez Free.
Fais encore quelques efforts, et tes emails seront tous rejetés.
Ma modification a dégradé le score ?
J'ai un peu de mal à comprendre.
J'ai maintenant une adresse Return-Path qui est valide.
-
Ma modification a dégradé le score ?
J'ai un peu de mal à comprendre.
Le détail du calcul du score de l'antispam de GOTO n'est pas donné!
J'ai maintenant une adresse Return-Path qui est valide.
Tant mieux. Tu vas pouvoir nous dire s'il y a des retours.
-
Et pourquoi donc ? Tu préfères la solution d'envoyer un email en disant que tu es xxx@yyy.com sans prouver que tu es xxx@yyy.com ?
Le SMTPAUTH n'est pas fait pour les webmasters.
-
Hein? Le contenu des courriels pas analysés par les frontaux? Donc pas de détection de spam avant acceptation du message?
Tu plaisantes j'espère?
Bien sur... que non...
T'as deja vu un mailer-daemon rejeter un spam ??? je parle de la premiere étape, spamassasin peut etre mis sur des frontaux secondaires pour des grois serveurs....
-
Return-Path: <www-data@lafibre.info>
Received: from lafibre.info (lafibre.info. [46.227.16.8])
by mx.google.com with ESMTP id e63si9162406wme.95.2016.01.31.06.23.49
for <_____@gmail.com>;
Sun, 31 Jan 2016 06:23:49 -0800 (PST)
Tu ne PEUX PAS enlever le return-path!
C'est l'information la plus basique d'un courriel : l'adresse d'expéditeur!
c'est drole, en 2000 quand je postais des mails d'essais à la main sous TELNET sur smtp.compuserve.com par exemple qui etait open j'ai jamais utilisé ce champ...
telnet servername portnumber
MAIL FROM Admin@test.com
RCPT TO: User@Domain.Com
DATA
Subject: test message
This is a test message you will not see a response from this command.
.
QUIT
-
Je viens de basculer sur le SMTP "localhost" sur le port 25.
tu etais sur quoi avant ???
-
Et si le rapport ham:spam est de 1:2? De 1:5? De 1:10? De 1:50?
c'est pas son taf.
-
Sinon, cela veut dire que je peux envoyer en SMTP en clair un email non chiffré sur un Wifi ouvert et être protégé? Ben non, n'importe qui peut entendre.
Si tu refais la même analogie en remplaçant Wireshark sur ta carte en mode moniteur par un passe PTT, le résultat est surprenant.
Quel est le plus gros coût d'entrée entre les deux ? Quelques euros vs un seuil relatif de compétences techniques.
-
Bien sur... que non...
T'as deja vu un mailer-daemon rejeter un spam ???
Bien sûr, c'est la seule façon de faire raisonnable.
Sinon, que fais-tu si tu détectes un spam?
-
c'est drole, en 2000 quand je postais des mails d'essais à la main sous TELNET sur smtp.compuserve.com par exemple qui etait open j'ai jamais utilisé ce champ...
telnet servername portnumber
MAIL FROM Admin@test.com
RCPT TO: [b]User@Domain.Com[/b]
Tu viens de l'écrire gros malin : User@Domain.Com
Une session de rattrapage sur les sessions SMTP s'impose...
Ce "Return-Path" INFORME le destinataire du message où aurait été envoyé le "bounce" SI le message AVAIT été rejeté (s'il voit le message c'est bien que ce n'est PAS le cas).
-
Si tu refais la même analogie en remplaçant Wireshark sur ta carte en mode moniteur par un passe PTT, le résultat est surprenant.
Quel est le plus gros coût d'entrée entre les deux ? Quelques euros vs un seuil relatif de compétences techniques.
Le fait d'écouter une fréquence radio non licenciée vs. l'accès un local privé.
-
c'est pas son taf.
C'est quoi son taf?
Héberger tous les merdes du monde?
Le email est gratuit. Il n'y a pas de droit pour un message à être acheminé.
-
tu etais sur quoi avant ???
Regarde les headers :
nouveau :
Received-SPF: pass (google.com: domain of ne-pas-repondre@lafibre.info designates 46.227.16.8 as permitted sender) client-ip=46.227.16.8;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of ne-pas-repondre@lafibre.info designates 46.227.16.8 as permitted sender) smtp.mailfrom=ne-pas-repondre@lafibre.info
Received: from localhost (localhost [127.0.0.1])
by lafibre.info (Postfix) with SMTP id E73B5A0D99
for <MOI@gmail.com>; Mon, 1 Feb 2016 08:12:07 +0100 (CET)
Subject: =?UTF-8?B?UmVwb25zZSBhIHVuIHN1amV0IDogRnJlZSBibG9xdWUgbGVzIG1haWxzIGVudm95w6lzIHBhciBXYW5ub25jZSAoc2l0ZSBkZSBwZXRpdGVzIGFubm9uY2VzKQ==?=
To: <MOI@gmail.com>
Mime-Version: 1.0
From: "La Fibre" <ne-pas-repondre@lafibre.info>
Date: Mon, 01 Feb 2016 07:11:55 -0000
C'est envoyé par SMTP depuis un client sur 127.0.0.1.
ancien :
Received-SPF: pass (google.com: domain of www-data@lafibre.info designates 46.227.16.8 as permitted sender) client-ip=46.227.16.8;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of www-data@lafibre.info designates 46.227.16.8 as permitted sender) smtp.mailfrom=www-data@lafibre.info
Received: by lafibre.info (Postfix, from userid 33)
id 8D640A1287; Sun, 31 Jan 2016 00:02:02 +0100 (CET)
To: MOI@gmail.com
Subject: =?UTF-8?B?UsOpcG9uc2Ugw6AgdW4gc3VqZXQgOiBPcmFuZ2UgZW4gZGlzY3Vzc2lvbiBwb3VyIHJhY2hldGVyIEJvdXlndWVzIFRlbGVjb20gPw==?=
X-PHP-Originating-Script: 1000:ScheduledTasks.php
From: "La Fibre" <ne-pas-repondre@lafibre.info>
Date: Sat, 30 Jan 2016 22:58:22 -0000
C'était posté directement par ScheduledTasks.php (UID 33).
-
Bien sûr, c'est la seule façon de faire raisonnable.
Sinon, que fais-tu si tu détectes un spam?
Le donner au client final humain en brut de coffrage et là, son antispam intégré au webmail ou a ses logiciels de messagerie via POP3/IMAP4en fera ce qu'il veut.... il pourra meme tous les lire si il veut ce client final humain....
-
Et donc s'il y a 100 fois plus de spam que de vrais courrier, on divise la capacité de traitement par 100, c'est cool.
-
Regarde les headers :
nouveau :
Received-SPF: pass (google.com: domain of ne-pas-repondre@lafibre.info designates 46.227.16.8 as permitted sender) client-ip=46.227.16.8;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of ne-pas-repondre@lafibre.info designates 46.227.16.8 as permitted sender) smtp.mailfrom=ne-pas-repondre@lafibre.info
Received: from localhost (localhost [127.0.0.1])
by lafibre.info (Postfix) with SMTP id E73B5A0D99
for <MOI@gmail.com>; Mon, 1 Feb 2016 08:12:07 +0100 (CET)
Subject: =?UTF-8?B?UmVwb25zZSBhIHVuIHN1amV0IDogRnJlZSBibG9xdWUgbGVzIG1haWxzIGVudm95w6lzIHBhciBXYW5ub25jZSAoc2l0ZSBkZSBwZXRpdGVzIGFubm9uY2VzKQ==?=
To: <MOI@gmail.com>
Mime-Version: 1.0
From: "La Fibre" <ne-pas-repondre@lafibre.info>
Date: Mon, 01 Feb 2016 07:11:55 -0000
C'est envoyé par SMTP depuis un client sur 127.0.0.1.
ancien :
Received-SPF: pass (google.com: domain of www-data@lafibre.info designates 46.227.16.8 as permitted sender) client-ip=46.227.16.8;
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of www-data@lafibre.info designates 46.227.16.8 as permitted sender) smtp.mailfrom=www-data@lafibre.info
Received: by lafibre.info (Postfix, from userid 33)
id 8D640A1287; Sun, 31 Jan 2016 00:02:02 +0100 (CET)
To: MOI@gmail.com
Subject: =?UTF-8?B?UsOpcG9uc2Ugw6AgdW4gc3VqZXQgOiBPcmFuZ2UgZW4gZGlzY3Vzc2lvbiBwb3VyIHJhY2hldGVyIEJvdXlndWVzIFRlbGVjb20gPw==?=
X-PHP-Originating-Script: 1000:ScheduledTasks.php
From: "La Fibre" <ne-pas-repondre@lafibre.info>
Date: Sat, 30 Jan 2016 22:58:22 -0000
C'était posté directement par ScheduledTasks.php (UID 33).
ok en fait c'est envoyé surement aussi par postfix ;) mais postfix ne rajoute plus d'headers car le minimum des headers est placé par ScheduledTasks.php ......
-
Le email est gratuit. Il n'y a pas de droit pour un message à être acheminé.
sauf si tu payes pour les avoir tous (sauf les virus) comme je fais.
-
Et donc s'il y a 100 fois plus de spam que de vrais courrier, on divise la capacité de traitement par 100, c'est cool.
j'ai 99% de merdes dans mon quota oui.
-
Tu viens de l'écrire gros malin : User@Domain.Com
RCPT TO: User@Domain.Com
=
Return-Path:User@Domain.Com
ah ?
-
sauf si tu payes pour les avoir tous (sauf les virus) comme je fais.
Ah OK mais l'envoyeur lui ne paye pas!
C'est une piste qui a été suggérée par Bill Gates, qui éradiquera le spam il y a plusieurs années.
-
RCPT TO: User@Domain.Com
=
Return-Path:User@Domain.Com
ah ?
Non, c'est le FROM: qui définit le Return-Path!
Return-Path = origine
TO = destination
-
ok en fait c'est envoyé surement aussi par postfix ;) mais postfix ne rajoute plus d'headers car le minimum des headers est placé par ScheduledTasks.php ......
C'est dans les deux cas postfix sauf qu'il n'est pas invoqué de la même façon :
- dans un cas, il est utilisé comme serveur SMTP (en TCP/IP), d'où l'IP source
- dans l'autre cas, il est utilisé localement via sendmail (comme en ligne de commande), d'où l'UID
donc la trace n'est pas la même et les entêtes peuvent différer un chouïa.
Après je suis pas un expert en email, hein.
-
Le fait d'écouter une fréquence radio non licenciée vs. l'accès un local privé.
Et moi, je choisis de m'insurger contre cette nuée de boîtes aux lettres qui envahissent outrageusement l'espace public.
-
Non, c'est le FROM: qui définit le Return-Path!
Return-Path = origine
TO = destination
exact c'était MAIL FROM.
bon bref le return-path n'est pas un header indispensable et minimal.
-
> - dans un cas, il est utilisé comme serveur SMTP (en TCP/IP), d'où l'IP source
> - dans l'autre cas, il est utilisé localement via sendmail (comme en ligne de commande), d'où l'UID
> donc la trace n'est pas la même et les entêtes peuvent différer un chouïa.
> Après je suis pas un expert en email, hein.
mais là, tu en as les bonnes bases :)
-
Et moi, je choisis de m'insurger contre cette nuée de boîtes aux lettres qui envahissent outrageusement l'espace public.
Plait-il? ???
-
exact c'était MAIL FROM.
bon bref le return-path n'est pas un header indispensable et minimal.
C'est un entête ajouté par le serveur recevant le message, pour l'information de l'utilisateur final.
-
Bravo, tu as réussi à atteindre le score 51 chez Free.
Fais encore quelques efforts, et tes emails seront tous rejetés.
J'ai trouvé la cause dans un mail de rejet : "Mime-Version: 1.0" est présent deux fois dans les header.
The message WAS NOT relayed to:
<xxxxxx@protelco.fr>:
554 5.6.0 Reject, id=00375-10 - BAD HEADER
This nondelivery report was generated by the program amavisd-new at host
mx0.protelco.fr. Our internal reference code for your message is
00375-10/xp-Lh25U4DKt
INVALID HEADER
Duplicate header field: "MIME-Version"
Return-Path: <ne-pas-repondre@lafibre.info>
From: "La Fibre" <ne-pas-repondre@lafibre.info>
Message-ID: <0444175db05562f7a040dc8ced278e64-p37494@lafibre.info>
X-Mailer: SMF
Subject: Nouveau message personnel : (Pas de titre)
dsn_status
Reporting-MTA: dns; mx0.protelco.fr
Received-From-MTA: smtp; mx0.protelco.fr ([127.0.0.1])
Arrival-Date: Wed, 3 Feb 2016 15:55:12 +0100 (CET)
Original-Recipient: rfc822;xxxxxx@protelco.fr
Final-Recipient: rfc822;xxxxxx@protelco.fr
Action: failed
Status: 5.6.0
Diagnostic-Code: smtp; 554 5.6.0 Reject, id=00375-10 - BAD HEADER
Last-Attempt-Date: Wed, 3 Feb 2016 15:55:12 +0100 (CET)
Final-Log-ID: 00375-10/xp-Lh25U4DKt
header
Return-Path: <ne-pas-repondre@lafibre.info>
Received: from lafibre.info (lafibre.info [46.227.16.8])
by mx0.protelco.fr (Postfix) with ESMTP id A5A03781889
for <xxxxxx@protelco.fr>; Wed, 3 Feb 2016 15:55:11 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by lafibre.info (Postfix) with SMTP id C8573A1025
for <xxxxxx@protelco.fr>; Wed, 3 Feb 2016 15:55:10 +0100 (CET)
Subject: Nouveau message personnel : (Pas de titre)
To: <xxxxxx@protelco.fr>
Mime-Version: 1.0
From: "La Fibre" <ne-pas-repondre@lafibre.info>
Date: Wed, 03 Feb 2016 14:55:10 -0000
Message-ID: <0444175db05562f7a040dc8ced278e64-p37494@lafibre.info>
X-Mailer: SMF
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="SMF-618a579e8f019205dc800254688b6104"
Content-Transfer-Encoding: 7bit
-
N'importe quoi!
Received: by lafibre.info (Postfix, from userid 33)
id 8DC4BA0F42; Thu, 21 Jan 2016 16:36:33 +0100 (CET)
To: MOI@gmail.com
Subject: =?UTF-8?B?UsOpcG9uc2Ugw6AgdW4gc3VqZXQgOiBVbmUgbm91dmVsbGUgbGl2ZWJveCBwb3VyIGZpbiAyMDE1IC4uLi4uLiBkaXNwb25pYmxlIHF1ZSBkw6lidXQgMjAxNg==?=
X-PHP-Originating-Script: 1000:ScheduledTasks.php
From: "La Fibre" <ne-pas-repondre@lafibre.info>
Date: Thu, 21 Jan 2016 15:32:54 -0000
Message-ID: <e8f5a488a4ef41577461634ac53fe03d-m298319@lafibre.info>
X-Mailer: SMF
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="SMF-8a98a67a85e21e107e08c4371a5823a6"
Content-Transfer-Encoding: 7bit
Cela n'apparaissait qu'une seule fois.
-
Le + propre à mes yeux c'est le smtp authentifié. Tu fais une adresse forum@lafibre.info et tu utilises le smtp de ton domaine avec login + pwd
Et comment le consommateur profite-t-il de cela?
-
Si tu refais la même analogie en remplaçant Wireshark sur ta carte en mode moniteur par un passe PTT, le résultat est surprenant.
Quel est le plus gros coût d'entrée entre les deux ? Quelques euros vs un seuil relatif de compétences techniques.
Oui, poser une "bretelle" est une ancienne "tradition" qui ne demande pas forcèment des compétences techniques très élevées.
Mais cela demande de prendre un risque même faible. Et on peut inspecter une armoire en cas de doute.
La mise sur écoute passive :
- d'un réseau Wifi ouvert
- au niveau d'un routeur que tu contrôles
est parfaitement indétectable pour toute personne n'ayant pas accès à l'ordinateur qui écoute et peut être enregistre les informations.
Cela me semble différent d'une attaque informatique d'un poste client, de la coupure d'un câble, etc.