hat jemand die kommerzielle variante von sendmail? ist die auch so zu konfigurieren wie das opensourcesendmail so mit m4 macros und dem ganzen kram? wenn ja warum kauft das ueberhaupt jemand?
Oh Mann, wer sich heutzutage mit Mail auseinandersetzen möchte muß schon ein wenig Zei investieren. Da sind exim, postfix und qmail auch nicht viel leichter _sicher_ zu konfigurieren.
m4 ist heutzutage evtl. nicht mehr jedem bekannt aber da sind schon klare Strukturen hinter, für sendmail gibt es ausgereifte Bücher - auch in deutsch. Kauft euch mal das aktuelle Linux Magazin, da ist ein hervorragender sendmail Artikel drin. Ich mag sendmail und nutze es seit Jahren.
Die Geschmäcker sind verschieden. Aber gerade wenn man in das Thema Mailserver einsteigen möchte, weiß ich nicht ob sendmail da das beste ist. Wäre evtl. so, als ob man einem absoluten EDV-Neuling gleich latex beibringen möchte ;) Gruß
Ich habe ja bisher kaum Erfahrung mit groesseren Setups, aber ein mir bekannter Admin, der auf seine Sendmail-Kenntnisse sehr stolz war, musste sich aus verschiedenen Gruenden dann mal mit Postfix auseinandersetzen. Danach wollte er von Sendmail nix mehr wissen, - war ihm zu sehr "pain in the ass"...
Ist meine Erinnerung richtig, dass Postfix von vornherein auf Sicherheit hin designt wurde?
>wer sich heutzutage mit Mail auseinandersetzen möchte muß schon ein wenig Zei investieren. Da sind exim, postfix und qmail auch nicht viel leichter _sicher_ zu konfigurieren.
Also von dem was ich gesehen habe spart man da schon massiv Zeit. Es kommt eben drauf an, für was man einen Mailserver brauchen will, ob es darum geht, China zu vernetzen oder nur 100 Leute zu verkabeln. Würde für China Sendmail nehmen, bei allem anderen Postfix.
Habe das für die RHCE Prüfung noch lernen dürfen und habe das als sehr umständliche Technologie erlebt. Alles ist recht non-standard. Was ist standard? Man schaue mal die config-files momentanter, d.h. in diesem Jahrzehnt erstellter OSe an (OSS) oder der der letzen Dekade und man erschrickt bei Sendmail. Muss ich das auch noch lernen? ist das nicht etwas überflüssig und eine Reform wäre angebracht?
>m4 ist heutzutage evtl. nicht mehr jedem bekannt aber da sind schon klare Strukturen hinter, für sendmail gibt es ausgereifte Bücher - auch in deutsch. >Kauft euch mal das aktuelle Linux Magazin, da ist ein hervorragender sendmail Artikel drin. Ich mag sendmail und nutze es seit Jahren.
Ja, klar, es gibt über alles Bücher. Die Frage ist doch, ob es ein mehr als tausend Seiten Buch benötigt, nur um die Basics zu beschreiben. Verkomplifiziert da nicht etwas?
Also, ich habe auch schon fast eine 4 auf dem Rücken, man will an altem vertrauten festhalten, aber manchmal muss man einfach einen Punkt machen und was reformieren, was zu altmodisch und kompliziert wurde. Natürlich ist es leicht, wenn man es schon gelernt hat, das schon atmet und im Schlaf macht, aber was ist mit allen Neueinsteigern? Wer denkt, dass Sendmail zeitgemäss zu konfigurieren ist, der hat den Doktor darauf gemacht (und das kann und muss man auch, damit man es richtig benützen kann) und wie auch der Author des Artikels im Linux Magazin die Bodenhaftung verloren, d.h. hat absolut keinen Schimmer mehr, dass er da Quanten-Physik Formeln drischt, die auch bei intelligenten Linux admins einfach zu weit geht und nur Fragezeichen hinterlassen. All die Leute, ich inklusive, lassen dann Sendmail sausen und nehmen was anderes, was auch funkt. Das Prinzip Linux ist eben ein Unix mit den neuen frischen Ideen, treibern und Features und Anpassungen an heute die die alte Unix Garde nie als notwendig sah.
Für alle die das noch nicht verstanden haben: Sendmail verwendet eine Art Compiler um das config file das man schreibt in ein Sendmail lesbares format zu übersetzen. Nicht das die für Menschen bestimmte Seite des config files wirklich viel verständlicher wäre. Braucht es diesen Compilerlauf?
Unix und Linux sind Zeitlos in vieler Hinsicht, etwas das perfekt ist, das muss man nicht ändern. Einverstanden. Aber das wird häufig als faule Ausrede gegen nötige Optimierungen und Verbesserungen verwendet.
Wie Einstein sagte: Man soll Dinge simpel machen, sie aber nicht versimplifizieren. ich sage: man soll Dinge kompliziert machen, so weit wie nötig, aber nicht mehr.
Sendmail braucht eine Reform, dringend. Sonst wird es aussterben. Nicht weil es zu teuer ist oder was... ich z.B. (und bin nicht schlecht informiert im ganzen) wusste gar nicht dass Sendmail kommerziel organisiert ist, hatte immer eine gratis Version im Einsatz.
Die Funktionalität und Stabilität von Sendmail wird übrigens von mir nicht angezweifelt, die ist ohne Frage ohne Konkurrenz. Die Sache ist nur, wie man es konfiguriert, ohne dass man zwischen dem und einer Famile haben entscheiden muss.
>m4 ist heutzutage evtl. nicht mehr jedem bekannt aber da sind schon klare Strukturen hinter, für sendmail gibt es ausgereifte Bücher - auch in deutsch. >Kauft euch mal das aktuelle Linux Magazin, da ist ein hervorragender sendmail Artikel drin. Ich mag sendmail und nutze es seit Jahren.
Habe Was vergessen: wegen den klaren Strukturen: Die gibt es überall, jedes config file das ich kenne hat die und selbst die spezielle Relativitätstheorie hat eine klar Struktur, aber leider verstehen alle nicht Physiker die überhaupt nicht.
Hehe, Sendmail ist ja mittlerweile fast ein Pseudonym für umständlich und komplizierte Mailkonfiguration. Obs stimmt kann ich nicht beurteilen da ich selbst nur Qmail und Exim kenne aber sicherlich wird da schon was dran sein... Die meisten werden aber deswegen abgeschreckt sein und die ganzen Sicherheitslücken tun ihr übriges. Zum Glück hat man ja die Wahl und mit Exim oder Qmail kommt man ja auch sehr gut ans Ziel und einfacher zu konfigurieren sind sie auch (mit Vexim erst recht).
Nun, ich hab noch nie nen Mailserver benötigt, kann also diesbezüglich net mitreden. Aber mir hat ja schon der Hinweis auf m4 gereicht. Das verwendet auch autocrap. (auto{conf|make|...}) Ich verwende zur Zeit als Buildsystem SCons. ANT scheit auch nett zu sein, aber die XML Syntax is abissal viel Tipparbeit. Dafür ist's deklarativ und somit in einer IDE einfacher zu integrieren.
Aber CMake ist noch einfacher und vor allem extrem schnell im Vergleich zum Python-basierten SCons... Generiert auch Unixfiles, Visual Studio und nmake kompatible und ist von der Syntax IMHO mit am einfachsten. Noch einfacher gehts natürlich mit dem Managed Makefiles z.B. bei Eclipse CDT...
SCons hat meiner Ansicht nach einen entscheidenden Vorteil gegenüber (C)Make: Die komplette Buildlogik ist hostbasiert. Im Gegensatz zu denen liefert man bei der Distribution seiner Software ein immer identisches, einfaches SConstruct mit, dessen Umsetzung in konkrete Shellogik zur Laufzeit erfolgt, plattformspezifische Optimierungen und neueste Verbesserungen inklusive.
Am wichtigsten aber ist, dass damit eine klare Linie gezogen wird zwischen Software und Dependencies. Oder systemweite Buildkonfigurationen ohne Environmentvariablenorgien... Build-Checks können in die Verantwortung der dazugehörigen Development-Pakete wandern, denn niemand muss sie mehr im Configureskript mitliefern. Natürlich geht das auch mit den Autotools, aber zu welchem Preis für den User?
SCons skaliert allerdings sehr schlecht und ist gerade bei großen Systemen sehr langsam. KDE4 soll deswegen auch mit CMake (war zumindest der letzte Stand den ich kenne) gebaut werden. Bei CMake ist die Buildlogik auch Hostbasiert, da die Testmodule nicht zum Buildscript sondern zu Cmake gehören "Module". Aber was auch immer... fast alles ist besser als die GNU-Autotools Die haben ihre besten Zeiten wohl hinter sich und es ist Zeit für SCons/CMake usw.
> SCons skaliert allerdings sehr schlecht Bei mir skaliert es hervorragend, auch bei größeren Projekten. Die meiste Zeit frißt ohnehin die GCC. :)
> Bei CMake ist die Buildlogik auch Hostbasiert Ah okay.
Es sieht mir, nach dem Lesen der Mailingliste, eher danach aus, als wäre die KDE-Entscheidung deshalb für CMake gefallen, weil der, der den Wandel von den Autotools für KDE4 vollziehen wollte, eben derjenige war, der CMake nutzt, und weil man keinen nahen Kontakt zu den SCons-Entwicklern hatte, während die CMake-Leute sich wohl ins Zeug legten. Über technische Vorteile sagt das nicht sehr viel aus. :)
Wie auch immer, möge die beste Lösung gewinnen, wobei ich halt im Detail ein Buildsystem, daß aus einer kompletten OO-Sprache mit reichhaltiger Classlib besteht, für mächtiger halte. Ja, ich weiß, alles turing-vollständig, trotzdem.
Man muß ja nicht unbedingt in der sendmail.cf herumwerken. Außerdem kann eine Oracle DB auch nicht von jedem Affen sofort installiert und administriert werden.
Manche Dinge muß man eben erst lernen. Vielleicht sollte man ja erst mal mit was leichtem Anfangen bevor man sich unbedingt an die Schergewichte in der Szene macht.
Aber PR Meldungen und Werbung hat es ja auch schon damals geschafft Lernresistenz bei den Usern und Admins zu verbreiten.
Es gibt zumindest keinen vernünftigen Grund, warum das Konfigurieren eines MTA derart komplex sein muß. Das man lernen kann, damit umzugehen, ist was anderes.
wenn ja warum kauft das ueberhaupt jemand?
wer sich heutzutage mit Mail auseinandersetzen möchte muß schon ein wenig Zei investieren. Da sind exim, postfix und qmail auch nicht viel leichter _sicher_ zu konfigurieren.
m4 ist heutzutage evtl. nicht mehr jedem bekannt aber da sind schon klare Strukturen hinter, für sendmail gibt es ausgereifte Bücher - auch in deutsch.
Kauft euch mal das aktuelle Linux Magazin, da ist ein hervorragender sendmail Artikel drin. Ich mag sendmail und nutze es seit Jahren.
Gruß
Danach wollte er von Sendmail nix mehr wissen, - war ihm zu sehr "pain in the ass"...
Ist meine Erinnerung richtig, dass Postfix von vornherein auf Sicherheit hin designt wurde?
>wer sich heutzutage mit Mail auseinandersetzen möchte muß schon ein wenig Zei investieren. Da sind exim, postfix und qmail auch nicht viel leichter _sicher_ zu konfigurieren.
Also von dem was ich gesehen habe spart man da schon massiv Zeit. Es kommt eben drauf an, für was man einen Mailserver brauchen will, ob es darum geht, China zu vernetzen oder nur 100 Leute zu verkabeln. Würde für China Sendmail nehmen, bei allem anderen Postfix.
Habe das für die RHCE Prüfung noch lernen dürfen und habe das als sehr umständliche Technologie erlebt. Alles ist recht non-standard. Was ist standard? Man schaue mal die config-files momentanter, d.h. in diesem Jahrzehnt erstellter OSe an (OSS) oder der der letzen Dekade und man erschrickt bei Sendmail. Muss ich das auch noch lernen? ist das nicht etwas überflüssig und eine Reform wäre angebracht?
>m4 ist heutzutage evtl. nicht mehr jedem bekannt aber da sind schon klare Strukturen hinter, für sendmail gibt es ausgereifte Bücher - auch in deutsch.
>Kauft euch mal das aktuelle Linux Magazin, da ist ein hervorragender sendmail Artikel drin. Ich mag sendmail und nutze es seit Jahren.
Ja, klar, es gibt über alles Bücher. Die Frage ist doch, ob es ein mehr als tausend Seiten Buch benötigt, nur um die Basics zu beschreiben. Verkomplifiziert da nicht etwas?
Also, ich habe auch schon fast eine 4 auf dem Rücken, man will an altem vertrauten festhalten, aber manchmal muss man einfach einen Punkt machen und was reformieren, was zu altmodisch und kompliziert wurde. Natürlich ist es leicht, wenn man es schon gelernt hat, das schon atmet und im Schlaf macht, aber was ist mit allen Neueinsteigern? Wer denkt, dass Sendmail zeitgemäss zu konfigurieren ist, der hat den Doktor darauf gemacht (und das kann und muss man auch, damit man es richtig benützen kann) und wie auch der Author des Artikels im Linux Magazin die Bodenhaftung verloren, d.h. hat absolut keinen Schimmer mehr, dass er da Quanten-Physik Formeln drischt, die auch bei intelligenten Linux admins einfach zu weit geht und nur Fragezeichen hinterlassen. All die Leute, ich inklusive, lassen dann Sendmail sausen und nehmen was anderes, was auch funkt.
Das Prinzip Linux ist eben ein Unix mit den neuen frischen Ideen, treibern und Features und Anpassungen an heute die die alte Unix Garde nie als notwendig sah.
Für alle die das noch nicht verstanden haben: Sendmail verwendet eine Art Compiler um das config file das man schreibt in ein Sendmail lesbares format zu übersetzen. Nicht das die für Menschen bestimmte Seite des config files wirklich viel verständlicher wäre. Braucht es diesen Compilerlauf?
Unix und Linux sind Zeitlos in vieler Hinsicht, etwas das perfekt ist, das muss man nicht ändern. Einverstanden. Aber das wird häufig als faule Ausrede gegen nötige Optimierungen und Verbesserungen verwendet.
Wie Einstein sagte: Man soll Dinge simpel machen, sie aber nicht versimplifizieren.
ich sage: man soll Dinge kompliziert machen, so weit wie nötig, aber nicht mehr.
Sendmail braucht eine Reform, dringend. Sonst wird es aussterben. Nicht weil es zu teuer ist oder was... ich z.B. (und bin nicht schlecht informiert im ganzen) wusste gar nicht dass Sendmail kommerziel organisiert ist, hatte immer eine gratis Version im Einsatz.
Die Funktionalität und Stabilität von Sendmail wird übrigens von mir nicht angezweifelt, die ist ohne Frage ohne Konkurrenz. Die Sache ist nur, wie man es konfiguriert, ohne dass man zwischen dem und einer Famile haben entscheiden muss.
>Kauft euch mal das aktuelle Linux Magazin, da ist ein hervorragender sendmail Artikel drin. Ich mag sendmail und nutze es seit Jahren.
Habe Was vergessen: wegen den klaren Strukturen:
Die gibt es überall, jedes config file das ich kenne hat die und selbst die spezielle Relativitätstheorie hat eine klar Struktur, aber leider verstehen alle nicht Physiker die überhaupt nicht.
Die meisten werden aber deswegen abgeschreckt sein und die ganzen Sicherheitslücken tun ihr übriges.
Zum Glück hat man ja die Wahl und mit Exim oder Qmail kommt man ja auch sehr gut ans Ziel und einfacher zu konfigurieren sind sie auch (mit Vexim erst recht).
Ich verwende zur Zeit als Buildsystem SCons. ANT scheit auch nett zu sein, aber die XML Syntax is abissal viel Tipparbeit. Dafür ist's deklarativ und somit in einer IDE einfacher zu integrieren.
Am wichtigsten aber ist, dass damit eine klare Linie gezogen wird zwischen Software und Dependencies. Oder systemweite Buildkonfigurationen ohne Environmentvariablenorgien... Build-Checks können in die Verantwortung der dazugehörigen Development-Pakete wandern, denn niemand muss sie mehr im Configureskript mitliefern. Natürlich geht das auch mit den Autotools, aber zu welchem Preis für den User?
lg
Erik
Aber was auch immer... fast alles ist besser als die GNU-Autotools
Bei mir skaliert es hervorragend, auch bei größeren Projekten. Die meiste Zeit frißt ohnehin die GCC. :)
> Bei CMake ist die Buildlogik auch Hostbasiert
Ah okay.
Es sieht mir, nach dem Lesen der Mailingliste, eher danach aus, als wäre die KDE-Entscheidung deshalb für CMake gefallen, weil der, der den Wandel von den Autotools für KDE4 vollziehen wollte, eben derjenige war, der CMake nutzt, und weil man keinen nahen Kontakt zu den SCons-Entwicklern hatte, während die CMake-Leute sich wohl ins Zeug legten. Über technische Vorteile sagt das nicht sehr viel aus. :)
Wie auch immer, möge die beste Lösung gewinnen, wobei ich halt im Detail ein Buildsystem, daß aus einer kompletten OO-Sprache mit reichhaltiger Classlib besteht, für mächtiger halte. Ja, ich weiß, alles turing-vollständig, trotzdem.
lg
Erik
- "Atomkraftwerke liefern saubere und sichere Energie"
- "BSE ist für den Menschen ungefährlich"
- "Es wird nie ein Mensch die Schallmauer durchbrechen"
Außerdem kann eine Oracle DB auch nicht von jedem Affen sofort installiert und administriert werden.
Manche Dinge muß man eben erst lernen.
Vielleicht sollte man ja erst mal mit was leichtem Anfangen bevor man sich unbedingt an die Schergewichte in der Szene macht.
Aber PR Meldungen und Werbung hat es ja auch schon damals geschafft Lernresistenz bei den Usern und Admins zu verbreiten.
lg
Erik