Journal Sortie de Exim 4.50

Posté par  .
Étiquettes : aucune
0
28
fév.
2005
Exim, le MTA de l'université de Cambridge, sort dans une nouvelle version corrigeant les quelques bugs de sécurité découverts en ce mois de janvier.

Pour rappel, Exim est un des MTA les plus connus avec Postfix et qmail, et offre de nombreuses fonctionnalités souvent (injustement ?) méconnues. En vrac:

  • filtrage du contenu du mail pendant la session SMTP avec un système d'acl (qui peut être étendu par le patch exiscan-acl): on rejette le mail au lieu de le bouncer par la suite.

  • système de routage des mails très flexible

  • intégration très aisée d'antispam ou antivirus sans recours à un outil externe comme amavis

  • très bonne intégration des recherches de sources de données (LDAP, SQL, etc.), bien utile pour la gestion de domaines virtuels

  • très robuste (utilisé par sourceforge.net notamment)


Le changelog: http://www.exim.org/ftp/ChangeLogs/ChangeLog-4.50(...)
  • # vhost

    Posté par  . Évalué à 2.

    Je ne connais rien a exim, et tant qu'a faire, si ya un journal qui en parle, j'en profite pour poser une mini question :)
    Exim supporte les virtual host (enfin supporte plusieurs domaines quoi) en natif sans utiliser d'odieux hacks a la qmail ou pas ?
    • [^] # Re: vhost

      Posté par  . Évalué à 6.

      Biensur, sans probleme,

      Il y a meme des outils pour ca:
      http://silverwraith.com/vexim/(...)

      Et meme sans ces outils, ca va assez vite de definir tes trucs, il y a plein de howtos partout
      http://www.google.de/search?hl=de&q=exim+howto&btnG=Suche&a(...)
      • [^] # Re: vhost

        Posté par  . Évalué à 4.

        grumpf, je suis un qmail-addict, mais ca mdonne envie de tester, parce que la gestion des vhosts est a peu pres trop pourrie avec qmail, c'est un gros bazar facilement gerable, mais bon, ca reste un espece de hack.
        • [^] # Re: vhost

          Posté par  . Évalué à 2.

          Honnêtement, ça se fait de façon naturelle, élégante, intuitive dans Exim. Que tu gères un ou plusieurs domaines, qu'ils soient stockés dans un fichier texte ou dans une base de données (SQL, LDAP, etc), la différence au niveau du fichier de config est absolument minime.
          • [^] # Re: vhost

            Posté par  . Évalué à 1.

            Cela vient en grande partie du fait que toute la gestion des recherches correspond en fait au même code dans Exim, que ca soit du LDAP, du SQL ou un fichier texte. Après il n'y a que les fonctions de bas niveau d'accès aux données qui changent. Pour Postfix, ce sont dans mes souvenirs des options de configuration bien différentes.
    • [^] # Re: vhost

      Posté par  . Évalué à 2.

      Ca se fait en natif et de façon super simple car tu peux utiliser le résultat d'une recherche ldap/sql/db pour décider du routage du mail, ou l'endroit du disque ou il doit être stocké.
      Exim est utilisé par des hébergeurs comme Lost-Oasis pour faire la gestion des mails des différents domaines qu'ils hébergent.
      • [^] # Re: vhost

        Posté par  . Évalué à 5.

        Le meilleur à propos de cette kill^Wnormal feature de requete vers à peu près ce que tu veux (ldap,sql,db,script etc...) c'est que tu peux en mettre en cascade.
        Genre cherche dans ce "ptit fichier plain text indexé qui va vite", si tu trouve pas, va chercher dans le "ldap qui va un peu moins vite".
        Quelle utilité ?
        Le ldap est la source primaire de données ou les modifs sont faites en temps réel, un cron par exemple dump son contenu dans un "ptit fichier plain text indexé qui va vite" à intervalles régulières et soigneusement choisies. Résultat Exim n'interroge le "ldap qui va un peu moins vite et qui peut servir à d'autres applis aussi" que pour les nouveaux comptes.

        Toussa pour dire qu'Exim c'est la flexibilité incarnée (et ça, ça fait mal à l'orteil).
  • # J'ose espérer que tu rigoles

    Posté par  . Évalué à 2.

    Exim est un des MTA les plus connus avec Postfix et qmail
    Non mais t'as un ordre de grandeur un peu... exagéré. Et sendmail dans tout ça ne serait pas un peu en tête du lot ?

    Pour info, exim est connu parce qu'il est par défaut sur debian. C'est à mon avis la véritable raison de sa célébrité. Après, ses qualités ont peut-être fait qu'il reste connu, mais pas plus.
    qmail est connu parce qu'il n'est pas libre selon les termes de la FSF, et qu'il a voulu renouveller le genre à sa manière.
    postfix parce qu'il a voulu renouveller le genre, et y est arrivé. Il est connu pour être plus simple à configurer que sendmail.

    Et sendmail, c'est le serveur historique.

    ----

    Pour la suite de fonctionnalités cités comme "killer features", je dirai que :
    * amavis n'est pas obligatoire pour certains autres MTA. Et je dirai qu'il y a certains avantages à l'utiliser d'ailleurs... Voir par exemple :
    http://www.gentoo.org/doc/en/mailfilter-guide.xml(...)
    Qui présente amavis d'une manière assez objective.
    * pour l'utilisation de SQL et LDAP, tous le font plus ou moins. Maintenant, c'est plus ou moins facile selon les cas. Le cas sendmail est une horreur à traiter si on veut faire les choses bien. Postfix est insuffisamment documenté sur ce point, et quand il y a une documentation, elle est soit incomplète, soit elle ne fonctionne pas. Pour qmail, je ne sais pas.
    * pour la robustesse, il a ses qualités, effectivement. Mais ce n'est pas une killer-feature, je dirai plutôt que c'est une raison qui fait qu'il est un bon MTA parmi les autres.

    Loin de moi l'envie de vouloir "casser", mais pour choisir un MTA, on ne se base pas toujours sur ce genre de critères. Par exemple, j'ai eu comme critère, une fois : installer un MTA qui puisse être interchangeable avec sendmail au niveau des commandes de base. Bah, je ne sais pas exim, mais postfix le permet (jusqu'à un certain point, tout de même).
    • [^] # Re: J'ose espérer que tu rigoles

      Posté par  . Évalué à 3.

      Réponse point à point:
      Sendmail fait (à mon goût) un peu partie de l'histoire: peu performant comparativement à ce qui se fait actuellement, sécurité qui laisse à désirer et configuration imbitable. Quand je parle de connu, il faut y voir un sous-entendu "intéressant à utiliser actuellement", et désolé de te décevoir, mais sendmail ne fait pas partie de cette liste.

      Dire que Exim est connu parce que c'est le MTA de debian, c'est un peu réducteur... Il semblerait que l'utilisation de ce MTA en Angleterre ne soit pas nécessairement liée à Debian. N'étant pas moi-même utilisateur de debian, je me demande alors bien comment j'en ai entendu parler...

      Amavis n'est pas forcément obligatoire, mais l'est par exemple pour postfix dès que l'on veut faire quelque chose d'un peu évolué... En ce qui concerne les fonctionnalités d'amavis, elles sont toutes utilisables nativement dans exim...
      De plus, pour avoir eu à réparer assez ponctuellement des serveurs mails totalement freezés, parce que amavis partait en vrille à 100% du proc pour une raison inconnue, si je peux me passer d'amavis, c'est aussi bien.

      Pour SQL et LDAP, l'intérêt est surtout dans la fléxibilité que l'on peut avoir avec ces recherches. La question n'est pas ici une question de facilité (c'est d'ailleurs par expérience plus "simple" de le faire avec postfix), mais de puissance. Info à part, qmail gère aussi très bien LDAP.

      Quant à la compatibilité sendmail au niveau ligne de commande, c'est assez anecdotique pour moi, et c'est certainement pas çà qui guiderait le choix d'un MTA :)
      Dans tous les cas, Exim peut émuler le fonctionnement de sendmail, comme le fait postfix.
      • [^] # Re: J'ose espérer que tu rigoles

        Posté par  . Évalué à 2.


        Sendmail fait (à mon goût) un peu partie de l'histoire: peu performant comparativement à ce qui se fait actuellement, sécurité qui laisse à désirer et configuration imbitable.

        Non, tout ça c'est fausse rumeurs et compagnies. sendmail est peut-être en dessous des autres niveau performances (c'est pour ca qu'il y a sendmail2 qui est en cours d'élaboration).
        Pour la partie sécurité, je demande à voir le "laisser à désirer".
        Enfin, la configuration imbittable, évidemment, si tu t'arrêtes à lire le fichier .m4 généré, je comprend que tu ais peur. Mais il y a un fabuleux main.cf clairement lisible, et à la portée de tout le monde, dans lequel on peut configurer tout le m4. Le seul point négatif c'est que la configuration de base est "trop simple", et que passer de cette configuration à une configuration plus élaborée avec ldap/mysql etc. en appoint, bah ça nécessite de lui ajouter des lignes qui ne sont pas dans le fichier de configuration, et il faut plus ou moins les inventer.
        Mais un fichier de configuration élaboré, même si complet/complexe, reste tout à fait lisible. C'est de le construire aux petits oignons qui est moins trivial si on n'a pas la documentation adéquate.


        Quand je parle de connu, il faut y voir un sous-entendu "intéressant à utiliser actuellement", et désolé de te décevoir, mais sendmail ne fait pas partie de cette liste.
        Si. Notamment parce qu'il possède un historique intéressant, et que comme tu dis, il "appartient au passé", un nombre important d'applications l'utilisent de manière avancée. Pour en avoir vu lors de mon stage de l'été dernier, je peux te dire que créer un programme qui se serve de sendmail n'est pas difficile, c'est même plutôt assez simple. Le programme en question était un programme d'appoint qui générait des statistiques. Il possède des avantages qui font que le remplacer sur un serveur n'est pas chose aisée, et comme il remplit très bien son rôle, il n'y a pas à le changer.

        sendmail n'est pas seulement là parce que "c'était comme ça avant, on change pas", mais parce qu'il a aussi des qualités. Il faut arrêter de cracher dessus.
        Entre autres, et quoi qu'on en dise, il a un avantage certain par rapport aux autres : il est supporté par une entreprise, qui fournit des services. On sait à qui s'adresser quand on a un problème. Tu peux payer pour avoir un support adapté.

        Dire que Exim est connu parce que c'est le MTA de debian, c'est un peu réducteur...
        C'était voulu aussi, pour créer un effet "phrase choc". Et pourtant, c'est comme ça que j'ai connu exim : à l'installation d'une debian j'ai vu qu'il installait exim par défaut.
        Il est aussi connu pour être le MTA le plus utilisé par les spammeurs, grâce à sa facilité de configuration d'ailleurs. Mais ça n'a rien à voir avec des quelconques défauts de conceptions/autres de exim.


        Il semblerait que l'utilisation de ce MTA en Angleterre ne soit pas nécessairement liée à Debian. N'étant pas moi-même utilisateur de debian, je me demande alors bien comment j'en ai entendu parler...
        N'ayant pas HP-UX chez moi je me demande comment j'en ai entendu parler. Bouche à oreille, etc. Chacun sa petite histoire, moi je l'ai découvert à l'installation d'une debian, d'autres, en cherchant un MTA, d'autres avec la chance.
        Et pourtant, si exim est largement implanté sur beaucoup de machines, je pense que Debian y est pour quelque chose.

        Amavis n'est pas forcément obligatoire, mais l'est par exemple pour postfix dès que l'on veut faire quelque chose d'un peu évolué... En ce qui concerne les fonctionnalités d'amavis, elles sont toutes utilisables nativement dans exim...
        Pourquoi vouloir s'affranchir d'une application tierce ? Si amavis évolue, est-ce que exim évoluera avec ? Difficile à dire. D'où à mon avis un avantage à utiliser amavis de manière séparée et ne pas compter seulement sur les capacités de exim.
        Mais bon ça c'est une opinion toute personnelle.

        Pour SQL et LDAP, l'intérêt est surtout dans la fléxibilité que l'on peut avoir avec ces recherches.
        Tout à fait. De plus, ça permet de s'affranchir du schéma UNIX des comptes.
        Un compte mail n'a pas besoin de tout ce qui est rendu disponible avec un compte UNIX. Il a besoin d'un répertoire mail, un login et un mot de passe. LDAP permet de simplifier le schéma et de ne pas toucher à /etc/passwd. En plus, il allège les accès à ce fichier.
        SQL pour les mails je n'y ai pas touché, donc je m'abstiendrais de commenter :)

        La question n'est pas ici une question de facilité (c'est d'ailleurs par expérience plus "simple" de le faire avec postfix), mais de puissance. Info à part, qmail gère aussi très bien LDAP.
        yep. La plupart des MTA gèrent le LDAP, et ils y ont intérêt, justement parce que le LDAP est très utilisé pour la gestion des comptes. Et un MTA qui ne permet pas la gestion de comptes mails via LDAP serait assez vite mis à l'écart pour ce genre de configurations.

        Quant à la compatibilité sendmail au niveau ligne de commande, c'est assez anecdotique pour moi, et c'est certainement pas çà qui guiderait le choix d'un MTA :)
        C'est un élément parmi d'autres. A considérer si tu as déjà un MTA sous sendmail et que tu veux le mettre à jour, et éventuellement changer le MTA. Parfois tu as justement (cf plus haut) plusieurs applications s'appuyant sur sendmail de façon assez prononcée (avec par exemple les fameuses options passées à sendmail, qui sont, sans documentation, effectivement imbittables). Changer le MTA, ok. Devoir reprogrammer tout l'environnement qui est autour te fait parfois oublier la première idée.
        C'est ce qui s'est passé pour moi, et j'ai dû rester sur sendmail dans le dernier cas de configuration. Loin de moi l'idée de dire que cette obligation est valable dans tous les cas. Mais, ça arrive.

        Dans tous les cas, Exim peut émuler le fonctionnement de sendmail, comme le fait postfix.

        sendmail fait partie de l'histoire, mais on a toujours un /usr/bin/sendmail, sous postfix, exim, etc. Hasard ?
        Pour moi, ça prouve une chose : sendmail restera un MTA connu pour longtemps. Il n'y a pas lieu de "l'oublier".

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.