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".
[^] # Re: J'ose espérer que tu rigoles
Posté par iznogoud . En réponse au journal Sortie de Exim 4.50. É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".