Et dans le fichier blacklist_hosts
Puis dans le fichier blacklist_email
Et dans le fichier blacklist_hosts
Puis dans le fichier blacklist_email
Et dans le fichier blacklist_hosts
Puis dans le fichier blacklist_email
La doc ;-)
http://www.postfix.org/postconf.5.html#check_client_access
http://www.postfix.org/postconf.5.html#check_sender_access
http://www.postfix.org/access.5.html
check_client_access vérifie le host qui te cause, check_sender_access le
domaine du from, mais faut pas les mettre dans smtpd_recipient_restrictions
car ça c'est pas une restriction sur le destinataire, faut le mettre dans
une restriction sur l'expéditeur (smtpd_sender_restrictions).
Sinon, juste un avis, je trouve plus facile de s'y retrouver en mettant du
check_sender_access hash:check_sender_access.hash
(avec un suffixe .list ou .pcre suivant les cas), je trouve que ça permet
de mieux savoir ce qu'on modifie quand on édite le fichier (et aussi de
faire du postmap *.hash pour pas en oublier un). Ça reste une convention
parmi d'autres, le tout est d'en suivre une qui te semble logique et où tu
t'y retrouve.
Une autre solution pour le spam (en plus de ton antispam), moins radicale
mais efficace, c'est de filtrer sur les headers et de marquer les mails
comme spam ou bulk ou ce que tu veux, mais de les livrer quand même, avec
par ex :
[....]
Après, si tu es le seul à avoir des boîtes mails sur ce serveur, tu peux bien sûr
adopter des règles plus radicales et jeter ou refuser des mails, chose que je me
permet pas ayant des boites pour d'autres personnes.
La doc ;-)
http://www.postfix.org/postconf.5.html#check_client_access
http://www.postfix.org/postconf.5.html#check_sender_access
http://www.postfix.org/access.5.html
check_client_access vérifie le host qui te cause, check_sender_access le
domaine du from, mais faut pas les mettre dans smtpd_recipient_restrictions
car ça c'est pas une restriction sur le destinataire, faut le mettre dans
une restriction sur l'expéditeur (smtpd_sender_restrictions).
Sinon, juste un avis, je trouve plus facile de s'y retrouver en mettant du
check_sender_access hash:check_sender_access.hash
(avec un suffixe .list ou .pcre suivant les cas), je trouve que ça permet
de mieux savoir ce qu'on modifie quand on édite le fichier (et aussi de
faire du postmap *.hash pour pas en oublier un). Ça reste une convention
parmi d'autres, le tout est d'en suivre une qui te semble logique et où tu
t'y retrouve.
Une autre solution pour le spam (en plus de ton antispam), moins radicale
mais efficace, c'est de filtrer sur les headers et de marquer les mails
comme spam ou bulk ou ce que tu veux, mais de les livrer quand même, avec
par ex :
[....]
Après, si tu es le seul à avoir des boîtes mails sur ce serveur, tu peux bien sûr
adopter des règles plus radicales et jeter ou refuser des mails, chose que je me
permet pas ayant des boites pour d'autres personnes.
La doc ;-)
http://www.postfix.org/postconf.5.html#check_client_access
http://www.postfix.org/postconf.5.html#check_sender_access
http://www.postfix.org/access.5.html
check_client_access vérifie le host qui te cause, check_sender_access le
domaine du from, mais faut pas les mettre dans smtpd_recipient_restrictions
car ça c'est pas une restriction sur le destinataire, faut le mettre dans
une restriction sur l'expéditeur (smtpd_sender_restrictions).
Sinon, juste un avis, je trouve plus facile de s'y retrouver en mettant du
check_sender_access hash:check_sender_access.hash
(avec un suffixe .list ou .pcre suivant les cas), je trouve que ça permet
de mieux savoir ce qu'on modifie quand on édite le fichier (et aussi de
faire du postmap *.hash pour pas en oublier un). Ça reste une convention
parmi d'autres, le tout est d'en suivre une qui te semble logique et où tu
t'y retrouve.
Une autre solution pour le spam (en plus de ton antispam), moins radicale
mais efficace, c'est de filtrer sur les headers et de marquer les mails
comme spam ou bulk ou ce que tu veux, mais de les livrer quand même, avec
par ex :
[....]
Après, si tu es le seul à avoir des boîtes mails sur ce serveur, tu peux bien sûr
adopter des règles plus radicales et jeter ou refuser des mails, chose que je me
permet pas ayant des boites pour d'autres personnes.
[....]
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
[...]
[....]
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
[...]
[....]
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
[...]
check_client_access vérifie le host qui te cause, check_sender_access le
domaine du from, mais faut pas les mettre dans smtpd_recipient_restrictions
car ça c'est pas une restriction sur le destinataire, faut le mettre dans
une restriction sur l'expéditeur (smtpd_sender_restrictions).
check_client_access vérifie le host qui te cause, check_sender_access le
domaine du from, mais faut pas les mettre dans smtpd_recipient_restrictions
car ça c'est pas une restriction sur le destinataire, faut le mettre dans
une restriction sur l'expéditeur (smtpd_sender_restrictions).
check_client_access vérifie le host qui te cause, check_sender_access le
domaine du from, mais faut pas les mettre dans smtpd_recipient_restrictions
car ça c'est pas une restriction sur le destinataire, faut le mettre dans
une restriction sur l'expéditeur (smtpd_sender_restrictions).
Le 04/04/18 à 23:07, "Ph. Gras" a écrit :
PG> ayant été emmerdé aussi par ce voyou, j'ai constitué un système pour
PG> récupérer toutes ses plages IP à bloquer (avec bash et ipcalc), et que
PG> je vous livre dans un fichier à télécharger ici :
PG> https://fichiers.enpret.com/top.txt
Je déconseille fortement ce genre de filtrage sauvage ;-)
Vu ta liste et les plages utilisées, tu interdis un paquet de serveurs ovh
(16 par /28, 32 par /27, etc), et je parie que dans ta liste y'a déjà 90%
des ips que ce "voyou" n'utilise plus et qui ont été relouées à d'autres
(voire 100%), pour la plupart parfaitement innocents.
Si tu as un script qui détecte que c'est du spam, il vaudrait mieux
l'envoyer à un rbl sérieux [1], mais le faire automatiquement est risqué
[2], et le faire après vérification par un humain chronophage :-/
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
Le 04/04/18 à 23:07, "Ph. Gras" <ph.gras@worldonline.fr> a écrit :
PG> ayant été emmerdé aussi par ce voyou, j'ai constitué un système pour
PG> récupérer toutes ses plages IP à bloquer (avec bash et ipcalc), et que
PG> je vous livre dans un fichier à télécharger ici :
PG> https://fichiers.enpret.com/top.txt
Je déconseille fortement ce genre de filtrage sauvage ;-)
Vu ta liste et les plages utilisées, tu interdis un paquet de serveurs ovh
(16 par /28, 32 par /27, etc), et je parie que dans ta liste y'a déjà 90%
des ips que ce "voyou" n'utilise plus et qui ont été relouées à d'autres
(voire 100%), pour la plupart parfaitement innocents.
Si tu as un script qui détecte que c'est du spam, il vaudrait mieux
l'envoyer à un rbl sérieux [1], mais le faire automatiquement est risqué
[2], et le faire après vérification par un humain chronophage :-/
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
Le 04/04/18 à 23:07, "Ph. Gras" a écrit :
PG> ayant été emmerdé aussi par ce voyou, j'ai constitué un système pour
PG> récupérer toutes ses plages IP à bloquer (avec bash et ipcalc), et que
PG> je vous livre dans un fichier à télécharger ici :
PG> https://fichiers.enpret.com/top.txt
Je déconseille fortement ce genre de filtrage sauvage ;-)
Vu ta liste et les plages utilisées, tu interdis un paquet de serveurs ovh
(16 par /28, 32 par /27, etc), et je parie que dans ta liste y'a déjà 90%
des ips que ce "voyou" n'utilise plus et qui ont été relouées à d'autres
(voire 100%), pour la plupart parfaitement innocents.
Si tu as un script qui détecte que c'est du spam, il vaudrait mieux
l'envoyer à un rbl sérieux [1], mais le faire automatiquement est risqué
[2], et le faire après vérification par un humain chronophage :-/
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
Le 05/04/2018 à 20:39, Daniel Caillibaud a écrit :[....]
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
[...]
Je plussoie en y rajoutant
- postgrey
- DKIM (opendkim)
Le 05/04/2018 à 20:39, Daniel Caillibaud a écrit :
> [....]
>
> Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
> l'ip qui t'appelle, avec comme base
> - obliger le smtp qui t'appelle à avoir une ip avec un reverse
> - que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
> si le reverse n'est pas le même que le domaine du helo)
> - que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
> [...]
Je plussoie en y rajoutant
- postgrey
- DKIM (opendkim)
Le 05/04/2018 à 20:39, Daniel Caillibaud a écrit :[....]
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
[...]
Je plussoie en y rajoutant
- postgrey
- DKIM (opendkim)
On 2018-04-05 22:01:34 +0200, daniel huhardeaux wrote:Le 05/04/2018 à 20:39, Daniel Caillibaud a écrit :[....]
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
[...]
Je plussoie en y rajoutant
- postgrey
C'est ennuyeux, sauf s'il y a la possibilité de n'activer le
greylistage que pour les mails douteux, i.e. après d'autres
vérifications.- DKIM (opendkim)
Certains le déconseillent. Je crois, à cause des mailing-lists qui
peuvent casser la signature. Du coup, ça ne sert plus à grand chose,
car certains spams ont des signatures DKIM valides.
On 2018-04-05 22:01:34 +0200, daniel huhardeaux wrote:
Le 05/04/2018 à 20:39, Daniel Caillibaud a écrit :
[....]
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
[...]
Je plussoie en y rajoutant
- postgrey
C'est ennuyeux, sauf s'il y a la possibilité de n'activer le
greylistage que pour les mails douteux, i.e. après d'autres
vérifications.
- DKIM (opendkim)
Certains le déconseillent. Je crois, à cause des mailing-lists qui
peuvent casser la signature. Du coup, ça ne sert plus à grand chose,
car certains spams ont des signatures DKIM valides.
On 2018-04-05 22:01:34 +0200, daniel huhardeaux wrote:Le 05/04/2018 à 20:39, Daniel Caillibaud a écrit :[....]
Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
l'ip qui t'appelle, avec comme base
- obliger le smtp qui t'appelle à avoir une ip avec un reverse
- que le reverse soit dans les dns et qu'il pointe bien vers cette ip (même
si le reverse n'est pas le même que le domaine du helo)
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise
[...]
Je plussoie en y rajoutant
- postgrey
C'est ennuyeux, sauf s'il y a la possibilité de n'activer le
greylistage que pour les mails douteux, i.e. après d'autres
vérifications.- DKIM (opendkim)
Certains le déconseillent. Je crois, à cause des mailing-lists qui
peuvent casser la signature. Du coup, ça ne sert plus à grand chose,
car certains spams ont des signatures DKIM valides.
Le 06/04/18 à 02:15, Vincent Lefevre a écrit :
VL> En ce qui me concerne, j'en ai marre de recevoir du spam en provenance
VL> de serveurs d'OVH. Les hébergeurs ont leur part de responsabilité. Et
VL> ils ne devraient pas relouer des adresses utilisées pour spammer (en
VL> particulier pendant plusieurs semaines ou mois).
Ils ne devraient peut-être pas mais le font, et même si c'est après
plusieurs mois, avec du blacklist en dur qui sera jamais viré le pb se pose
toujours.
D'une manière générale, un blocage avec une liste en dur est pas terrible
si y'a pas de purge automatique. Je le pratique pourtant, mais sur des
domaines et jamais des ip,
et plutôt pour tagger des mails qu'en rejeter.
VL> Les RBL ne détectent pas tout.
Non, mais en les choisissant correctement ça permet quand même d'en
éliminer avant l'analyse (avec du reject s'ils sont plusieurs à lister
telle ip comme spammeuse), et ensuite l'antispam doit faire son boulot pour
tagger ce qui a été accepté à l'entrée.
VL> > - que le domaine annoncé dans le helo pointe bien vers l'ip qu'il
VL> > utilise
VL>
VL> Non, ce n'est pas toujours le cas. Notamment cela empêche d'envoyer
VL> du mail directement depuis une machine derrière un NAT.
Non, car je parle de l'ip qui me cause, pas celle d'origine ni celles des
relais précédents, et je maintiens que l'ip publique sortante qui veut
m'envoyer des mails doit avoir un reverse qui doit résoudre vers cette ip
publique.
Le 06/04/18 à 02:15, Vincent Lefevre <vincent@vinc17.net> a écrit :
VL> En ce qui me concerne, j'en ai marre de recevoir du spam en provenance
VL> de serveurs d'OVH. Les hébergeurs ont leur part de responsabilité. Et
VL> ils ne devraient pas relouer des adresses utilisées pour spammer (en
VL> particulier pendant plusieurs semaines ou mois).
Ils ne devraient peut-être pas mais le font, et même si c'est après
plusieurs mois, avec du blacklist en dur qui sera jamais viré le pb se pose
toujours.
D'une manière générale, un blocage avec une liste en dur est pas terrible
si y'a pas de purge automatique. Je le pratique pourtant, mais sur des
domaines et jamais des ip,
et plutôt pour tagger des mails qu'en rejeter.
VL> Les RBL ne détectent pas tout.
Non, mais en les choisissant correctement ça permet quand même d'en
éliminer avant l'analyse (avec du reject s'ils sont plusieurs à lister
telle ip comme spammeuse), et ensuite l'antispam doit faire son boulot pour
tagger ce qui a été accepté à l'entrée.
VL> > - que le domaine annoncé dans le helo pointe bien vers l'ip qu'il
VL> > utilise
VL>
VL> Non, ce n'est pas toujours le cas. Notamment cela empêche d'envoyer
VL> du mail directement depuis une machine derrière un NAT.
Non, car je parle de l'ip qui me cause, pas celle d'origine ni celles des
relais précédents, et je maintiens que l'ip publique sortante qui veut
m'envoyer des mails doit avoir un reverse qui doit résoudre vers cette ip
publique.
Le 06/04/18 à 02:15, Vincent Lefevre a écrit :
VL> En ce qui me concerne, j'en ai marre de recevoir du spam en provenance
VL> de serveurs d'OVH. Les hébergeurs ont leur part de responsabilité. Et
VL> ils ne devraient pas relouer des adresses utilisées pour spammer (en
VL> particulier pendant plusieurs semaines ou mois).
Ils ne devraient peut-être pas mais le font, et même si c'est après
plusieurs mois, avec du blacklist en dur qui sera jamais viré le pb se pose
toujours.
D'une manière générale, un blocage avec une liste en dur est pas terrible
si y'a pas de purge automatique. Je le pratique pourtant, mais sur des
domaines et jamais des ip,
et plutôt pour tagger des mails qu'en rejeter.
VL> Les RBL ne détectent pas tout.
Non, mais en les choisissant correctement ça permet quand même d'en
éliminer avant l'analyse (avec du reject s'ils sont plusieurs à lister
telle ip comme spammeuse), et ensuite l'antispam doit faire son boulot pour
tagger ce qui a été accepté à l'entrée.
VL> > - que le domaine annoncé dans le helo pointe bien vers l'ip qu'il
VL> > utilise
VL>
VL> Non, ce n'est pas toujours le cas. Notamment cela empêche d'envoyer
VL> du mail directement depuis une machine derrière un NAT.
Non, car je parle de l'ip qui me cause, pas celle d'origine ni celles des
relais précédents, et je maintiens que l'ip publique sortante qui veut
m'envoyer des mails doit avoir un reverse qui doit résoudre vers cette ip
publique.
Bonjour,
Débat intéressant compte tenu de la « demande » supposée
d’interventionnisme préalable à la faute. Et pourquoi pas la
constitution d’un fichier « S » (pour SPAM mauvais esprits ! :-)
Après, on pourrait discuter de savoir s’il faut leur faire porter
un signe distinctif… Bon,, j’arrête de jeter de l’huile sur le
feu.
Histoire d’être plus sur la demande initiale, pourquoi ne pas
utiliser des techniques comme la liste grise (paquet greylist).
Cela ne fait que simuler une surcharge temporaire de votre serveur
SMTP et la requête de représentation ultérieure pour tout mail
venant d’une origine nouvelle (ou non membre d’une liste blanche).
Cela envoie à l’émetteur un signal 451 prévu par la RFC 821. Si
l’émetteur est un vrai serveur SMTP, il représente l’envoi dans le
1/4 d’heure suivante, il est alors accepté par greylist. Comme les
SPAMMEURs font des envois en très grand nombre, ils ne
peuvent/souhaitent tenir à jour une base des serveurs à recontacter
et ne font pas de re-présentation du mail dans 80% des cas. C’est
très efficace pour éloigner les SPAMMEURS, l’inconvénient est la
latence de 1/4 d’heure mais, somme toute, un système de messagerie
n’est pas un chat ! Ceci combiné avec l’appel aux serveurs RBL
(SpamCop, SpamHaus ou autre) et une analyse spamassassin/clamav
nous protège très efficacement même si tout ceci ne saurait être à
100% efficace. Tout ceci reste totalement légal et respecte la
liberté de chacun. Il n’y a, en aucune manière, intrusion dans le
contenu autre qu’une analyse baysienne ou anti-virus mais
simplement forçage du respect d’une certaine « netiquette ». Ceci a
également l’avantage de ne demander aucune intervention de
l’émetteur « honnête » devant prouver son … honnêteté comme
d’autres systèmes.
Bonjour,
Débat intéressant compte tenu de la « demande » supposée
d’interventionnisme préalable à la faute. Et pourquoi pas la
constitution d’un fichier « S » (pour SPAM mauvais esprits ! :-)
Après, on pourrait discuter de savoir s’il faut leur faire porter
un signe distinctif… Bon,, j’arrête de jeter de l’huile sur le
feu.
Histoire d’être plus sur la demande initiale, pourquoi ne pas
utiliser des techniques comme la liste grise (paquet greylist).
Cela ne fait que simuler une surcharge temporaire de votre serveur
SMTP et la requête de représentation ultérieure pour tout mail
venant d’une origine nouvelle (ou non membre d’une liste blanche).
Cela envoie à l’émetteur un signal 451 prévu par la RFC 821. Si
l’émetteur est un vrai serveur SMTP, il représente l’envoi dans le
1/4 d’heure suivante, il est alors accepté par greylist. Comme les
SPAMMEURs font des envois en très grand nombre, ils ne
peuvent/souhaitent tenir à jour une base des serveurs à recontacter
et ne font pas de re-présentation du mail dans 80% des cas. C’est
très efficace pour éloigner les SPAMMEURS, l’inconvénient est la
latence de 1/4 d’heure mais, somme toute, un système de messagerie
n’est pas un chat ! Ceci combiné avec l’appel aux serveurs RBL
(SpamCop, SpamHaus ou autre) et une analyse spamassassin/clamav
nous protège très efficacement même si tout ceci ne saurait être à
100% efficace. Tout ceci reste totalement légal et respecte la
liberté de chacun. Il n’y a, en aucune manière, intrusion dans le
contenu autre qu’une analyse baysienne ou anti-virus mais
simplement forçage du respect d’une certaine « netiquette ». Ceci a
également l’avantage de ne demander aucune intervention de
l’émetteur « honnête » devant prouver son … honnêteté comme
d’autres systèmes.
Bonjour,
Débat intéressant compte tenu de la « demande » supposée
d’interventionnisme préalable à la faute. Et pourquoi pas la
constitution d’un fichier « S » (pour SPAM mauvais esprits ! :-)
Après, on pourrait discuter de savoir s’il faut leur faire porter
un signe distinctif… Bon,, j’arrête de jeter de l’huile sur le
feu.
Histoire d’être plus sur la demande initiale, pourquoi ne pas
utiliser des techniques comme la liste grise (paquet greylist).
Cela ne fait que simuler une surcharge temporaire de votre serveur
SMTP et la requête de représentation ultérieure pour tout mail
venant d’une origine nouvelle (ou non membre d’une liste blanche).
Cela envoie à l’émetteur un signal 451 prévu par la RFC 821. Si
l’émetteur est un vrai serveur SMTP, il représente l’envoi dans le
1/4 d’heure suivante, il est alors accepté par greylist. Comme les
SPAMMEURs font des envois en très grand nombre, ils ne
peuvent/souhaitent tenir à jour une base des serveurs à recontacter
et ne font pas de re-présentation du mail dans 80% des cas. C’est
très efficace pour éloigner les SPAMMEURS, l’inconvénient est la
latence de 1/4 d’heure mais, somme toute, un système de messagerie
n’est pas un chat ! Ceci combiné avec l’appel aux serveurs RBL
(SpamCop, SpamHaus ou autre) et une analyse spamassassin/clamav
nous protège très efficacement même si tout ceci ne saurait être à
100% efficace. Tout ceci reste totalement légal et respecte la
liberté de chacun. Il n’y a, en aucune manière, intrusion dans le
contenu autre qu’une analyse baysienne ou anti-virus mais
simplement forçage du respect d’une certaine « netiquette ». Ceci a
également l’avantage de ne demander aucune intervention de
l’émetteur « honnête » devant prouver son … honnêteté comme
d’autres systèmes.
[...]- DKIM (opendkim)
Certains le déconseillent. Je crois, à cause des mailing-lists qui
peuvent casser la signature. Du coup, ça ne sert plus à grand chose,
car certains spams ont des signatures DKIM valides.
[...]
- DKIM (opendkim)
Certains le déconseillent. Je crois, à cause des mailing-lists qui
peuvent casser la signature. Du coup, ça ne sert plus à grand chose,
car certains spams ont des signatures DKIM valides.
[...]- DKIM (opendkim)
Certains le déconseillent. Je crois, à cause des mailing-lists qui
peuvent casser la signature. Du coup, ça ne sert plus à grand chose,
car certains spams ont des signatures DKIM valides.