Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :
Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Le 07/04/2014 17:52, Christophe a écrit :Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
ça me pose un vrai problème de blacklister mon propre domaine !!!!!!
Dans mon exemple, domaine.com représente le domaine de mon serveur...
Le 07/04/2014 17:52, Christophe a écrit :
Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :
Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
ça me pose un vrai problème de blacklister mon propre domaine !!!!!!
Dans mon exemple, domaine.com représente le domaine de mon serveur...
Le 07/04/2014 17:52, Christophe a écrit :Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
ça me pose un vrai problème de blacklister mon propre domaine !!!!!!
Dans mon exemple, domaine.com représente le domaine de mon serveur...
Le 07/04/2014 17:52, Christophe a écrit :Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
ça me pose un vrai problème de blacklister mon propre domaine !!!!!!
Dans mon exemple, domaine.com représente le domaine de mon serveur...
Le 07/04/2014 17:52, Christophe a écrit :
Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :
Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
ça me pose un vrai problème de blacklister mon propre domaine !!!!!!
Dans mon exemple, domaine.com représente le domaine de mon serveur...
Le 07/04/2014 17:52, Christophe a écrit :Bonsoir,
Le 07/04/2014 16:35, C. Mourad Jaber a écrit :Est-il possible d'ajouter une règle dans postfix pour rejeter les mails
contenant une forme d'usurpation d'identité aussi grossière ?
Je pense que l'option smtpd_sender_restrictions doit pouvoir répondre à
ta problématique :
dans le fichier /etc/postfix/main.cf
smtpd_sender_restrictions = hash:/etc/postfix/access
dans le fichier /etc/postfix/access
domaine.com REJECT
suivi d'un
postmap /etc/postfix/access
pour générer le fichier hash qui va bien.
A prendre avec des pincettes, je n'ai pas testé ;) .
@+
Christophe.
ça me pose un vrai problème de blacklister mon propre domaine !!!!!!
Dans mon exemple, domaine.com représente le domaine de mon serveur...
évidement le scan.domaine.com n'existe pas mais les règles de spf
vont laisser passer ce message parce que le domaine semble
légitime...
évidement le scan.domaine.com n'existe pas mais les règles de spf
vont laisser passer ce message parce que le domaine semble
légitime...
évidement le scan.domaine.com n'existe pas mais les règles de spf
vont laisser passer ce message parce que le domaine semble
légitime...
J'ai reçu une vague de spam forgé d'une manière qui arrive à passer les
enregistrements SPF : Ce sont des mails contenant un HELO déclarant un sous
domaine du nom de domaine de réception par exemple :
- mail de destination et de source :
- serveur d'envoi : Received: from murphx.net (109.170.154.29) by
scan.domaine.com (10.0.4.132) with Microsoft SMTP Server
évidement le scan.domaine.com n'existe pas mais les règles de s pf vont
laisser passer ce message parce que le domaine semble légitime...
Est-il possible d'ajouter une règle dans postfix pour rejeter les ma ils
contenant une forme d'usurpation d'identité aussi grossière ?
J'ai reçu une vague de spam forgé d'une manière qui arrive à passer les
enregistrements SPF : Ce sont des mails contenant un HELO déclarant un sous
domaine du nom de domaine de réception par exemple :
- mail de destination et de source : fax@domaine.com
- serveur d'envoi : Received: from murphx.net (109.170.154.29) by
scan.domaine.com (10.0.4.132) with Microsoft SMTP Server
évidement le scan.domaine.com n'existe pas mais les règles de s pf vont
laisser passer ce message parce que le domaine semble légitime...
Est-il possible d'ajouter une règle dans postfix pour rejeter les ma ils
contenant une forme d'usurpation d'identité aussi grossière ?
J'ai reçu une vague de spam forgé d'une manière qui arrive à passer les
enregistrements SPF : Ce sont des mails contenant un HELO déclarant un sous
domaine du nom de domaine de réception par exemple :
- mail de destination et de source :
- serveur d'envoi : Received: from murphx.net (109.170.154.29) by
scan.domaine.com (10.0.4.132) with Microsoft SMTP Server
évidement le scan.domaine.com n'existe pas mais les règles de s pf vont
laisser passer ce message parce que le domaine semble légitime...
Est-il possible d'ajouter une règle dans postfix pour rejeter les ma ils
contenant une forme d'usurpation d'identité aussi grossière ?
RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Johnny B a écrit :RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
JKB
Johnny B a écrit :
RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.
Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
JKB
Johnny B a écrit :RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
JKB
Johnny B a écrit :RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
JKB
Johnny B a écrit :
RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.
Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
JKB
Johnny B a écrit :RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
JKB
Le 04/07/2014 10:40 PM, BERTRAND Joël a écrit :Johnny B a écrit :RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Merci pour les infos du SPF je connais ;)
Pourquoi utiliser du SPF pour éviter le forging alors que Postfix le
fait très bien et de façon native ? Je répondrai à ma propre question en
disant que c'est un choix perso.
SPF est très puissant mais n'est utile que si la grande majorité des
domaines ont un enregistrement SPF, or ce n'est pas vraiment le cas.
Meme si les majors des webmails ont encouragé l'utilisation du SPF ca ne
deviendra sans doute jamais un standard. ( et je le déplore)
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
J'ai largement utilisé ces tools y compris le greylisting ;) (je ne vois
pas l'intérêt du greylisting mais c'est un avis perso)
Je préfère utiliser Postfix a "100%" plutot que de rajouter des couches
de checks alors qu'il remplit très bien ce rôle (c'est aussi un avis
perso ;) )
Le 04/07/2014 10:40 PM, BERTRAND Joël a écrit :
Johnny B a écrit :
RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Merci pour les infos du SPF je connais ;)
Pourquoi utiliser du SPF pour éviter le forging alors que Postfix le
fait très bien et de façon native ? Je répondrai à ma propre question en
disant que c'est un choix perso.
SPF est très puissant mais n'est utile que si la grande majorité des
domaines ont un enregistrement SPF, or ce n'est pas vraiment le cas.
Meme si les majors des webmails ont encouragé l'utilisation du SPF ca ne
deviendra sans doute jamais un standard. ( et je le déplore)
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.
Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
J'ai largement utilisé ces tools y compris le greylisting ;) (je ne vois
pas l'intérêt du greylisting mais c'est un avis perso)
Je préfère utiliser Postfix a "100%" plutot que de rajouter des couches
de checks alors qu'il remplit très bien ce rôle (c'est aussi un avis
perso ;) )
Le 04/07/2014 10:40 PM, BERTRAND Joël a écrit :Johnny B a écrit :RE Hello, (désolé pour le bug de police thunderbird ;)
Pour le forging il est inutile de passer par SPF ou Policyd2 par
exemple. (ces tools sont très utiles mais pour d'autres choses)
Il faut donc utiliser les options de restrictions Postfix comme :
smtpd_sender_restrictions >>>
reject_authenticated_sender_login_mismatch
reject_invalid_helo_hostname
La méthode de Joel BERTRAND pour aussi fonctionner mais ce n'est pas
viable. Imagine toi blacklister 50 000 serveurs de spams ;)
Sauf que je ne blackliste rien. C'est au smtp distant d'avoir un
champ SPF valide. Je ne fais que vérifier lors du FROM (donc bien
avant la transaction concernant les données) que l'émetteur utilise
bien le bon SMTP.
Mon domaine, c'est systella.fr avec un champ SPF "v=spf1
+a:rayleigh.systella.fr -all". Si une adresse forgée vient chez moi
avec comme expéditeur un sous-domaine de systella.fr et que ce mail
n'est pas venu de rayleigh.systella.fr, mon sendmail le jette (même
sans bounce). Et ce mécanisme est automatique. Il n'y a pas 50000
serveurs de spam à blacklister.
Merci pour les infos du SPF je connais ;)
Pourquoi utiliser du SPF pour éviter le forging alors que Postfix le
fait très bien et de façon native ? Je répondrai à ma propre question en
disant que c'est un choix perso.
SPF est très puissant mais n'est utile que si la grande majorité des
domaines ont un enregistrement SPF, or ce n'est pas vraiment le cas.
Meme si les majors des webmails ont encouragé l'utilisation du SPF ca ne
deviendra sans doute jamais un standard. ( et je le déplore)
Raffinement : j'utilise aussi les soft-failed pour greylister,
comme les blacklists traditionnelles. C'est très efficace.Il est essentiel d'utiliser les restrictions Postfix avant les tools
DKIM,SPF,Spamassassin,Amavis etc... Ces restrictions sont natives a
Postfix et fonctionnent divinement bien, cela évite aussi de bouffer les
ressources car ces forging ou spams sont rejetés avant d'être traités.
Attention la gestion Postfix peu devenir un enfer ;)
Je pense surtout que tu n'as pas bien compris l'intérêt du SPF. Ce
n'est pas d'éviter les spams en provenance de domaines de spam, mais
justement d'éviter que des spammeurs forgent des adresses.
J'ai largement utilisé ces tools y compris le greylisting ;) (je ne vois
pas l'intérêt du greylisting mais c'est un avis perso)
Je préfère utiliser Postfix a "100%" plutot que de rajouter des couches
de checks alors qu'il remplit très bien ce rôle (c'est aussi un avis
perso ;) )