Sendmail macht mich wahnsinnig...

[turrican]

... dass sendmail ein kompletter Mailserver wäre, was man ja gar nicht bräuchte, weil ein lokaler völlig ausreichen würde??? Was sind das denn für Argumente?

Das sendmail kannst dir hier im übertragenen Sinne als vollwertigen Exchange Server denken - für rein lokalen Mailtransport wäre dieser auch overkill (quasi ein Hochhaus, wo ein Zelt reicht).

Kann mich erinnern, dass wir - wenn ich mal mit Mailern in der Welt außerhalb Exchange konfrontiert war - sendmail meist durch exim oder später dann postfix ersetzt hatten, einfach weil keiner sendmail so richtig traute bzw Risiken eingehen wollte.

Ein Mailserver ist halt immer mit einem gewissen Risiko behaftet, selbst in perfekt konfiguriertem Zustand (kann man den überhaupt je erreichen) kann es halt sein, dass etwas unvorhergesehenes, von extern einwirkendes damit passiert - wie @mr44er und @Rosendoktor oben anschaulich beschrieben haben.

Mit Mailern wie exim oder postfix ist dieses Risiko zwar auch nicht auf Null, aber doch geringer als mit sendmail - exim ist so gesehen auch nicht unbedingt "kleiner" als sendmail.

Es gibt aber auch Mailadmins, welche trotz sendmail ruhig schlafen können.

 

[Azazyel]

Ich habe da mal reingelesen und finde den Artikel ehrlich gesagt etwas sonderbar: Es wird gesagt, dass sendmail in der Vergangenheit zahlreiche Sicherheitslücken hatte, die in FreeBSD aber behoben wurden.

Eine Software, die in der Vergangenheit massig Sicherheitslücken hatte, wird aller Voraussicht nach auch in der Zukunft massig Sicherheitslücken haben. An sendmail wurden keine signifikanten architekturellen oder sonstige Veränderungen vorgenommen, die eine erhebliche Verbesserung der Sicherheitslage vermuten lassen.

Daher ist davon auszugehen, dass in sendmail noch massig Sicherheitslücken schlummern.

Dann wird weiterhin kritisiert, dass weiterhin ständig Verbesserungen zur Sicherheit einfließen, diese aber nicht genauer mitgeteilt werden.

Stell dir vor, du administrierst einen FreeBSD-Server. Getreu dem Motto "never change a running system" aktualisiert du ihn nur, wenn eine Sicherheitslücke bekannt wird.

Wird nun eine Sicherheitslücke in sendmail entdeckt, aber von FreeBSD heimlich, still und leise gefixt wird, aktualisiert du deinen Server natürlich nicht - bist aber nun trotzdem verwundbar.

Dann wird auch noch kritisiert, dass sendmail ein kompletter Mailserver wäre, was man ja gar nicht bräuchte, weil ein lokaler völlig ausreichen würde???

Der alte Unix-Ansatz, bei dem jeder Server auch ein gleichberechtigter Mail-Server ist, ist inzwischen völlig überholt und wird kaum mehr praktiziert:

• Endanwender nehmen einen dedizierten Mail-Client (Evolution etc.) oder einen Web-Client
• Professionelle Betreiber nehmen einen ordentlichen MTA

Jetzt hätte FreeBSD folgende sinnvolle Optionen (ohne Anspruch auf Vollständigkeit):

• Gar nichts (mit dem Nachteil, dass rein lokale Mailzustellung nicht funktionieren würde)
• Einen schlanken und sicheren MTA für rein lokale Zustellung wie msmtp
• Einen ausgewachsenen und ordentlichen MTA wie Postfix

Keinesfalls ist sendmail eine sinnvolle Option. Scheiße bleibt Scheiße und wird nicht besser, wenn man sie weit jenseits des Verfallsdatums im Basissystem belässt.

Was sind das denn für Argumente?

Das sind professionelle Argumente, die dem aktuellen Stand der Technik entsprechen.

Sorry, dass sich das Bild dann für mich nicht ganz so negativ gestaltet. Was den Performancevergleich im anderen Artikel anbelangt, wird nicht genau dargestellt, auf welchen Plattformen man da vergleicht. Vielleicht läuft sendmail auf Windows oder Linux ja wirklich nicht so schnell wie andere, möglicherweise auf FreeBSD aber viel besser, weil nativ.

Nativ läuft sendmail auf allen Plattformen.

Im Jahre 2020 ist die Performance auch nur für große Hoster eine ernstzunehmende Frage. Du kannst zuhause auf einem Raspberry Pi problemlos eine Million Mails pro Tag mit sendmail durchjagen. Mit Postfix halt noch eine Menge mehr.

Ich finde es also nicht schlecht, dass er weiterhin im Basissystem als Bordmittel vorhanden und aktiviert ist, wer etwas anderes auf FreeBSD will, kann das ja einfach erreichen.

Der Verbleib von sendmail im Voreinstellung Basissystem verletzt den Grundsatz der reasonable defaults. Du stellst dem Anwender keine Kacke vor die Nase, sondern setzt ihm als Voreinstellung sinnvolle Software zur Verfügung. Den Verbleib von sendmail im FreeBSD-Basissystem kann man nicht schönreden.

 

[turrican]

Ich frage mich eher, wie es mit sendmail eigentlich soweit kommen konnte (Security-Alptraum, etc)?

Den gibts ja jetzt ja schon ziemlich lang (wie lang eigentlich?), und grade in der UNIX Welt galten doch die Grundsätze "ein Auftrag, ein Tool" und "so simpel wie möglich" - wie konnte sendmail also so ins Hintertreffen geraten? Bereits große Anfangskomplexität?

Normalerweise wurde Software über die Jahre doch eher besser - mittels Code-Audits, neue Programmier-Paradigmen etc?

Ok, früher spielte Sicherheit in der Softwarewelt natürlich noch nicht die Rolle wie heute, aber trotzdem...

 

[Azazyel]

Ich frage mich eher, wie es mit sendmail eigentlich soweit kommen konnte (Security-Alptraum, etc)?

1983 musste man noch keinen Gedanken an Security verschwenden; sendmail stammt noch aus einer Zeit vor Malware, Spam und Konsorten. Es ist unglaublich schwierig, Software nachträglich sicher zu bekommen, wenn man Security nicht von Anfang an berücksichtigt hat.

Den gibts ja jetzt ja schon ziemlich lang (wie lang eigentlich?), und grade in der UNIX Welt galten doch die Grundsätze "ein Auftrag, ein Tool" und "so simpel wie möglich" - wie konnte sendmail also so ins Hintertreffen geraten? Bereits große Anfangskomplexität?

Historisch gewachsen.

Normalerweise wurde Software über die Jahre doch eher besser - mittels Code-Audits, neue Programmier-Paradigmen etc?

Das wäre aber dann kein sendmail mehr. Manchmal hilft nur noch wegschmeißen und neumachen.

Ok, früher spielte Sicherheit in der Softwarewelt natürlich noch nicht die Rolle wie heute, aber trotzdem...

Als bei sendmail die Einsicht kam, hatte man schon einen Koloss geschaffen, den man nicht mehr bändigen konnte.

 

[Yamagi]

Ich habe vor langer Zeit auch größere Sendmail-Installationen betreut. Irgendwann sind sie dann aus gutem Grund verschwunden. Ich bin bei Exim hängen geblieben, was konzeptionell doch recht ähnlich ist. Andere sind weiter zu Postfix, was radikaler dem Unix-Prinzip folgt. Zur gleichen Zeit wurde auch Exchange groß, Microsoft war aber nie so wirklich meine Welt. Und zwischendurch gab es auch noch qmail.

Sendmail hat zwei grundlegende Probleme. Einmal ist Sendmail alt. Es kommt aus einer Zeit, als E-Mails noch per UUCP übertragen wurden und es den ganzen Themenbereich Sicherheit schlicht noch nicht gab. Sendmail ist nach dem "Jeder vertraut jedem"-Prinzip entwickelt worden und in der Folge steckt es so tief in der Architektur drin, dass es sich kaum mehr entfernen lässt. Das zweite Problem hängt eng damit zusammen. Wie viele alte Software ist Sendmail gewachsen. In den 1980ern war DEC ein bedeutender Spieler auf dem Mark professioneller IT, also baute man deren MAIL11-Protokolle ein. E-Mail zu Fax und umgekehrt war eine schöne Sache, also musste Sendmail FAX lernen. Irgendwann kam dann SMTP, später durch ESMTP erweitert. Und so weiter. In der Folge kann Sendmail wirklich alles.

Programme, die eine miese Architektur haben und alles können, sind meistens keine gute Sache. Im Fall von Sendmail äußerst sich das vor allem in der extrem komplexen (turingvollständigen!) Konfiguration. Sendmail zu konfigurieren nahm Ausmaße an, dass es selbst mit viel Einarbeitung kaum mehr möglich war, die Konfiguration zu verstehen. Daher kam man auf die wenig schöne Idee den selbst nicht unbedingt zugänglichen M4 Makroprozessor [0] daurmzutüdeln. Man konfiguriert also im Normalfall M4 mittels einer Art Script, welches dann die Senmail-Konfiguration generiert.

Das war dann auch mein Hauptproblem mit Sendmail. Und sicher auch das vieler anderer Admins: Es ist bei Sendmail extrem schwierig bis unmöglich zu überblicken, was man eigentlich genau konfiguriert hat. Sehr viele Sicherheitsprobleme von Sendmail waren dann auch nicht einmal Sendmail selbst. Es waren einfach unbeabsichtigt fehlerhafte Konfigurationen.

Trotzdem sehe ich in Sendmail im Basissystem kein Problem. Das Sendmail im Basissystem ist eine minimale Installation, die eh kaum mehr als lokale Zustellung und ein lokales Relay per Smarthost unterstützt. Außerdem läuft sie in Standardeinstellung im Submission Modus. Der Ressourcenbedarf ist nach heutigen Maßstäben vernachlässigbar. Wer nur lokale Mailzustellung will, kann es lassen, wie es ist und glücklich sein. Wer ein Sendmail für komplexere lokales Mailrouting will, hat ihn. Und alle anderen können einfach auf DMA umstellen oder einen MTA ihrer Wahl installieren. Dank Mailwrapper ist das System selbst MTA-agnostisch, oder anders gesagt, /usr/sbin/sendmail muss nicht Sendmail sein. Kurz um, es gibt wirklich wichtigere Probleme als Sendmail im FreeBSD Basisystem, über die man sich Gedanken machen kann.

https://en.wikipedia.org/wiki/M4_(computer_language)

 

[cabriofahrer]

Es gibt auf FreeBSD im Basissystem bereits den DMA (Dragonfly Mail Agent), der kann alles außer eingehendes SMTP.

Kurze Verständnisfrage: "Eingehendes SMTP"? Für den Eingang verwendet man doch normalerweise IMAP oder POP3 und SMTP ist für den Ausgang. Damit hätte DMA doch eigentlich alles, was man normalerweise braucht. Ist eingehendes SMTP also ein besonderes Feature von sendmail und bedeutet das, dass man dann für eingehende Mails gar keinen zusätzlichen IMAP oder POP3 Server mehr bräuchte?

 

[turrican]

IMAP und/oder POP3 benutzen (benutzten früher) die Clients, um auf den Server zuzugreifen und Mails abzuholen, bzw einzuliefern.

Server zu Server ist SMTP, und ich denke um das ging es hier bei @KobRheTilla

 

[mr44er]

Kurze Verständnisfrage: "Eingehendes SMTP"?

Aus Sicht des Servers. Wenn du Server spielst, brauchst du ein und ausgehend SMTP.

Dein Mailclient (mit gmail-Account) sendet ne E-Mail an postfachvomkumpel@gmx.de (ausgehend SMTP) -> (eingehend SMTP) gmail-Server (ausgehend SMTP) -> (eingehend SMTP) gmx-Server.

 

[Athaba]

SMTP sendet/empfängt mails. IMAP und POP sind Protokolle um remote auf den Mailspeicher (Datei, Verzeichnisstruktur, DB, etc.) zugreifen zu können. Also quasi FTP für Mails?

Fun Fact: Oftmals (quasi immer) gibt's sogar noch ein weiteres Protokoll am Server selbst, nämlich LMTP (Local Mail Transfer Protocol). Aber das wird wie der Name schon sagt lokal verwendet, also hat man da als Enduser nichts damit am Hut.

Soll heißen, wenn du Zugrift auf den Server hast als User, dann kannst du ja mail eingeben oder die Mail-Dir oder Datei ja selbst lesen. Mutt macht das auch, oder sogar Thunderbird gab's das mal (auch wenn ich es jetzt nicht finde), dass du die Mails von der MAIL-Umgebungsvariable bekommst.

Mit Incoming/Outgoing ist in dem Fall der Umstand gemeint, dass du ja wenn du eine E-Mail abschickst die zuerst an deinen Server sendest, der sie dann weiter an einen anderen Server sendet.

Jedenfalls würden Mails ohne IMAP und POP immer noch funktionieren. Und wenn man zum Beispiel immer über Webmail auf die eigenen Mails zugreift, dann kann es sogar sein, dass es in einem Setup garnicht vorkommt. Zumindest, wenn das Webmail tatsächlich auf dem selben Server wie die Mails selbst liegt.

 

[Andy_m4]

Soll heißen, wenn du Zugrift auf den Server hast als User, dann kannst du ja mail eingeben oder die Mail-Dir oder Datei ja selbst lesen.

Mein Reden schon seit Jahren. Mehr als cat und ggf. less braucht man gar nicht als Mailclient. :-)

 

[Rosendoktor]

Mein Reden schon seit Jahren. Mehr als cat und ggf. less braucht man gar nicht als Mailclient. :-)

Und überhaupt, Mails verschickt man mit Telnet!

 

[Athaba]

Und überhaupt, Mails verschickt man mit Telnet!

Niemals! openssl s_client

Aber im Ernst. Es ging darum dass das zum Beispiel Formate ist indem E-Mails abgespeichert werden und IMAP und POP Zugriff drauf bieten und nicht den eigentlichen Mailverkehr machen.

 

[double-p]

Mein Reden schon seit Jahren. Mehr als cat und ggf. less braucht man gar nicht als Mailclient. :-)

Viel Spass mit UTF-8, MIME-attachments usw.. im Prinzip passt das schon, aber das ist nicht so wirklich das Thema.

in4b: ich setze postfix seit 1998 ein - aber hatte auch bis 2015 noch "spezialisierte" sendmail Instanzen.
Diese mit Hilfe von einem, der lange bei sendmail Inc unter Vertrag stand und die ersten GMX Installationen administriert hat.

sendmail-is-not-for-kids.. Auf der EuroBSDCon in Lillehammer gab es auch einen adhoc Vortrag von Eric Allman wie und wieso
sich sendmail so schlecht entwickelt hat und auch er postfix als wirklich gut findet.
Am Abend gab es gut Rotwein und Eric war auch da absolut am Thema "better use something modern".

 

[pchris]

[...]
Dann musst Du noch dma als neuen Mailer einsetzen:

/etc/rc.conf:

dma_enable="YES"

/etc/mail/mailer.conf:

sendmail        /usr/libexec/dma
send-mail       /usr/libexec/dma
mailq           /usr/libexec/dma

Ich habe deine Hinweise heute verwendet, um auf meinen beiden Computern den MTA auszutauschen.

Aber warum schreibst du "dma_enable="YES"" in /etc/rc.conf? Ich habe dazu kein passendes rc-Skript gefunden. In meinem Setup läuft es auch so.

Und für die Datei /etc/mail/mailer.conf gibt es auch eine Vorlage in /usr/share/examples/dma/mailer.conf. Kann einfach kopiert werden und funktioniert.

 

[Andy_m4]

Aber warum schreibst du "dma_enable="YES"" in /etc/rc.conf? Ich habe dazu kein passendes rc-Skript gefunden. In meinem Setup läuft es auch so.

Du hast völlig recht.
Das war ein Fehler meinerseits.

 

[pchris]

Was mir beim Einrichten auch noch aufgefallen ist: Die Datei /etc/dma/auth.conf muss für dma (/usr/libexec/dma mit setgid) lesbar sein. Daher ist es sinnvoll folgende Besitz- und Zugriffrechte zu vergeben:

-rw-r-----  1 root  mail    65 Jan  4 11:29 auth.conf
-rw-r--r--  1 root  mail  2239 Jan  4 11:30 dma.conf

Vielleicht hilft das jemandem in Zukunft.

 

[Arne]

Ohne ein altes Pferd aufwärmen zu wollen, Google hat mich gerade darauf gestoßen:

Hier gibt es noch einen ausführlichen Vergleich der unterschiedlichen MTAs: Postfix vs. Sendmail vs. Exim

Spoiler: Fazit des Vergleichs

sendmail verliert in jeder relevanten Disziplin.

Das ist nicht ganz korrekt wiedergegeben. Für Sendmail spricht, was auch in dem verlinkten Artikel herauskommt, die Punkte Flexibilität und Konfigurationsmöglichkeiten.

Es gibt Probleme, die mit Sendmail erheblich einfacher gelöst werden können als mit Postfix oder nur mit Sendmail gelöst werden können was aber dann auf Schreiben entsprechender cf Rulesets hinausläuft und damit sicher out of scope für Otto-Normal Anwender ist.
Derartige Probleme treten aber glücklicherweise auch nur bei recht extremen Anwendungsszenarien auf.

Sendmail ist overkill als Default MTA, hat aber seinen Platz in seiner Nische, weswegen er nicht verdammt werden sollte.

Was das Wording angeht, dass so mancher auch hier gegen sendmail zu Felde führt. Man sollte nicht vergessen, dass das schnell für uns BSDler persönlich wird wenn man sich anschaut, mit wem der Autor von Sendmail verheiratet ist.

 

[KobRheTilla]

Es gibt Probleme, die mit Sendmail erheblich einfacher gelöst werden können als mit Postfix oder nur mit Sendmail gelöst werden können

Kannst du ein Beispiel nennen?

Rob

 

[double-p]

Kannst du ein Beispiel nennen?

/etc/mail/submit.mc

define(`confRECEIVED_HEADER',`id $i; $b')
define(`confMESSAGEID_HEADER', `<$t.$i@$M>')dnl
define(`confFROM_HEADER', `<$g>')dnl
MASQUERADE_AS(`example.com')dnl
FEATURE(masquerade_envelope)dnl

... ich muss weg

 

[medV2]

uff, da muss ne Triggerwarnung her, ich bekomm schon ptsd wenn ich das nur sehe...

 

[double-p]

Wenn der Blutdruckberg durch ist.. das ist in erster Linie um "interne" hostnames - speziell in den Received: lines zu unterdruecken.
Postfix mag so eine Protokollviolation garnicht; auch wenn man es natuerlich reingehackt bekommt. Aber hey, in sendmail brauche ich nur 3 ganz einfache m4 Zeilen!