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.

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?

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.

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?

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.

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!

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.