J'ai mis en place une adresse chez moi de type spam@chez-moi dont le
principe est de piper dans /usr/bin/sa-learn --spam
De cette fa=C3=A7on, tous les spams qui traversent encore spamassassin sont
trait=C3=A9s de cette mani=C3=A8re.
Malheureusement, je trouve sur mon disque deux endroits o=C3=B9 sont
stock=C3=A9s les bayes_toks et autres fichiers d'apprentissage:
/var/mail/.spamassassin/ et /root/.spamassassin/
Il semble que le second soit utilis=C3=A9 par mon pipe, =C3=A9tant donn=C3=
=A9 que
c'est le fichier /etc/aliases qui contient cette directive.
Concernant le premier, je ne sais pas si c'est spamd (lanc=C3=A9 par root)
ou spamc (lanc=C3=A9 par exim) qui g=C3=A9n=C3=A8rent/utilisent ce r=C3=A9p=
ertoire.
Une piste serait la bienvenue.
--=20
Mais si, Linux est user-friendly. Mais Linux il choisit ses amis, lui !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Daniel Huhardeaux
François TOURDE wrote:
Bonjour la liste.
J'ai mis en place une adresse chez moi de type dont le principe est de piper dans /usr/bin/sa-learn --spam
De cette façon, tous les spams qui traversent encore spamassassin sont traités de cette manière.
Malheureusement, je trouve sur mon disque deux endroits où sont stockés les bayes_toks et autres fichiers d'apprentissage:
/var/mail/.spamassassin/ et /root/.spamassassin/
Il semble que le second soit utilisé par mon pipe, étant donné que c'est le fichier /etc/aliases qui contient cette directive.
Es tu sur? Postfix par ex, execute les scripts avec l'identite nobody:nogroup.
J'ai créé un utilisateur learn.spam et un learn.ham avec bash /bin/false. Le répertoire .spamassassin de learn.ham pointant sur celui de learn.spam et writable par nogroup. Les mails arrivent à learn.ham ou learn.spam puis sont pipés sa-learn --ham ou --spam
J'ai mis en place une adresse chez moi de type spam@chez-moi dont le
principe est de piper dans /usr/bin/sa-learn --spam
De cette façon, tous les spams qui traversent encore spamassassin sont
traités de cette manière.
Malheureusement, je trouve sur mon disque deux endroits où sont
stockés les bayes_toks et autres fichiers d'apprentissage:
/var/mail/.spamassassin/ et /root/.spamassassin/
Il semble que le second soit utilisé par mon pipe, étant donné que
c'est le fichier /etc/aliases qui contient cette directive.
Es tu sur? Postfix par ex, execute les scripts avec l'identite
nobody:nogroup.
J'ai créé un utilisateur learn.spam et un learn.ham avec bash
/bin/false. Le répertoire .spamassassin de learn.ham pointant sur celui
de learn.spam et writable par nogroup. Les mails arrivent à learn.ham ou
learn.spam puis sont pipés sa-learn --ham ou --spam
J'ai mis en place une adresse chez moi de type dont le principe est de piper dans /usr/bin/sa-learn --spam
De cette façon, tous les spams qui traversent encore spamassassin sont traités de cette manière.
Malheureusement, je trouve sur mon disque deux endroits où sont stockés les bayes_toks et autres fichiers d'apprentissage:
/var/mail/.spamassassin/ et /root/.spamassassin/
Il semble que le second soit utilisé par mon pipe, étant donné que c'est le fichier /etc/aliases qui contient cette directive.
Es tu sur? Postfix par ex, execute les scripts avec l'identite nobody:nogroup.
J'ai créé un utilisateur learn.spam et un learn.ham avec bash /bin/false. Le répertoire .spamassassin de learn.ham pointant sur celui de learn.spam et writable par nogroup. Les mails arrivent à learn.ham ou learn.spam puis sont pipés sa-learn --ham ou --spam
Le 13235ième jour après Epoch, Daniel Huhardeaux écrivait:
François TOURDE wrote:
Bonjour la liste.
J'ai mis en place une adresse chez moi de type dont le principe est de piper dans /usr/bin/sa-learn --spam
De cette façon, tous les spams qui traversent encore spamassassin sont traités de cette manière.
Malheureusement, je trouve sur mon disque deux endroits où sont stockés les bayes_toks et autres fichiers d'apprentissage:
/var/mail/.spamassassin/ et /root/.spamassassin/
Il semble que le second soit utilisé par mon pipe, étant donné que c'est le fichier /etc/aliases qui contient cette directive.
Es tu sur? Postfix par ex, execute les scripts avec l'identite nobody:nogroup.
Après vérification, c'est bien mail:mail qui est l'initiateur du pipe, donc les fichiers de /var/mail/.spamassassin/ sont manipulés par sa-learn
Par contre, les fichiers de /root/.spamassassin sont touchés à la même date.
Bref, je ne sais pas comment faire pour "unifier" ce comportement, sachant que spamc est utilisé "system-wide" et que sa-learn a cette même vocation (Tous mes utilisateurs ont la même conception du spam).
Tout dépend de ton setup (mailer, spamassasin, mailscanner, antivirus, ....) Ici aussi c'est worldwide et je n'ai pas ce comportement. N'y aurait il pas une règle procmail?
Le 13235ième jour après Epoch,
Daniel Huhardeaux écrivait:
François TOURDE wrote:
Bonjour la liste.
J'ai mis en place une adresse chez moi de type spam@chez-moi dont le
principe est de piper dans /usr/bin/sa-learn --spam
De cette façon, tous les spams qui traversent encore spamassassin sont
traités de cette manière.
Malheureusement, je trouve sur mon disque deux endroits où sont
stockés les bayes_toks et autres fichiers d'apprentissage:
/var/mail/.spamassassin/ et /root/.spamassassin/
Il semble que le second soit utilisé par mon pipe, étant donné que
c'est le fichier /etc/aliases qui contient cette directive.
Es tu sur? Postfix par ex, execute les scripts avec l'identite
nobody:nogroup.
Après vérification, c'est bien mail:mail qui est l'initiateur du pipe,
donc les fichiers de /var/mail/.spamassassin/ sont manipulés par
sa-learn
Par contre, les fichiers de /root/.spamassassin sont touchés à la même
date.
Bref, je ne sais pas comment faire pour "unifier" ce comportement,
sachant que spamc est utilisé "system-wide" et que sa-learn a cette
même vocation (Tous mes utilisateurs ont la même conception du spam).
Tout dépend de ton setup (mailer, spamassasin, mailscanner, antivirus,
....) Ici aussi c'est worldwide et je n'ai pas ce comportement. N'y
aurait il pas une règle procmail?
Le 13235ième jour après Epoch, Daniel Huhardeaux écrivait:
François TOURDE wrote:
Bonjour la liste.
J'ai mis en place une adresse chez moi de type dont le principe est de piper dans /usr/bin/sa-learn --spam
De cette façon, tous les spams qui traversent encore spamassassin sont traités de cette manière.
Malheureusement, je trouve sur mon disque deux endroits où sont stockés les bayes_toks et autres fichiers d'apprentissage:
/var/mail/.spamassassin/ et /root/.spamassassin/
Il semble que le second soit utilisé par mon pipe, étant donné que c'est le fichier /etc/aliases qui contient cette directive.
Es tu sur? Postfix par ex, execute les scripts avec l'identite nobody:nogroup.
Après vérification, c'est bien mail:mail qui est l'initiateur du pipe, donc les fichiers de /var/mail/.spamassassin/ sont manipulés par sa-learn
Par contre, les fichiers de /root/.spamassassin sont touchés à la même date.
Bref, je ne sais pas comment faire pour "unifier" ce comportement, sachant que spamc est utilisé "system-wide" et que sa-learn a cette même vocation (Tous mes utilisateurs ont la même conception du spam).
Tout dépend de ton setup (mailer, spamassasin, mailscanner, antivirus, ....) Ici aussi c'est worldwide et je n'ai pas ce comportement. N'y aurait il pas une règle procmail?
Non. En fait, il faut (vaut mieux?) passer l'option "-u mail" dans /etc/default/spamassassin et laisser traiter l'alias système par le user mail (dans exim).
Non. En fait, il faut (vaut mieux?) passer l'option "-u mail" dans
/etc/default/spamassassin et laisser traiter l'alias système par le
user mail (dans exim).
Non. En fait, il faut (vaut mieux?) passer l'option "-u mail" dans /etc/default/spamassassin et laisser traiter l'alias système par le user mail (dans exim).
