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 ...
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 ?
Tu peux mettre dans ton message de rejet une URL qui renvoie vers une page HTML. Cela te permet de développer les explications, le tout dans plusieurs langues, etc. N'oublie pas que ceux qui recevront le message d'erreur sont les utilisateurs finaux et ce seront donc eux avant tout qui accéderont à la page. Mais celle-ci doit aussi donner les détails suffisants pour les administrateurs.
Skreetch
Bonjour à tous,
Bonjour,
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 ?
Tu peux mettre dans ton message de rejet une URL qui renvoie vers une
page HTML. Cela te permet de développer les explications, le tout dans
plusieurs langues, etc. N'oublie pas que ceux qui recevront le message
d'erreur sont les utilisateurs finaux et ce seront donc eux avant tout
qui accéderont à la page. Mais celle-ci doit aussi donner les détails
suffisants pour les administrateurs.
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 ?
Tu peux mettre dans ton message de rejet une URL qui renvoie vers une page HTML. Cela te permet de développer les explications, le tout dans plusieurs langues, etc. N'oublie pas que ceux qui recevront le message d'erreur sont les utilisateurs finaux et ce seront donc eux avant tout qui accéderont à la page. Mais celle-ci doit aussi donner les détails suffisants pour les administrateurs.
Skreetch
Eric Razny
Le Thu, 28 Jul 2005 09:12:49 +0000, Samuel a écrit :
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.
Aie! J'avais discuté de cette possibilité il y a un ou deux ans sur des forums anglophone -en particulier je voulais faire un filtrage sur les headers -jusqu'au premier double saut de ligne à partir du DATA- et j'en avais conclus que ce n'est pas une bonne idée :
a) ça viole les RFCs
b) Si c'est un vrai MTA en face, l'arrêt n'étant pas prévu dans les RFCs il va probablement réémettre un nombre de fois conséquent "sa merde" et l'économie de BP (voir point 3) et de temps machine va vite se transformer en dépense
c) le fonctionnement même de TCP/IP fait que de toute façon il y a de forte chance que tu reçoive tout les paquets même si tu ne traite qu'une partie du premier. Donc de toute façon pour la BP c'est rappé (les virus et autres spams se chiffrent rarement en MB).
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).
Et c'est la merde si en face tu as du filtrage pour une raison ou une autre (greylisting par exmple, car toi tu vas renvoyé un code 5xx parce que tu as reçu du 4xx)
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'.
Yep. Sauf pour les quelques domaines que j'ai mis *manuellement* [1] avec amour dans mon access :)
Eric.
PS : la on est franchement HS, donc XPost et Fu2
[1] ie ce n'est pas une erreur, je ne veux plus les entendre.
Le Thu, 28 Jul 2005 09:12:49 +0000, Samuel a écrit :
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.
Aie!
J'avais discuté de cette possibilité il y a un ou deux ans sur des
forums anglophone -en particulier je voulais faire un filtrage sur les
headers -jusqu'au premier double saut de ligne à partir du DATA- et j'en
avais conclus que ce n'est pas une bonne idée :
a) ça viole les RFCs
b) Si c'est un vrai MTA en face, l'arrêt n'étant pas prévu dans les
RFCs il va probablement réémettre un nombre de fois conséquent "sa
merde" et l'économie de BP (voir point 3) et de temps machine va vite se
transformer en dépense
c) le fonctionnement même de TCP/IP fait que de toute façon il y a de
forte chance que tu reçoive tout les paquets même si tu ne traite qu'une
partie du premier. Donc de toute façon pour la BP c'est rappé (les virus
et autres spams se chiffrent rarement en MB).
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).
Et c'est la merde si en face tu as du filtrage pour une raison ou une
autre (greylisting par exmple, car toi tu vas renvoyé un code 5xx parce
que tu as reçu du 4xx)
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'.
Yep. Sauf pour les quelques domaines que j'ai mis *manuellement* [1] avec
amour dans mon access :)
Eric.
PS : la on est franchement HS, donc XPost et Fu2
[1] ie ce n'est pas une erreur, je ne veux plus les entendre.
Le Thu, 28 Jul 2005 09:12:49 +0000, Samuel a écrit :
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.
Aie! J'avais discuté de cette possibilité il y a un ou deux ans sur des forums anglophone -en particulier je voulais faire un filtrage sur les headers -jusqu'au premier double saut de ligne à partir du DATA- et j'en avais conclus que ce n'est pas une bonne idée :
a) ça viole les RFCs
b) Si c'est un vrai MTA en face, l'arrêt n'étant pas prévu dans les RFCs il va probablement réémettre un nombre de fois conséquent "sa merde" et l'économie de BP (voir point 3) et de temps machine va vite se transformer en dépense
c) le fonctionnement même de TCP/IP fait que de toute façon il y a de forte chance que tu reçoive tout les paquets même si tu ne traite qu'une partie du premier. Donc de toute façon pour la BP c'est rappé (les virus et autres spams se chiffrent rarement en MB).
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).
Et c'est la merde si en face tu as du filtrage pour une raison ou une autre (greylisting par exmple, car toi tu vas renvoyé un code 5xx parce que tu as reçu du 4xx)
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'.
Yep. Sauf pour les quelques domaines que j'ai mis *manuellement* [1] avec amour dans mon access :)
Eric.
PS : la on est franchement HS, donc XPost et Fu2
[1] ie ce n'est pas une erreur, je ne veux plus les entendre.
Eric Razny
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. 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!)
jcc
Merci à tous pour ces nombreuses réponses, je crois que dans un premier temps je vais tester sur l'existence dans les DNS des relais smtp (ip-MX) qui envoient les mails, mais laisser tomber le test pour le Helo qui me semble effectivement un peu exagéré.
-- jc
Merci à tous pour ces nombreuses réponses, je crois que dans un premier
temps je vais tester sur l'existence dans les DNS des relais smtp
(ip-MX) qui envoient les mails, mais laisser tomber le test pour le Helo
qui me semble effectivement un peu exagéré.
Merci à tous pour ces nombreuses réponses, je crois que dans un premier temps je vais tester sur l'existence dans les DNS des relais smtp (ip-MX) qui envoient les mails, mais laisser tomber le test pour le Helo qui me semble effectivement un peu exagéré.
-- jc
Patrice Labracherie
"Alain Montfranc" a écrit dans le message de news:
Patrice Labracherie a couché sur son écran : Comme ca quand un client est vérolé tu en profites bien ;-) ?
Sinon le systeme des greylist est extremement efficace...
effectivement, ca permet de rentabiliser l'antivirus :) mais c'est quand même assez rare (a vu de pif <1% / spam)
le système des greylist est chouette, mais j'utilise aussi fetchmail pour alimenter une partie de la messagerie, et par construction ca peut pas marcher avec lui, dommage.
"Alain Montfranc" <alain-news.wanadoo.fr@montfranc.com> a écrit dans le
message de news:mn.e1d17d573f4d3c82.15643@montfranc.com...
Patrice Labracherie a couché sur son écran :
Comme ca quand un client est vérolé tu en profites bien ;-) ?
Sinon le systeme des greylist est extremement efficace...
effectivement, ca permet de rentabiliser l'antivirus :)
mais c'est quand même assez rare (a vu de pif <1% / spam)
le système des greylist est chouette, mais j'utilise aussi fetchmail pour
alimenter une partie de la messagerie, et par construction ca peut pas
marcher avec lui, dommage.
"Alain Montfranc" a écrit dans le message de news:
Patrice Labracherie a couché sur son écran : Comme ca quand un client est vérolé tu en profites bien ;-) ?
Sinon le systeme des greylist est extremement efficace...
effectivement, ca permet de rentabiliser l'antivirus :) mais c'est quand même assez rare (a vu de pif <1% / spam)
le système des greylist est chouette, mais j'utilise aussi fetchmail pour alimenter une partie de la messagerie, et par construction ca peut pas marcher avec lui, dommage.
