[RESOLU] mailfront-mailrules

par **agecanonix** » 23 Fév 2006 12:43

Bonjour,

Sur les conseils de Gaston, j'ai téléchargé cette contrib et l'ai mise en place pour tenter de résoudre mes problèmes d'afflux de mails à des adresses inconnues.

Avant de créer mes règles, je me pose deux questions :
1- Si j'ai bien compris, la contrib ne fait qu'apporter une interface graphique à mailfront qui est installé d'office, afin de pouvoir facilement y ajouter des règles. Or, les règles par défaut sont exactement celles que je voudrais établir. J'aimerais que quelqu'un qui n'a pas encore installé cette config me dise s'il a un fichier /var/qmail/control/mailrules.default contenant des règles en vue d'accepter les mails à destination de tous les utilisateurs de la SME et pour rejeter toutes les autres adresses au domaine ?

1b - Question subsidiaire : Si ces règles existent sur toutes les SME, pourquoi la mienne "mouline" tant lorsque je reçois des mails à une adresse inconnue, apparemment en train de passer chaque mail mal adressé à l'antispam et à l'antivirus ? Pourquoi les règles d'élimination du courrier mal adressé n'interviennent-elles pas avant ?

2- Quelle peut être l'interraction avec fetchmail (shirms) ? Faut-il que je crée des règles pour accepter les adresses des bals localisées chez le FAI et récupérées par fetchmail, ou ce qui arrive est déjà ré-adressé par fetchmail aux adresses locales ?

par **jibe** » 23 Fév 2006 19:23

Salut,

Voici le contenu de /var/qmail/current/mailrules.default sur mon serveur perso :

Code: Tout sélectionner: d*:*!*: Sorry, we don't allow that here d*:*@*@*: Sorry, we don't allow that here d*:*%*: Sorry, percent hack not accepted here k*:postmaster@[192.168.65.17]

Je ne vois rien qui pourrait

accepter les mails à destination de tous les utilisateurs de la SME et pour rejeter toutes les autres adresses au domaine

J'ai sur mon serveur clamav+spamassassin+fetchmail, mais pas mailrules/mailfront. Donc, si tu as d'autres règles, elles pourraient bien être dûes à cette contrib...

Je ne peux guère t'en dire plus, ne connaissant pas mailrules/mailfront. Pour les éventuels problèmes possibles avec fetchmail, il faudrait poser la question à sibsib (Pascal, si tu passes par là...), mais je ne vois pas bien le problème : ne peux-tu pas établir tes rêgles en tenant compte de tes adresses externes ? Je ne vois pas ce que tu risques à le faire ?

Mais bon, en y réfléchissant, je vois mal comment fetchmail pourrait ré-injecter dans qmail des courriers adressés à tonadresseexterne@chezton.fai : la conversion en tonadresseinterne@tondomaine.local me semble devoir être faite avant... A voir...

par **agecanonix** » 24 Fév 2006 20:13

Bonjour,

Merci jibé !

J'ai vu ton post hier soir juste avant d'aller au lit. Comme il confirme bien que la contrib "mailrules" installe de nouvelles règles qui bloquent tout courrier non destiné à un utilisateur ou un alias existant, j'ai remis à jour mon IP chez dyndns pour relancer la récupération des mails. Et là, merveille : le serveur n'était pas planté ce matin ! Les boites s'étaient bien remplies, mais plus aucun mail avec un destinataire inconnu !

Dès que j'ai un petit moment, je mettrai en place la mise à jour automatique de l'IP chez dyndns, et je n'attends plus que la confirmation par sibsib de la compatibilité fetchmail/mailrules pour relancer fetchmail.

par **sibsib** » 24 Fév 2006 22:25

Salut à tous,

Suite au post de Agecanonix, j'ai installé mailfront mailrules hier, et ce produit es tout à fait sympathique.

En l'état, incompatible avec smeserver-mxbackup, mais sympathique tout de même !

@agecanonix: J'ai pas fait énormément de tests, mais çà a l'air compatible avec fetchmail. Et c'est assez logique :

Fetchmail se comporte comme un client de messagerie par rapport à la boite externe qu'il 'fetche' (et je rappelle que POP3 et IMAP4 se contrefichent de l'adresse de messagerie associée à la boite quand on fait la relève du courrier), et dépose ensuite le messag dans le serveur local en utilisant l'adresse locale

Donc, les en-têtes de messages ne sont pas perturbés et çà se passe à priori bien.

A+,
Pascal

par **agecanonix** » 27 Fév 2006 10:25

Bonjour,

sibsib a écrit:Suite au post de Agecanonix, j'ai installé mailfront mailrules hier, et ce produit es tout à fait sympathique.

Heureux de t'avoir donné l'occasion de le connaitre ! Je le découvre également, et ça m'a effectivement l'air intéressant. Et en tous cas, il a merveilleusement bien résolu mon problème : après un week-end avec des amis au cours duquel j'ai laissé le serveur se dém** tout seul, avec mise à jour automatique des IP chez dyndns et donc réception du courrier, je le retrouve ce matin en pleine forme, avec seulement les mails habituels déposés dans les boites et rien de mal adressé

sibsib a écrit:En l'état, incompatible avec smeserver-mxbackup, mais sympathique tout de même !

Tiens, curieux ! En tous cas, avec le mx backup par mailhop de chez dyndns, ça a l'air de bien fonctionner. Donc, d'après toi, à ne pas combiner avec ta contrib pour MX Backup entre deux SME ?

sibsib a écrit:@agecanonix: J'ai pas fait énormément de tests, mais çà a l'air compatible avec fetchmail. Et c'est assez logique :

Fetchmail se comporte comme un client de messagerie par rapport à la boite externe qu'il 'fetche' (et je rappelle que POP3 et IMAP4 se contrefichent de l'adresse de messagerie associée à la boite quand on fait la relève du courrier), et dépose ensuite le messag dans le serveur local en utilisant l'adresse locale

Donc, les en-têtes de messages ne sont pas perturbés et çà se passe à priori bien.

Pas encore essayé... Je procède lentement et par étapes, je me suis pour le moment contenté de remettre en route correctement la mise à jour automatique de l'IP et donc la mise en ligne du serveur SMTP. Puisque tu me rassures sur ce point, je vais maintenant procéder à la remise en service de fetchmail.

En tous cas, merci à tous ceux qui m'ont aidé dans cette affaire que je sentais vraiment très mal, mais qui se termine finalement très bien.

par **sibsib** » 27 Fév 2006 21:37

Salut,

agecanonix a écrit:
sibsib a écrit:En l'état, incompatible avec smeserver-mxbackup, mais sympathique tout de même !

Tiens, curieux ! En tous cas, avec le mx backup par mailhop de chez dyndns, ça a l'air de bien fonctionner. Donc, d'après toi, à ne pas combiner avec ta contrib pour MX Backup entre deux SME ?

Oui, c'est vrai, j'aurais pu détailler un peu :-(

En fait, après la lecture en diagonale des fichiers générés par mailrules, il configure le serveur de mail pour recevoir uniquement les e-mails à destination des adresses e-mail valides pour le serveur local.
C'est pour çà que tu as trouvé la liste de tes utilisateurs (plutôt de leurs e-mails) dans le fichier mailrules.default

Par contre, étant moi même mx-backup pour d'autres domaines, il faut évidemment que les mails à l'attention de ces domaines (tous les mails, y compris ceux qui seront finalement rejetés chez le vrai propriétaire de ces domaines) soient acceptés.
Il faudrait donc que j'améliore mx-backup pour qu'il auto-configure le fichier mailrules.default.
En attendant, il faut rentrer une règle supplémentaire dans mailrules pour chaque domaine 'MX-Backupé'

Idéalement, il faudrait prévoir un système de réplication de la liste générée sur le MX-Principal par mailrules afin de détruire 'à la naissance' les nombreux spams qui viennent nous pourrir les MX-Backup.

Mais çà, administrativement, quand le MX-Backup dépend d'autres équipes que le MX Principal...

A+,
Pascal

par **jibe** » 06 Mars 2006 22:14

Salut,

sibsib a écrit:J'ai pas fait énormément de tests, mais çà a l'air compatible avec fetchmail.

Ben, je crois tenir la preuve que non :wink:

Bon, c'est un cas un peu particulier. J'ai moi aussi installé cette contrib "tout à fait sympathique", dans l'espoir de me débarasser de quelques spammeurs. Et dans ma précipitation, j'ai oublié que je récupère un compte d'un autre domaine que celui de la SME. Autrement dit, j'iai une adresse, disons jibe@unautredomaine.com qui est renvoyée sur jibe@monfai.com et que je récupère dans jibe2@mondomaine.com. Et là, comment est-ce possible, je n'en sais rien, toujours est-il que les courriers spam adressés à jibe@unautredomaine.com arrivent bien dans la BAL de jibe2@mondomaine.com et ce, malgré le fait que les règles de mailfront soient censées les éliminer. Non seulement ils arrivent à destination, mais il semble que fetchmail les multiplie (ils arrivent une quarantaine de fois à l'heure de relevé de fetchmail <= est-ce cela qu'on appelle la mise en quarantaine ? :lol:

) et en même temps, fetchmail envoie à admin@mondomaine.com un message d'impossibilité de distribution (d'où, pour chaque spam, là encore 40 messages...)

Bon, je vais regarder ça de plus près : il doit y avoir une certaine logique dans l'histoire, pour le moment je me suis contenté de constater. Je voulais surtout prévenir de possibles problèmes. Maintenant, si le Grand Gourou de fetchmail a une idée, je suis bien sûr preneur :wink:

Je tiens au courant...

par **jibe** » 06 Mars 2006 22:49

Bon, ça a l'air en fait plus compliqué et plus bizarre...

En fait, les mails donnant lieu à un message MAILER-DAEMON de fetchmail sont bien ceux rejetés, je ne les retrouve pas dans les BALs

Donc tout va bien de ce côté, sauf que ce message de fetchmail m'emm*** : si j'élimine directement le spam, ce n'est pas pour me retrouver avec autant de messages de MAILER-DAEMON !

Par contre, ceux qui arrivent... arrivent je ne sais comment... Voici une partie des règles personnalisées de mailfront-mailrules :

Code: Tout sélectionner: Reject from *@terra-computer.fr to *@* Reject from *@welcomeoffice.com to *@* Reject from *@cps-diffusion.com to *@* Reject from *@bp06.net to *@*

les mails en provenance de terra-computer.fr et de bp06.net donnent lieu à 40 messages de MAILER-DAEMON à l'heure où fetchmail a relevé la BAL de mon FAI. Quant à ceux en provenance de welcomeoffice.com et de cps-diffusion.com, ils arrivent 40 fois à destination :shock:

La seule différence que je vois, c'est que ce sont ceux en .com qui passent, mais bon, ce n'est probablement qu'une coïncidence...

Et tous ceux destinés à jibe@unautredomaine.com et non filtrés arrivent aussi à 40 exemplaires ! Pour autant que je puisse en juger avec ma très courte expérience, tout ce qui est à destination des autres BAL semble traité correctement (tant pour les éliminations par mailfront que pour la réception)

Je continue mes investigations...

par **jibe** » 06 Mars 2006 23:27

En fait, les messages reçus par l'admin sont assez curieux : je ne l'avais pas remarqué à prime abord, mais d'après les entêtes :

Le mail est reçu par SME, passe par clamav et spamassassin, puis rejeté par fetchmail pour mauvaise adresse (peut-être à cause de la règle de mailfront ? L'adresse est pourtant bonne...)
fetchmail le renvoie à l'expéditeur ( j'ai paramétré pour qu'admin soit informé, pas pour un retour à l'expé...)
le MAILER-DAEMON local informe fetchmail que l'adresse de l'expé est invalide (pas surprenant pour du spam !)

Bon, je n'ai jamais regardé comment ça se passe en cas de mauvaise adresse du destinataire, le circuit est peut-être normal. Mais ce qui me surprend, c'est que certains mails soient rejetés pour mauvaise adresse et que d'autres soient acceptés, alors que les règles mailrules sont identiques (ou plutôt équivlentes) dans les deux cas... Et surtout, que dans un cas comme dans l'autre, le mail aurait dû être éliminé par mailfront dès le début, avant de passer par clamav et spamassassin...
A suivre...

par **sibsib** » 07 Mars 2006 23:17

hello,

oups....

Chuis pô inspiré, sur le coup.

Eventuellement, peux tu poster (ici, si çà me met pas des innocents en danger, ou en mail perso) des en-têtes complets de messages ?

Là, il commence à être tard dans ma tête, je relis tous tes posts demain, j'espère, et je vois si je trouve une logique la dedans ( Il y en a une, c'est sûr ! reste à la trouver...)

A+,
Pascal

par **jibe** » 09 Mars 2006 22:57

Salut,

Après un petit échange privé avec sibsib, je me replonge dans ce problème que j'avais un peu laissé de côté faute de temps. Et je m'aperçois que j'avais omis de remettre la récup normale des message avec suppression, après avoir demandé à fetchmail de les laisser sur le serveur pour un test (qui n'avait rien à voir avec ce problème).

En fait, il y a peu de messages dans la BAL chez mon FAI, mais aucun n'est marqué comme lu ! Ils sont donc relevés à chaque passage de fetchmail, ce qui explique probablement la multiplicité reçue. J'ai fait du ménage, et vais tenter de comprendre avec moins de messages (plus de 800 ce soir, plus 1600 notifications à l'admin :evil:

).

Suite au prochain numéro...

par **jibe** » 12 Mars 2006 23:08

Salut,

Depuis mon ménage de l'autre jour, tout est rentré dans l'ordre... Je ne m'explique ni pourquoi j'avais ces mails multiples et traités différemment selon leur provenance alors qu'ils étaient filtrés exactement de la même façon, ni pourquoi le phénomène s'est arrêté...

L'explication réside probablement dans les mails qui étaient dans la boite chez mon FAI, mais malheureusement je n'ai pensé ni à les sauvegarder quelque part, ni même à en établir une liste précise :oops:

Bon : tout ce que je peux dire est : soyez prudent lorsque vous combinez des contribs d'origines diverses. Comme m'a dit sibsib, la chaine de traitement de mes mails utilise 2 produits d'origine (mailfront et qmail) et 4 contribs (spamassassin, clamav, fetchmail et mailrules). Quelques interférences imprévues ne sont pas impossibles

par **jibe** » 28 Mars 2006 09:13

Salut,

J'ai eu de nouveau des mails qui se répètent. La plupart ne sont simplement pas marqués comme "lu" par fetchmail, et disparaissent si je les marque "lu" via webmail sur la BAL chez mon FAI. Mais d'autres continuent d'arriver, même après avoir été marqués manuellement "lu"...

Sur conseil de sibsib, j'ai passé le relevé des BAL en IMAP, et le problème a aussitôt disparu. Il semblerait donc qu'il soit préférable de paramétrer fetchmail pour relever en IMAP plutôt qu'en POP. Je pense qu'il n'y a aucune différence à l'utilisation, si ce n'est qu'on évite des problèmes bien curieux...

[RESOLU] mailfront-mailrules

[RESOLU] mailfront-mailrules

Qui est en ligne ?