Il y a une problématique toute autre pour le SPAM, pour laquelle on ( lautre.net) est confronté : on fournit des mails et des espaces web à nos membres (~1000+). Ces espaces web se font parfois trouer, et servent à envoyer plein de spam à coup de mail() en php. Ça on voit assez facilement comment limiter.
Le soucis c'est plus quand ils se font voler leur password mail (il semblerait que ce soit plutôt lié à leur machine qu'à la sécurité du transport). Dans ce cas, on se retrouve à se prendre des mail report avec un User-Agent: SquirelMail qui est un des webmail que l'on propose...
Et c'est pour cette seconde catégorie qu'il est difficile pour nous de lutter : on pourrait mettre un anti-spam en sortie, mais niveau neutralité, on a vu mieux. Du coup, on a pensé à faire des filtres genre, si le From est pas géré par nous, on bloque. Sauf que parfois, les spammeurs utilisent compte@compte.lautre.net qui est le mail générique du membre.. Donc ça passerait à travers.
Des idées pour lutter contre le spam sortant pour une situation comme celle-ci?
2014-05-03 21:15 GMT+02:00 Christophe tech@stuxnet.org:
Salut la liste,
C'est un post un peu généraliste, dans le but de faire un peu le point sur les techniques actuelles de lutte (ou pas ...) .
Je me pose pas mal de questions sur les mesures à prendre pour lutter contre le Spam, sans dans la mesure du possible , être trop restrictif. D'un point de vue technique, mais aussi d'un point de vue légal.
D'un point de vue technique : les possibilités sont nombreuses, et j'en oublie surement ...
Reverse DNS : C'est la base d'en avoir un (donc bannir ceux qui n'en présentent pas) , mais baser une vérification dessus (genre HELO = reverse), c'est juste aller au casse pipe.
RBL (les listes étant nombreuses) : Particulièrement efficace, à utiliser selon le contexte, si par exemple on ne veut pas que des personnes/entreprises qui hébergent leur propre serveur mail derrière une connexion résidentielle passent à la trappe (cas fréquemment rencontré).
SPF : Plutôt sympa dans le principe, si tant que les DNS des domaines expéditeurs soient correctement configurés.
Amavis (couplé à clamav, spamassassin, ou autre) Trop rien à redire, et très rares ont été les faux-positifs dans ce cas.
Vérifications sur les champs From et le return-path des e-mails recus : Sur le From , ca fonctionne plutôt bien. Sur le return-path c'est à utiliser avec prudence.
Si je prend un exemple récent : Si vous êtes client OVH et que vous faites cette vérification , ca donne lieu à certaines déconvenues .
From: support@ovh.com Return path: xxx-ovh@nichandle.ovh.net
(nichandle.ovh.net n'est pas en mesure de recevoir de mails ... et donc impossible de vérifier que le return-path est correct)
DKIM et DMARC : Gros sujet de polémique ces derniers temps, particulièrement en ce qui concerne les messages en provenance des mailing lists : les entêtes et contenus étant la majorité du temps modifiés au cours du transit par le moteur de ML.
Sender ID: Existe t'il des implémentations libres à ce sujet ?
Greylist : Sympa aussi dans le principe et particulièrement efficace, mais susceptible d'apporter d'autres soucis, si on est, dans l'urgence, en attente d'un mail envoyé par un client alors qu'on est au téléphone avec ce dernier (ou inversement). (jusqu'à présent, j'ai fait sans, mais je vois bien ce qu'il se passe dans le `postqueue -p̀ quand on envoie ... ).
Je suis bien conscient que tout ceci est question de compromis, et de contexte.
J'aimerais toutefois avoir vos avis, sur ce qui selon vous est une configuration "acceptable" à l'heure actuelle.
D'un point de vue légal (moins simple) :
Si tant est qu'une adresse mail qui reçoit du spam n'a été inscrite que sur un seul et unique service sur un nom de domaine "privé", (à comprendre, pas du gmail, ou tout autre service ouvert au public), est-on en mesure de porter plainte contre le service concerné pour "fuite/revente d'informations" et/ou "atteinte à la vie privée" ?
@ Bientôt . Christophe. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/