Le 15.06.02, Grégoire Cachet a tapoté :
| Le sam 15/06/2002 à 11:34, Thomas Nemeth a écrit :
| > Le 15.06.02, [EMAIL PROTECTED] a tapoté :
| >
| > | > > mda "/usr/bin/procmail -Y -d %T"
| > | > j'ai ajouté ca dans mon /etc/fetchmailrc
| >
| > Ce n'est pas forcément nécessaire : si la config de fetchmail
| > ne spécifie pas de MDA, il envoie les messages au MTA local (si
| > tu en as un) et celui-ci les transmet au MDA s'il y a lieu.
|
| si j'ai compris le principe MTA = exim chez moi ?
Oui.
| en gros fetchmail récupere les messages par pop
| il les envoye au MTA local par smtp (j'ai remarqué ca en debug-run)
| le MTA local se charge de les mettre dans ma boite
Oui, via le MDA :)
POP --> fetchmail --> MTA --> MDA
|___________________^ (si on spécifie l'option mda
dans la config de fetchmail)
| je les récupere sur la machine perso par pop avec evolution
Par mbox si c'est en local (mbox est le format standard
de /var/mail/xxx)
| il y a un autre circuit
|
| les mails arrivent directement par smtp dans exim
Dans ce cas il faut que ton serveur SMTP soit ouvert à
l'extérieur. Perso, je ne le fais pas...
| exim s'en charge, je les récupere par pop avec evolution
Oui (hormis pop :)
| pour filtrer tous les mails, le mieux est de le faire au niveau d'exim,
| comme ca, on filtre tout
Tout à fait.
| comment invoquer spamassassin depuis exim ? via procmail ?
Soit via procmail, soit directement dans exim. Je n'ai pas
installé spamassassin, mais il me semble avoir vu un truc
de ce genre sur leur site web.
| avec la config de procmail et celle d'exim (voir les mails précédents)
| c'est censé marcher, cependant spamassassin ne fais rien visiblement.
Ouais. Il doit y avoir un pb d'install.
| le probleme vient peut etre de la suite :
|
| > procmail: Program failure (70) of "spamassassin"
| > procmail: Rescue of unfiltered data succeeded
| >
| > Signifie que spamassassin a échoué, mais que les mails non filtrés
| > ont tout de même pu être sauvés. Le vrai problème se trouve là :
|
| ca c'est bon signe plutot, je perds pas trop de mails ;-)
:)) Si tu savais le nombre de mails que j'ai pu perdre à la suite
de diverses conneries (genre je détruit un utilisateur temporaire
avec mon nom sous OpenBSD sans avoir démonté /var/mail qui est en
NFS, du coup tous mes mails sont partis dans /dev/null ce jour-là
car OpenBSD supprime aussi les mails des utilisateurs).
| > Insecure dependency in mkdir while running setuid at
| > /usr/share/perl/5.6.1/File/Path.pm line 137.
| >
| > Quelle est cette dépendence non-sûre à propos de mkdir dans
| > /usr/share/perl/5.6.1/File/Path.pm à la ligne 137 ?
| > Pourquoi spamassassin est-il setuid (root je suppose) ?
|
| fetchmail tourne sous l'user fetchmail
Oui (encore que moi, je le fais tourner sous mon uid), mais
ce n'est pas fetchmail qui pose pb, c'est spamassassin.
| le seul programme de la chaine qui a des bits setuid c'est procmail :
|
| serveur:~# ls -l /usr/bin/procmail
| -rwsr-sr-x 1 root mail 65532 avr 16 19:26
| /usr/bin/procmail
C'est normal : procmail doit être capable de délivrer les messages
dans /var/mail
| cependant fetchmail n'appartient pas au groupe mail, et fetchmail ne
| tourne pas en root, donc je vois pas pourquoi il me parle de setuid ...
ls -l `which spamassassin`
| voila ce que contient /usr/share/perl/5.6.1/File/Path.pm aux environs de
| la ligne 137 : (j'ai noté la ligne 137)
...
| unless (mkdir($path,$mode)) { # <--- LIGNE 137
...
| ca peut aider ?
Bof. ÀMHA, le pb vient surtout du bit suid de spamassassin.
Qu'est-ce que ça donne sans ça ?
| merci
Avec plaisir.
Thomas
--
BOFH excuse #89:
Electromagnetic energy loss
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
