Re: spamassassin, exim et fetchmail

[Grégoire Cachet <gregoire.cachet@wanadoo.fr>]

Le sam 15/06/2002 à 11:34, Thomas Nemeth a écrit :
> Le 15.06.02, teardrop@free.fr a tapoté :
> 
> | On Sat, Jun 15, 2002 at 10:55:38AM +0200, Grégoire Cachet wrote:
> | >
> | > > Oui, dans ton .fetchmailrc, il faut ajouter après les poll
> | > > mda "/usr/bin/procmail -Y -d %T"
> | > > (en vérifiant le chemin vers procmail bien sur)
> | >
> | > 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 ?

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

je les récupere sur la machine perso par pop avec evolution

il y a un autre circuit

les mails arrivent directement par smtp dans exim
exim s'en charge, je les récupere par pop avec evolution

pour filtrer tous les mails, le mieux est de le faire au niveau d'exim,
comme ca, on filtre tout

comment invoquer spamassassin depuis exim ? via procmail ?

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.

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 ;-)

> 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

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

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 ...

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)

sub mkpath {
    my($paths, $verbose, $mode) = @_;
    # $paths   -- either a path string or ref to list of paths
    # $verbose -- optional print "mkdir $path" for each directory
created
   # $mode    -- optional permissions, defaults to 0777
    local($")=$Is_MacOS ? ":" : "/";
    $mode = 0777 unless defined($mode);
    $paths = [$paths] unless ref $paths;
    my(@created,$path);
    foreach $path (@$paths) {
        $path .= '/' if $^O eq 'os2' and $path =~ /^\w:\z/s; # feature
of CRT
        # Logic wants Unix paths, so go with the flow.
        if ($Is_VMS) {
            next if $path eq '/';
            $path = VMS::Filespec::unixify($path);
            if ($path =~ m:^(/[^/]+)/?\z:) {
                $path = $1.'/000000';
            }
        }
        next if -d $path;
        my $parent = File::Basename::dirname($path);
        unless (-d $parent or $path eq $parent) {
            push(@created,mkpath($parent, $verbose, $mode));
        }
        print "mkdir $path\n" if $verbose;
        unless (mkdir($path,$mode)) { # <--- LIGNE 137
            my $e = $!;
            # allow for another process to have created it meanwhile
            croak "mkdir $path: $e" unless -d $path;
        }
        push(@created, $path);
    }
    @created;
}


ca peut aider ?

merci

grégoire

-- 
Les femmes ressemblent aux girouettes, 
elles se fixent quand elles se rouillent.
Voltaire


--
To UNSUBSCRIBE, email to debian-user-french-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org