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]