Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Bloquer un TLD sous Postfix

14 réponses
Avatar
JUPIN Alain
Bonjour,

Sur mon installation Postfix sous Wheezy, je cherche à rejeter tous les
messages dont l'adresse email provient du tld .top (donc toutes les
adresse en xxxx@xxxx.top) car 100% des emails reçus depuis ce TLD sont
des publicités non sollicitées ... grrrr

Dans le main.cf, j'ai mis ceci :
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    check_client_access hash:/etc/postfix/blacklist_hosts,
    check_sender_access hash:/etc/postfix/blacklist_email,
    reject_non_fqdn_recipient,.....

Et dans le fichier blacklist_hosts
.top            REJECT

Puis dans le fichier blacklist_email
.top        REJECT

Bien sur j'ai effectué le postmap des fichiers blacklist_hosts et
blacklist_email, redemarré Postfix et les mails passent toujours :(

J'ai foiré quelle étape ?
Merci à vous pour votre aide.

--
Alain JUPIN

10 réponses

1 2
Avatar
Grégory Bulot
Bonjour,
Pas sur de la syntaxe, mais je propose ceci :
Le Wed, 4 Apr 2018 14:56:08 +0200 JUPIN Alain a écrit
Et dans le fichier blacklist_hosts

/^*..top$/            REJECT
Puis dans le fichier blacklist_email

/^*..top$/        REJECT
Avatar
JUPIN Alain
Bonjour,
Le 04/04/2018 à 15:57, Daniel Caillibaud a écrit :
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).

Effectivement, il fallait mettre le blacklist email dans
sender_restrictions et le blacklist_hosts dans client_restrictions.
Cela semble fonctionner pour l'instant
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.

En fait, sur ce TLD précis, 100% des mails envoyés sont non sollicités
et cela n'a rien à voir avec des newsletters.
Voilà pourquoi je souhaite opter pour une solution radicale.
Par ailleurs, suite à ce message, j'ai eu une réponse en privée (et non
sur cette liste) d'une personne qui a carrément juger bon de m’appeler
sur mon téléphone portable perso pour savoir si sa réponse convenait !
C'est nouveau çà ? c'est un cas généralisé ici ? car sincèrement, je
trouve la démarche "douteuse".
Mais merci à vous pour vos réponses.
Alain
Avatar
daniel huhardeaux
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)
--
Daniel
Avatar
Vincent Lefevre
On 2018-04-04 15:57:43 +0200, Daniel Caillibaud wrote:
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).

On peut très bien le mettre dans smtpd_recipient_restrictions.
Cf le "Other restrictions that are valid in this context:" dans
la page man postconf(5). Ça peut être utile si on veut utiliser
certaines règles dépendant du destinataire en priorité, voire un
"check_client_access" dépendant du destinataire.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/&gt;
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/&gt;
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Avatar
Vincent Lefevre
On 2018-04-05 20:39:18 +0200, Daniel Caillibaud wrote:
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.

En ce qui me concerne, j'en ai marre de recevoir du spam en provenance
de serveurs d'OVH. Les hébergeurs ont leur part de responsabilité. Et
ils ne devraient pas relouer des adresses utilisées pour spammer (en
particulier pendant plusieurs semaines ou mois).
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 :-/

Les RBL ne détectent pas tout.
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

Non! Il y a des endroits où ça bloquerait du mail légitime.
Quand j'avais considéré d'ajouter une telle restriction, j'avais
vu que dans le mail que je recevais, certains correspondants
n'avaient pas de reverse (vérification par la command host).
- 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)

Donc non également.
- que le domaine annoncé dans le helo pointe bien vers l'ip qu'il utilise

Non, ce n'est pas toujours le cas. Notamment cela empêche d'envoyer
du mail directement depuis une machine derrière un NAT.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/&gt;
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/&gt;
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Avatar
Vincent Lefevre
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.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/&gt;
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/&gt;
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Avatar
BERTRAND Jo=c3=abl
Vincent Lefevre a écrit :
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.

Bonjour,
Je n'utilise pas postfix, mais ce que je fais doit pouvoir être
transposé à postfix sans trop de difficultés.
1/ serveur mail sous Sendmail + Procmail
2/ greylist avec SPF :
- blackliste d'autorité les mails avec usurpation de domaine ;
- score avec les RBL + spamassassin ;
- geoip (pour virer d'autorité certains pays lors de phases de spam
prolongées)
3/ spamassasin
4/ clamav
Par dessus, j'ai un "greeting delay" configuré dans sendmail et je
refuse un mail en provenance de serveur sans reverse DNS.
Je suis à peu près tranquille avec ça. Quelques merdouilles arrivent
encore à passer, mais elles sont rares (moins d'une dizaine par jour qui
arrivent taguées SPAM par spamassassin, donc immédiatement gérées par
procmail qui les balance en indésirable).
Aucun de mes contacts ne s'est jamais plaint de ne pas réussir à
m'envoyer un mail.
Bien cordialement,
JKB
Avatar
Vincent Lefevre
On 2018-04-06 10:16:09 +0200, Daniel Caillibaud wrote:
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.

L'utilisateur peut se plaindre à son hébergeur et/ou changer
d'hébergeur. Les blacklists en dur permettent aussi de mettre
la pression sur les hébergeurs.
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,

Les spammeurs changent souvent de domaine, plus que d'IP.
Sinon, je blackliste aussi sur des NS. C'est ce que j'ai dû faire
pour me débarrasser définitivement d'un spammeur qui m'a spammé
pendant plusieurs mois. Il changeait à chaque fois de domaine (il
en avait plusieurs centaines, avec des noms semblant plus ou moins
aléatoires), et dans une moindre mesure d'IP.
et plutôt pour tagger des mails qu'en rejeter.

Trier les mails taggés fait perdre du temps.
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.

Chez moi, la plupart du spam est éliminé par les RBL, mais il en reste
beaucoup qui passe au travers.
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.

Je parle bien d'envoyer un mail directement, sans relais. Dans le
passé, c'était ma config, car les relais de mon FAI étaient souvent
blacklistés (petit FAI, et de plus laxiste sur le spam).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/&gt;
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/&gt;
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Avatar
BERTRAND Jo=c3=abl
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Pierre Malard a écrit :
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.

Ne pas oublier le GREETING EHLO. Les spammeurs n'attendent
généralement pas la bannière du SMTP avant de balancer le spam. Ils
font un EHLO puis balancent directement le reste du message sans
attendre la réponse. En mettant un GH à 1s, je vire une très grosse
partie des importuns. Inconvénient : le SMTP n'écoute pas durant une
seconde, donc une connexion est tenue jusqu'au timeout et s'achève par
un "NO DATA AFTER EHLO" ou quelque chose du genre (donc ne pas oublier
de gérer les timeouts finement pour les montées en charge).
Cordialement,
JKB
Avatar
daniel huhardeaux
Le 06/04/2018 à 02:24, Vincent Lefevre a écrit :
[...]
- 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.

Ah ? DKIM, DMARC et SPF sont partout donnés gagnants pour la lutte
contre le SPAM, j'ai du mal à suivre ton raisonnement.
Dans tous les cas pour nos serveurs, depuis leur implantation en plus du
grey listing et des points évoqués par Daniel Caillibaud, les choses se
sont bien améliorées.
--
Daniel
1 2