Hallöle,
ich hab heute das HIER gelesen. Ich weiss der Artikel ist schon was älter, aber trifft das heute auch noch zu? Würden die Kollegen heute immer noch sowas bauen oder kann Exim/Postfix das mittlerweile alles was dort gefordert wurde?
Und die evtl wichtigste Frage ist, warum hat man nicht an Exim/Postfix rumgeschraubt? Ist ja immerhin OpenSource.
Das ganze nur mal so aus neugier, danke vorab!
eigenene Mailer programmieren, noch sinnvoll?
eigenene Mailer programmieren, noch sinnvoll?
Debian-Nutzer
ZABBIX Certified Specialist
ZABBIX Certified Specialist
- Blackbox
- Beiträge: 4289
- Registriert: 17.09.2008 17:01:20
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: eigenene Mailer programmieren, noch sinnvoll?
Ich denke nicht, dass es einen noch einen MTA braucht.
Besser wäre wahrscheinlich, die bestehenden MTA um nützliche Funktionen zu erweitern, wenn möglich.
Besser wäre wahrscheinlich, die bestehenden MTA um nützliche Funktionen zu erweitern, wenn möglich.
Eigenbau PC: Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Desktop PC: Dell Inspiron 530 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Notebook: TUXEDO BU1406 - Debian Sid - Kernel: 6.5.13 - Xfce 4.18 mit sway
Alles Minimalinstallationen und ohne sudo/PA/PW.
Rootserver: Rocky Linux 9.3 - Kernel: 5.14
Freie Software unterstützen, Grundrechte stärken!
Re: eigenene Mailer programmieren, noch sinnvoll?
Ist vermutlich immer eine Budget Frage bzw Einstellung der Entwickler.
Angenommen die brauchten halt Feature X und sie sahen, das gibts in exim, postfix und co nicht. Naja dann kann ich entweder anfangen das feature in der bestehenden Software zu implementieren oder eben neu schreiben.
Die Hindernisse bei ersterem sind wohl, dass nicht sicher ist, ob meine Änderungen upstream angenommen werden - ansonsten hast du halt deinen fork den du managen musst.
Dann kommt da wohl auch hinzu wie gut der code geschrieben ist und ob man diese Änderungen einfach einbauen kann oder erstmal die ganze Kernarchitektur auf den Kopf gestellt werden muss.
Das Problem beim zweiten ist wohl ganz klar, dass manche Dinge eben nicht ganz trivial sind (Mail ist sicherlich sowas) und man da echt viel testen muss, um ein system zu bauen was funktioniert.
Allerdings kann es sicherlich sinnvoll sein, was neu zu schreiben, insbesondere wenn die upstream software nicht so toll managebar ist... (keine ahnung wie das für exim/postfix ausschaut).
Andererseits gibts halt auch immer Entwickler die meinen es geht besser wie sie das wollen und sträuben sich einfach aus purem egoismus gegen ein bestehendes Produkt
Der Artikel verrät leider nicht die genauen Beweggründe.
Von der Arbeitszeit kann wohl beides genau so lang dauern...
In dem Zusammenhang spannend wäre auch ob jemand weiß was Google für Gmail einsetzt. Meine Vermutung wäre, die haben auch selber ne Lösung gebaut.
Angenommen die brauchten halt Feature X und sie sahen, das gibts in exim, postfix und co nicht. Naja dann kann ich entweder anfangen das feature in der bestehenden Software zu implementieren oder eben neu schreiben.
Die Hindernisse bei ersterem sind wohl, dass nicht sicher ist, ob meine Änderungen upstream angenommen werden - ansonsten hast du halt deinen fork den du managen musst.
Dann kommt da wohl auch hinzu wie gut der code geschrieben ist und ob man diese Änderungen einfach einbauen kann oder erstmal die ganze Kernarchitektur auf den Kopf gestellt werden muss.
Das Problem beim zweiten ist wohl ganz klar, dass manche Dinge eben nicht ganz trivial sind (Mail ist sicherlich sowas) und man da echt viel testen muss, um ein system zu bauen was funktioniert.
Allerdings kann es sicherlich sinnvoll sein, was neu zu schreiben, insbesondere wenn die upstream software nicht so toll managebar ist... (keine ahnung wie das für exim/postfix ausschaut).
Andererseits gibts halt auch immer Entwickler die meinen es geht besser wie sie das wollen und sträuben sich einfach aus purem egoismus gegen ein bestehendes Produkt
Der Artikel verrät leider nicht die genauen Beweggründe.
Von der Arbeitszeit kann wohl beides genau so lang dauern...
In dem Zusammenhang spannend wäre auch ob jemand weiß was Google für Gmail einsetzt. Meine Vermutung wäre, die haben auch selber ne Lösung gebaut.
Re: eigenene Mailer programmieren, noch sinnvoll?
Hast Du mal in den Code von Exim und Postfix reingelesen? Mach das mal, vielleicht klärt sich die Frage dann von selbstColttt hat geschrieben:06.08.2019 15:52:34Und die evtl wichtigste Frage ist, warum hat man nicht an Exim/Postfix rumgeschraubt? Ist ja immerhin OpenSource.
Re: eigenene Mailer programmieren, noch sinnvoll?
naja da steht doch am Anfang:Der Artikel verrät leider nicht die genauen Beweggründe.
Punkt 2,3,5 sollten die heute alle haben,
- Kernkomponente ist ein Mailstore-Cluster, der seine Ressourcen selbstständig verteilt, also gut ausnutzt
- Ausfallsicherheit durch Redundanz
- Lauffähig auf üblicher Hardware
- Datenschnittstelle zur hauseigenen Statistiksoftware
- Antiviren- und Antispam-API
- TKÜV-Schnittstelle (konzernweit rund 50 Überwachungsanfragen pro Jahr).
Punkt 4, 6 kommt halt drauf an was man da genau haben möchte
Punkt 1 wäre noch recht interessant wie das umgesetzt worden ist
Debian-Nutzer
ZABBIX Certified Specialist
ZABBIX Certified Specialist
Re: eigenene Mailer programmieren, noch sinnvoll?
Ja jein. Die Features die sie haben wollen legen sie offen, aber ich meinte eigentlich sie sagen nicht warum sie nicht ein bestehendes Produkt angepasst haben.Colttt hat geschrieben:07.08.2019 09:02:14naja da steht doch am Anfang:Der Artikel verrät leider nicht die genauen Beweggründe.
Re: eigenene Mailer programmieren, noch sinnvoll?
Das Mail-Thema ist komplex und sicherheitskritisch. Das macht man nicht mal nebenher.
Man muss sich schon gut ueberlegen, ob man einen MTA schreiben will. Insbesondere sollte man einen eigenen MTA nur dann schreiben, wenn man die wichtigen MTAs (Postfix, Sendmail, qmail, Exim und Opensmtpd) analysiert hat. Einen eigenen MTA zu schreiben, um sich nicht in andere MTAs einarbeiten zu muessen ist IMO das Gegenteil der Realitaet. Wenn man einen eigenen MTA schreiben will (der besser sein soll), dann wird man mehr ueber die anderen MTAs lernen muessen als wenn man einen von ihnen verbessern will!
MTAs fuer Mailserver (im Gegensatz zu MTAs auf Workstations) sind heute mehr sowas wie Mailframeworks fuer Lastmanagement und Pluginschnittstellen. Das hat sich veraendert. Insofern ist die Frage, was man den schaffen will: Ein besseres Framework oder bessere Plugins? Einen neuen MTA (d.h. das Framework) zu schreiben koennte sich deshalb lohnen, weil die meisten MTAs noch aus einer Zeit kommen, wo das Mailsystem dezentraler, weniger angegriffen und insgesamt kleiner war. Ich koennte mir vorstellen, dass diese MTAs manche neuen Anforderungen nicht so gut umsetzen und dass man grundlegende Designentscheidungen eben nicht nachtraeglich drueberlegen kann. (Opensmtpd ist eine Neuentwicklung. Leider weiss ich nicht mehr darueber.)
Ich habe den kleinen MTA Masqmail (10.000 SLOC) 2008 uebernommen, eine Zeitlang aktiv entwickelt und dann noch 'ne Weile gepflegt. So kleine MTA-Projekte koennen in der heutigen Mailwelt IMO nicht mehr bestehen (ausser als lokale MTAs auf Workstations oder im geschuetzten Heimnetz).
Edit: Nachdem ich den Artikel kurz ueberflogen habe, sehe ich darin meine oben beschriebene Einschaetzung fuer die Gruende einer Neuentwicklung (geaenderte Anforderungen, die das Grunddesign betreffen) bestaetigt.
Man muss sich schon gut ueberlegen, ob man einen MTA schreiben will. Insbesondere sollte man einen eigenen MTA nur dann schreiben, wenn man die wichtigen MTAs (Postfix, Sendmail, qmail, Exim und Opensmtpd) analysiert hat. Einen eigenen MTA zu schreiben, um sich nicht in andere MTAs einarbeiten zu muessen ist IMO das Gegenteil der Realitaet. Wenn man einen eigenen MTA schreiben will (der besser sein soll), dann wird man mehr ueber die anderen MTAs lernen muessen als wenn man einen von ihnen verbessern will!
MTAs fuer Mailserver (im Gegensatz zu MTAs auf Workstations) sind heute mehr sowas wie Mailframeworks fuer Lastmanagement und Pluginschnittstellen. Das hat sich veraendert. Insofern ist die Frage, was man den schaffen will: Ein besseres Framework oder bessere Plugins? Einen neuen MTA (d.h. das Framework) zu schreiben koennte sich deshalb lohnen, weil die meisten MTAs noch aus einer Zeit kommen, wo das Mailsystem dezentraler, weniger angegriffen und insgesamt kleiner war. Ich koennte mir vorstellen, dass diese MTAs manche neuen Anforderungen nicht so gut umsetzen und dass man grundlegende Designentscheidungen eben nicht nachtraeglich drueberlegen kann. (Opensmtpd ist eine Neuentwicklung. Leider weiss ich nicht mehr darueber.)
Ich habe den kleinen MTA Masqmail (10.000 SLOC) 2008 uebernommen, eine Zeitlang aktiv entwickelt und dann noch 'ne Weile gepflegt. So kleine MTA-Projekte koennen in der heutigen Mailwelt IMO nicht mehr bestehen (ausser als lokale MTAs auf Workstations oder im geschuetzten Heimnetz).
Edit: Nachdem ich den Artikel kurz ueberflogen habe, sehe ich darin meine oben beschriebene Einschaetzung fuer die Gruende einer Neuentwicklung (geaenderte Anforderungen, die das Grunddesign betreffen) bestaetigt.
Use ed once in a while!