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.
Salut,
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.
Non je ne suis pas d'accord. D'ailleurs même google impose un reverse DNS en IPv6 si tu veux causer avec eux. Donc, ca permet aux "gens" de se responsabiliser.
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é).
Les RBL -> Out, c'est n'importe quoi, trop de faux positifs. A utiliser dans Spam Assassin et polcyweight.
SPF : Plutôt sympa dans le principe, si tant que les DNS des domaines expéditeurs soient correctement configurés.
Ca fait plus de bien que de mal.
Amavis (couplé à clamav, spamassassin, ou autre) Trop rien à redire, et très rares ont été les faux-positifs dans ce cas.
Idem.
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)
Effectivement trop dangereux. Sans compter les ml.
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.
Je sens que ca va être le standard. DKIM est déjà méga facile a implémenter avec amavisd-new. Quand a DMARC... Wait & see pour ma part.
Sender ID: Existe t'il des implémentations libres à ce sujet ?
Hein ? :)
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 ... ).
Alors dans les postfix récents il y a un postcreen. Ca marche très bien. Beaucoup mieux que du greylisting que j'ai pour ma part simplement dégagé car ... Trop des gens pensent que le mail est une messagerie instantanée...
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.
Done.
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" ?
Je suis pour le mail jetable. Donc pour des gens comme sncf / edf / gdf / .. ils ont le droit a leur mail personnalisé.
Si jamais je reçois la moindre saloperie (c'est arrivé une fois pour ma part), un certain mail + spam au tel leur a bien fait comprendre que au second mails de pub, il avaient droit a une plainte à la CNIL...
Après, déjà : ne pas ecrire dans une mailing liste archivée en public permet de régler le pb.
Autre détail : les auto-respondeur = a proscrire... C'est extrêmement dangereux et aident les spammeurs a tester si les mails existent. Sans compter le social engineering qui peux en découdre...
Xavier
Le sam 3 mai 14 à 22:49:43 +0200, Xavier Beaudouin kiwi@oav.net écrivait :
Salut,
Salut,
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.
Je sens que ca va être le standard. DKIM est déjà méga facile a implémenter avec amavisd-new. Quand a DMARC... Wait & see pour ma part.
Difficile d'y échapper ! Les ML de FreeBSD.org viennent d'ailleurs de prendre le truc en compte, car le nombre de rejets (bounces) augmentait réguliérement.
Sender ID: Existe t'il des implémentations libres à ce sujet ?
Hein ? :)
Ben oui, il y a au moins ENMA, qui implémente SPF et Sender Id. Cf. http://sourceforge.net/projects/enma/.
Par contre, je ne sais pas ce que ça vaut...
Bonjour,
Le 04/05/2014 12:24, Thierry Thomas a écrit :
Sender ID: Existe t'il des implémentations libres à ce sujet ?
Ben oui, il y a au moins ENMA, qui implémente SPF et Sender Id. Cf. http://sourceforge.net/projects/enma/.
Par contre, je ne sais pas ce que ça vaut...
Merci pour le lien Thierry.
@+ Christophe.
Hello Xavier, merci pour tes réponses,
Le 03/05/2014 22:49, Xavier Beaudouin a écrit :
Salut,
Reverse DNS :
[...]
Non je ne suis pas d'accord. D'ailleurs même google impose un reverse DNS en IPv6 si tu veux causer avec eux. Donc, ca permet aux "gens" de se responsabiliser.
Je suis parfaitement d'accord. Mon interrogation était plus de savoir, si le reverse DNS de l'IP (v4 ou v6, peu importe) devait nécessairement correspondre au HELO/EHLO qui est transmis lors de la transaction SMTP.
(en partant du postulat que certains n'ont pas trop le choix et/ou ne peuvent pas attribuer une adresse IP publique spécifiquement à leur serveur de messagerie).
Et du coup, n'est il pas "trop" restrictif de refuser des mails si ces deux champs diffèrent ?
Les RBL -> Out, c'est n'importe quoi, trop de faux positifs. A utiliser dans Spam Assassin et polcyweight.
Si j'ai bien compris, le but serait plus de l'utiliser comme une composante de détection dans SpamAssassin qui fait varier le score final, plutôt que comme test à l'entrée ?
C'est pô bête ça ;). Je me le garde dans un coin.
Sinon, au niveau listes, lesquelles semblent les plus fiables ?
J'ai pris l'habitude d'utiliser cbl.abuseat.org, et sbl.spamhaus.org : je n'ai pas vraiment eu à m'en plaindre jusqu'à présent.
Greylist :
[...]
Alors dans les postfix récents il y a un postcreen. Ca marche très bien. Beaucoup mieux que du greylisting que j'ai pour ma part simplement dégagé car ... Trop des gens pensent que le mail est une messagerie instantanée...
Je ne connaissais pas, je vais regarder ça de plus près ;) Merci pour l'info.
D'un point de vue légal (moins simple) :
[...]
Je suis pour le mail jetable. Donc pour des gens comme sncf / edf / gdf / .. ils ont le droit a leur mail personnalisé.
Je suis partisan de cette pratique également, d’où la question d'origine ;).
Si jamais je reçois la moindre saloperie (c'est arrivé une fois pour ma part), un certain mail + spam au tel leur a bien fait comprendre que au second mails de pub, il avaient droit a une plainte à la CNIL...
C'est une technique aussi ;).
Après, déjà : ne pas ecrire dans une mailing liste archivée en public permet de régler le pb.
On est d'accord, les bots sont friands de ce genre de pages web ...
Autre détail : les auto-respondeur = a proscrire... C'est extrêmement dangereux et aident les spammeurs a tester si les mails existent. Sans compter le social engineering qui peux en découdre...
Je n'y avais pas pensé (on ne les utilise pas de toutes façons), mais en effet ;)
@+ Christophe.
Salut,
Reverse DNS :
[...]
Non je ne suis pas d'accord. D'ailleurs même google impose un reverse DNS en IPv6 si tu veux causer avec eux. Donc, ca permet aux "gens" de se responsabiliser.
Je suis parfaitement d'accord. Mon interrogation était plus de savoir, si le reverse DNS de l'IP (v4 ou v6, peu importe) devait nécessairement correspondre au HELO/EHLO qui est transmis lors de la transaction SMTP.
(en partant du postulat que certains n'ont pas trop le choix et/ou ne peuvent pas attribuer une adresse IP publique spécifiquement à leur serveur de messagerie).
Et du coup, n'est il pas "trop" restrictif de refuser des mails si ces deux champs diffèrent ?
Dans les RFC il y a un MAY, ce qui veux dire, il est possible que oui.
Par contre rien ne t'empêche d'avoir DEUX PTR a ton ip. Et dans un FQDN il y a Fully Qualified Domain Name, faire des tests si EHLO mybadly.hostname.local, risque de s'exposer a des refus de certains serveurs de mails.
Après pour moi, les spammer passant par des drones bots, ca fait un bon antispam. Reste a prévoir une white liste pour les admins boulets...
Les RBL -> Out, c'est n'importe quoi, trop de faux positifs. A utiliser dans Spam Assassin et polcyweight.
Si j'ai bien compris, le but serait plus de l'utiliser comme une composante de détection dans SpamAssassin qui fait varier le score final, plutôt que comme test à l'entrée ?
C'est ce que je fais, il y a plein de CF pour ca chez spamassassin.
C'est pô bête ça ;). Je me le garde dans un coin.
Sinon, au niveau listes, lesquelles semblent les plus fiables ?
J'ai pris l'habitude d'utiliser cbl.abuseat.org, et sbl.spamhaus.org : je n'ai pas vraiment eu à m'en plaindre jusqu'à présent.
J'utilise ca:
reject_rbl_client dev.null.dk, reject_rbl_client virbl.dnsbl.bit.nl,
Sur d'autres serveurs moins "grand public avec des gens relou(tm)(c)(r)", les deux que tu as cité sont aussi utilisés. Mais attention, certains commerciaux(tm)(c)(r) peuvent se plaindre:)
Greylist :
[...]
Alors dans les postfix récents il y a un postcreen. Ca marche très bien. Beaucoup mieux que du greylisting que j'ai pour ma part simplement dégagé car ... Trop des gens pensent que le mail est une messagerie instantanée...
Je ne connaissais pas, je vais regarder ça de plus près ;) Merci pour l'info.
C'est un peu vieux :D
/Xavier
Hello,
Le 04/05/2014 20:00, Xavier Beaudouin a écrit :
Reverse DNS :
[...]
(en partant du postulat que certains n'ont pas trop le choix et/ou ne peuvent pas attribuer une adresse IP publique spécifiquement à leur serveur de messagerie).
Et du coup, n'est il pas "trop" restrictif de refuser des mails si ces deux champs diffèrent ?
Dans les RFC il y a un MAY, ce qui veux dire, il est possible que oui.
Par contre rien ne t'empêche d'avoir DEUX PTR a ton ip.
Je suis bien d'accord avec toi, si toutefois, tout le monde avait la possibilité de le faire ... (en d'autres termes , gérer son réseau de bout en bout) .
Va essayer de faire ca avec un abonnement Orange dit "pro" . (déjà tenter un PTR sur la seule IP dispo ? C'est déjà la top classe , elle est fixe ! ;) )
Et dans un FQDN il y a Fully Qualified Domain Name, faire des tests si EHLO mybadly.hostname.local, risque de s'exposer a des refus de certains serveurs de mails.
Ca, oui c'est évident ;). Et je serais le premier à le refuser :
| reject_non_fqdn_sender
RBL
[...] J'utilise ca:
reject_rbl_client dev.null.dk, reject_rbl_client virbl.dnsbl.bit.nl,
A titre d'info (ce n'est pas la première fois que j'essaie) :
| L'erreur suivante s'est produite en essayant d'accéder à l'URL : http://null.dk/ | | La connexion 84.243.240.2 a échouée. | | Le système a retourné : (110) Connection timed out
Est-ce que dev.null.dk est encore active ?
Sur d'autres serveurs moins "grand public avec des gens relou(tm)(c)(r)", les deux que tu as cité sont aussi utilisés. Mais attention, certains commerciaux(tm)(c)(r) peuvent se plaindre:)
Greylist :
C'est un peu vieux :D
Je le conçois, mais je touche à tellement de choses différentes, qu'il est parfois difficile de se tenir au courant de tout ;) .
@Tous :
Merci pour toutes ces informations sur la liste et en privé : vous m'avez donné du grain à moudre ;) .
A bientôt. Christophe.
Salut,
Par contre rien ne t'empêche d'avoir DEUX PTR a ton ip.
Je suis bien d'accord avec toi, si toutefois, tout le monde avait la possibilité de le faire ... (en d'autres termes , gérer son réseau de bout en bout) .
Va essayer de faire ca avec un abonnement Orange dit "pro" . (déjà tenter un PTR sur la seule IP dispo ? C'est déjà la top classe , elle est fixe ! ;) )
Bah... Déjà si ton FAI est pas bon : changer de FAI. Des gens qui font de l'ip fixe en ADSL *ET* qui laissent le choix de pouvoir mettre des PTR correct aux IP, il y en as plein. Des petits et des gros, même des fois moins cher que l'AS3215.
Et dans un FQDN il y a Fully Qualified Domain Name, faire des tests si EHLO mybadly.hostname.local, risque de s'exposer a des refus de certains serveurs de mails.
Ca, oui c'est évident ;). Et je serais le premier à le refuser :
| reject_non_fqdn_sender
+1
RBL
[...] J'utilise ca:
reject_rbl_client dev.null.dk, reject_rbl_client virbl.dnsbl.bit.nl,
A titre d'info (ce n'est pas la première fois que j'essaie) :
| L'erreur suivante s'est produite en essayant d'accéder à l'URL : http://null.dk/ | | La connexion 84.243.240.2 a échouée. | | Le système a retourné : (110) Connection timed out
Est-ce que dev.null.dk est encore active ?
May 7 11:49:40 172.31.1.2 postfix/smtpd[13289]: NOQUEUE: reject: RCPT from srv-154-129.out-neo-b-1.com[37.59.154.129]:57007: 550 5.7.1 Service unavailable; Client host [37.59.154.129] blocked using dev.null.dk; Blocked http://www.spamsources.fabel.dk/ip/37.59.154.129; from=bounces@sf3.co to=cEnSoReD@caudium.net proto=ESMTP helo=<srv-154-129.out-neo-b-1.com>
Je confirme que oui :p
/Xavier
Hello,
Le 07/05/2014 14:46, Xavier Beaudouin a écrit :
Va essayer de faire ca avec un abonnement Orange dit "pro" . (déjà tenter un PTR sur la seule IP dispo ? C'est déjà la top classe , elle est fixe ! ;) )
Bah... Déjà si ton FAI est pas bon : changer de FAI. Des gens qui font de l'ip fixe en ADSL *ET* qui laissent le choix de pouvoir mettre des PTR correct aux IP, il y en as plein. Des petits et des gros, même des fois moins cher que l'AS3215.
Je suis une fois de plus d'accord, et je ne parlais pas de mon FAI ;) (je prenais ce cas comme simple exemple) mais bien de celui qui, hébergeant son serveur derrière une liaison de ce type pointe le bout de son nez sur (au hasard) mon serveur de messagerie.
Est-ce que dev.null.dk est encore active ?
May 7 11:49:40 172.31.1.2 postfix/smtpd[13289]: NOQUEUE: reject: RCPT from srv-154-129.out-neo-b-1.com[37.59.154.129]:57007: 550 5.7.1 Service unavailable; Client host [37.59.154.129] blocked using dev.null.dk; Blocked http://www.spamsources.fabel.dk/ip/37.59.154.129; from=bounces@sf3.co to=cEnSoReD@caudium.net proto=ESMTP helo=<srv-154-129.out-neo-b-1.com>
Je confirme que oui :p
Tout va bien alors ;) .
@+ Christophe.
On 04/05/14 18:27, Christophe wrote:
Hello Xavier, merci pour tes réponses,
Le 03/05/2014 22:49, Xavier Beaudouin a écrit :
Salut,
Reverse DNS :
[...]
Non je ne suis pas d'accord. D'ailleurs même google impose un reverse DNS en IPv6 si tu veux causer avec eux. Donc, ca permet aux "gens" de se responsabiliser.
Je suis parfaitement d'accord. Mon interrogation était plus de savoir, si le reverse DNS de l'IP (v4 ou v6, peu importe) devait nécessairement correspondre au HELO/EHLO qui est transmis lors de la transaction SMTP.
(en partant du postulat que certains n'ont pas trop le choix et/ou ne peuvent pas attribuer une adresse IP publique spécifiquement à leur serveur de messagerie).
Et du coup, n'est il pas "trop" restrictif de refuser des mails si ces deux champs diffèrent ?
Les RBL -> Out, c'est n'importe quoi, trop de faux positifs. A utiliser dans Spam Assassin et polcyweight.
Si j'ai bien compris, le but serait plus de l'utiliser comme une composante de détection dans SpamAssassin qui fait varier le score final, plutôt que comme test à l'entrée ?
C'est pô bête ça ;). Je me le garde dans un coin.
Sinon, au niveau listes, lesquelles semblent les plus fiables ?
J'ai pris l'habitude d'utiliser cbl.abuseat.org, et sbl.spamhaus.org : je n'ai pas vraiment eu à m'en plaindre jusqu'à présent.
Dans le même cas que Xavier (des utilisateurs qui peuvent raler un tantinet... j'en fais partie... :) ) j'ai trié et jeté pas mal de RBL ces dernières années. On utilise maintenant, avec succès et à ma connaissance aucun faux positif : bogons.cymru.com, zen.spamhaus.org et relays.dnsbl.sorbs.net.
Jon
Le Sat, May 03, 2014 at 09:15:09PM +0200, Christophe [tech@stuxnet.org] a écrit:
SPF : Plutôt sympa dans le principe, si tant que les DNS des domaines expéditeurs soient correctement configurés.
Non et non. SPF, ça ne sert pas pour protéger du spam, ça sert à "valider" que le serveur émetteur d'un mail est autorisé par le titulaire du domaine de l'adresse expéditeur. Faire confiance à SPF pour délivrer un mail, c'est la porte ouverte (et déjà empruntée) aux spameurs qui mettent en place des domaines le temps d'un envoi, avec SPF & co
SPF et DKIM, ça cherche à limiter l'usurpation d'identité de l'adresse expéditeur, c'est tout. (et ça peut limiter un peu le backscatter, et encore...)
On 05/05/2014 10:17 AM, Dominique Rousseau wrote:
SPF et DKIM, ça cherche à limiter l'usurpation d'identité de l'adresse expéditeur, c'est tout. (et ça peut limiter un peu le backscatter, et encore...)
Non, c'est prévu pour limiter l'usurpation du domaine expéditeur et non celle de l'adresse mail expéditrice.
François
Le Mon, May 05, 2014 at 10:23:23AM +0200, Francois Petillon [fantec@proxad.net] a écrit:
On 05/05/2014 10:17 AM, Dominique Rousseau wrote:
SPF et DKIM, ça cherche à limiter l'usurpation d'identité de l'adresse expéditeur, c'est tout. (et ça peut limiter un peu le backscatter, et encore...)
Non, c'est prévu pour limiter l'usurpation du domaine expéditeur et non celle de l'adresse mail expéditrice.
Oui, en effet. Merci pour la précision, Fantec :)
De notre côté on a mis en place un système qui analyse les headers des mails pour qualifier la provenance. On fait un tri manuel de tous les mails non sollicité que l'on reçoit et que nos clients nous transmettent. On s'est inscrit à différents endroits avec des boites mails dédiées pour visualiser la revente des mails.
Une fois le tout mélangé on obtient une liste de domaine / ip qui envoient des spam "propres" (les newsletter FR d'entreprises qui veulent nous vendre des choses dont on a pas besoin).
On fabrique une liste spamassassin de règles et on applique une note qui fait passer obligatoire en status spam. Les spams sont après rangés dans le répertoire Junk qui va bien, libre aux gens de les consulter et les supprimer.
Avec ce système on s'est rendu compte que des services comme Mailjet et consors du même type nous adresses aucun mail légitime depuis presque un an. Je me demande même qui utilise ces services pour de l'acheminement de courriel normal.
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/
On 05/16/2014 12:28 PM, François wrote:
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).
Ou à l'inscription sur des sites web en utilisant le même mot de passe que le compte mail et en utilisant le compte mail en question comme adresse de contact. Vu que les spammeurs ont des compétences en piratage de site web, ils récupèrent une base abonnés avec des emails et des mots de passe...
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...
Pas de SMTP en mode authentifié ?
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.
Résumons : on savez que vos utilisateurs se font compromettre leurs comptes, vous savez que ces comptes compromis sont utilisés pour balancer du spam mais, pour être parfaitement neutre, il n'est pas question d'essayer de bloquer ce qui semble anormal ?
Et les destinataires des spams en question, ils sont censés en penser quoi de votre neutralité ?
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.
Dans votre cas, le gros intérêt des webmails est que vous avez accès au carnet d'adresse. Si un utilisateur se met à envoyer un ratio conséquent de mails sur des adresses qui ne font pas partie du carnet d'adresse, il y a probablement quelque chose à creuser.
Des idées pour lutter contre le spam sortant pour une situation comme celle-ci?
Quotas pour limiter la volumétrie des comptes abusifs, monitoring de l'utilisation des comptes pour trouver les comptes compromis, filtrage antispam en sortie.
François
2014-05-16 13:00 GMT+02:00 Francois Petillon fantec@proxad.net:
On 05/16/2014 12:28 PM, François wrote:
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).
Ou à l'inscription sur des sites web en utilisant le même mot de passe que le compte mail et en utilisant le compte mail en question comme adresse de contact. Vu que les spammeurs ont des compétences en piratage de site web, ils récupèrent une base abonnés avec des emails et des mots de passe...
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...
Pas de SMTP en mode authentifié ?
Si mais justement, on se retrouve avec des credentials valides, d'où la difficulté.
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.
Résumons : on savez que vos utilisateurs se font compromettre leurs comptes, vous savez que ces comptes compromis sont utilisés pour balancer du spam mais, pour être parfaitement neutre, il n'est pas question d'essayer de bloquer ce qui semble anormal ?
Et les destinataires des spams en question, ils sont censés en penser quoi de votre neutralité ?
Le problème c'est que tout faux positif en envoi de mail est problématique, car le membre qui envoit son mail pensera (légitimement) que celui-ci est en cours de delivery.
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.
Dans votre cas, le gros intérêt des webmails est que vous avez accès au carnet d'adresse. Si un utilisateur se met à envoyer un ratio conséquent de mails sur des adresses qui ne font pas partie du carnet d'adresse, il y a probablement quelque chose à creuser.
Sauf si le spammer se connecte directement au SMTP authentifié... Certains de nos membres envoient beaucoup de mails, donc le seuil est difficile à définir (en smtp j'entends, on a déjà des seuils avec le sendmail des serveurs web).
Donc en gros on est condamnés à lire des spam report pour voir que, zut tel compte envoit du spam, faut locker. C'est donc pas très synchrone.
Des idées pour lutter contre le spam sortant pour une situation comme celle-ci?
Quotas pour limiter la volumétrie des comptes abusifs, monitoring de l'utilisation des comptes pour trouver les comptes compromis, filtrage antispam en sortie.
Comme je disais, compte abusif, c'est pas facile à définir. Le monitoring c'est pas idiot, par contre l'antispam en sortie, comme je disais, je vois pas comment régler les faux positifs. Ou alors ça vient juste mettre un flag suspicieux ...
Merci en tout cas!
François _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
François
Salut,
Le ven 16 mai 14 à 15:53:07 +0200, François aifsair+frsag@gmail.com écrivait :
Sauf si le spammer se connecte directement au SMTP authentifié... Certains de nos membres envoient beaucoup de mails, donc le seuil est difficile à définir (en smtp j'entends, on a déjà des seuils avec le sendmail des serveurs web).
Faudrait vérifier, mais j'imagine que ceux qui envoient beaucoup de courriers légitimes ne le font pas par le webmail, donc beaucoup (à définir...) de mail via le webmail = suspicieux.
Ça ne règle pas tout, mais ça fait déjà une source de moins.
À +
Le 16/05/2014 18:16, Thierry Thomas a écrit :
Salut,
Le ven 16 mai 14 à 15:53:07 +0200, François aifsair+frsag@gmail.com écrivait :
Sauf si le spammer se connecte directement au SMTP authentifié... Certains de nos membres envoient beaucoup de mails, donc le seuil est difficile à définir (en smtp j'entends, on a déjà des seuils avec le sendmail des serveurs web).
Faudrait vérifier, mais j'imagine que ceux qui envoient beaucoup de courriers légitimes ne le font pas par le webmail, donc beaucoup (à définir...) de mail via le webmail = suspicieux.
Ça ne règle pas tout, mais ça fait déjà une source de moins.
À +
Ceux qui envoient beaucoup de mail le font sans doute pour des campagnes de mailing list ou autre (j'entends : quand ils en envoient énormément). Cela ne dérange donc pas trop que tous les mails ne partent pas dans la seconde. Donc tu peux dire à ces utilisateurs d'utiliser un autre SMTP, qui fera un rate control adapté. Pour les autres, le rate control sera drastique. Pour les mails via PHP, voici un petit bout de doc : http://www.void.gr/kargig/blog/2011/12/19/rate-limit-outgoing-emails-from-ph... En gros, c'est le même principe que ma première solution : on crée une seconde queue, et le serveur principal va faire du rate control, avec possiblement du rate control par domaine (on peut ajuster quasiment à volonté). ça multiplie le nombre de ports en écoute, et ça ne fait pas tout (car maintenant il faut sécuriser tout ça!), mais ça peut aider. A+ ---------
Aurélien DUCLOS
Hello,
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.
L'anti-spam en sortie m'as déjà évité d'avoir un mailhub blacklisté dans des rbl diverses.
C'est la monté en CPU de l'antispam qui m'as alerté.
Xavier
On ven. 16 mai 2014 à 12:28:21, François wrote:
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?
Si postfix, cluebringer (le nouveau petit nom de policyd) est une bonne méthode pour mettre un bridage sur un nombre de mails par unité temporelle.
Ensuite, il faut faire en sorte d'être averti, pour pouvoir bloquer temporairement le compte de l'utilisateur incriminé.
Mettre un filtre en sortie qui bloque le spam n'est pas une hérésie, c'est quelque chose de normal : vous ne voulez pas affecter la façon dont le réseau fonctionne pour un utilisateur légitime, mais empêcher une utilisation illégitime de vos ressources, qui peut avoir de très mauvaises conséquences pour votre serveur mail (blackliste chez les RBL, etc).
-
Aurélien Duclos -
Christophe -
Dominique Rousseau -
Francois Petillon -
François -
Jonathan Clarke -
Pierre-Elliott Bécue -
Thierry Thomas -
Wallace -
Xavier Beaudouin