Bonjour, j'aurais aimé savoir si il était possible de donner une directive quelque part pour que  amavis et spamassassin n'analysent pas les mails provenant d'adresse en @mondomaine.com
 
Merci d'avance

oui mais c'est un peu compliqué.  
mais surtout c'est totalement a deconseiller car forger son mailfrom est a la porté de n'importe qui. (c'est d'ailleurs pour cela que tu ne trouve pas cete option dans la conf d'amavisd)
 
mieux vaut reflechir a des connections differentes avec authentification sur le serveur par lesquelles le filtrage serait limité voire desactivé.
 

Oui je sais bien que c'est très facile de se faire passer pour n'importe qui.
 
Mais on m'impose ça.
Donc si tu pouvait un peu me guider ça serait très sympa de ta part

mais quels sont les imperatifs ?  
qu'est ce qui justifie de faire ceci ?
 
bon apres ca les regarde mais bon...
 
donc on est bien d'accord qu'il s'agit de ton domaine, celui qui est géré par le serveur de mail en question c'est ca ?
 
suivant la config il y a plus simple et secure pour faire ceci
 
decris un peu la configuration:
postconf -n
master.Cf
 
 

En fait ils veulent pas savoir le pourquoi du comment  
Un mail en interne est passer en spam et ça fait toute une histoire.
 
Enfin bref...
 
postconf -n  
 

 
Master.cf
 

l'authentification des clients ne se fait que par 83.144.147.145/28 ?
 
si tu avais une Auth SASL tu pourrais faire un truc qui tienne bien la route.
 
tu pourrais aussi faire une instance smtp sur un autre port innacessible depuis l'exterieur du lan (le 587 par ex) et desactiver le filtrage sur celui ci.  
 
mais cela demanderait de reparametrer les clients sur le nouveau port.
 
 
 
sinon la solution quick and dirty sur le mailfrom:
 
dans le main.cf:
 
tu enleves l'appel a amavisd (content_filter = smtp-amavis:[127.0.0.1]:10024) puis tu ajoutes:
 

 
/etc/postfix/amavis-bypass

 
 
/etc/amavisd.conf:
 

 
 
mais c'est a mon avis un veritable sabotage de la securité.

si c'est juste des mails internes qui sont classés a tort comme spam, il vaut mieux revoir ta conf car il existe de multiples parametres dans amavsid/SA pour eviter cela.
 
encore une fois utiliser le truc du dessus c'est un scandale a mon avis.
 
 

Oui c'est clair que c'est du sabotage!
Surtout que c'est un peu mon truc la sécurité.
 
Le SASL ça fait 6 mois que j'en parle
 
Merci beaucoup en tout cas

c'est pour ca que cela meriterait plutot de revoir la conf d'amavisd/sa .  
par exemple le trusted et internal networks sont til bien parametrés ?
 
c'eest ce genre de chose qui fait baisser le score sur les mails interne, d'une maniere "normale" et securisée.

n'aurait il pas été plus simple dans un cas comme celui-ci de mettre dans spamassassin le domaine de la société en whitelist (liste blanche)?

comme on peut forger un mailfrom (l'adresse expeditrice) et que c'est d'ailleurs tres souvent employés par les spammeurs, cela reviendrait à rendre inutile le systeme de filtrage

c'est vrai! bon pour ma part c'est ce que j'ai fait sur mon serveur et je n'ai eu en plusieurs années que 2 ou 3 spam qui se sont fait passer comme provenant de mon domaine!
Je sais pas si en entreprise ça arrive plus souvent. j'imagine que oui!
Mais comme on demande à tchouvince de le faire je me suis dis que ce serait plus simple et rapide que de modifier amavisd.conf

cela dit cela revient au meme que le truc que j'ai ecrit plus haut, et que je deconseille fortement, meme si a la limite celui d'en haut permet de cibler le sender qui aura droit a ce whitelistage.
 
il existe d'autres maniere de faire cela correctment dans amavisd, sans prendre de risques sur la securité.
 
l'ideal etant bien sur de coupler cela a une authentification SASL et une verification du mailfrom associé.

 
A ce propos je suis en train de refaire complètement ma config de mon serveur mail et j'ai justement utilisé l'authentification SASL
Donc quand j'envoie un mail j'ai une ligne dans mon header qui correspond à ça:

 
comment je devrais faire pour créer une règle dans spamassassin pour vérifier qu'un mail provenant de mon domaine provient d'une personne authentifiée? Et attribuer un score en fonction de cette vérification?
Parce que si un mail prétend provenir de mon domaine mais que l'emetteur est pas authentifié c'est que c'est nécessairement un spam et inversement! Enfin si j'ai bien compris le principe

 
En même temps un relais SMTP se doit de refuser un mail arrivant de *@mondomaine.com depuis l'exterieur.
(enfin si c'est possible avec l'architecture)

 
le moyen le plus simple, la plus fiable et qui permet en plus d'economiser des ressources, est de bypasser le filtrage pour les users authentifiés SASL
 
mais tu peux bien sur ajouter une regle dans SA pour juste baisser  le score en fonction du header.
j'en ai pas sous la main et j'avoue que les expressions regulieres c'est pas mon truc !
 
je prefere largement traiter cela en bypass par les policy bank

 
 
oui mais en pratique c'est rare.
car il existe des relais qui sont de veritables relais pour de multiples domaines, les uilisateurs etant validés par l'auth SASL. (cas de certain FAI, des hebergeurs, etc, etc)
maintenir une liste de domaines autorisés pour eux seraient un enfer

Oui suivant l'architecture, j'imagine que ça peut devenir compliqué.
Mais peut être qu'avec la sienne il peut le faire?
 
Par contre j'ai pas compris, tes mails internes sont passés à l'antispam également?

 
je connaissais pas cette méthode! je vais me documenter ça à l'air pas mal!
merci pour ces infos  

bon alors j'ai rajouté ça au master.cf de postfix

 
et ça dans amavisd.conf

 
ça ne lance plus d'analyse antispam sur les mails de mon domaine, le contrôle antivirus fonctionne tout de même et les mails provenant de domaines externes sont toujours analysé! Donc à priori c'est bon!
 
C'est bien de ça dont tu parlais toniotonio concernant les bypass via policy bank?

oui c'est exactement ca
 
juste 2 precisions:
 
sur les version recentes de postfix les noms de certains parametres ont changé meme si les anciens sont toujours valides (pour l'instant) mais il serait prudent de commencer des maintenant a utiliser ces nouvelles appellations:
 

 
 
 
de plus le port smtps est considéré desormais comme obsolete, il vaut mieux ne plus l'utiliser (c'est le port 587 submission qui le remplace officiellement)
 
 

merci beaucoup pour ces précisions!