Reverse DNS et relais messagerie pb cornelien

"jcc" <jice@pilotoXXpas_de_spamXXrama.net> a écrit dans le message de
news:dc8a1m$mt0$1@s1.news.oleane.net...

Bonjour à tous,


Ma question est de savoir quelle démarche vous appliquez face à ce
problème pour ceux qui y sont confrontés ?

Renoncer au filtrage c'est la porte grande ouverte aux spams, appliquer
le filtrage c'est les utilisateurs qui ne reçoivent pas certains mails
qui peuvent être importants.

Perso, je suis pas trop regardant sur les mails entrant en smtp (juste
interdire le relay), et je préfere filtrer les mails sur le contenu au
moment du dispatch vers les bal des users
j'utilise procmail et spambnc qui marche tres bien
+ un filtre avec une whiteliste issue directement du crm de l'entreprise
pour éviter de rejeter un mail douteux venant d'un utilisateur connu.

Le Wed, 27 Jul 2005 16:07:20 +0000, jcc a écrit :

Bonjour.
Le post est à cheval sur fcs et fcms. Le sujet est souvent visité la bas
alors ça peut aussi être interressant de jeter un oeil aux archives.

Bonjour à tous,

Très classiquement j'utilise en DMZ un relais messagerie configuré pour
rejeter les mails reçus qui échouent au test reverse DNS (ip-champ MX
inconnus des DNS publics et/ou champ Helo ne correspondant pas à ce qui
est renseigné dans les DNS).

Autant je verifie le reverse autant amha vérifier le EHLO (ou HELO)
comme tu le fait c'est un coup à bloquer un paquet d'emails légitimes.

Le RFC2821 précise :
the command *may* be interpreted as saying "Hello, I am <domain>"
mais il n'y a nulle part une telle obligation, et pas mal de postmaster
n'y prête pas une attention suffisante pour que ça puisse être
discriminant.

Par contre tu peux filtrer sans risque un HELO <ton domaine> si tu n'a pas
à recevoir ça sur ton serveur. Attention quand même aux mauvais gags.

Pour le filtrage sur le reverse il ne fait pas non plus partie de RFC2821
mais il est souvent utilisé car il est rare qu'un serveur smtp légitime
n'ait pas un reverse positionné plus ou moins correctement.

La plus grande partie des mails shootés sont des spams bien sur, mais
quelques uns sont émis par des expéditeurs de bonne foi utilisant une
messagerie mal configurée.

Ben oui, c'est normal, voir au dessus.

Les émetteurs des mails shootés reçoivent un mail d'alerte en retour,
mais comme 999 fois sur 1000 il ne le comprennent pas et ne le
transmettent pas à postmaster si il existe.

Surtout si ton utilisateur est anglais et que Môssieur Postmaster parle
engliche ;)

Ma question est de savoir quelle démarche vous appliquez face à ce
problème pour ceux qui y sont confrontés ?

Autant on peut reprocher pas mal de chose à sendmail, autant son
leitmotiv "soyez strict sur ce que vous envoyez et souple sur ce que vous
recevez" me parait interressant pour gérer le courrier.

Renoncer au filtrage c'est la porte grande ouverte aux spams, appliquer le
filtrage c'est les utilisateurs qui ne reçoivent pas certains mails qui
peuvent être importants.

Tout filtrage s'expose potentiellement à un faux positif.
Maintenant il existe amha largement de quoi lutter contre tant que tu
t'occupe d'un MTA de taille petite ou moyenne[1]. Pour mon cas le
greylisting a fait des miracles et contrairement aux prévisions des
cassandres il est efficace depuis pas mal de temps (je me limite même à
5mn).

Ensuite pour ce qui reste tu peux tagger les spam/virus (amavisd,
mailscanner + spamassassin, razor,... ) et les laisser passer.

Enfin pour des raisons évidentes de sécu je mets les emails vérolés en
quarantaine, récupérable sur demande (processus automatisé ou non).


En conjonction avec des RTBL très peu aggressives (en clair qui laissent
passer beaucoup de merdes quand même mais qui évitent les faux positifs)
je n'utilise même plus de filtre pour "ranger" les emails taggés mail ou
virus tellement j'en ai peu (et j'ai quelques adresses publiques dans la
nature).

Ce qui est assez incroyable c'est de constater parfois que certains mails
rejetés sont émis depuis de très grosses boites mais que leurs relais
étant mal déclarés ou mal configurés les mails vont à la trappe.

Il faudra un jour arrêter de supposer que grosse boite = compétance.
Pour certaines c'est le cas mais l'expérience semble surtout montrer
qu'une augmentation des effectifs va souvent avec une dillution des
responsabilités ( via, parfois, des sous traitances attribuées un peu à
la légère).

Certains ont-ils déjà été confrontés à ce problème, quelle
démarche avez vous adopté ?

Tiens c'est marrant, tu bégaye du clavier? :)
Voir plus haut la réponse.

Je ne peut quand même pas éplucher les
logs à longueur de journée

Ahem, l'examen des logs ça se scripte.
Ici on retombe en plein dans l'objet de se forum :
A quoi ça sert de mettre des dispositifs en place si on ne peut les
exploiter? (et j'imagine que personne ne va s'en servir pour du forensic,
si seulement les logs sont encore intacts)

Pour rester dans la sécu d'ailleurs j'aime bien l'anti phishing de
MailScanner, même s'il est un peu violent (il ajoute un warning dans
parties html où un lien ne pointe pas vers le domaine représenté par le
texte qui va avec).

et écrire à tous ces gens de mieux
configurer leurs relais ...

J'ai parfois vu des MX secondaire refuser le domaine normalement
attribué, ou quelques gags bizarre, j'ai toujours eu une réponse du
postmaster (bon, en général les rares fois où je dois leur écrire je
mets aussi en copie au responsable du domaine, etc... Ca aide à la
réaction :-/ ).

Mais bon, je choississais des postmasters des boites avec qui j'ai un
contact direct ou indirect ; pour la majeure partie c'est peine perdue et
tu risque de consommer énormément de temps sans remplir le violon :)

Si le postmaster ne réagit pas et que tu dois accepter son courrier, de
toute façon c'est réglé (ce qui ne signifie pas que tu ne dois pas
examiner les emails pour du spam ou les virus[2] ni accepter toutes les
adresses IP qui ne sont pas des MTA (histoire de ne pas lancer un troll
sur le filtrage des adresses IP "residentielles". D'ailleurs toute
réponse à ce sujet part en hors charte à la modération, ils ont plus
l'habitude sur fcms :) )

Merci pour vos lumières

Celle d'un amateur éteind, manque de sommeil :)

Eric

[1] A partir d'une certaine taille les mécanismes de filtrage et de
vérification deviennent coûteux en ressources et demande beaucoup de
rélexion préalable, car un mauvais choix peut vite mettre à genoux les
serveurs. Remarque dans ce cas c'est réglé pour le filtrage :)

[2] Je sais, ce n'est pas le rôle d'un MTA de vérifier les emails mais
j'ai une paix royale avec les end users pas à jour de leur antivirus et
adeptent du "c'est quoi ça? je clicke!)

Salut,

Très classiquement j'utilise en DMZ un relais messagerie configuré pour
rejeter les mails reçus qui échouent au test reverse DNS (ip-champ MX
inconnus des DNS publics et/ou champ Helo ne correspondant pas à ce qui
est renseigné dans les DNS).

Euh, ça vient d'où qu'un *client* SMTP doit obligatoirement être déclaré
comme MX et avoir un reverse ?

Autant je verifie le reverse autant amha vérifier le EHLO (ou HELO)
comme tu le fait c'est un coup à bloquer un paquet d'emails légitimes.

Sur quoi la vérification du reverse est-elle fondée, au juste ?

Pour le filtrage sur le reverse il ne fait pas non plus partie de RFC2821

En effet, d'où mon interrogation.

mais il est souvent utilisé car il est rare qu'un serveur smtp légitime
n'ait pas un reverse positionné plus ou moins correctement.

Cf. ma première question, ça vient d'où qu'un *client* SMTP légitime
doit aussi être un serveur ?

Patrice Labracherie a couché sur son écran :

+ un filtre avec une whiteliste issue directement du crm de l'entreprise
pour éviter de rejeter un mail douteux venant d'un utilisateur connu.

Comme ca quand un client est vérolé tu en profites bien ;-) ?

Sinon le systeme des greylist est extremement efficace...

Le Wed, 27 Jul 2005 16:07:20 +0000, jcc a écrit :

Bonjour.
Le post est à cheval sur fcs et fcms. Le sujet est souvent visité la bas
alors ça peut aussi être interressant de jeter un oeil aux archives.

Bonjour à tous,

Très classiquement j'utilise en DMZ un relais messagerie configuré pour
rejeter les mails reçus qui échouent au test reverse DNS (ip-champ MX
inconnus des DNS publics et/ou champ Helo ne correspondant pas à ce qui
est renseigné dans les DNS).

Autant je verifie le reverse autant amha vérifier le EHLO (ou HELO)
comme tu le fais c'est un coup à bloquer un paquet d'emails légitimes.

Le RFC2821 précise :
the command *may* be interpreted as saying "Hello, I am <domain>"
mais il n'y a nulle part une telle obligation, et pas mal de postmasters
n'y prêtent pas une attention suffisante pour que ça puisse être
discriminant.

Par contre tu peux filtrer sans risque un HELO <ton domaine> si tu n'a pas
à recevoir ça sur ton serveur. Attention quand même aux mauvais gags.

Pour le filtrage sur le reverse il ne fait pas non plus partie de RFC2821
mais il est souvent utilisé car il est rare qu'un serveur smtp légitime
n'ait pas un reverse positionné plus ou moins correctement.

La plus grande partie des mails shootés sont des spams bien sur, mais
quelques uns sont émis par des expéditeurs de bonne foi utilisant une
messagerie mal configurée.

Ben oui, c'est normal, voir au dessus.

Les émetteurs des mails shootés reçoivent un mail d'alerte en retour,
mais comme 999 fois sur 1000 il ne le comprennent pas et ne le
transmettent pas à postmaster si il existe.

Surtout si ton utilisateur est français et que Môssieur Postmaster parle
engliche ;)

Ma question est de savoir quelle démarche vous appliquez face à ce
problème pour ceux qui y sont confrontés ?

Autant on peut reprocher pas mal de chose à sendmail, autant son
leitmotiv "soyez strict sur ce que vous envoyez et souple sur ce que vous
recevez" me parait interressant pour gérer le courrier.

Renoncer au filtrage c'est la porte grande ouverte aux spams, appliquer le
filtrage c'est les utilisateurs qui ne reçoivent pas certains mails qui
peuvent être importants.

Tout filtrage s'expose potentiellement à un faux positif.
Maintenant il existe amha largement de quoi lutter contre tant que tu
t'occupe d'un MTA de taille petite ou moyenne[1]. Pour mon cas le
greylisting a fait des miracles et contrairement aux prévisions des
cassandres il est efficace depuis pas mal de temps (je me limite même à
5mn).

Ensuite pour ce qui reste tu peux tagger les spam/virus (amavisd,
mailscanner + spamassassin, razor,... ) et les laisser passer.

Enfin pour des raisons évidentes de sécu je mets les emails vérolés en
quarantaine, récupérable sur demande (processus automatisé ou non).


En conjonction avec des RTBL très peu aggressives (en clair qui laissent
passer beaucoup de merdes quand même mais qui évitent les faux positifs)
je n'utilise même plus de filtre pour "ranger" les emails taggés spam ou
virus tellement j'en ai peu (et j'ai quelques adresses publiques dans la
nature).

Ce qui est assez incroyable c'est de constater parfois que certains mails
rejetés sont émis depuis de très grosses boites mais que leurs relais
étant mal déclarés ou mal configurés les mails vont à la trappe.

Il faudra un jour arrêter de supposer que grosse boite = compétance.
Pour certaines c'est le cas mais l'expérience semble surtout montrer
qu'une augmentation des effectifs va souvent avec une dillution des
responsabilités ( via, parfois, des sous traitances attribuées un peu à
la légère).

Certains ont-ils déjà été confrontés à ce problème, quelle
démarche avez vous adopté ?

Tiens c'est marrant, tu bégaye du clavier? :)
Voir plus haut la réponse.

Je ne peut quand même pas éplucher les
logs à longueur de journée

Ahem, l'examen des logs ça se scripte.
Ici on retombe en plein dans l'objet de se forum :
A quoi ça sert de mettre des dispositifs en place si on ne peut les
exploiter? (et j'imagine que personne ne va s'en servir pour du forensic,
si seulement les logs sont encore intacts)

Pour rester dans la sécu d'ailleurs j'aime bien l'anti phishing de
MailScanner, même s'il est un peu violent (il ajoute un warning dans
parties html où un lien ne pointe pas vers le domaine représenté par le
texte qui va avec).

et écrire à tous ces gens de mieux
configurer leurs relais ...

J'ai parfois vu des MX secondaires refuser le domaine normalement
attribué, ou quelques gags bizarres, j'ai toujours eu une réponse du
postmaster (bon, en général les rares fois où je dois leur écrire je
mets aussi en copie au responsable du domaine, etc... Ca aide à la
réaction :-/ ).

Mais bon, je choississais des postmasters des boites avec qui j'ai un
contact direct ou indirect ; pour la majeure partie c'est peine perdue et
tu risque de consommer énormément de temps sans remplir le violon :)

Si le postmaster ne réagit pas et que tu dois accepter son courrier, de
toute façon c'est réglé (ce qui ne signifie pas que tu ne dois pas
examiner les emails pour du spam ou les virus[2] ni accepter toutes les
adresses IP qui ne sont pas des MTA (histoire de ne pas lancer un troll
sur le filtrage des adresses IP "residentielles". D'ailleurs toute
réponse à ce sujet part en hors charte à la modération, ils ont plus
l'habitude sur fcms :) )

Merci pour vos lumières

Celle d'un amateur éteind, manque de sommeil :)

Eric

[1] A partir d'une certaine taille les mécanismes de filtrage et de
vérification deviennent coûteux en ressources et demande beaucoup de
rélexion préalable, car un mauvais choix peut vite mettre à genoux les
serveurs. Remarque dans ce cas c'est réglé pour le filtrage :)

[2] Je sais, ce n'est pas le rôle d'un MTA de vérifier les emails mais
j'ai une paix royale avec les end users pas à jour de leur antivirus et
adeptes du "c'est quoi ça? je clicke!)

Le Wed, 27 Jul 2005 16:07:20 +0000, jcc a écrit :

Bonjour.
Le post est à cheval sur fcs et fcms. Le sujet est souvent visité la bas
alors ça peut aussi être interressant de jeter un oeil aux archives.

Bonjour à tous,

Très classiquement j'utilise en DMZ un relais messagerie configuré pour
rejeter les mails reçus qui échouent au test reverse DNS (ip-champ MX
inconnus des DNS publics et/ou champ Helo ne correspondant pas à ce qui
est renseigné dans les DNS).

Autant je verifie le reverse autant amha vérifier le EHLO (ou HELO)
comme tu le fais c'est un coup à bloquer un paquet d'emails légitimes.

Le RFC2821 précise :
the command *may* be interpreted as saying "Hello, I am <domain>"
mais il n'y a nulle part une telle obligation, et pas mal de postmasters
n'y prêtent pas une attention suffisante pour que ça puisse être
discriminant.

Par contre tu peux filtrer sans risque un HELO <ton domaine> si tu n'a pas
à recevoir ça sur ton serveur. Attention quand même aux mauvais gags.

Pour le filtrage sur le reverse il ne fait pas non plus partie de RFC2821
mais il est souvent utilisé car il est rare qu'un serveur smtp légitime
n'ait pas un reverse positionné plus ou moins correctement.

La plus grande partie des mails shootés sont des spams bien sur, mais
quelques uns sont émis par des expéditeurs de bonne foi utilisant une
messagerie mal configurée.

Ben oui, c'est normal, voir au dessus.

Les émetteurs des mails shootés reçoivent un mail d'alerte en retour,
mais comme 999 fois sur 1000 il ne le comprennent pas et ne le
transmettent pas à postmaster si il existe.

Surtout si ton utilisateur est français et que Môssieur Postmaster parle
engliche ;)

Ma question est de savoir quelle démarche vous appliquez face à ce
problème pour ceux qui y sont confrontés ?

Autant on peut reprocher pas mal de chose à sendmail, autant son
leitmotiv "soyez strict sur ce que vous envoyez et souple sur ce que vous
recevez" me parait interressant pour gérer le courrier.

Renoncer au filtrage c'est la porte grande ouverte aux spams, appliquer le
filtrage c'est les utilisateurs qui ne reçoivent pas certains mails qui
peuvent être importants.

Tout filtrage s'expose potentiellement à un faux positif.
Maintenant il existe amha largement de quoi lutter contre tant que tu
t'occupe d'un MTA de taille petite ou moyenne[1]. Pour mon cas le
greylisting a fait des miracles et contrairement aux prévisions des
cassandres il est efficace depuis pas mal de temps (je me limite même à
5mn).

Ensuite pour ce qui reste tu peux tagger les spam/virus (amavisd,
mailscanner + spamassassin, razor,... ) et les laisser passer.

Enfin pour des raisons évidentes de sécu je mets les emails vérolés en
quarantaine, récupérable sur demande (processus automatisé ou non).


En conjonction avec des RTBL très peu aggressives (en clair qui laissent
passer beaucoup de merdes quand même mais qui évitent les faux positifs)
je n'utilise même plus de filtre pour "ranger" les emails taggés spam ou
virus tellement j'en ai peu (et j'ai quelques adresses publiques dans la
nature).

Ce qui est assez incroyable c'est de constater parfois que certains mails
rejetés sont émis depuis de très grosses boites mais que leurs relais
étant mal déclarés ou mal configurés les mails vont à la trappe.

Il faudra un jour arrêter de supposer que grosse boite = compétance.
Pour certaines c'est le cas mais l'expérience semble surtout montrer
qu'une augmentation des effectifs va souvent avec une dillution des
responsabilités ( via, parfois, des sous traitances attribuées un peu à
la légère).

Certains ont-ils déjà été confrontés à ce problème, quelle
démarche avez vous adopté ?

Tiens c'est marrant, tu bégaye du clavier? :)
Voir plus haut la réponse.

Je ne peut quand même pas éplucher les
logs à longueur de journée

Ahem, l'examen des logs ça se scripte.
Ici on retombe en plein dans l'objet de se forum :
A quoi ça sert de mettre des dispositifs en place si on ne peut les
exploiter? (et j'imagine que personne ne va s'en servir pour du forensic,
si seulement les logs sont encore intacts)

Pour rester dans la sécu d'ailleurs j'aime bien l'anti phishing de
MailScanner, même s'il est un peu violent (il ajoute un warning dans
parties html où un lien ne pointe pas vers le domaine représenté par le
texte qui va avec).

et écrire à tous ces gens de mieux
configurer leurs relais ...

J'ai parfois vu des MX secondaires refuser le domaine normalement
attribué, ou quelques gags bizarres, j'ai toujours eu une réponse du
postmaster (bon, en général les rares fois où je dois leur écrire je
mets aussi en copie au responsable du domaine, etc... Ca aide à la
réaction :-/ ).

Mais bon, je choississais des postmasters des boites avec qui j'ai un
contact direct ou indirect ; pour la majeure partie c'est peine perdue et
tu risque de consommer énormément de temps sans remplir le violon :)

Si le postmaster ne réagit pas et que tu dois accepter son courrier, de
toute façon c'est réglé (ce qui ne signifie pas que tu ne dois pas
examiner les emails pour du spam ou les virus[2] ni accepter toutes les
adresses IP qui ne sont pas des MTA (histoire de ne pas lancer un troll
sur le filtrage des adresses IP "residentielles". D'ailleurs toute
réponse à ce sujet part en hors charte à la modération, ils ont plus
l'habitude sur fcms :) )

Merci pour vos lumières

Celle d'un amateur éteind, manque de sommeil :)

Eric

[1] A partir d'une certaine taille les mécanismes de filtrage et de
vérification deviennent coûteux en ressources et demande beaucoup de
rélexion préalable, car un mauvais choix peut vite mettre à genoux les
serveurs. Remarque dans ce cas c'est réglé pour le filtrage :)

[2] Je sais, ce n'est pas le rôle d'un MTA de vérifier les emails mais
j'ai une paix royale avec les end users pas à jour de leur antivirus et
adeptes du "c'est quoi ça? je clicke!)

Le Thu, 28 Jul 2005 05:59:10 +0000, Pascal@plouf a écrit :

Très classiquement j'utilise en DMZ un relais messagerie configuré
pour rejeter les mails reçus qui échouent au test reverse DNS
(ip-champ MX inconnus des DNS publics et/ou champ Helo ne correspondant
pas à ce qui est renseigné dans les DNS).

Euh, ça vient d'où qu'un *client* SMTP doit obligatoirement être
déclaré comme MX et avoir un reverse ?

Oops, j'ai lu ce que je voulais lire : simplement qu'il existe un
enregistrement reverse (PTR) valide pour l'adresse IP qui envoi l'email.

Autant je verifie le reverse autant amha vérifier le EHLO (ou HELO)
comme tu le fait c'est un coup à bloquer un paquet d'emails légitimes.

Sur quoi la vérification du reverse est-elle fondée, au juste ?

Sur rien! (c'est d'ailleurs précisé dans mon post) mais j'ai rarement vu
un MTA légitime avec une IP qui n'a pas de DNS inverse.
Ceci dit je me contente pour ma part généralement de vérifier
l'existence du domaine présenté dans le From: de l'enveloppe.

Pour le filtrage sur le reverse il ne fait pas non plus partie de
RFC2821

En effet, d'où mon interrogation.

Elle est du au fait que j'ai répondu à ce que j'ai cru lire et non pas
de ce qu'il y avait d'écrit!

mais il est souvent utilisé car il est rare qu'un serveur smtp
légitime n'ait pas un reverse positionné plus ou moins correctement.

Cf. ma première question, ça vient d'où qu'un *client* SMTP légitime
doit aussi être un serveur ?

Même réponse. Surtout que dans pas mal de structures ce n'est pas le
même serveur (ni parfois logiciel) qui est utilisé pour les emails
sortant et entrant.

Ensuite j'ai oublié de parler de SPF[1]. Autant je suis violement contre
l'obligation de l'utiliser que prônent certains (ça casse des RFCs)
autant si le domaine présente cet enregistrement dans le DNS je ne vois
pas de raison de ne pas s'en servir (si on ne prévoit pas de forward par
exemple :) ).

Eric

Attention : Fu2 positionné car je ne suis plus persuadé que ça concene
directement la sécu.

[1] Rappel pour éviter les enfilades courantes sur ce sujet : SPF n'est
*pas* un mécanisme anti-spam. Il indique juste qu'un domaine annonce ses
client smtp légitimes ; le corrolaire est qu'on peut filtrer le spam se
présentant dudit domaine mais emis d'adresses IP non présentées dans
les enregistrements SPF.

Le Wed, 27 Jul 2005 16:07:20 +0000, jcc a écrit :

Bonjour.
Le post est à cheval sur fcs et fcms. Le sujet est souvent visité la bas
alors ça peut aussi être interressant de jeter un oeil aux archives.

Bonjour à tous,

Très classiquement j'utilise en DMZ un relais messagerie configuré pour
rejeter les mails reçus qui échouent au test reverse DNS (ip-champ MX
inconnus des DNS publics et/ou champ Helo ne correspondant pas à ce qui
est renseigné dans les DNS).

Autant je verifie le reverse autant amha vérifier le EHLO (ou HELO)
comme tu le fais c'est un coup à bloquer un paquet d'emails légitimes.

Le RFC2821 précise :
the command *may* be interpreted as saying "Hello, I am <domain>"
mais il n'y a nulle part une telle obligation, et pas mal de postmasters
n'y prêtent pas une attention suffisante pour que ça puisse être
discriminant.

Par contre tu peux filtrer sans risque un HELO <ton domaine> si tu n'a pas
à recevoir ça sur ton serveur. Attention quand même aux mauvais gags.

Pour le filtrage sur le reverse il ne fait pas non plus partie de RFC2821
mais il est souvent utilisé car il est rare qu'un serveur smtp légitime
n'ait pas un reverse positionné plus ou moins correctement.

La plus grande partie des mails shootés sont des spams bien sur, mais
quelques uns sont émis par des expéditeurs de bonne foi utilisant une
messagerie mal configurée.

Ben oui, c'est normal, voir au dessus.

Les émetteurs des mails shootés reçoivent un mail d'alerte en retour,
mais comme 999 fois sur 1000 il ne le comprennent pas et ne le
transmettent pas à postmaster si il existe.

Surtout si ton utilisateur est français et que Môssieur Postmaster parle
engliche ;)

Ma question est de savoir quelle démarche vous appliquez face à ce
problème pour ceux qui y sont confrontés ?

Autant on peut reprocher pas mal de chose à sendmail, autant son
leitmotiv "soyez strict sur ce que vous envoyez et souple sur ce que vous
recevez" me parait interressant pour gérer le courrier.

Renoncer au filtrage c'est la porte grande ouverte aux spams, appliquer le
filtrage c'est les utilisateurs qui ne reçoivent pas certains mails qui
peuvent être importants.

Tout filtrage s'expose potentiellement à un faux positif.
Maintenant il existe amha largement de quoi lutter contre tant que tu
t'occupe d'un MTA de taille petite ou moyenne[1]. Pour mon cas le
greylisting a fait des miracles et contrairement aux prévisions des
cassandres il est efficace depuis pas mal de temps (je me limite même à
5mn).

Ensuite pour ce qui reste tu peux tagger les spam/virus (amavisd,
mailscanner + spamassassin, razor,... ) et les laisser passer.

Enfin pour des raisons évidentes de sécu je mets les emails vérolés en
quarantaine, récupérable sur demande (processus automatisé ou non).


En conjonction avec des RTBL très peu aggressives (en clair qui laissent
passer beaucoup de merdes quand même mais qui évitent les faux positifs)
je n'utilise même plus de filtre pour "ranger" les emails taggés spam ou
virus tellement j'en ai peu (et j'ai quelques adresses publiques dans la
nature).

Ce qui est assez incroyable c'est de constater parfois que certains mails
rejetés sont émis depuis de très grosses boites mais que leurs relais
étant mal déclarés ou mal configurés les mails vont à la trappe.

Il faudra un jour arrêter de supposer que grosse boite = compétance.
Pour certaines c'est le cas mais l'expérience semble surtout montrer
qu'une augmentation des effectifs va souvent avec une dillution des
responsabilités ( via, parfois, des sous traitances attribuées un peu à
la légère).

Certains ont-ils déjà été confrontés à ce problème, quelle
démarche avez vous adopté ?

Tiens c'est marrant, tu bégaye du clavier? :)
Voir plus haut la réponse.

Je ne peut quand même pas éplucher les
logs à longueur de journée

Ahem, l'examen des logs ça se scripte.
Ici on retombe en plein dans l'objet de se forum :
A quoi ça sert de mettre des dispositifs en place si on ne peut les
exploiter? (et j'imagine que personne ne va s'en servir pour du forensic,
si seulement les logs sont encore intacts)

Pour rester dans la sécu d'ailleurs j'aime bien l'anti phishing de
MailScanner, même s'il est un peu violent (il ajoute un warning dans
parties html où un lien ne pointe pas vers le domaine représenté par le
texte qui va avec).

et écrire à tous ces gens de mieux
configurer leurs relais ...

J'ai parfois vu des MX secondaires refuser le domaine normalement
attribué, ou quelques gags bizarres, j'ai toujours eu une réponse du
postmaster (bon, en général les rares fois où je dois leur écrire je
mets aussi en copie au responsable du domaine, etc... Ca aide à la
réaction :-/ ).

Mais bon, je choississais des postmasters des boites avec qui j'ai un
contact direct ou indirect ; pour la majeure partie c'est peine perdue et
tu risque de consommer énormément de temps sans remplir le violon :)

Si le postmaster ne réagit pas et que tu dois accepter son courrier, de
toute façon c'est réglé (ce qui ne signifie pas que tu ne dois pas
examiner les emails pour du spam ou les virus[2] ni accepter toutes les
adresses IP qui ne sont pas des MTA (histoire de ne pas lancer un troll
sur le filtrage des adresses IP "residentielles". D'ailleurs toute
réponse à ce sujet part en hors charte à la modération, ils ont plus
l'habitude sur fcms :) )

Merci pour vos lumières

Celle d'un amateur éteind, manque de sommeil :)

Eric

[1] A partir d'une certaine taille les mécanismes de filtrage et de
vérification deviennent coûteux en ressources et demande beaucoup de
rélexion préalable, car un mauvais choix peut vite mettre à genoux les
serveurs. Remarque dans ce cas c'est réglé pour le filtrage :)

[2] Je sais, ce n'est pas le rôle d'un MTA de vérifier les emails mais
j'ai une paix royale avec les end users pas à jour de leur antivirus et
adeptes du "c'est quoi ça? je clicke!)

Le Wed, 27 Jul 2005 16:07:20 +0000, jcc a écrit :

Bonjour.
Le post est à cheval sur fcs et fcms. Le sujet est souvent visité la bas
alors ça peut aussi être interressant de jeter un oeil aux archives.

Bonjour à tous,

Très classiquement j'utilise en DMZ un relais messagerie configuré pour
rejeter les mails reçus qui échouent au test reverse DNS (ip-champ MX
inconnus des DNS publics et/ou champ Helo ne correspondant pas à ce qui
est renseigné dans les DNS).

Autant je verifie le reverse autant amha vérifier le EHLO (ou HELO)
comme tu le fais c'est un coup à bloquer un paquet d'emails légitimes.

Le RFC2821 précise :
the command *may* be interpreted as saying "Hello, I am <domain>"
mais il n'y a nulle part une telle obligation, et pas mal de postmasters
n'y prêtent pas une attention suffisante pour que ça puisse être
discriminant.

Par contre tu peux filtrer sans risque un HELO <ton domaine> si tu n'a pas
à recevoir ça sur ton serveur. Attention quand même aux mauvais gags.

Pour le filtrage sur le reverse il ne fait pas non plus partie de RFC2821
mais il est souvent utilisé car il est rare qu'un serveur smtp légitime
n'ait pas un reverse positionné plus ou moins correctement.

La plus grande partie des mails shootés sont des spams bien sur, mais
quelques uns sont émis par des expéditeurs de bonne foi utilisant une
messagerie mal configurée.

Ben oui, c'est normal, voir au dessus.

Les émetteurs des mails shootés reçoivent un mail d'alerte en retour,
mais comme 999 fois sur 1000 il ne le comprennent pas et ne le
transmettent pas à postmaster si il existe.

Surtout si ton utilisateur est français et que Môssieur Postmaster parle
engliche ;)

Ma question est de savoir quelle démarche vous appliquez face à ce
problème pour ceux qui y sont confrontés ?

Autant on peut reprocher pas mal de chose à sendmail, autant son
leitmotiv "soyez strict sur ce que vous envoyez et souple sur ce que vous
recevez" me parait interressant pour gérer le courrier.

Renoncer au filtrage c'est la porte grande ouverte aux spams, appliquer le
filtrage c'est les utilisateurs qui ne reçoivent pas certains mails qui
peuvent être importants.

Tout filtrage s'expose potentiellement à un faux positif.
Maintenant il existe amha largement de quoi lutter contre tant que tu
t'occupe d'un MTA de taille petite ou moyenne[1]. Pour mon cas le
greylisting a fait des miracles et contrairement aux prévisions des
cassandres il est efficace depuis pas mal de temps (je me limite même à
5mn).

Ensuite pour ce qui reste tu peux tagger les spam/virus (amavisd,
mailscanner + spamassassin, razor,... ) et les laisser passer.

Enfin pour des raisons évidentes de sécu je mets les emails vérolés en
quarantaine, récupérable sur demande (processus automatisé ou non).


En conjonction avec des RTBL très peu aggressives (en clair qui laissent
passer beaucoup de merdes quand même mais qui évitent les faux positifs)
je n'utilise même plus de filtre pour "ranger" les emails taggés spam ou
virus tellement j'en ai peu (et j'ai quelques adresses publiques dans la
nature).

Ce qui est assez incroyable c'est de constater parfois que certains mails
rejetés sont émis depuis de très grosses boites mais que leurs relais
étant mal déclarés ou mal configurés les mails vont à la trappe.

Il faudra un jour arrêter de supposer que grosse boite = compétance.
Pour certaines c'est le cas mais l'expérience semble surtout montrer
qu'une augmentation des effectifs va souvent avec une dillution des
responsabilités ( via, parfois, des sous traitances attribuées un peu à
la légère).

Certains ont-ils déjà été confrontés à ce problème, quelle
démarche avez vous adopté ?

Tiens c'est marrant, tu bégaye du clavier? :)
Voir plus haut la réponse.

Je ne peut quand même pas éplucher les
logs à longueur de journée

Ahem, l'examen des logs ça se scripte.
Ici on retombe en plein dans l'objet de se forum :
A quoi ça sert de mettre des dispositifs en place si on ne peut les
exploiter? (et j'imagine que personne ne va s'en servir pour du forensic,
si seulement les logs sont encore intacts)

Pour rester dans la sécu d'ailleurs j'aime bien l'anti phishing de
MailScanner, même s'il est un peu violent (il ajoute un warning dans
parties html où un lien ne pointe pas vers le domaine représenté par le
texte qui va avec).

et écrire à tous ces gens de mieux
configurer leurs relais ...

J'ai parfois vu des MX secondaires refuser le domaine normalement
attribué, ou quelques gags bizarres, j'ai toujours eu une réponse du
postmaster (bon, en général les rares fois où je dois leur écrire je
mets aussi en copie au responsable du domaine, etc... Ca aide à la
réaction :-/ ).

Mais bon, je choississais des postmasters des boites avec qui j'ai un
contact direct ou indirect ; pour la majeure partie c'est peine perdue et
tu risque de consommer énormément de temps sans remplir le violon :)

Si le postmaster ne réagit pas et que tu dois accepter son courrier, de
toute façon c'est réglé (ce qui ne signifie pas que tu ne dois pas
examiner les emails pour du spam ou les virus[2] ni accepter toutes les
adresses IP qui ne sont pas des MTA (histoire de ne pas lancer un troll
sur le filtrage des adresses IP "residentielles". D'ailleurs toute
réponse à ce sujet part en hors charte à la modération, ils ont plus
l'habitude sur fcms :) )

Merci pour vos lumières

Celle d'un amateur éteind, manque de sommeil :)

Eric

[1] A partir d'une certaine taille les mécanismes de filtrage et de
vérification deviennent coûteux en ressources et demande beaucoup de
rélexion préalable, car un mauvais choix peut vite mettre à genoux les
serveurs. Remarque dans ce cas c'est réglé pour le filtrage :)

[2] Je sais, ce n'est pas le rôle d'un MTA de vérifier les emails mais
j'ai une paix royale avec les end users pas à jour de leur antivirus et
adeptes du "c'est quoi ça? je clicke!)

Bonjour,

Bonjour à tous,
Très classiquement j'utilise en DMZ un relais messagerie configuré pour
rejeter les mails reçus qui échouent au test reverse DNS (ip-champ MX
inconnus des DNS publics et/ou champ Helo ne correspondant pas à ce qui
est renseigné dans les DNS).
La plus grande partie des mails shootés sont des spams bien sur, mais
quelques uns sont émis par des expéditeurs de bonne foi utilisant une
messagerie mal configurée.
Les émetteurs des mails shootés reçoivent un mail d'alerte en retour,
mais comme 999 fois sur 1000 il ne le comprennent pas et ne le
transmettent pas à postmaster si il existe.
Ma question est de savoir quelle démarche vous appliquez face à ce
problème pour ceux qui y sont confrontés ?
Renoncer au filtrage c'est la porte grande ouverte aux spams, appliquer
le filtrage c'est les utilisateurs qui ne reçoivent pas certains mails
qui peuvent être importants.
Ce qui est assez incroyable c'est de constater parfois que certains
mails rejetés sont émis depuis de très grosses boites mais que leurs
relais étant mal déclarés ou mal configurés les mails vont à la trappe.
Certains ont-ils déjà été confrontés à ce problème, quelle démarche avez
vous adopté ? Je ne peut quand même pas éplucher les logs à longueur de
journée et écrire à tous ces gens de mieux configurer leurs relais ...
Merci pour vos lumières

Je ne pense pas qu'il existe une méthode universelle pour tout supprimer.
Plus tu mets de filtres, plus t'as de chances d'avoir des faux positifs.
Il faut mettre en place seulement les filtres qui matchent un maximum de
clients sans faire de faux positifs en fonction de tes critères.
En fait je filtre plus les mauvaises configurations que le manque de
configuration, par exemple :

pour le Hello, s'il n'est pas configuré (adresse IP par ex), c'est pas
grave ... par contre si le hello correspond à mon nom de domaine ou à
mon adresse IP publique ... je vire.
Pareil pour le reverse DNS : il doit au moins exister et si ce n'est pas
du asmtp (pour les nomades) et que ça vient de *.abo.wanadoo.fr ou de
*.fbx.proxad.net ... refus de la transaction smtp avec message explicatif.

Tout ça permet quand même de faire du ménage pendant la transaction smtp.
Après rien ne vaut un anti-spam qui travaille sur le corps du message.
Je suis en train de mettre en place Exim4 avec SA-Exim qui permet couper
net l'échange DATA en fonction du score de SA ... l'avantage étant que
le serveur d'en face reste avec sa 'merde' sur les bras.

Actuellement je me dirige aussi avec Exim4 vers une fonction
intéressante : le callout ... durant le début de la transaction smtp le
serveur vérifie 'en live' l'existence de l'adresse mail présentée par le
client. Je crois que certains gros serveur n'aiment pas cette
fonctionalité (aol etc ... mais à vérifier).

Voilà en gros ce que je suis en train de mettre en place.
Le seul filtre où j'ai un gros doute c'est l'obligation d'avoir un
reverse DNS ... mais si je ne mets pas ça en place ... je ne peux plus
filtrer sur le reverse donc pour moi c'est un moindre mal.

De plus ne pas oublier de désactiver *tous* les filtres pour
'postmaster' et 'abuse'.

Samuel.