Re: Bloquer un TLD sous Postfix

[Daniel Caillibaud]

Le 07/04/18 à 02:46, "Ph. Gras"  a écrit :
PG> Bonjour,
PG> 
PG> > Je déconseille fortement ce genre de filtrage sauvage ;-)  
PG> 
PG> les remontrances de Daniel me semblent infondées et parfaitement
PG> déplacées.

C'est pas des remontrances, juste qu'amha mettre du filtrage en dur n'est
pas à conseiller, pour les raisons que je détaillais.

Ensuite, ça reste un conseil, que personne n'est obligé de suivre, encore
heureux que chacun puisse configurer son smtp comme il l'entend.

Amicalement,

-- 
Daniel

On n'a rien à gagner à emmerder les gens qui n'ont rien à perdre.
Frédéric Dard (Les pensées de San-Antonio)

Re: Bloquer un TLD sous Postfix

[Vincent Lefevre]

On 2018-04-07 13:33:15 +0200, daniel huhardeaux wrote:
> 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.

Concernant DKIM, cf la discussion:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689414

Et en pratique, je reçois plein de mail légitime avec signature DKIM
cassée (T_DKIM_INVALID). La plupart, en provenance de mailing-lists.
Mais aussi les mails de Samsung SHOP, donc des mails qui peuvent être
importants.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bloquer un TLD sous Postfix

[Vincent Lefevre]

On 2018-04-07 11:13:19 +0200, BERTRAND Joël wrote:
>   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).

À ce propos, j'ai ceci dans ma config de postfix:

postscreen_greet_action = enforce

et postscreen_greet_wait a sa valeur par défaut (de 2 à 6 secondes
suivant la charge).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bloquer un TLD sous Postfix

[Erwan David]

Le 04/07/18 à 13:33, daniel huhardeaux a écrit :
> 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.
>
J'au un plugin de vérification DKIM sur mon thunderbird, plein de mail
légitime avec DKIM cassé...

Re: Bloquer un TLD sous Postfix

[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

Re: Bloquer un TLD sous Postfix

[BERTRAND Joël]

-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

Re: Bloquer un TLD sous Postfix

[Pierre Malard]

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.

Pour répondre à la question initiale : ce système évite toute tenue « à la main 
» obligatoire d’une liste noire.

Cordialement

> Le 7 avr. 2018 à 02:46, Ph. Gras  a écrit :
> 
> Bonjour,
> 
>> Je déconseille fortement ce genre de filtrage sauvage ;-)
> 
> les remontrances de Daniel me semblent infondées et parfaitement déplacées.
> 
> Le filtrage que j'ai réalisé est basé sur un host effectué sur les 256 
> adresses IP
> d'une plage dans laquelle se trouve celle d'un expéditeur avec le domaine sur
> lequel on cause et un de ses copains en .club
> 
>> 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.
> 
> Cette liste est fraîche et après un rapide sondage, toujours d'actualité.
> 
>> Et la généralisation de ces comportements amène à la conclusion que seuls
>> gmail, hotmail & co peuvent envoyer des mails ayant de bonnes chances
>> d'arriver. Donc tous ceux qui maintenaient leur petit serveur de mail perso
>> abandonnent parce qu'ils sont régulièrement blacklistés ici ou là, de
>> manière totalement arbitraire et obscure, évidemment sans être prévenus,
>> et que ça devient trop pénible à maintenir.
> 
> Raisonnement un peu rapide auquel il manque une solide argumentation.
> Je fais partie de ceux qui maintiennent un petit serveur de mail perso et j'ai
> la conviction que mes règles sont suffisamment laxistes pour ne pas perdre
> de mail sur les domaines qu'il gère.
> 
> Je suppose que OVH ne surveille pas ce que font ses clients pour respecter
> la neutralité du Net. Les réclamations que j'ai pu adresser à cette société 
> par
> le passé pour des comportements abusifs ou frauduleux ont été rapidement
> et correctement traités.
> 
>> 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 :-/
> 
> Tu n'as pas pris la peine de me lire avant de partir sur tes grands chevaux.
> 
> Je n'ai pas évoqué un script, mais un système ! Il y a intervention humaine.
> 
>> Et ensuite tu peux tagguer / rejeter d'après ce domaine, mais si tu
>> rejettes, fais le avec un message donnant une idée du motif (genre "too
>> much spam")
> 
> Je ne rejette pas ces IP, je les DROP après enquête avec iptables.
> 
> Bonne continuation,
> 
> Ph. Gras

--
Pierre Malard

« L'utopie, c'est la vérité de demain »
 Victor Hugo (1802-1885)
   |\  _,,,---,,_
   /,`.-'`'-.  ;-;;,_
  |,4-  ) )-,_. ,\ (  `'-'
 '---''(_/--'  `-'\_)   πr

perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  ) )-,_. ,\ 
(  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_): 
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--



signature.asc
Description: Message signed with OpenPGP

Re: Bloquer un TLD sous Postfix

[Ph. Gras]

Bonjour,

> Je déconseille fortement ce genre de filtrage sauvage ;-)

les remontrances de Daniel me semblent infondées et parfaitement déplacées.

Le filtrage que j'ai réalisé est basé sur un host effectué sur les 256 adresses 
IP
d'une plage dans laquelle se trouve celle d'un expéditeur avec le domaine sur
lequel on cause et un de ses copains en .club

> 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.

Cette liste est fraîche et après un rapide sondage, toujours d'actualité. 

> Et la généralisation de ces comportements amène à la conclusion que seuls
> gmail, hotmail & co peuvent envoyer des mails ayant de bonnes chances
> d'arriver. Donc tous ceux qui maintenaient leur petit serveur de mail perso
> abandonnent parce qu'ils sont régulièrement blacklistés ici ou là, de
> manière totalement arbitraire et obscure, évidemment sans être prévenus,
> et que ça devient trop pénible à maintenir.

Raisonnement un peu rapide auquel il manque une solide argumentation.
Je fais partie de ceux qui maintiennent un petit serveur de mail perso et j'ai
la conviction que mes règles sont suffisamment laxistes pour ne pas perdre
de mail sur les domaines qu'il gère.

Je suppose que OVH ne surveille pas ce que font ses clients pour respecter
la neutralité du Net. Les réclamations que j'ai pu adresser à cette société par
le passé pour des comportements abusifs ou frauduleux ont été rapidement
et correctement traités.

> 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 :-/

Tu n'as pas pris la peine de me lire avant de partir sur tes grands chevaux.

Je n'ai pas évoqué un script, mais un système ! Il y a intervention humaine.

> Et ensuite tu peux tagguer / rejeter d'après ce domaine, mais si tu
> rejettes, fais le avec un message donnant une idée du motif (genre "too
> much spam")

Je ne rejette pas ces IP, je les DROP après enquête avec iptables.

Bonne continuation,

Ph. Gras

Re: Bloquer un TLD sous Postfix

[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: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bloquer un TLD sous Postfix

[Daniel Caillibaud]

Le 06/04/18 à 02:15, Vincent Lefevre  a écrit :

VL> On 2018-04-05 20:39:18 +0200, Daniel Caillibaud wrote:
VL> > Le 04/04/18 à 23:07, "Ph. Gras"  a écrit :  
VL> > PG> ayant été emmerdé aussi par ce voyou, j'ai constitué un système
VL> > PG> pour récupérer toutes ses plages IP à bloquer (avec bash et
VL> > PG> ipcalc), et que je vous livre dans un fichier à télécharger ici :
VL> > PG> https://fichiers.enpret.com/top.txt  
VL> > 
VL> > Je déconseille fortement ce genre de filtrage sauvage ;-)
VL> > 
VL> > Vu ta liste et les plages utilisées, tu interdis un paquet de
VL> > serveurs ovh (16 par /28, 32 par /27, etc), et je parie que dans ta
VL> > liste y'a déjà 90% des ips que ce "voyou" n'utilise plus et qui ont
VL> > été relouées à d'autres (voire 100%), pour la plupart parfaitement
VL> > innocents.  
VL> 
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> > Si tu as un script qui détecte que c'est du spam, il vaudrait mieux
VL> > l'envoyer à un rbl sérieux [1], mais le faire automatiquement est
VL> > risqué [2], et le faire après vérification par un humain
VL> > chronophage :-/  
VL> 
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> > Sinon, pour le blindage de ton smtp, vaut mieux se fier au domaine de
VL> > l'ip qui t'appelle, avec comme base
VL> > - obliger le smtp qui t'appelle à avoir une ip avec un reverse  
VL> 
VL> Non! Il y a des endroits où ça bloquerait du mail légitime.
VL> Quand j'avais considéré d'ajouter une telle restriction, j'avais
VL> vu que dans le mail que je recevais, certains correspondants
VL> n'avaient pas de reverse (vérification par la command host).

Jamais vu le cas (et je reçois plusieurs milliers de mails par jour de
plusieurs centaines de smtp).

Et si ça arrivait, il pourrait pas écrire à grand monde vu que cette
exigence est très majoritaire chez les hébergeurs de mail (y'en a même qui
imposent reverse qui résoud vers l'ip + reverse identique au helo).

VL> > - que le reverse soit dans les dns et qu'il pointe bien vers cette ip
VL> > (même si le reverse n'est pas le même que le domaine du helo)  
VL> 
VL> Donc non également.

Ben, je pense toujours que si ;-)

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.

C'est un peu plus strict que les RFC, mais qqun qui respecte pas ça peut
pas envoyer de mail à google|hotmail|yahoo|free|orange|… donc j'adopte
aussi ça pour pas prendre plus de spam. C'est vrai que ça accentue le
standard de fait, mais ça me choque pas vu la règle en question.

Avant ça permettait de rejeter d'office tous les spams envoyés depuis les
"PC zombies", celui qui hébergeait un serveur mail chez lui devait prévoir
un reverse ayant une entrée dns, éventuellement avec du dyndns s'il avait
pas d'ip fixe.
Maintenant la plupart des FAI français proposent des ip publiques avec
reverse qui résout, et ils bloquent le port 25 par défaut, mais y'a encore
pas mal d'ip de PC vérolés à travers le monde qui ne satisfont pas ça, et
j'ai jamais vu de mail légitime en provenir (ok, en les bloquant je risque
pas de le savoir, mais j'ai jamais eu de plaintes et mon smtp reçoit du
courrier d'un peu partout).

Amicalement,


-- 
Daniel

Je fais deux régimes en même temps, parce qu'avec
un seul, j'avais pas assez à manger.
Coluche

Re: Bloquer un TLD sous Postfix

[BERTRAND Joël]

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

Re: Bloquer un TLD sous Postfix

[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: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bloquer un TLD sous Postfix

[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: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bloquer un TLD sous Postfix

[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: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Bloquer un TLD sous Postfix

[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

Re: Bloquer un TLD sous Postfix

[Daniel Caillibaud]

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.

Et la généralisation de ces comportements amène à la conclusion que seuls
gmail, hotmail & co peuvent envoyer des mails ayant de bonnes chances
d'arriver. Donc tous ceux qui maintenaient leur petit serveur de mail perso
abandonnent parce qu'ils sont régulièrement blacklistés ici ou là, de
manière totalement arbitraire et obscure, évidemment sans être prévenus,
et que ça devient trop pénible à maintenir.

Ça me paraît à l'encontre de ce qu'on doit être nombreux à soutenir ici
(code libre et données privées protégées), en sapant le travail de
https://degooglisons-internet.org/

Attention, j'ai pas dit que tu étais vendu à google, et le spam est
pénible pour tout le monde, mais bloquer sauvagement des plages d'ip
entières revient à favoriser les gros acteurs du mail (car eux ne seront
jamais bloqués vu le nb d'individus honnêtes à qui ils offrent leurs
services).

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
Je crois que c'est la conf par défaut de postfix dans debian, à vérifier.

Et ensuite tu peux tagguer / rejeter d'après ce domaine, mais si tu
rejettes, fais le avec un message donnant une idée du motif (genre "too
much spam")

[1] par sérieux j'entends
- qui bloque pas automatiquement au 1er signalement
- qui ne rançonne pas pour le débloquage
- qui débloque automatiquement au bout d'un moment
(je crois que spamcop satisfaisait ces critères, à vérifier, mais il n'est
pas le seul)

[2] Une détection automatique et fiable du spam me paraît pas vraiment
possible, et même des systèmes très élaborés ont des faux positifs, même si
effectivement, on peut considérer qu'un score de 6 ou 7 à spamassassin est
du spam à 99,9% (p'tet plus de 9 après la virgule). En tout cas je met dans
un dossier spam_certain à partir de 6 et j'ai encore jamais vu de mail
légitime dedans (et j'avoue le vider après l'avoir regardé très
superficiellement).


Amicalement,

-- 
Daniel

On ne dit pas « je vais au coiffeur » mais « je vais au
capilliculteur »
Pierre Desproges

Re: Bloquer un TLD sous Postfix

[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

Re: Bloquer un TLD sous Postfix

[Ph. Gras]

Salut,

> 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 x...@.top) car 100% des emails reçus depuis ce TLD sont des publicités 
> non sollicitées … g

ayant été emmerdé aussi par ce voyou, j'ai constitué un système pour récupérer 
toutes ses plages IP à bloquer
(avec bash et ipcalc), et que je vous livre dans un fichier à télécharger ici :
https://fichiers.enpret.com/top.txt

Bonne réception,

Ph. Gras

Re: Bloquer un TLD sous Postfix

[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

Re: Bloquer un TLD sous Postfix

[Daniel Caillibaud]

Le 04/04/18 à 14:56, JUPIN Alain  a écrit :

JA> Bonjour,
JA> 
JA> Sur mon installation Postfix sous Wheezy, je cherche à rejeter tous les 
JA> messages dont l'adresse email provient du tld .top (donc toutes les 
JA> adresse en x...@.top) car 100% des emails reçus depuis ce TLD sont 
JA> des publicités non sollicitées ... g
JA> 
JA> Dans le main.cf, j'ai mis ceci :
JA> smtpd_recipient_restrictions =
JA>      permit_mynetworks,
JA>      permit_sasl_authenticated,
JA>      check_client_access hash:/etc/postfix/blacklist_hosts,
JA>      check_sender_access hash:/etc/postfix/blacklist_email,
JA>      reject_non_fqdn_recipient,.
JA> 
JA> Et dans le fichier blacklist_hosts
JA> .top            REJECT
JA> 
JA> Puis dans le fichier blacklist_email
JA> .top        REJECT
JA> 
JA> Bien sur j'ai effectué le postmap des fichiers blacklist_hosts et 
JA> blacklist_email, redemarré Postfix et les mails passent toujours :(
JA> 
JA> J'ai foiré quelle étape ?

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 :

   header_checks = pcre:/path/to/header_checks.pcre

et dedans tu peux mettre par ex des regex sur les headers comme

/^Received:.*\.(demarque-en-cours\.com|elasticemail\.info|tendances-maison\.com/
 PREPEND X-Bulk: YES detected 32

Le n° me sert juste à savoir quelle règle il s'est pris quand je regarde
un faux positif (ça peut toujours arriver), et coté livraison si y'a du X-Bulk 
dans les headers je mets ça dans un dossier bulk, car l'envoi en masse n'est 
pas 
forcément du spam ;-)

(et celui qui est vraiment abonné à une newsletter qu'il veut recevoir ailleurs 
que dans bulk peut se mettre une règle avant celle-là pour choisir son dossier 
de livraison)

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.


-- 
Daniel

Le  mec qui a convaincu les aveugles de porter des lunettes
de soleil est quand même un excellent commercial.

Bloquer un TLD sous Postfix

[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 x...@.top) car 100% des emails reçus depuis ce TLD sont 
des publicités non sollicitées ... g


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