Spamassassin : Ne pas traiter les mails locaux - Logiciels - Linux et OS Alternatifs
Marsh Posté le 28-10-2008 à 18:27:08
J'utilise ça:
/etc/postfix/main.cf
|
/etc/postfix/sender_access_catchall
|
Et pas de content_filter définit dans postfix évidemment.
Du coup si ça match dans permit_mynetworks ou saslauthenticated, les mails ne sont pas filtrés
Marsh Posté le 28-10-2008 à 19:51:33
c'est une solution
ou tu peux utiliser directement amavisd pour le faire, ce qui te permettra de finement controler le filtrage (SA, antivirus, fichiers bannis....) et donc par ex de toujours filtrer les virus sur les mails sortants mais pas les spams ou les fichiers bannis.
ca se fait directment dans le fichier de conf d'amavisd avec des policy_bank.
le reseau interne est matché par défaut par une policy MYNETS.
tu peux aussi ajouter un port supplementaire sur postfix, dédié à l'envoi de tes clients (aveec SASL et TLS), dans lequel tu dirigeras le flux vers une autre policy_bank d'amavis, qui ecoutera sur un autre port que le 10024
bref pas mal de possibilité pour faire ce que tu désires
Marsh Posté le 28-10-2008 à 20:02:39
exact
Marsh Posté le 28-10-2008 à 20:39:36
Je pense que c'est vraiment ce qu'il y'a de plus simple à mettre en place. Par contre toniotonio, vu que tu as l'air de toucher sur amavis j'ai quelques questions:
1. Comment crée-t-on un contexte particulier dans amavis?
En gros j'ai un fetchmail qui renvoie des mails dans un postfix sur un port particulier. Du coup je pourrais très bien imaginer que cette instance de postfix attaque amavis d'une façon particulière afin de différencier le filtrage du vrai MTA et du fetchmail.
L'idée ça serait de pouvoir avoir du D_BOUNCE pour le MTA et D_DISCARD pour le fetchmail.
2. Peut-on modifier la destination d'un message lorsque son score dépasse en certain seuil ? Actuellement j'ai un D_PASS sur le spam, qui se retrouve filtré par sieve. Cependant je ne vois pas l'intérêt de delivrer un spam qui a scorer à +15. J'aimerais donc avoir D_PASS pour les spam > 6.31, overrider par un D_BOUNCE si le score > 15.
Merci d'avance
Marsh Posté le 28-10-2008 à 21:08:39
Merci pour les deux solutions.
J'ai choisi l'intervention dans le fichier de conf d'amavis, (policy_bank et MYNETS).
Je souhaitais ne désactiver que le passage dans spamassassin et laisser tourner clamav pour les mails sortant.
C'est dingue comme amavis est paramétrable.
M300A je garde ta soluce sous le coude, il est effectivement appréciable, selon les cas, de pouvoir de décharger un peu amavis.
Je suis aussi intéressé par tes questions M300A.
Marsh Posté le 29-10-2008 à 01:52:04
1. tu veux faire cette distinction sur quoi ? spam ? virus ?
dans tous les cas je te deconseille de faire du bounce sur les spams, quelque soit le contexte (a part en interne pour de l'envoi a la limite)
2. il faut dans ce cas que tu utilises les fonctionnalités de base d'amavisd, c'est a dire la mise en quarantaine.
tu as le choix entre mettre en quarantaine dans un dossier, vers une boite mail, dans une base sql..
je te conseille la base sql, car tu pourras consulter aisement les messsages et meme les reemettre vers leur destinataires en cas de FP. Encore mieux tu pourras laisser les users faire ca eux meme au travers d'une interface web.
en gros amavisd fonctionnemera comme maintenant pour les mails entre 6.31 et 15, mais au dessus de 15 les mails seront mis en quarantaine (kill_level)
avec une gestion sql complete tu pourras meme personaliser ce comportement par user ou par domaine.
vois ce que tu veux faire, je te posterai un exemple
Marsh Posté le 29-10-2008 à 15:51:36
Je ne sais si je dois créer un nouveau post mais j'ai une petite question concernant les instances multiples d'amavis et postfix.
Je récupère des mails via fetchmail et je souhaiterais qu'ils passent dans spamassassin et clamav.
J'ai donc fait en sorte que postfix et amavis écoutent sur un deuxième port, je peux ainsi renvoyer le courrier récupéré via fetchmail vers ce nouveau canal afin qu'il puisse être traité spécifiquement.
Tout fonctionne correctement, dans les logs on peut voir que le courrier transite bien vers la nouvelle instance de postfix.
Cependant, j'ai un problème dans amavis, la clause MYNETS vient mettre le bazar.
Les mails fetchmail étant récupérés en local la clause MYNETS est activée et du coup le scan spamassassin se voit désactivé...
Voici le paramétrage d'amavis :
Code :
|
Marsh Posté le 29-10-2008 à 15:53:08
configure fetchmail pour envoyer les messages vers l'ip publique de ton serveur et non 127.0.0.1
cela devrait suffire
mais c'est pas terrible comme solution
le mieux c'est comme je disais plus haut de creer une policy specifique
Marsh Posté le 29-10-2008 à 15:58:43
En fait, fetchmail envoie le courrier sur 127.0.0.1/10026, vers l'instance de postfix que j'ai créé pour traiter les mails de fetchmail.
Concernant la policy spécifique ça ne correspond pas à ce que j'ai fait dans amavis ?
Marsh Posté le 29-10-2008 à 17:10:44
ta policy_bank existe mais elle ne stipule rien
comme les policy_bank s'ajoutent lors du traitement, c'est MYNET qui va imposer les parametres qu'elle contient
et comme ton fetchmaiul se connecte en 127.00.0.0 il matche la policy MYNET aussi
donc en l'etat tu bypasses le traitement antispam
je suis plus sur de l'ordre mais je crois que mynets n'est pas prioritaire dans le cas ou le meme parametre serait stipulé , a tester
dans tous les cas, tu devraias restaurer MYNETS comme dans le fuchier par defaut (car la il est trop limité) et indiqué dans ta policy que tu as crée bypass_spam_checks_maps => [1],
Marsh Posté le 29-10-2008 à 17:29:31
MYNETS n'était pas présent dans le fichier fraichement installé.
Je l'ai donc rajouté.
Qu'entends-tu par "Car là il est trop limité", tu veux dire que certains paramètres utiles sont manquants ?
Je dois reconnaître que je suis un peu paumé là, si je rajoute bypass_spam_checks_maps => [1] dans la policy que j'ai créé ($policy_bank{'EXT-FM'}) les mails ne vont pas être analysés par SpamAssassin et c'est justement le contraire que je souhaite.
Marsh Posté le 29-10-2008 à 17:43:18
c'est une version debian j'imagine ?
dans les sources tu as le fichier d'origine avec les exemples fonctionnels
mais il ne te manque rien de vital ici
je te conseille de dire a fetchmail d'envoyer le flux vers l'ip publique du serveur
comme ca amavisd ne declenchera plus MYNET
Marsh Posté le 29-10-2008 à 17:56:44
Oui, il s'agit bien d'une version Debian.
J'irai jeter un coup d'oeil dans les exemples.
Merci beaucoup pour ton aide.
Je préfère éviter de renvoyer le flux vers l'IP publique, ce problème n'est pas urgent et je souhaite plutôt persévérer et me perfectionner dans le paramétrage d'amavis afin de maitriser ce genre de situation.
Marsh Posté le 29-10-2008 à 18:14:41
tu auras du mal a faire autrement
( fetchmail c'est le mal !)
cela ne presente aucun risque d'envoyer vers l'ip du serveur (quand je dis publique je veux dire l'ip autre que 127.0.0.1, cela peut etre 192.x.x.x )
Marsh Posté le 29-10-2008 à 19:17:47
Y'a une alternative à fetchmail ?
Effectivement, j'avais mal interprété le "publique" ^^
Marsh Posté le 30-10-2008 à 09:15:12
pas vraiment etant donné que le pb est le fait que l'on se retrouve avec des mails qui proviennent tous du meme client smtp
Marsh Posté le 07-10-2009 à 18:06:59
Je remonte le post car je cherche aussi a by-passer spamassassin pour le courrier envoyé depuis le réseau local.
La petite différence est que j'utilise uniquement Postfix + Spamassassin ..
dans le master.cf de postfix il y a :
|
Est-ce que les lignes suivantes dans local.cf de spamassassin pourraient suffire ?
|
Marsh Posté le 27-10-2008 à 12:12:01
Salut,
Mon serveur de messagerie tourne sous Debian Lenny : Postfix, SpamAssassin, ClamAV et Amavis.
Tout tourne correctement, les mails passent bien à travers ClamAV et SpamAssassin.
Le problème c'est que même les mails locaux passent à travers Amavis et je souhaiterais que ce ne soit pas le cas, au moins pour SpamAssassin (Certains de nos mails en interne sont considérés comme des spams).
J'ai bien tenté de modifier le local.cf et d'y rajouter les paramètres trusted_networks et internal_networks mais pas de changement, je dois surement pas modifier ce qu'il faut.
Voici mes fichiers de conf :
postconf -n
master.cf
20-debian_defaults
local.cf