Re: réglage amavis dans debian pour les banned mail
On Tue, 1 Nov 2011 18:46:57 +0100
Yann Cohen <yann@ianco.org> wrote:
> > > - est-il possible de notifier le destinataire qu'un mail qui lui
> > > était adressé est banni en plus de l'administrateur du mail ?
> >
> > Normalement c'est le contraire qui est fait: un bounce est renvoyé à
> > l'expéditeur; sans doute qu'avec un peu d'astuce et qq scripts ça
> > doit- être possible (mais ça n'a strictement aucun intérêt, à part
> > l'exercice de style).
>
> Je comprends le principe, mais dans mon cas l'expéditeur n'a pas su
> déchiffrer correctement le message de bounce et il s'est acharné à
> relancer le mail, avec toujours le même résultat (c'est étrange
> non ?)...
Mauvais utilisateur, ordinateur doit changer utilisateur: rm -rf utilisateur :)
> Dans mon cas, j'ai pu contourner parce que je suis aussi destinataire
> des mails de postmaster et que j'attendais ce mail...
Tant que la conf n'est pas stabilisé (en même après pour une entreprise),
le bon réflexe c'est de créer des dossiers IMAP (ou POP3, mais c'est moins
pratique) et d'y envoyer les e-mails, au lieu de les mettre en quarantaine,
par ex:
* JUNKMAIL (équiv. quarantaine)
* TO_BE_CHECK (e-mails "douteux" ayant le cul entre 2 chaises)
Si le besoin s'en fait sentir, on peut aussi scinder entre SPAMS & VIRII, etc.
> > > - comment faire pour que le mail banni puisse être diffusé tout de
> > > même ?
> >
> > Faire en sorte qu'il ne soit pas banni - parce qu'un e-mail banni,
> > il est banni, vraiment banni de chez banni, pas à moitié banni,
> > ni un quart banni, 100% banni, et on ne publie pas les bani;
> > seule exception: s'il est banni-wé, là il peut passer par le SGC.
>
> Il est banni, mais la relégation de ce bannissement est un répertoire
> au fin fond du /var/lib/amavis/... là où je l'ai trouvé d'ailleurs...
> Donc pas tant que cela...
>
> En fait, existe-t-il une appli qui permet le contrôle de ces
> bannissements et qui peut permettre de les distribuer tout de même. Je
> sais que des applis similaires existe pour le spam : elles interceptent
> les spam les stockent temporairement et signalent la "rétention" au
> destinataire qui peut choisir de le recevoir tout de même...
V. ci-dessus - il faut en fait désactiver complètement la quarantaine,
puis créer des règles de redirection en fonction des résultats des
scans; d'où l'intérêt d'utiliser procmail qui est bcp plus simple à
programmer.
CEPENDANT, la moindre erreur (surtout dans procmail) étant fatale, je te
conseille vivement de récupérer tes e-mails avec fetchmail (à moins que
ça ne soit un svr sans relais, en prise directe sur le web, auquel cas il
faut travailler sur un svr-bis) et d'ajouter l'option 'keep' (n'efface
pas les e-mails de la source lors de la récup) jusqu'à ce que tout soit
aux p'tits oignons.
> > > - existe-t-il une méthode pour effectuer un apprentissage et mettre
> > > une adresse mail dans une white-list pour ce type de détection ?
> >
> > Non, c'est du "dur" - enlever .zip, .rar, etc n'est pas un PB à
> > partir du moment où le paramétrage est correct et qu'ils sont scannés
> > en profondeur (si possible en entrée ET en sortie) - par contre il
> > vaut mieux refuser les .com, .exe, .pif, etc.
> >
> Dans mon cas il s'agit d'une suppression de pièce jointe qui était un
> fichier zip qui contenait un exe pour une mise à jour de soft...
> Donc j'aurais préféré qu'il ne vire pas le zip et fasse son
> inspection en profondeur pour les virus...
Là, je ne sais pas (tjrs utilisé amaclou uniquement avec Linux, donc tout
viré le relatif à w$ dans /dev/null); donc tu dois tester d'abord en
désactivant la quarantaine des .zip, et plus si pas d'affinités.
> Alors je vais ôter l'élimination des zip, rar etc. je vais donc compter
> sur l'antivirus pour la détection des PB.
Hèèèèè, pas tout qd même!
Procède par ordre, c'est la façon Debian: on interdit tout, puis on ouvre
au fur et à mesure des test&|besoins.
--
#videolan
<colin> p_bit_stream->buffer |=((u32) *(p_bit_stream->byte_stream.p_byte++))
<colin> << (24 - p_bit_stream->i_available);
<colin> psychopathes
Reply to: