Ich bin zwar von QMail auch nicht gerade begestert aber man man muß zugeben das der Mailserver ziemlich Rubust und Leistungsfähig ist. Nur die Weiterentwicklung ist leider liegengeblieben.
Es geht nicht darum. Es geht darum, das er Recht hat, das die Distributionen ihre eigene Welt schaffen wollen, und alle ausserhalb dieser Welt AUSGRENZEN möchte.
Ich nutze Linux seit 5 Jahren, bin an sich zufrieden damit, aber ich gebe ihm in dieser Hinsicht zu 100% Recht!
Nun ja, einen Mailserver zu schreiben der einige Jahre ohne ein wirkliches Update auskommt und kaum (keine ??) Sicherheitslücken hat ist schon eine Leistung. Bei der Installation hatte ich zwar das Buch neben dran liegen, aber danach lief gut und ohne Probleme. Einmalige Aufwände bei der Einrichtung sind zu verkraften. Ich setzte ihn nicht mehr ein weil mir das rumgepatche auch mit den Konflikten irgendwann zu blöd war.
Ja das war immer ein Problem von QMail. Die Überprüfung ob ein bestimmter Empfänger auf dem Server überhaupt existiert hat erst nach der Einlieferung in die Queue stattgefunden. Daher wurden unnötige Bounces generiert.
Es gab zwar ein paar Patches und auch ein Plugin für qmail-spp existiert aber von Haus aus konnte QMail das nicht. Das lag vor allem an der Einstellung von Bernstein das jeder Programmteil von den anderen isoliert sein sollte. Leider war das des guten zuviel.
In einer Biärdistribution kann das nicht gewesen sein. Die Lizenz unter der QMail bis vor kurzem stand hat es Distributoren nicht erlaubt QMail als Paket mitzuführen. Meistens war als Workaround ein Buildskript in der Distribution vorhanden das QMail dann gebaut und als Paket verpackt hat.
Bei *BSD könnte es in den Ports mit dabei gewesen sein aber wohl nicht als Binärpaket.
Super! Jetzt, wo ich alle Mailserver umgestellt hab, macht DJB sowas. Dass Qmail nicht wirklich frei ist, war für mich *der* Grund auf exim zu wechseln, da ich Qmail eben nicht binär vertreiben darf. *SIG*
QMail ist mit Abstand der beste Mailserver, und schlägt exim und postfix aus meiner Sicht um Längen! Von sendmail mal ganz zu schweigen. QMail skaliert optimal, kommt auch mit riesigen Mailvolumen zurecht, ist extrem sicher (kein einziges Securityhole in den letzten 9 Jahren!) und sehr angenehm zu konfigurieren. Zusammen mit vpopmail ist Qmail ein unschlagbarer Mailserver und man spart sich den ganzen Rotz, virtuelle User über MySQL-Datenbanken, SASL und so'n Dreck mit exim zu hosten.
Ich bin echt gespannt, was da die nächsten Tage und Wochen so passiert. Ich hoffe, dass das wilde "Rumgepatche" damit nun endlich aufhören wird...
Und dann schauen wir mal, was mit Qmail2 so kommen wird.
Thema Securityhole: Hatte Postfix auch nichts "nennenswertes" weil es auch konsequent auf Sicherheit programmiert wurde. QMAIL bietet afaik (korrigiert mich ob ich falschliege) fast keine gescheiten "Konfigurationsoptionen" in Richtung "Antispam" wie es z.B. Postfix bietet, da DJB meinte sein Mailer könne alles was die Welt (die Spammer meinte er damit wohl auch) so braucht, hat mein Provider (in der Fa.) grosse Probleme die Spamflut auch nur annähernd einzudämmen ...
QMail mit vpopmail würde ich nicht unschlagbar nennen. Ich hab 3 solche Mailserver an den Backen als Altlast von meinem Vorgänger. Die AntiSpam Möglichkeiten von QMail sind doch arg eingeschränkt und das schlimmste ist das QMail unnötige Bounces erzeugt hat, da man beim Einliefern von Haus aus nicht feststgestellt wird ob der Empfänger existiert oder nicht und das nutzen Spammer gerne für Backscatter Spamming aus. Zum Glück habe ich vor einiger Zeit für den qmail-spp Patch ein "Plugin" entdeckt das diese Überprüfung nachrüstet.
Ich selbst stehe eher auf Postfix aber schiele auch immer etwas in Richtung Exim. Vor allem die ACLs haben es mir angetan aber ich muß mich noch intensiver in das Thema einlesen.
Und was Exim + SASL angeht so hab ich einen Tipp für dich. Nimm Dovecot als IMAP Server und lass die Authentifikation über Dovecot laufen:
Ach ja und die Sicherheit von QMail ist nur deshalb so gut da sich das Teil quasi die letzten 9 Jahre nicht bewegt hat und die Patches die QMail mit notwendigen Funktionen versorgt haben, hatten durchaus Sicherheitslöcher. Ich erinnere mich noch an ein Loch in einem Patch der QMail SMTP Authentifikation beigebracht hat der es erlaubt hat Mails zu verschicken ohne Authentifikation.
Also ich bin von der Lösung Qmail + vpopmail + courier (mit authdaemon über vchkpw) immer noch begeistert und mir ist noch keine vergleichbare Lösung zu Gesicht bekommen. Entweder man muss Exim+SASL und courier über MySQL laufen lassen (grausam!) oder man relle Benutzer in /etc/passwd oder man nutzt ganz krude Vorgehensweisen. Von exim wird z.B. vorgeschlagen, sich für SMTPAuth testweise auf einem IMAP-Server einzuloggen, um zu schauen, ob das Passwort passt. Und das ist -- wohlgemerkt -- ein ernst gemeinter Vorschlag. Da lob ich mir vpopmail!
Dadurch dass QMail in den letzten 9 Jahren nicht weiterentwickelt wurde, hat man zugegebenermaßen weniger Möglichkeiten zur Spambekämpfung. Dadurch bedingt sind es 2 Punkte, die mich stören: Mails müssen grundsätzlich erst einmal angenommen werden und damit bürdet man sich die Bounces auf und erzeigt "collerateral spam". Und: alle Mails werden grundsätzlich vollständig angenommen: ich hatte mal einen Kunden, dem eine 500MB große Mail etwa 80 Mal zugestellt wurde (jedesmal mit einem temporary error) und das hat bei ihm unnötige Traffic-Kosten verursacht. Qmail hätte die Mail jedoch schon nach dem RCTP TO ablehnen können.
Bei postfix sieht es aber auch nicht besser aus. Eine vernünftige Integration von spamassassin hab ich nicht finden können. Und spamassassin über die master.cf einzubinden ist von hinten mit dem Strick durchs Auge.
Bei exim ist die Konfiguration sehr "gewöhnungsbedüftig". Diese Art Makrosprache, die man in der exim.conf benutzen kann, ist zwar seht mächtig, aber auch extrem hässlich. If-Else-Konstrukte in einer Konfigurationsdatei sind nicht mein Ding. Dafür hat man aber über die ACLs viele nette Möglichkeiten, Spam direkt auf SMTP-Ebene abzulehnen. Von daher bin ich von Qmail auf exim umgestiegen. Und es gibt eine ganz hervorragende Spam-Doku für exim. Sehr lesenswert. Zusammen mit policyd-weight und greylisting kommt da nichts durch.
Was Exim + SASL + Courier angeht da hab ich nicht ohne Grund dovecot als IMAP/POP3 Server vorgeschlagen.
Dovecot ist ein 100%tiger Ersatz für Courier und neben einem eigenen MDA den man benutzen kann bietet es auch einen Authdaemon der von Postfix und Exim angesprochen werden kann. Das Authentifikationsprotokoll ist einfacher gestrickt als SASL und man braucht keine Zusatzlibs. Daher ist bei Postfix die Dovecot Authentifikation seit Version 2.3 fester Bestandteil und bei Exim seit Version 4.64.
Da sich Dovecot gegen viele verschiedene Datenquellen authentifizieren kann hat man gleichzeitig diese Möglichkeiten dann auch für die SMTP Authentfikation. Damit kann man virtuelle Benutzer auch ohne Datenbank nutzen. Man kann sich z.B. gegen eine Passwd Datei oder gegen LDAP authentifizieren. Auch eine Authentifikation gegen vpopmail oder checkpassword ist vorgesehen.
Was für QMail User zur Spamabwehr interessant sein dürfte ist qpsmtpd. Das ist ein Ersatz für den qmail SMTP Daemon und in Perl geschrieben. Durch die Pluginmöglichkeiten und das man in jeder Phase der SMTP Kommunikation bis zum endgültigen 200 OK nach dem erfolgreichen Abschluß der Übertragung eingreifen kann, hat man extrem viele Möglichkeiten zur Spamabwehr.
Es gibt z.B. Plugins die verfüttern die Mail an Spamassassin oder einen Virenscanner (z.B. ClamAV) gleich nach dem End of Data. Wenn es als Spam identifiziert wird oder als Wurm / Virus dann kommt statt dem "200 OK" eine 500er Meldung und die Mail wird ohne Bounce einfach abgelehnt.
qpsmtpd wird unter anderem von apache.org und cpan.org verwendet, und die haben so ca. 2 Mio Mails pro Tag zu verarbeiten.
Qmail ist imho kein schlechter Mailer nur über die Jahre eben etwas angegraut, hätte DJB schon früher seinen Starrsinn beiseite gelegt, wäre vielen Administratoren manch "Patchorgie" erspart geblieben. Einige Provider setzen immer noch QMAIL ein, weil es wohl z.B. hierfür noch Schnittstellen gibt für die "grafische Verwaltungsoberfläche von Mail-Managementtools". Persönlich bevorzuge ich jedoch Postfix ...
Dazu hätte er ganz einfach des Programm unter die GPL stellen können. Die verhindert Forks zwar nicht, macht sie aber unwahrscheinlich, d.h. es wird nicht geforked, solange das Programm von seinem Projektleiter nicht total ins Eck gefahren wird (wie es z.B. mit XF86 passierte).
Public Domain führt allerdings mit sehr hoher Wahrscheinlichkeit zu Forks, ganz besonders zu Closed-Source Abspaltungen, sofern sich eine Firma davon einen Vorteil verspricht.
Der Herr Berstein ist zwar sicher ein guter Programmierer und Computersicherheitsfachmann, aber von der Wirkungsweise von Lizenzen hat er offensichtlich nicht viel mitbekomen. Mich würde es wundern, wenn nicht qmail-code in großem Stil von Softwarefirmen in eigene Produkte eingebaut würde, bzw. sich nicht viele kleine closed-source qmail-Abkömmlinge bilden würden.
Ich denke sehr wohl, dass sich DJB mit den Lizenzen auskennt. Die Wahl einer nicht-offenen Lizenz für Qmail (du darfst binäre Pakete nur vertreiben, wenn sie exakt dem entsprechen, wenn man es selbst kompiliert hätte), macht aus Admin-Sicht durchaus Sinn. Wenn Du an einem vanilla-Qmail-System sitzt, weißt Du ganz genau wo was liegt und warum etwas nicht funktioniert.
Das Problem sind da eher die Distributionen. Das Debian Paket z.B. nimmt das Standard-Qmail 1.03 und packt da einige (wenige) Patches rein und erzeugt das deb beim Installieren. Damit untergräbt Debian eigentlich das, was DJB mit seiner Lizenz erreichen wollte.
Dass DJB jetzt public domain gewählt hat (und nicht GPL) wird auch seine Gründe haben. Nur weil Du da vielleicht anderer Meinung bist oder das ganze nicht verstehst, heißt das noch nicht, dass das keinen Sinn ergibt.
Von Daniel Seuffert am So, 2. Dezember 2007 um 01:34 #
Die Tatsache, daß es alleine über 700 Distributionen gibt lässt mich über deine Aussagen schmunzeln.
Unabhängig davon kommt dieser Schritt in meinen Augen zu spät, sendmail/Postfix haben wesentlich größere Verbreitung gefunden und die Freigabe unter PD wird an der Verbreitung/Qualität von qmail wohl vordergründig wenig ändern.
das qmail jetzt keine chance mehr hat würde ich nicht behaupten die meisten nötigen neuen funktionen sind ja in form von patches vorhanden. und qmail wird heute noch bei vielen providern verwendent weil es einfach wenig resourcen frist zumindest weniger wie sendmail/postfix. hoffe das es jetzt nicht 600 verschiedene paket versionen geben wird jede mit anderen patches, er hätte doch einfach selbst ein einziges projekt im vorfeld anleiern bzw jemanden dafür suchen können der das ein wenig unter seine fittiche weiter führt und auf aktuellen stand bringt.
Von Daniel Seuffert am So, 2. Dezember 2007 um 11:21 #
Ich wollte mit meinem post nicht den eindruck erwecken, als wolle ich qmail totreden. Es hat eine treue Fangemeinde seit Jahren und die wird das Werk fortführen. Allerding sieht man z.B. an sendmail, wie groß die Beharrungskräfte sind. Die Leute sind etwas gewohnt und stellen sich nur ganz extrem schwer um. Wer einmal X benutzt hat und damit halbwegs zufrieden war nimmt schwerlich morgen Y. qmail, exim und all die anderen stehen im Schatten von sendmail und Postfix und bei maturierten Segmenten wie MTAs ändert sich höchstens auf sehr lange Zeiträume etwas. Da gibt es auch keine richtigen Killerfeatures, die Nutzer veranlassen könnten morgen von A nach B zu switchen.
Deine zweite Aussage trifft imho den Nagel auf den Kopf: Genau das hätte Bernstein schon vor Jahren tun sollen, als ihm klar war, daß er zu wenig Zeit und Lust hatte qmail entsprechend weiterzuetwickeln. Hätte er diesen Schritt vor Jahren getan hätte heute qmail garantiert eine wesentlich größere Bedeutung und ich an seiner Stelle hätte das getan getreu dem Motto: If you love them set them free. Es ist schade drum, weil die Anlagen alle da waren seit Beginn. Aber vielleicht findet sich eine Person/Gruppe, die so stark ist, daß sie das Heft an sich reißt und die Entwicklung so stark vorantreibt, daß andere gar nicht auf den Gedanken kommen ständig zu "forken".
Von Thilo Pfennig am So, 2. Dezember 2007 um 20:53 #
Das intelligenteste wäre, wenn sich Leute zusammentun und den Code auf GPL umschreiben und dann weiterentwickeln. Public Domain bedeutet das jeder mit dem Code machen kann, was er will - auch proprietär machen oder eben GPL.
Nur die Weiterentwicklung ist leider liegengeblieben.
Es geht darum, das er Recht hat, das die Distributionen ihre eigene Welt schaffen wollen,
und alle ausserhalb dieser Welt AUSGRENZEN möchte.
Ich nutze Linux seit 5 Jahren, bin an sich zufrieden damit, aber ich gebe
ihm in dieser Hinsicht zu 100% Recht!
Grüße
Felix
Es gibt doch schließlich mit Outlook und Thunderbird 2 gute Mailprogramme die auf jeden fall mehr als nur ausreichend sind.
Ein bisschen grüner magischer Rauch und die Mail ist beim Empfänger? Oder doch lieber ein paar MTAs die sich darum kümmern?
Deshalb verkauft meine Firma jetzt neu grüne Rauchmaschinen auf EBay...
Brauser, was sind jetzt nochmal Brauser?
Ach ja, ich geh immer mit dem Internet Exploder ins Netz.
Apache und IIS verwendet doch keiner!
Über PowerPoint reicht sein Horizont nicht hinaus.
Also ich bin erst bei E wie E-Mail.
http://www.egilh.com/blog/archive/2006/05/28/2769.aspx
Daher wurden unnötige Bounces generiert.
Es gab zwar ein paar Patches und auch ein Plugin für qmail-spp existiert aber von Haus aus konnte QMail das nicht.
Das lag vor allem an der Einstellung von Bernstein das jeder Programmteil von den anderen isoliert sein sollte. Leider war das des guten zuviel.
Habe damals nahezu alles ausprobiert, koennte auch ?BSD sein.
Meistens war als Workaround ein Buildskript in der Distribution vorhanden das QMail dann gebaut und als Paket verpackt hat.
Bei *BSD könnte es in den Ports mit dabei gewesen sein aber wohl nicht als Binärpaket.
QMail ist mit Abstand der beste Mailserver, und schlägt exim und postfix aus meiner Sicht um Längen! Von sendmail mal ganz zu schweigen.
QMail skaliert optimal, kommt auch mit riesigen Mailvolumen zurecht, ist extrem sicher (kein einziges Securityhole in den letzten 9 Jahren!) und sehr angenehm zu konfigurieren. Zusammen mit vpopmail ist Qmail ein unschlagbarer Mailserver und man spart sich den ganzen Rotz, virtuelle User über MySQL-Datenbanken, SASL und so'n Dreck mit exim zu hosten.
Ich bin echt gespannt, was da die nächsten Tage und Wochen so passiert. Ich hoffe, dass das wilde "Rumgepatche" damit nun endlich aufhören wird...
Und dann schauen wir mal, was mit Qmail2 so kommen wird.
QMAIL bietet afaik (korrigiert mich ob ich falschliege) fast keine gescheiten "Konfigurationsoptionen" in Richtung "Antispam" wie es z.B. Postfix bietet, da DJB meinte sein Mailer könne alles was die Welt (die Spammer meinte er damit wohl auch) so braucht, hat mein Provider (in der Fa.) grosse Probleme die Spamflut auch nur annähernd einzudämmen ...
Die AntiSpam Möglichkeiten von QMail sind doch arg eingeschränkt und das schlimmste ist das QMail unnötige Bounces erzeugt hat, da man beim Einliefern von Haus aus nicht feststgestellt wird ob der Empfänger existiert oder nicht und das nutzen Spammer gerne für Backscatter Spamming aus. Zum Glück habe ich vor einiger Zeit für den qmail-spp Patch ein "Plugin" entdeckt das diese Überprüfung nachrüstet.
Ich selbst stehe eher auf Postfix aber schiele auch immer etwas in Richtung Exim. Vor allem die ACLs haben es mir angetan aber ich muß mich noch intensiver in das Thema einlesen.
Und was Exim + SASL angeht so hab ich einen Tipp für dich. Nimm Dovecot als IMAP Server und lass die Authentifikation über Dovecot laufen:
http://wiki.dovecot.org/HowTo/EximAndDovecotSASL
Da spart man sich den Ärger mit SASL.
Ach ja und die Sicherheit von QMail ist nur deshalb so gut da sich das Teil quasi die letzten 9 Jahre nicht bewegt hat und die Patches die QMail mit notwendigen Funktionen versorgt haben, hatten durchaus Sicherheitslöcher.
Ich erinnere mich noch an ein Loch in einem Patch der QMail SMTP Authentifikation beigebracht hat der es erlaubt hat Mails zu verschicken ohne Authentifikation.
Interessant! Geht übrigens anscheinend auch mit Postfix: http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL
Dadurch dass QMail in den letzten 9 Jahren nicht weiterentwickelt wurde, hat man zugegebenermaßen weniger Möglichkeiten zur Spambekämpfung. Dadurch bedingt sind es 2 Punkte, die mich stören: Mails müssen grundsätzlich erst einmal angenommen werden und damit bürdet man sich die Bounces auf und erzeigt "collerateral spam". Und: alle Mails werden grundsätzlich vollständig angenommen: ich hatte mal einen Kunden, dem eine 500MB große Mail etwa 80 Mal zugestellt wurde (jedesmal mit einem temporary error) und das hat bei ihm unnötige Traffic-Kosten verursacht. Qmail hätte die Mail jedoch schon nach dem RCTP TO ablehnen können.
Bei postfix sieht es aber auch nicht besser aus. Eine vernünftige Integration von spamassassin hab ich nicht finden können. Und spamassassin über die master.cf einzubinden ist von hinten mit dem Strick durchs Auge.
Bei exim ist die Konfiguration sehr "gewöhnungsbedüftig". Diese Art Makrosprache, die man in der exim.conf benutzen kann, ist zwar seht mächtig, aber auch extrem hässlich. If-Else-Konstrukte in einer Konfigurationsdatei sind nicht mein Ding. Dafür hat man aber über die ACLs viele nette Möglichkeiten, Spam direkt auf SMTP-Ebene abzulehnen. Von daher bin ich von Qmail auf exim umgestiegen. Und es gibt eine ganz hervorragende Spam-Doku für exim. Sehr lesenswert.
Zusammen mit policyd-weight und greylisting kommt da nichts durch.
Dovecot ist ein 100%tiger Ersatz für Courier und neben einem eigenen MDA den man benutzen kann bietet es auch einen Authdaemon der von Postfix und Exim angesprochen werden kann. Das Authentifikationsprotokoll ist einfacher gestrickt als SASL und man braucht keine Zusatzlibs. Daher ist bei Postfix die Dovecot Authentifikation seit Version 2.3 fester Bestandteil und bei Exim seit Version 4.64.
Da sich Dovecot gegen viele verschiedene Datenquellen authentifizieren kann hat man gleichzeitig diese Möglichkeiten dann auch für die SMTP Authentfikation.
Damit kann man virtuelle Benutzer auch ohne Datenbank nutzen. Man kann sich z.B. gegen eine Passwd Datei oder gegen LDAP authentifizieren.
Auch eine Authentifikation gegen vpopmail oder checkpassword ist vorgesehen.
Was für QMail User zur Spamabwehr interessant sein dürfte ist qpsmtpd. Das ist ein Ersatz für den qmail SMTP Daemon und in Perl geschrieben.
Durch die Pluginmöglichkeiten und das man in jeder Phase der SMTP Kommunikation bis zum endgültigen 200 OK nach dem erfolgreichen Abschluß der Übertragung eingreifen kann, hat man extrem viele Möglichkeiten zur Spamabwehr.
Es gibt z.B. Plugins die verfüttern die Mail an Spamassassin oder einen Virenscanner (z.B. ClamAV) gleich nach dem End of Data. Wenn es als Spam identifiziert wird oder als Wurm / Virus dann kommt statt dem "200 OK" eine 500er Meldung und die Mail wird ohne Bounce einfach abgelehnt.
qpsmtpd wird unter anderem von apache.org und cpan.org verwendet, und die haben so ca. 2 Mio Mails pro Tag zu verarbeiten.
vielen Administratoren manch "Patchorgie" erspart geblieben. Einige Provider setzen immer noch QMAIL ein, weil es wohl z.B. hierfür noch Schnittstellen gibt für die "grafische Verwaltungsoberfläche von Mail-Managementtools".
Persönlich bevorzuge ich jedoch Postfix ...
just my 2ct.
Public Domain führt allerdings mit sehr hoher Wahrscheinlichkeit zu Forks, ganz besonders zu Closed-Source Abspaltungen, sofern sich eine Firma davon einen Vorteil verspricht.
Der Herr Berstein ist zwar sicher ein guter Programmierer und Computersicherheitsfachmann, aber von der Wirkungsweise von Lizenzen hat er offensichtlich nicht viel mitbekomen. Mich würde es wundern, wenn nicht qmail-code in großem Stil von Softwarefirmen in eigene Produkte eingebaut würde, bzw. sich nicht viele kleine closed-source qmail-Abkömmlinge bilden würden.
SW-Soft verwendet ein modifiziertes QMail als Mailserver für Plesk.
Das gibt es nur als fertiges Paket.
Das Problem sind da eher die Distributionen. Das Debian Paket z.B. nimmt das Standard-Qmail 1.03 und packt da einige (wenige) Patches rein und erzeugt das deb beim Installieren. Damit untergräbt Debian eigentlich das, was DJB mit seiner Lizenz erreichen wollte.
Dass DJB jetzt public domain gewählt hat (und nicht GPL) wird auch seine Gründe haben. Nur weil Du da vielleicht anderer Meinung bist oder das ganze nicht verstehst, heißt das noch nicht, dass das keinen Sinn ergibt.
Unabhängig davon kommt dieser Schritt in meinen Augen zu spät, sendmail/Postfix haben wesentlich größere Verbreitung gefunden und die Freigabe unter PD wird an der Verbreitung/Qualität von qmail wohl vordergründig wenig ändern.
Deine zweite Aussage trifft imho den Nagel auf den Kopf: Genau das hätte Bernstein schon vor Jahren tun sollen, als ihm klar war, daß er zu wenig Zeit und Lust hatte qmail entsprechend weiterzuetwickeln. Hätte er diesen Schritt vor Jahren getan hätte heute qmail garantiert eine wesentlich größere Bedeutung und ich an seiner Stelle hätte das getan getreu dem Motto: If you love them set them free. Es ist schade drum, weil die Anlagen alle da waren seit Beginn. Aber vielleicht findet sich eine Person/Gruppe, die so stark ist, daß sie das Heft an sich reißt und die Entwicklung so stark vorantreibt, daß andere gar nicht auf den Gedanken kommen ständig zu "forken".