staging.inyokaproject.org

Ein neues AOSP enthält kaum mehr Apps als ein Featurephone. Mit F-Droid kann man aber viele Funktionen nachrüsten. Die App-Qualität schwankt von Herausragend bis zu Brauchbar und es gibt viele nicht gepflegte Apps im Store. Die folgende Liste kann also eine kleine Orientierungshilfe für den Anfang geben.

Die Liste entspricht weder dem Anspruch perfekt, noch vollständig zu sein, sondern spiegelt nur wieder was ich mir so auf meinem Android Gerät installiere bzw. wo ich die Basis von LineageOS nutze.

Für vieles andere wie Kalender, Kontakte, Dateien, Galerie, Musik, Rechner, Rekorder usw. reichen mir die vorinstallierten Apps aus LineageOS.

Ist diese Liste perfekt und deckt alle Bedürfnisse ab? Leider nein! Eine Reihe Apps muss direkt aus dem Play Store (oder eine freie Implementierung wie Aurora) bezogen werden. Bei mir sind das:

Je nach Anwendungsszenario reicht das bereits. Mir persönlich fehlen keine essenziellen Apps, aber ich würde mir natürlich wünschen, dass die 6 Apps in der unteren Tabelle langfristig weniger werden.

Das Jahr 2020 war schon ein paar Wochen alt, als ich verkündete, was euch 2020 hier erwartet. Ich glaube, ich habe mich an den Ausblick gehalten.

Das Jahr fing ruhig an, bevor es unser aller Leben radikal veränderte. War mein Berufsleben2019 noch vom Pendeln zur Dienststelle und zurück geprägt, hat die Pandemie auch meinen Arbeitsplatz radikal verändert. Seit Mitte März arbeite ich konsequent im heimischen Arbeitszimmer. Seither habe ich screen in den Ruhestand entlassen und arbeite konsequent mit tmux und xpanes.

Ich habe lange über die Anschaffung eines elektrisch höhenverstellbaren Schreibtischs für mein Arbeitszimmer nachgedacht, bevor ich knapp 5 Monate später einen solchen mein Eigen nannte. Ich denke, dies war in diesem Jahr meine sinnvollste Anschaffung.

Auch die berufliche Kommunikation hat sich stark verändert; in meinen Augen jedoch weder zum Positiven noch zum Negativen. Bisher bin ich im Home-Office sehr zufrieden. Eine Rückkehr in die Dienststelle kann ich mir aktuell hingegen nicht vorstellen.

Mitte des Jahres durfte ich mit einem Team rund um Mohit Goyal (Senior Principal Product Manager, Red Hat) zusammen arbeiten und habe Red Hat Insights unter die Lupe genommen. Dabei herausgekommen ist unter anderem folgende Artikelserie:

1. Einführung in Red Hat Insights
2. Erkundung von Red Hat Insights — Advisor
3. Schwachstellen-Management mit Red Hat Insights
4. Red Hat Insights – Compliance
5. Red Hat Insights – Patch and Drift
6. Persönliche Bewertung von Red Hat Insights

In der Kategorie Ansible gab es hingegen nicht so viel Neues. Ich habe in diesem Jahr eher ein wenig Projektpflege beim Spiegelserver für arme Admins und dem Patchmanagement für RHEL betrieben.

Zusammen mit einem Kollegen habe ich noch ein Tutorial zur Nutzung des DNS-Alias-Modus mit dem acme.sh-Client geschrieben. Wir haben einiges an positiven Rückmeldungen dafür bekommen, was mich persönlich sehr gefreut hat.

Wie an den Artikeln zu erkennen ist, lag der Fokus in diesem Jahr auf Technologien und Produkten von Red Hat. Dies wird sich in 2021 vermutlich in Teilen fortsetzen. Vermutlich wird hier dann vermehrt etwas zu Linux-Containern zu lesen sein, mit denen ich mich etwas ausführlicher beschäftigen möchte.

Darüber hinaus plane ich die Einführung einer neuen Kategorie, deren Name noch nicht feststeht. In dieser möchte ich technische Sachverhalte möglichst einfach erklären, so dass auch Menschen ohne IT-Ausbildung verstehen können, wie das Internet und unsere digitale Welt funktionieren.

Ich wünsche euch allen einen guten Rutsch ins Jahr 2021!

Mozillas neuester Dienst hört auf den Namen Firefox Relay und schützt die persönliche E-Mail-Adresse vor Spam und unerwünschter Offenlegung. Firefox Relay hat mittlerweile die Beta-Phase verlassen.

Firefox Relay ist ein neuer Dienst von Mozilla. Seit dem Start der geschlossenen Beta-Phase im Sommer sowie der offenen Beta-Phase im August wurden viele Verbesserungen vorgenommen und Probleme behoben. In diesem Monat hat Firefox Relay die Beta-Phase verlassen und zählt damit als offizielles Produkt von Mozilla, welches jetzt auch über die Navigation der offiziellen Mozilla-Website erreichbar ist.

Was ist Firefox Relay?

E-Mail-Adressen sind gleichzusetzen mit einer persönlichen Adresse. Sie sind einmalig und viele Nutzer besitzen nur eine einzige E-Mail-Adresse, die sie teilweise auf dutzenden, wenn nicht gar auf hunderten Websites verwenden. Findet auf einer Website, auf der man mit seiner E-Mail-Adresse registriert ist, ein Datendiebstahl statt, wird damit in vielen Fällen auch die persönliche E-Mail-Adresse offengelegt. Und haben Spammer erstmal eine E-Mail-Adresse in ihrem System, darf man sich auf viele unerwünschte E-Mails ohne realistische Hoffnung einstellen, dass der Spam abnehmen wird.

Mit Firefox Relay können Alias-Adressen angelegt werden, die der Nutzer für Newsletter-Anmeldungen und Website-Registrierungen angeben kann. Firefox Relay leitet diese E-Mails dann an die persönliche E-Mail-Adresse weiter. Wird ein Alias nicht mehr benötigt, kann dieser ganz einfach temporär deaktiviert oder komplett gelöscht werden.

Mittels Firefox-Erweiterung können in Online-Formularen ganz einfach bei Bedarf neue Alias-Adressen angelegt werden, ohne dass hierfür zunächst die Weboberfläche von Firefox Relay aufgesucht werden muss.

Verfügbarkeit und Kosten von Firefox Relay

Firefox Relay steht derzeit nur in englischer Sprache, dafür aber überall in der Welt zur Verfügung. Die Nutzung von Firefox Relay ist aktuell für alle Nutzer kostenlos.

Der Beitrag Firefox Relay verlässt Beta-Phase erschien zuerst auf soeren-hentzschel.at.

Linux und die Idee der freien Software sind eng verwoben. Proprietäre Software kann zwar theoretisch für Linux vertrieben werden, das ideologische Umfeld und die geringe Verbreitung haben hier aber kein großes Ökosystem entstehen lassen. Drei prominente Ausnahmen möchte ich hier kurz vorstellen. Im dritten Teil: Master PDF Editor

PDFs sind der Quasi-Standard für den Austausch von Dokumenten, die nicht zur Bearbeitung vorgesehen sind. Manchmal muss man die Dokumente dennoch manipulieren oder aber die PDFs enthalten Funktionen über den Standard hinaus. In solchen Fällen benötigt man einen leistungsstarken Editor. In der Windows-Welt gibt es dazu den Standard Adobe Acrobat Pro und viele kleinere Projekte. Bei macOS hat sich PDF Expert weitestgehend durchgesetzt, wenn Anwender Funktionen über die integrierte Vorschau hinaus suchen.

Master PDF Editor

Keine Alternativen

PDF-Betrachter gibt es für Linux wie Sand am Meer. Dabei handelt es sich nahezu ausnahmslos um grafische Aufsätze auf die verbreitete Poppler-Bibliothek. Hinzu kommen dann noch graduelle Unterschiede, was zusätzlich noch unterstützt wird. Manche erlauben sogenannte Annoationen, andere nicht. Diese Betrachter bieten aber strukturell bedingt keine Funktionen über die Poppler-Bibliothek hinaus. Damit lassen sich vermutlich 95% der im Umlauf befindlichen PDFs fehlerfrei betrachten, aber mehr eben auch nicht.

Wenn man PDFs manipulieren möchte, muss man auf andere Werkzeuge ausweichen und landet schnell bei Kommandozeilenwerkzeugen wie PDFtk. Damit lässt sich viel anstellen aber der Wechsel zwischen unterschiedlichen Werkzeugen für ein PDF passt nicht in den Arbeitsablauf eines jeden. Als integrierte Lösung (die zudem noch sehr gut mit den proprietären Erweiterungen von Adobe funktioniert) gibt es nur den Master PDF Editor.

Master PDF Editor – kurz vorgestellt

Code Industry Ltd. ist eine russische Firma. Den Master PDF Editor gibt es für Windows, macOS und Linux. Zum Download stehen Pakete für Ubuntu (DEB) und CentOS/RHEL (RPM). Diese Pakete lassen sich natürlich auch mit anderen Distributionen nutzen, die mit diesen Paketformaten arbeiten. Arch Linux und seine Abkömmlinge werden über das AUR versorgt und es existiert auch noch eine gepflegte Version auf FlatHub. Die Installation sollte also mit jeder noch so abwegigen Linux-Variante möglich sein.

Der Master PDF Editor greift auf Qt 5 zurück und integriert sich dadurch sehr gut in KDE Plasma, aber die Darstellung in GTK-basierten Desktopumgebungen ist auch vollkommen akzeptabel – wie bei anderen Qt Programmen eben auch.

Die freie Version hat zwar viele Möglichkeiten, fügt aber ein Wasserzeichen ein. Deshalb werden die meisten nicht umhinkommen eine Lizenz zu erwerben. Diese kostet etwas weniger als 70 €. Aktuell sind es gerade 66,31 € wegen der reduzierten Mehrwertsteuer. Das ist für einen so mächtigen PDF Editor ein absolut annehmbarer Preis.

Was der Master PDF Editor?

Ich habe schon vor Corona meine Arbeitsweise digitalisiert. Meine persönliche Bibliothek für die Doktorarbeit umfasst gegenwärtig 1287 PDF-Dateien mit Texten – vom Aufsatz bis zur Monografie. Diese müssen beim Eingang bearbeitet werden, weil Doppelscans oder nicht benötigte Teile entfernt werden müssen und die Texte eine OCR Schicht bekommen. Das kann man alles mit freien Werkzeugen erledigen, aber ich habe in meiner macOS-Zeit die Vorzüge mächtiger und funktionaler grafischer Lösungen schätzen gelernt. Deshalb nutze ich dafür den hier vorgestellten Editor.

Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay  

Der Artikel Proprietäre Softwareperlen für Linux Teil III: Master PDF Editor erschien zuerst auf [Mer]Curius

Linux und die Idee der freien Software sind eng verwoben. Proprietäre Software kann zwar theoretisch für Linux vertrieben werden, das ideologische Umfeld und die geringe Verbreitung haben hier aber kein großes Ökosystem entstehen lassen. Drei prominente Ausnahmen möchte ich hier kurz vorstellen. Im dritten Teil: Master PDF Editor

PDFs sind der Quasi-Standard für den Austausch von Dokumenten, die nicht zur Bearbeitung vorgesehen sind. Manchmal muss man die Dokumente dennoch manipulieren oder aber die PDFs enthalten Funktionen über den Standard hinaus. In solchen Fällen benötigt man einen leistungsstarken Editor. In der Windows-Welt gibt es dazu den Standard Adobe Acrobat Pro und viele kleinere Projekte. Bei macOS hat sich PDF Expert weitestgehend durchgesetzt, wenn Anwender Funktionen über die integrierte Vorschau hinaus suchen.

Master PDF Editor

Keine Alternativen

PDF-Betrachter gibt es für Linux wie Sand am Meer. Dabei handelt es sich nahezu ausnahmslos um grafische Aufsätze auf die verbreitete Poppler-Bibliothek. Hinzu kommen dann noch graduelle Unterschiede, was zusätzlich noch unterstützt wird. Manche erlauben sogenannte Annoationen, andere nicht. Diese Betrachter bieten aber strukturell bedingt keine Funktionen über die Poppler-Bibliothek hinaus. Damit lassen sich vermutlich 95% der im Umlauf befindlichen PDFs fehlerfrei betrachten, aber mehr eben auch nicht.

Wenn man PDFs manipulieren möchte, muss man auf andere Werkzeuge ausweichen und landet schnell bei Kommandozeilenwerkzeugen wie PDFtk. Damit lässt sich viel anstellen aber der Wechsel zwischen unterschiedlichen Werkzeugen für ein PDF passt nicht in den Arbeitsablauf eines jeden. Als integrierte Lösung (die zudem noch sehr gut mit den proprietären Erweiterungen von Adobe funktioniert) gibt es nur den Master PDF Editor.

Master PDF Editor - kurz vorgestellt

Code Industry Ltd. ist eine russische Firma. Den Master PDF Editor gibt es für Windows, macOS und Linux. Zum Download stehen Pakete für Ubuntu (DEB) und CentOS/RHEL (RPM). Diese Pakete lassen sich natürlich auch mit anderen Distributionen nutzen, die mit diesen Paketformaten arbeiten. Arch Linux und seine Abkömmlinge werden über das AUR versorgt und es existiert auch noch eine gepflegte Version auf FlatHub. Die Installation sollte also mit jeder noch so abwegigen Linux-Variante möglich sein.

Der Master PDF Editor greift auf Qt 5 zurück und integriert sich dadurch sehr gut in KDE Plasma, aber die Darstellung in GTK-basierten Desktopumgebungen ist auch vollkommen akzeptabel - wie bei anderen Qt Programmen eben auch.

Die freie Version hat zwar viele Möglichkeiten, fügt aber ein Wasserzeichen ein. Deshalb werden die meisten nicht umhinkommen eine Lizenz zu erwerben. Diese kostet etwas weniger als 70 €. Aktuell sind es gerade 66,31 € wegen der reduzierten Mehrwertsteuer. Das ist für einen so mächtigen PDF Editor ein absolut annehmbarer Preis.

Was der Master PDF Editor?

Ich habe schon vor Corona meine Arbeitsweise digitalisiert. Meine persönliche Bibliothek für die Doktorarbeit umfasst gegenwärtig 1287 PDF-Dateien mit Texten - vom Aufsatz bis zur Monografie. Diese müssen beim Eingang bearbeitet werden, weil Doppelscans oder nicht benötigte Teile entfernt werden müssen und die Texte eine OCR Schicht bekommen. Das kann man alles mit freien Werkzeugen erledigen, aber ich habe in meiner macOS-Zeit die Vorzüge mächtiger und funktionaler grafischer Lösungen schätzen gelernt. Deshalb nutze ich dafür den hier vorgestellten Editor.

Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay  

… was ist das eigentlich? Und wie wirkt sich die Nutzung für den einzelnen Nutzer oder eine Organisation wie ein Unternehmen oder eine Behörde aus? Zu diesen Fragen mache ich mir in diesem Beitrag ein paar Gedanken, die ich gern mit euch diskutieren möchte.

Die Antwort auf die erste Frage fällt mir dabei noch leicht. Freie Software bzw. Open Source Software (FLOSS) sind Anwendungen, die unter einer freien bzw. freizügigen Lizenz stehen. Dabei orientiere ich mich an den Debian-Richtlinien für Freie Software (DFSG), welche u. a. bestimmen:

1. Die Software darf uneingeschränkt weitergegeben oder verkauft werden.
2. Der Quelltext der Software muss offen und für jeden frei zugänglich sein. Eine Weitergabe der Software muss sowohl als Quelltext als auch in kompilierter Form erlaubt sein.
3. Es muss erlaubt sein, die Software zu untersuchen, zu ändern, zu erweitern und unter den gleichen Lizenzbedingungen wie die Original-Software weiterzugeben.
4. Die Lizenz darf keine Person oder Gruppe von Personen diskriminieren.
5. Die Lizenz darf keine Einschränkungen hinsichtlich des Einsatzbereichs vornehmen. Beispielsweise darf sie nicht verhindern, dass das Programm geschäftlich oder für genetische Forschungen verwendet wird.

Was habe ich als (privater) Nutzer davon?

Auch wenn es schön ist, den Quelltext bei Interesse studieren zu können, glaube ich persönlich nicht, dass viele Nutzer von dieser Möglichkeit Gebrauch machen. Und wenn doch, haben sie den Text vermutlich schnell wieder von ihrem Bildschirm verbannt.

Nun sind viele FLOSS-Anwendungen kostenlos erhältlich und nutzbar. Und obwohl ich die Geiz-ist-geil-Mentalität nicht mag, ist dies für den Anwender tatsächlich ein großer Vorteil.

Zu meinen Schul- und Ausbildungszeiten kostete professionelle und oftmals proprietäre Bürosoftware verdammt viel Geld. Teilweise waren dies mehrere hundert DM bzw. EUR. Und dafür durfte man die entsprechenden Anwendungen nur auf einem einzigen PC installieren. Nun hatte ich damals weder die Bereitschaft noch die Mittel, so viel Geld für ein Office-Paket aufzubringen, von dessen Funktionsumfang ich nur einen Bruchteil benötigte und nutzen würde.

Daher war ich hoch erfreut, dass es OpenOffice gab. Entstanden aus den offengelegten Quelltexten von StarOffice bot sich mir hiermit die Möglichkeit, meine Briefe, Aufsätze, Tabellen und Präsentationen zu gestalten, ohne mich dafür in Unkosten zu stürzen. Zugegeben sahen die Präsentationsvorlagen damals schon wie Tapeten aus den siebziger Jahren aus. Aber die proprietären Alternativen waren damals nicht viel besser.

Viele unter euch kennen sicherlich die Überraschungen, die man erleben kann, wenn man Text- und Tabellen-Dokumente zwischen freien und proprietären Office-Suiten austauscht. Aber glaubt mir, diese Problemchen sind nicht mit denen vergleichbar, als ich meinem Lehrer den Aufsatz, verfasst auf einem C64, auf einer 5,25-Zoll-Diskette überreicht habe. Zum Glück hatte ich noch die auf Endlospapier gedruckte Fassung dabei, erstellt auf einem 9-Düsen-Tintenstrahl-Drucker, welche mir die Note rettete.

Ein ärgerliches Problem jedoch bleibt. Es nützt dem Bürger nichts, wenn seine mit freier Software erstellten Dokumente von Behörden nicht angenommen bzw. verarbeitet werden können. Genauso doof ist die Situation anders herum. Wenn man von Behörden Dateien übermittelt bekommt, welche sich nur mit der proprietären Software anzeigen lassen, mit der sie erstellt wurden. Hier ist in den letzten zwanzig Jahren schon vieles besser und einfacher geworden. Und als Optimist glaube ich daran, so lange zu leben, dass ich noch erleben werde, dass es noch besser wird.

Habt ihr ähnliche Erfahrungen gemacht? Wie seht ihr die Situation heute?

Mit den Jahren hat sich die Situation bei der Bürosoftware geändert. So gab es zwischenzeitlich für private Nutzung und für Schüler/Studenten eine proprietäre Office-Suite für 99 EUR, welche gleichzeitig auf bis zu drei Geräten installiert und genutzt werden durfte. Hier stimmt für meinen Geschmack das Preis-Leistungsverhältnis. Nur war diese Software nicht für mein Betriebssystem erhältlich und kam somit nicht in Frage. Ich glaube jedoch bis heute, dass es entsprechende Angebote nicht gegeben hätte, ohne dass freie Alternativen verfügbar gewesen wären und es heute noch sind.

Ein weiteres Beispiel für FLOSS ist die in diesem Beitrag schon für einige Links verwendete Wikipedia. Früher hatte man vielleicht ein Lexikon oder den Brockhaus daheim. Wobei letzterer sogar eine echte Geldanlage war. Das Wissen in den Büchern verstaubte, wie die Bücher selbst auch. Heute haben dank Wikipedia sehr viele Menschen dieser Welt freien Zugang zu nahezu unbegrenztem Wissen. Ich finde dies großartig.

Ich schrieb eingangs, dass ich kein Freund der Geiz-ist-geil-Mentalität bin. Dies liegt in der Annahme begründet, dass gute Software nicht nur in der Freizeit von Entwicklern zwischen 22:00-23:50 Uhr entsteht. Wenn viele Entwickler gute Anwendungen programmieren, sollten sie dafür auch bezahlt werden. Doch scheint es wider der Natur des Menschen zu sein, für eine Leistung zu bezahlen, die er auch kostenlos erhalten kann. Dies missfällt mir und ich habe beschlossen, da nicht mitzumachen.

Ich selbst bin mittleren Alters, habe Familie, stehe mitten im Berufsleben und beziehe ein Einkommen, welches meiner Familie und mir ein gutes Auskommen ermöglicht. Und ich habe beschlossen, einen kleinen unbedeutenden Teil meines Einkommens für FLOSS-Projekte zu spenden.

Dabei überlege ich mir einmal im Jahr, welchen Betrag ich insgesamt spenden möchte und welche Anwendungen oder Projekte ich besonders häufig genutzt habe; bzw. welche Anwendungen/Projekte mir besonders wichtig waren. Anschließend entscheide ich, wie ich den von mir festgelegten Betrag aufteile und überweise die einzelnen Summen. Mir ist bewusst, dass der gespendete Betrag nichtmal einem Monatsgehalt eines professionellen Software-Entwicklers entspricht. Doch ich denke, Kleinvieh macht auch Mist und habe ein gutes Gefühl dabei.

Heute nutze ich fast ausschließlich freie Software. E-Mail-Client, Textverarbeitung, Editoren und Betriebssystem; alles FLOSS. Dabei bin ich der Nutzung proprietärer Software gar nicht abgeneigt. So würde ich auch heute noch zu proprietären Anwendungen für die Steuererklärung oder das Online-Banking greifen, bevor ich mich mit den freien Alternativen abquäle.

Zwar existieren einige liebgewonnene Anwendungen heute nicht mehr, weil die Hersteller sie abgekündigt oder zur Unbenutzbarkeit weiterentwickelt haben. Doch habe ich das gleiche auch schon mit FLOSS-Anwendungen durchgemacht.

Wie ist das bei euch? Verwendet ihr freie bzw. quell-offene Software in eurem Alltag? Wenn ja, in welchem Umfang? Und wie zufrieden seid ihr damit? In welchen Bereichen fehlt es eurer Meinung nach an freien Alternativen? Nutzt gern die Kommentarfunktion oder schreibt mir per E-Mail, wenn ihr mögt.

Was tun, wenn’s klemmt?

FLOSS und proprietäre Software haben gemein, dass sie fehlerbehaftet sind. Ohne eine Gewährleistungspflicht auf Software wird sich dieser Umstand auch nie ändern. Doch was kann man als Privatanwender tun, wenn eine Anwendung mal nicht so will, wie sie soll? Oder man einfach nicht weiß, wie man sein gewünschtes Ziel erreicht?

In meinen Augen gehört zu jeder Anwendung auch ein Handbuch, eine Anleitung und eine Befehlsreferenz als Dokumentation. Je nach Hersteller, Projekt bzw. Anwendung schwankt die Qualität von Dokumentation von „nicht vorhanden“ über „beschissen ist geprahlt“ bis „erfreulich gut“. Hier lohnt sich ein erster Blick. Kommt man mit der vorhandenen Dokumentation nicht weiter, findet man häufig Hilfe in den unzähligen Internetforen, wo freiwillige, engagierte Nutzer anderen Nutzern bei Sorgen, Nöten und Problemen weiterhelfen.

Um nicht ständig die gleichen Fragen aufs neue zu beantworten, wird lediglich verlangt, das verdammte Handbuch (RTFM) gelesen und die Suchfunktion verwendet zu haben, bevor man ein neues Thema eröffnet. Wer sich an diese einfachen, grundlegenden Regeln hält und darüber hinaus stets freundlich bleibt, dem wird mit großer Wahrscheinlichkeit geholfen.

Wer hingegen rüpelhaft, in rauhem Ton sofortige Unterstützung und Lösungen für ein Problem mit einer Anwendung einfordert, für die man nichtmal einen Cent zu spenden/zahlen bereit war, darf sich nicht wundern, am langen Arm zu verhungern. Und das ist in meinen Augen vollkommen in Ordnung.

Neben der Dokumentation und den Internetforen gibt es natürlich noch die technisch begabten Verwandten. Diese reisen meist an Wochenenden und hohen Feiertagen an, um die IT-Probleme ihrer Familie und Nachbarn zu fixen. Doch bitte nutzt die Hilfe dieser edlen Ritter ohne Rüstung nicht schamlos aus. Sie kommen euch unter Umständen viel häufiger besuchen, wenn sie für den Kaffee nicht drei Laptops und zwei Handys neuinstallieren müssen.

Damit sind die Möglichkeiten eigentlich auch ausgeschöpft. Kommerzielle und finanziell interessante Support-Angebote für Privatanwender existieren meines Wissens nach so gut wie nicht.

FLOSS lebt vom Mitmachen, nicht vom Meckern

Freie Software wird meist unentgeltlich zur Nutzung angeboten. Diese wird nicht selten von Freiwilligen in deren Freizeit geschaffen. Auch Unternehmen, welche der Gemeinschaft etwas zurückgeben möchten, beschäftigen Entwickler, die einen Teil ihrer Arbeitszeit an Open Source Software arbeiten können.

Fehler werden höchstwahrscheinlich nicht mit Absicht eingebaut. Und nicht jeder erdenkliche Anwendungsfall wird von Beginn an in der Entwicklung berücksichtigt. Darüber zu meckern und Forderungen für etwas zu stellen, was man kostenlos nutzen darf, hat bisher in den seltensten Fällen geholfen.

Hat man Wünsche den Funktionsumfang einer Anwendung betreffend, kann man diese an das jeweilige Projekt richten. Liest man zuvor die sog. Contribution guidelines (zu Deutsch in etwa: Beitragsleitlinie), erhöht dies die Chancen, dass ein Beitrag Berücksichtigung findet.

Unterstützung und Hilfe ist an allen Ecken und Enden des FLOSS-Universums von Nöten und oft herzlich willkommen. Dabei muss man kein Software-Entwickler sein. Denn oft mangelt es an Dingen, die mit dem Code nicht viel zu tun haben. So kann man zum Beispiel:

• Dokumentationen schreiben, erweitern und verbessern
• Dokumentationen in andere Sprachen übersetzen
• Nutzern in Internetforen und auf Maillinglisten bei der Lösung ihrer Probleme helfen
• Fehlerbilder verifizieren und Patches testen

FLOSS ist Software von der Gemeinschaft für die Gemeinschaft. Bring dich ein, mach mit!

Ein (paar) Wort(e) an Entwickler und Paket-Betreuer

Ihr habt zum Teil großartige Anwendungen geschaffen und stellt sie der Gemeinschaft zur Verfügung. Ihr seid auf Hilfe angewiesen und braucht/sucht Nachwuchs, der bereit ist, zu lernen, wie man Software erstellt, pflegt, pakettiert und verteilt? Dann denkt bitte daran, dass jeder mal klein anfängt und man dem Nachwuchs aufs Pferd helfen muss, bevor dieser losreiten kann.

Zum Teil habt ihr rund um eure Software Ökosysteme aus Versionskontrollsystemen, Build-Umgebungen, CI/CD und Kommunikationskanäle geschaffen, die für Anfänger und technisch interessierte Laien nur schwer zu durchdringen sind. Wer sich bei der Beantwortung der Frage, wie man ein Distributions-Paket betreuen kann, tagelang durch verschiedenste Wiki-Seiten und gefühlt das halbe Internet gewühlt hat, gibt danach oft frustriert auf.

Ich habe kein Patentrezept, wie man es optimal gestalten kann. Doch klafft IMHO zwischen Tutorials wie „Wie baut man ein {DEB,RPM}-Paket“ und „So baut und betreut man Pakete für Distribution XY“ eine große Lücke, durch welche potenzieller Nachwuchs durchfällt.

Hier ist eventuell eine Diskussion innerhalb der einzelnen Communities notwendig, wie der Prozess der Nachwuchsgewinnung verbessert werden kann.

Oder habe ich hier ein falsches Bild von der FLOSS-Welt und es gibt kein Nachwuchsproblem, weil man sich vor neuen Paketbetreuern kaum retten kann?

Was haben Unternehmen und Behörden von FLOSS?

TL;DR: Mehr Souveränität. Keine starke Abhängigkeit von einem einzelnen Anbieter. Und Freiheit.

Ich habe in vorstehendem Absatz ganz bewusst auf Begriffe wie „kostenlos“, „unentgeltlich“ und „Kostenreduzierung“ verzichtet. In meinen Augen greift die Reduzierung von FLOSS auf vermeintliche Kostenvorteile zu kurz und ist nicht selten mit ein Grund für das Scheitern von Migrationsprojekten hin zu FLOSS. Statt dessen möchte ich in diesem Beitrag Aspekte hervorheben, die IMHO häufig zu kurz kommen.

Dazu beginne ich mit einem Beispiel aus der Closed Source Welt. Es wird ein Produkt wie zum Beispiel ein Betriebssystem oder eine Anwendung eines proprietären Herstellers erworben und in die eigenen Geschäftsprozesse integriert. Nicht selten zahlt man einmal für die Lizenz, um das Produkt überhaupt nutzen zu dürfen und darüber hinaus für ein Abonnement, über welches man Updates, Sicherheits-Patches und Unterstützung durch den Hersteller-Support bekommt. Der Hersteller kann beliebig darüber entscheiden, wie lange er ein Produkt unterstützt und wann er es abkündigt, so dass der Kunde ggf. ein Nachfolgeprodukt erneut kaufen muss. Wenn es ganz dumm läuft, stellt der Anbieter ein Produkt komplett ein, ohne dass es ein Nachfolgeprodukt gibt. Als Kunde guckt man dann halt in die Röhre und kann sich erneut auf die Suche nach einem Produkt machen, das man ggf. unter Anpassung der eigenen Prozesse integriert. Damit einher geht häufig die Anpassung weiterer Systeme und Prozesse, sowie der Austausch von Client-Anwendungen und Anwenderschulungen.

Die schlechte Nachricht ist, dies alles kann beim Einsatz von FLOSS ebenfalls passieren. Doch gibt es bei FLOSS noch eine weitere Option, die sich als vorteilhaft erweisen kann. Auch dazu möchte ich euch ein Beispiel geben.

Angenommen es wird eine Software genutzt, die ein engagierter FLOSS-Entwickler als Hobby-Projekt in seiner Freizeit erstellt hat. Die Software besitzt ausschließlich Abhängigkeiten zu anderen FLOSS-Technologien und deckt alle Anforderung des Unternehmens bzw. der Behörde ab. Die Nutzung ist unbeschränkt und kostenlos möglich. Mittlerweile ist die Anwendung tief in die eigenen Prozesse integriert und elementarer Bestandteil der Wertschöpfungskette. Alle sind glücklich und alle sind froh.

Doch dann endet eines Jahres die Unterstützung für eine FLOSS-Technologie von der diese Anwendung abhängt. Es gibt ein Major-Release-Upgrade für diese Technologie. Die FLOSS-Anwendung muss jedoch angepasst werden, um weiterhin lauffähig zu sein.

Nun kann man den bzw. die Entwickler der Anwendung ganz lieb fragen, ob sie die notwendigen Anpassungen vornehmen mögen. Vielleicht hat man Glück und dies geschieht innerhalb weniger Tage. Vielleicht hat man auch Pech und sie haben einfach keine Lust.

Wenn es an der Motivation fehlt, kann man auf die verrückte Idee kommen und den Entwicklern anbieten, sie für die notwendigen Anpassungen zu bezahlen und einen Preis mit ihnen aushandeln. Für mich liegt dieser Gedanke nahe, würde man einen proprietären Hersteller doch auch bezahlen. Und das häufig sogar für Änderungen, die man gar nicht wollte/brauchte.

Nun kann es durchaus immer noch passieren, dass der/die Entwickler das Angebot ablehnen. Sie haben einfach keine Lust, sich weiterhin um ihre alte Anwendung zu kümmern. Was bleibt nun übrig, außer eine Markterkundung durchzuführen, eine Alternative zu eruieren und Himmel und Hölle in Bewegung zu setzen, um diese zu implementieren?

Halt! Stopp! Es gibt noch eine weitere Alternative. Die Anwendung ist quell-offen und der Quelltext liegt euch vor. Die Anwendung kann jederzeit aus diesem neu erstellt werden und ihr habt das Recht, beliebige Anpassungen am Quelltext vorzunehmen. Wenn euch die Anwendung wichtig genug ist, hindert euch nichts und niemand daran, eigene Entwickler einzustellen, welche den Quelltext studieren und notwendige Anpassungen vornehmen. Und da ihr diese Entwickler selbst bezahlt, könnt ihr sie auch mit Priorität an euren Wunsch-Funktionen arbeiten lassen.

Jetzt wurde auch schon deutlich, warum ich das Argument, FLOSS sei kostenlos bzw. günstig, doof finde. Es trifft nicht zu. Spätestens wenn ich eigene Entwickler beschäftige und hoffentlich auch bezahle, kostet dies ebenfalls Geld; nur investiert man das Geld hierbei in eigene Ressourcen. Ähnlich ist es, wenn man sich Funktionen im Auftrag entwickeln lässt. Nur behält man hierbei die Souveränität über die Software, im Gegensatz zum Produkt eines proprietären Anbieters.

Selbstverständlich mag dies nicht in jedem Fall möglich sein. Doch in vielen Fällen ist dies ein gangbarer Weg und einer der großen Vorteile des FLOSS-Entwicklungsmodells. Ein weiterer Vorteil besteht darin, dass man nicht die gesamte Entwicklungsarbeit allein bewältigen muss. Die Last kann auf viele Schultern weltweit verteilt werden. So arbeiten Entwickler aus verschiedensten Branchen mit am Linux-Kernel. Gleiches gilt für den BSD-Kern und unzählige andere Projekte.

Wer hilft wenn’s klemmt?

Grundsätzlich stehen die gleichen Optionen zur Verfügung, die auch Privatnutzern offen stehen. Darüber hinaus bietet sich häufig die Möglichkeit, Support-Verträge mit Herstellern oder Systemhäusern abzuschließen.

So bieten z.B. Red Hat, SUSE, Canonical und Oracle verschiedene Support-Optionen für das jeweilige Portfolio an. Darüber hinaus haben sich auch im deutschsprachigen Raum einige Firmen etabliert, welche Support-Dienstleistungen für vielfältige FLOSS-Projekte/Produkte anbieten.

Diese Firmen verdienen nicht nur Geld mit Dienstleistungen rund um FLOSS. Sie beteiligen sich häufig mit eigenem Personal und/oder finanziell an der Weiterentwicklung diverser Projekte.

Die Qualität des Supports ist meiner Erfahrung nach mit dem proprietärer Anbieter vergleichbar. Das gilt sowohl im positiven wie negativen Sinne.

Nutzt einfach die Suchmaschine eures geringsten Misstrauens und ihr werdet bestimmt einen passenden Dienstleister finden.

Auch hier gilt, nicht meckern, mitmachen!

Ich möchte mich wiederholen: „FLOSS ist Software von der Gemeinschaft für die Gemeinschaft. Bring dich ein, mach mit!“

Dies sollte in meinen Augen besonders für Behörden und Organisationen gelten, die den Betrieb und die Entwicklung ihrer Anwendungen mit dem Steuergeld von Bürgerinnen und Bürgern finanzieren. Deshalb unterstütze ich die Kampagne „Public Money, Public Code“. Innovationen und Investitionen in Freie Software verschwinden nicht hinter verschlossenen Türen zum Nutzen Weniger; statt dessen können alle Nutzer davon profitieren. So z.B. auch Bürgerinnen und Bürger, die daheim evtl. die gleichen FLOSS-Anwendungen nutzen, die auch der Staat nutzt und mit weiterentwickelt.

Bisher ist vieles davon noch bloße Utopie. Scheitert es doch im öffentlichen Dienst schon oft genug daran, an Open Source Projekte zu spenden. Geld für Berater-Verträge auszugeben ist da schon einfacher möglich. Doch auch auf diesem Weg kann man ja FLOSS-Projekte unterstützen. Ich glaube da wo ein Wille ist, ist auch ein Weg.

Schlussworte

Freie Software und Open Source Software sind frei im Sinne von:

• Der Quelltext liegt offen vor und kann von jedem Menschen eingesehen, studiert und weitergegeben werden.
• Jeder Mensch hat das Recht den Quelltext zu verändern.
• Die Verwendung der Software ist in keiner Weise beschränkt.

Wer einfach nur seine Arbeit erledigen möchte, mag dabei mit FLOSS-Software genau so viel Glück oder Pech wie mit proprietärer Software haben. FLOSS bietet hingegen Souveränität und Freiheit; mit allen Vor- und Nachteilen, die das mit sich bringen mag. Technisch interessierte Menschen können sich mit ihr vertraut machen, dazulernen und Teil einer Gemeinschaft werden.

Ich mag FLOSS und glaube Open Source Entwicklungsmodelle sind auch in Zukunft nicht mehr aus unserer Welt wegzudenken.

Android ist keine Alternative, schon gar nicht mit integrierten Google-Diensten. Es bleibt daher nur das Ausweichen auf eine Custom ROM ohne Google-Dienste mit freier Software. Das Prozedere ist im Jahr 2020 nicht einfacher als im Jahr 2014 – eher ist sogar das Gegenteil der Fall. Das Grundproblem ist, dass die Custom ROM Community nie ihren Modder-Wurzeln entwachsen ist.

Rahmenbedingungen

Parallel zu meinem iPhone hatte ich seit Langem ein Android Gerät mit einer AOSP-ROM und F-Droid. Leider ist mein bisheriges Huawei Smartphone endgültig aus der Liste der unterstützten Geräte gefallen (was angesichts der beschränkten Hardware verständlich ist) und ließ sich nicht mehr sicher betreiben. Die Suche nach einer Alternative gestaltete sich etwas schwierig (siehe: In eigener Sache: Android Smartphone mit Custom ROM). Im Jahresrückblick hatte ich schon erwähnt, dass ich zwischen einem Google Pixel 5 und einem Samsung Galaxy S10 schwanke (siehe: Wasser predigen, Wein trinken? – Mein Nutzungsverhalten 2020). Dank eines sehr guten Gebraucht-Angebots für ein Galaxy S10 fiel die Wahl auf Letzteres.

Das Samsung Galaxy S10 hatte ich nach viel Recherche ausgesucht. Erstens passen die Rahmendaten, da die Hardware kaum größer als mein iPhone SE 2020 ist und das für mich die ideale Größe darstellt, zweitens sind die Spezifikationen immer noch ansehnlich. Zudem macht Samsung die Entsperrung des Bootloaders sehr leicht. Eine Schaltfläche in den Entwickleroptionen umlegen, einmal in den Download-Mode wechseln und das war es schon. Abgesehen von Google selbst machen kaum Anbieter es den Kunden hier so einfach. Zudem steht mit heimdall eine gute Lösung für den Flashvorgang unter Linux zur Verfügung. Zu guter Letzt hilft natürlich alles nichts, wenn die Community das Gerät nicht unterstützt. Hier lohnt sich immer ein Blick in die passenden Foren auf XDA Developers. Samsungs ehemalige Flaggschiffe werden meist sehr gut unterstützt, weil die in hohen Stückzahlen abgesetzt wurden und somit in der Community viele Abnehmer fanden.

Keine offiziellen Kanäle

Die Rahmenbedingungen sind also nahe am Optimum dessen was man an Hardware für eine Custom ROM haben kann. Leider ist die Community in den letzten Jahren immer mehr zerfasert. LineageOS ist so ein bisschen das Debian der Custom ROM Welt. Dutzende ROMs basieren darauf, aber das Kernprojekt bekommt kaum offizielle Releases für die einzelnen Geräte hin. Die Projektkommunikation ist kaum existent, die Ankündigungen veraltet und völlig intransparent, was gerade aktuelle Versionen für welche Geräte sind. Andere Projekte wie crDroid veröffentlichen zwar offizielle Releases aus Basis von LineageOS aber mit vollkommen veralteten Sicherheitsständen. Das hier als Beispiel dienende Samsung Galaxy S10 bekommt nur crDroid 6.10 mit Patch Level aus dem Sommer. Man muss deshalb in den Themen auf XDA Devlopers nach passenden ROMs aktuellen suchen.

Das ganze Vorgehen erinnert mich an Tauschbörsen der frühen 2000er Jahre und ist eigentlich unzumutbar. Man muss sich die Ironie des Vorgangs einfach mal vergegenwärtigen, dass man für mehr Sicherheit des Smartphones in einem Forum einen Link anklickt, der zu irgendeinem Filehoster führt, wo man ein Betriebssystem herunterlädt und auf das Smartphone flasht. Basis für die Wahl ist Renommee eines ROM Entwicklers mit irgendeinem Pseudonym.

Flashvorgang mit Tücken

Selbst wenn man also seine Custom ROM gefunden hat und gut unterstützte Hardware sein Eigen nennt, ist der Flashvorgang nicht trivial. Wie gesagt: Ich nutze seit 2014 Android Geräte mit Custom ROMs. HTC Desire, Nexus 4, zuletzt Huawei. Einfacher ist es nicht geworden, so viel ist klar. Am Anfang muss man ein, zwei ROMs durch testen, weil sich manches super lesende Projekt in echt ziemlich „hacky“ anfühlt. Leider kann man bei Samsung Geräten nicht einfach von einer höheren Version zurück zu einer niedrigeren Version. Irgendwelche Inkompatibilitätschecks machen einem da einen Strich durch die Rechnung.

Kurzum: Irgendwann war mein Gerät das, was die Szene „soft bricked“ nennt. Das bedeutet, das Gerät startet nicht mehr, ich komme allerdings noch in den Download-Mode und kann das noch irgendwie retten (anders als bei „hard bricked“). Eine virtuelle Maschine mit Windows musste her, eine Software namens Odin und eine aus mehr oder minder dubiosen Quellen bezogene Stock ROM. Damit konnte das Smartphone wieder auf den Ausgangslevel zurückgesetzt und anschließend erneut eine ROM geflasht werden.

Letztlich hat es geklappt und ich habe eine sehr gute ROM auf dem Gerät. Ich behaupte aber mal, dass 60% der Anwender, die sich per zutrauen würden, so etwas zu machen und 99% der Besitzer eines Smartphones irgendwo auf dem Weg ein nicht mehr benutzbares Gerät gehabt hätten. Denn ohne mich hier selbst rühmen zu wollen, aber ich habe über 6 Jahre Erfahrung mit Custom ROMs. Recovery, Baseband, Radio, Bootloader, Custom ROM, Stock ROM – alles bekannte Begriffe und die gängigen Problemlösungen. Nach bald 15 Jahren mit Linux hat man zudem keine Scheu vor der Kommandozeile.

Schlussfolgerung

Das Kernproblem sind meiner Meinung nach nicht die Hardwarehersteller. Samsung lässt einen immerhin den Bootloader öffnen und man kann sich zur Rettung auch irgendwie die offizielle ROM besorgen. Das Problem ist meiner Meinung nach wirklich die Community. Linux ist auch nicht immer trivial (gewesen) und es gibt Hürden bei der Installation. Um Linux hat sich aber eine professionelle Community mit professionell geführten Projekten, tollen Wikis und viel Expertise versammelt. Niemand stellt eine Linux-Distribution mit Downloadlink in einem Forum vor und supportet dann im Thema.

Die Custom ROM Szene ist einfach nie ihren Modder-Wurzeln entwachsen. Vielversprechende Projekte wie CyanogenOS haben sich verspekuliert und andere wie LineageOS siechen eher vor sich hin.

Custom ROMs sind daher meiner Meinung nach (um ein schlimmes Wort aus der Politik zu verwenden) nicht mehr als eine Brückentechnologie. Man kann damit irgendwie arbeiten, wenn man partout kein iPhone haben möchte, aber die wirkliche Lösung kann nur in offen unterstützter Hardware und wirklich freien Systemen liegen.

Der Artikel Smartphone mit Custom ROM austatten – Erfahrungen und Schlussfolgerungen erschien zuerst auf [Mer]Curius

Android ist keine Alternative, schon gar nicht mit integrierten Google-Diensten. Es bleibt daher nur das Ausweichen auf eine Custom ROM ohne Google-Dienste mit freier Software. Das Prozedere ist im Jahr 2020 nicht einfacher als im Jahr 2014 - eher ist sogar das Gegenteil der Fall. Das Grundproblem ist, dass die Custom ROM Community nie ihren Modder-Wurzeln entwachsen ist.

Rahmenbedingungen

Parallel zu meinem iPhone hatte ich seit Langem ein Android Gerät mit einer AOSP-ROM und F-Droid. Leider ist mein bisheriges Huawei Smartphone endgültig aus der Liste der unterstützten Geräte gefallen (was angesichts der beschränkten Hardware verständlich ist) und ließ sich nicht mehr sicher betreiben. Die Suche nach einer Alternative gestaltete sich etwas schwierig (siehe: In eigener Sache: Android Smartphone mit Custom ROM). Im Jahresrückblick hatte ich schon erwähnt, dass ich zwischen einem Google Pixel 5 und einem Samsung Galaxy S10 schwanke (siehe: Wasser predigen, Wein trinken? - Mein Nutzungsverhalten 2020). Dank eines sehr guten Gebraucht-Angebots für ein Galaxy S10 fiel die Wahl auf Letzteres.

Das Samsung Galaxy S10 hatte ich nach viel Recherche ausgesucht. Erstens passen die Rahmendaten, da die Hardware kaum größer als mein iPhone SE 2020 ist und das für mich die ideale Größe darstellt, zweitens sind die Spezifikationen immer noch ansehnlich. Zudem macht Samsung die Entsperrung des Bootloaders sehr leicht. Eine Schaltfläche in den Entwickleroptionen umlegen, einmal in den Download-Mode wechseln und das war es schon. Abgesehen von Google selbst machen kaum Anbieter es den Kunden hier so einfach. Zudem steht mit heimdall eine gute Lösung für den Flashvorgang unter Linux zur Verfügung. Zu guter Letzt hilft natürlich alles nichts, wenn die Community das Gerät nicht unterstützt. Hier lohnt sich immer ein Blick in die passenden Foren auf XDA Developers. Samsungs ehemalige Flaggschiffe werden meist sehr gut unterstützt, weil die in hohen Stückzahlen abgesetzt wurden und somit in der Community viele Abnehmer fanden.

Keine offiziellen Kanäle

Die Rahmenbedingungen sind also nahe am Optimum dessen was man an Hardware für eine Custom ROM haben kann. Leider ist die Community in den letzten Jahren immer mehr zerfasert. LineageOS ist so ein bisschen das Debian der Custom ROM Welt. Dutzende ROMs basieren darauf, aber das Kernprojekt bekommt kaum offizielle Releases für die einzelnen Geräte hin. Die Projektkommunikation ist kaum existent, die Ankündigungen veraltet und völlig intransparent, was gerade aktuelle Versionen für welche Geräte sind. Andere Projekte wie crDroid veröffentlichen zwar offizielle Releases aus Basis von LineageOS aber mit vollkommen veralteten Sicherheitsständen. Das hier als Beispiel dienende Samsung Galaxy S10 bekommt nur crDroid 6.10 mit Patch Level aus dem Sommer. Man muss deshalb in den Themen auf XDA Devlopers nach passenden ROMs aktuellen suchen.

Das ganze Vorgehen erinnert mich an Tauschbörsen der frühen 2000er Jahre und ist eigentlich unzumutbar. Man muss sich die Ironie des Vorgangs einfach mal vergegenwärtigen, dass man für mehr Sicherheit des Smartphones in einem Forum einen Link anklickt, der zu irgendeinem Filehoster führt, wo man ein Betriebssystem herunterlädt und auf das Smartphone flasht. Basis für die Wahl ist Renommee eines ROM Entwicklers mit irgendeinem Pseudonym.

Flashvorgang mit Tücken

Selbst wenn man also seine Custom ROM gefunden hat und gut unterstützte Hardware sein Eigen nennt, ist der Flashvorgang nicht trivial. Wie gesagt: Ich nutze seit 2014 Android Geräte mit Custom ROMs. HTC Desire, Nexus 4, zuletzt Huawei. Einfacher ist es nicht geworden, so viel ist klar. Am Anfang muss man ein, zwei ROMs durch testen, weil sich manches super lesende Projekt in echt ziemlich "hacky" anfühlt. Leider kann man bei Samsung Geräten nicht einfach von einer höheren Version zurück zu einer niedrigeren Version. Irgendwelche Inkompatibilitätschecks machen einem da einen Strich durch die Rechnung.

Kurzum: Irgendwann war mein Gerät das, was die Szene "soft bricked" nennt. Das bedeutet, das Gerät startet nicht mehr, ich komme allerdings noch in den Download-Mode und kann das noch irgendwie retten (anders als bei "hard bricked"). Eine virtuelle Maschine mit Windows musste her, eine Software namens Odin und eine aus mehr oder minder dubiosen Quellen bezogene Stock ROM. Damit konnte das Smartphone wieder auf den Ausgangslevel zurückgesetzt und anschließend erneut eine ROM geflasht werden.

Letztlich hat es geklappt und ich habe eine sehr gute ROM auf dem Gerät. Ich behaupte aber mal, dass 60% der Anwender, die sich per zutrauen würden, so etwas zu machen und 99% der Besitzer eines Smartphones irgendwo auf dem Weg ein nicht mehr benutzbares Gerät gehabt hätten. Denn ohne mich hier selbst rühmen zu wollen, aber ich habe über 6 Jahre Erfahrung mit Custom ROMs. Recovery, Baseband, Radio, Bootloader, Custom ROM, Stock ROM - alles bekannte Begriffe und die gängigen Problemlösungen. Nach bald 15 Jahren mit Linux hat man zudem keine Scheu vor der Kommandozeile.

Schlussfolgerung

Das Kernproblem sind meiner Meinung nach nicht die Hardwarehersteller. Samsung lässt einen immerhin den Bootloader öffnen und man kann sich zur Rettung auch irgendwie die offizielle ROM besorgen. Das Problem ist meiner Meinung nach wirklich die Community. Linux ist auch nicht immer trivial (gewesen) und es gibt Hürden bei der Installation. Um Linux hat sich aber eine professionelle Community mit professionell geführten Projekten, tollen Wikis und viel Expertise versammelt. Niemand stellt eine Linux-Distribution mit Downloadlink in einem Forum vor und supportet dann im Thema.

Die Custom ROM Szene ist einfach nie ihren Modder-Wurzeln entwachsen. Vielversprechende Projekte wie CyanogenOS haben sich verspekuliert und andere wie LineageOS siechen eher vor sich hin.

Custom ROMs sind daher meiner Meinung nach (um ein schlimmes Wort aus der Politik zu verwenden) nicht mehr als eine Brückentechnologie. Man kann damit irgendwie arbeiten, wenn man partout kein iPhone haben möchte, aber die wirkliche Lösung kann nur in offen unterstützter Hardware und wirklich freien Systemen liegen.

Mozilla hat Firefox 84.0.1 für Windows, Apple macOS sowie Linux veröffentlicht und damit mehrere Probleme der Vorgängerversion behoben, welche überwiegend in Zusammenhang mit Drittanbietern stehen.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Mit dem Update auf Firefox 84.0.1 hat Mozilla mögliche Absturzursachen behoben, welche durch verschiedene „Sicherheits“-Softwares verursacht worden sind. Auch Abstürze sowie Probleme mit dem Laden von sicheren Websites in Zusammenhang mit Drittanbieter-PKCS11-Modulen sowie Smartcards wurden behoben.

Für Nutzer eines Computers mit Apple Silicon-CPU wurde der User-Agent auf einer bestimmten Website temporär angepasst, weil auf Grund einer fehlerhaft implementierten User-Agent-Erkennung dieser Seite die Spiele nicht geladen werden konnten.

Außerdem wurde ein Performance-Problem und mögliches Flackern von Canvas-Elementen behoben, von welchem Windows-Nutzer ohne WebRender betroffen waren.

Der Beitrag Mozilla veröffentlicht Firefox 84.0.1 erschien zuerst auf soeren-hentzschel.at.

Biometrie zur Authentifizierung greift immer mehr um sich. Smartphones sind heutzutage obligatorisch mit Fingerabdruck oder Gesichtserkennung entsperrbar. Viele Notebooks, vor allem im Business-Segment, bieten ebenfalls Fingerabdruckleser. Anders als bei MacBooks halte ich deren Verwendung für keine gute Idee.

Biometrische Authentifizierungsverfahren sind eine komplizierte Abwägungsgeschichte. Grundsätzlich sind sie nicht so sicher wie viele Anwender glauben (siehe auch: (Un-)Sicherheit per Fingerabdruck & Biometrische Daten zur Authentifizierung sind unsicher!). Zudem halte ich den Gewöhnungseffekt für sehr gefährlich, da die technischen Geräte es für uns selbstverständlich machen, biometrische Daten zu hinterlegen (siehe: Kommentar: Die Macht der Gewohnheit – Biometrische Daten). Andererseits nutzten vor dem Aufkommen solcher Verfahren viel zu wenige Anwender sichere PINs oder Passwörter für ihre mobilen Geräte. Entweder schützte man diese gar nicht oder mit simplen Wischmustern. Fingerabdruck oder Gesichtserkennung bieten hier durchaus einen Mehrwert.

Trotzdem sollte man sich der grundsätzlichen Gefahr immer bewusstsein. Ein kompromittierter Dienst und ein gehacktes Passwort sind ärgerlich, aber dann erzeugt mal halt ein neues Kennwort (dank Passwortverwaltung hat man schließlich individuelle Kennwörter pro Dienst). Gerät ein Fingerabdruck in die falschen Hände, ist diese Authentifizierungsmöglichkeit verbrannt. Schließlich kann man sich schlecht einen neuen Finger verschaffen. Die Individualität und Unveränderbarkeit biometrischer Merkmale wird hier zum Nachteil.

Den oben beschriebenen Mehrwert biometrischer Merkmale gegenüber gar keiner oder einer schlechten Sicherung gibt es aber nur, wenn das Gerät sicher ist. Weder Android noch die Apple-Systeme iOS / macOS speichern den Abdruck einfach als Bild auf der Festplatte. Biometrische Merkmale werden in einem besonders geschützten Bereich verarbeitet. Bei iOS wird dies als Secure Enclave bezeichnet, bei Android erfolgt die Verarbeitung im TEE. Keine App erhält durch die ausgefeilten Berechtigungssysteme direkten Zugriff auf den Fingerabdruck. Ein weiterer Grundsatz ist, keine Bilder der Fingerabdrücke zu speichern, sondern Hash-Werte derselben. Diese Maßnahmen hat Apple ebenfalls in seine MacBooks mit dem T2 Co-Prozessor übernommen.

Alle diese Sicherheitsvorkehrungen gibt es für Linux auf dem Desktop nicht. Gängige Software wie fprint oder fingerprint-gui speichern den Fingerabdruck als Bild im System, z. B. unterhalb von /etc. Wenn man nun noch bedenkt, dass das Linux-Berechtigungskonzept für Applikationen ein wenig in die Jahre gekommen ist, viele Distributionen Benutzern via sudo Systemverwalterrechte einräumen und die Kennwörter vieler Benutzeraccounts nicht gerade den Ansprüchen an sichere Passwörter genügen, sollte die ganze Misere klar sein.

Kurzum: Finger weg von biometrischen Verfahren unter Linux (bis hier ganz grundlegend was geändert wird).

Die ganze Sache ist übrigens ein schönes Beispiel für die falsche Sicherheit, die Open Source manchmal verschafft. Linux gilt als sicheres System, Open Source als vertrauenswürdig. Google und Apple genießen diese Vorschusslorbeeren nicht und mussten deshalb bei der Einführung biometrischer Verfahren viel Kritik einstecken und die technischen Sicherheitsmaßnahmen genau darlegen. Bei Linux guckt sich das keiner so genau an, denn es ist ja schließlich ein sicheres und vertrauenswürdiges System.

Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay 

Der Artikel Authentifizierung per Fingerabdruck mit Linux – Keine gute Idee! erschien zuerst auf [Mer]Curius

Biometrie zur Authentifizierung greift immer mehr um sich. Smartphones sind heutzutage obligatorisch mit Fingerabdruck oder Gesichtserkennung entsperrbar. Viele Notebooks, vor allem im Business-Segment, bieten ebenfalls Fingerabdruckleser. Anders als bei MacBooks halte ich deren Verwendung für keine gute Idee.

Biometrische Authentifizierungsverfahren sind eine komplizierte Abwägungsgeschichte. Grundsätzlich sind sie nicht so sicher wie viele Anwender glauben (siehe auch: (Un-)Sicherheit per Fingerabdruck & Biometrische Daten zur Authentifizierung sind unsicher!). Zudem halte ich den Gewöhnungseffekt für sehr gefährlich, da die technischen Geräte es für uns selbstverständlich machen, biometrische Daten zu hinterlegen (siehe: Kommentar: Die Macht der Gewohnheit - Biometrische Daten). Andererseits nutzten vor dem Aufkommen solcher Verfahren viel zu wenige Anwender sichere PINs oder Passwörter für ihre mobilen Geräte. Entweder schützte man diese gar nicht oder mit simplen Wischmustern. Fingerabdruck oder Gesichtserkennung bieten hier durchaus einen Mehrwert.

Trotzdem sollte man sich der grundsätzlichen Gefahr immer bewusstsein. Ein kompromittierter Dienst und ein gehacktes Passwort sind ärgerlich, aber dann erzeugt mal halt ein neues Kennwort (dank Passwortverwaltung hat man schließlich individuelle Kennwörter pro Dienst). Gerät ein Fingerabdruck in die falschen Hände, ist diese Authentifizierungsmöglichkeit verbrannt. Schließlich kann man sich schlecht einen neuen Finger verschaffen. Die Individualität und Unveränderbarkeit biometrischer Merkmale wird hier zum Nachteil.

Den oben beschriebenen Mehrwert biometrischer Merkmale gegenüber gar keiner oder einer schlechten Sicherung gibt es aber nur, wenn das Gerät sicher ist. Weder Android noch die Apple-Systeme iOS / macOS speichern den Abdruck einfach als Bild auf der Festplatte. Biometrische Merkmale werden in einem besonders geschützten Bereich verarbeitet. Bei iOS wird dies als Secure Enclave bezeichnet, bei Android erfolgt die Verarbeitung im TEE. Keine App erhält durch die ausgefeilten Berechtigungssysteme direkten Zugriff auf den Fingerabdruck. Ein weiterer Grundsatz ist, keine Bilder der Fingerabdrücke zu speichern, sondern Hash-Werte derselben. Diese Maßnahmen hat Apple ebenfalls in seine MacBooks mit dem T2 Co-Prozessor übernommen.

Alle diese Sicherheitsvorkehrungen gibt es für Linux auf dem Desktop nicht. Gängige Software wie fprint oder fingerprint-gui speichern den Fingerabdruck als Bild im System, z. B. unterhalb von /etc. Wenn man nun noch bedenkt, dass das Linux-Berechtigungskonzept für Applikationen ein wenig in die Jahre gekommen ist, viele Distributionen Benutzern via sudo Systemverwalterrechte einräumen und die Kennwörter vieler Benutzeraccounts nicht gerade den Ansprüchen an sichere Passwörter genügen, sollte die ganze Misere klar sein.

Kurzum: Finger weg von biometrischen Verfahren unter Linux (bis hier ganz grundlegend was geändert wird).

Die ganze Sache ist übrigens ein schönes Beispiel für die falsche Sicherheit, die Open Source manchmal verschafft. Linux gilt als sicheres System, Open Source als vertrauenswürdig. Google und Apple genießen diese Vorschusslorbeeren nicht und mussten deshalb bei der Einführung biometrischer Verfahren viel Kritik einstecken und die technischen Sicherheitsmaßnahmen genau darlegen. Bei Linux guckt sich das keiner so genau an, denn es ist ja schließlich ein sicheres und vertrauenswürdiges System.

Bilder:
Einleitungsbild und Beitragsbild von von mohamed Hassan via pixabay 

Durch eine Fehlbestellung bin ich zu einen Gaming Headset gekommen.

Es ist das EKSA E900Pro.

Auf dem Karton steht zwar was von 7.1 Sound (WTF) aber nur per USB auf Windows.

Da konnte ich nicht anders, die inneren Stimmen, ihr versteht. Also angestöpselt, die Nachrichten sahen gut aus:

usb 1-3: new full-speed USB device number 7 using xhci_hcd
usb 1-3: New USB device found, idVendor=0d8c, idProduct=0012, bcdDevice= 1.00
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-3: Product: USB Audio Device
usb 1-3: Manufacturer: C-Media Electronics Inc.
input: C-Media Electronics Inc. USB Audio Device as /devices/pci0000:00/0000:00:14.0/usb1/1-3/1-3:1.3/0003:0D8C:0012.0003/input/input42
hid-generic 0003:0D8C:0012.0003: input,hidraw0: USB HID v1.00 Device [C-Media Electronics Inc. USB Audio Device] on usb-0000:00:14.0-3/input3

Das sah gut aus! (Debian Bullseye)

Also mal ein wenig in den Einstellungen von Gnome gesucht und fündig geworden. Das USB Audio Devie ist bei mir als drittes Audio Device aufgeführt und kann ausgewählt werden (rechts Detailansicht von Jitsi)

Was Jetzt noch fehlt, ist die automatische Aktivierung des Headsets, damit ich nicht immer manuell umschalten muss.

Da gibt es übrigens eine ganz einfache Möglichkeit die Reihenfolge der Devices zu beeinflussen.

Und zwar so: als root in 

/etc/modprobe.d/sound-cards-order einfach

options snd_usb_audio index=0
options snd_hda_intel index=1

schreiben. Die Datei existiert vermutlich noch nicht. (details zur Konfiguration hier wiki.ubuntuusers.de/Soundkarten_konfigurieren/ )

Nach dem nächsten Neustart funktioniert das automatische aktivieren einwandfrei. 

Interessanterweise ist dadurch gleich der NVIDIA Sound Kram verschwunden.

Ps: Das Headset hat auch noch eine 4 poligen 3.5mm polige Buchse und passendes Kabel, das habe ich auch probiert, nur das Mikro wollte nicht an Anhieb, mit USB kein Problem.

Deshalb habe ich da nicht weiter geforscht...

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Einrichtung Proxmox

Beginnen wir mit den notwendigen Schritten im Proxmox Mail Gateway. Meldet euch dazu mit eurem root-Login im Webinterface an. Dieses erreicht ihr unter https://NameEuresServers:8006 - dort angemeldet werdet ihr vom Dashboard begrüßt. Wechselt nun in den Unterpunkt Mail Proy, den ihr unter Configuration vorfindet.

Relaying

Der erste Reiter lauter Relaying. Wir tragen dort als Default Relay den vollen Hostnamen der mailcow-Installation ein, so wie dieser auch von euch aufgerufen wird.
Disable MX lookup (SMTP) stellt ihr auf Yes um, die restlichen Einstellungen verbleiben bei den Standardwerten.

Relay Domains

Wir wechseln in den nächsten Reiter, Relay Domains. Über Create könnt ihr nun sämtliche Domains anlegen, die ihr auch in mailcow konfiguriert habt und die über das Mail Gateway laufen sollen.

Options (optional)

Im Reiter Options könnt ihr bei Bedarf die Message Size (bytes) hochsetzen, standardmäßig sind hier 10 MB hinterlegt, die ich für mich leicht erhöht habe. Ebenfalls kann hier auf Wunsch Greylisting deaktiviert werden.

Network

Im Reiter Network hinterlegt ihr die IP-Adresse eures mailcow-Servers. Somit weiß Proxmox Mail Gateway, dass der Server eine vertraute Zone ist.

TLS
Enable TLS unter dem Reiter TLS und schon geht es weiter.

DKIM (optional)
Wollt ihr DKIM verwenden könnt ihr das entweder über mailcow direkt oder aber Proxmox machen, entscheidet euch jedoch für eine Lösung. Solltet ihr bisher mailcow verwendet haben, aber auch DKIM über Proxmox nutzen wollen, löscht im mailcow-Interface den DKIM-Key der Domain, so dass mailcow diese nicht länger signiert.

Im Proxmox Interface setzt die Option Enable DKIM Signing auf Yes, hinterlegt einen Selector, in meinem Fall z.B. "dkim" und hinterlegt unter dem Punkt Sign Domains alle Domains, die per DKIM signieren sollen.

Das war es auf Seiten Proxmox. Wir wechseln zu mailcow.

Einrichtung mailcow

Im mailcow-Interface angemeldet, wechseln wir unter dem Punkt Konfiguration zum Reiter Routing. Interessant hier ist direkt der Punkt Senderabhängige Transport Maps.
Fügt dort euren Server mit der Proxmox-Installation nach dem Schema <euerProxmoxHostname>:26 hinzu. Eine Authentifizierung ist nicht notwendig. Anschließend sollte dieser in der Übersicht auftauchen.

Anschließend geht es in die Eigenschaften einer Domain unter Konfiguration -> E-Mail-Setup. Klickt auf Bearbeiten, der Domain, die ihr mit dem Mail Gateway nutzten wollt.
Setzt dort in der Variable Senderabhängige Transport Maps den eben eingerichteten Server und speichert die Änderungen.

Wie schon im Punkt DKIM unter Proxmox erwähnt, solltet ihr euch dafür entscheiden, Proxmox zur DKIM Prüfung und Signierung zu verwenden, löscht den DKIM-Key der Domain unter  Konfiguration -> Konfiguration -> ARC/DKIM-Keys.

Abschließende Anpassungen

Damit auch eingehende Nachrichten nun auf Spam und Viren geprüft werden, müssen versendene Mail-Server natürlich wissen, dass Proxmox nun als Eingangstor fungiert. Dazu müsst ihr den MX-Record eurer jeweiligen Domain im DNS auf den Proxmox-Server umbiegen. Im gleichen Zuge könnt ihr sofern notwendig auch euren DKIM-TXT-Record anpassen. Bei Proxmox findet ihr diesen in den DKIM-Einstellungen unter View DNS Record. Solltet ihr das Ganze erst einmal testen wollen, empfiehlt es sich temporär mit einer niederigen TTL zu arbeiten um im Fehlerfall schnell wieder die DNS-Records zu ändern.

Das war's auch schon, ab sofort fungiert eur Proxmox Mail Gateway als zusätzlicher Schutz vor Spam. Admininistrieren könnt ihr diesen ab sofort unter dem Punkt Administration im Proxmox Interface.

Wer diesem Blog schon länger folgt weiß, dass ich seit längerer Zeit auf die selbstgehostete Mailserver-Lösung mailcow setze. Diese setzt auf Docker und bringt eigentlich alles mit, was man für einen Mail-Server benötigt, so auch einen Spam-Schutz in Form von rspamd. Probleme mit Spam hatte ich somit in der Vergangenheit glücklicherweise bisher selten.

Dennoch siegte der Spieltrieb und ich wollte ich mich näher mit Proxmox Mail Gateway auseinandersetzen. Proxmox wird dem ein oder anderen ein Begriff sein, am bekanntesten ist das österreichische Unternehmen wohl für seine Virtualisierungslösung Proxmox VE.
Mit Proxmox Mail Server wird - seit kurzer Zeit auch als Community-Variante -  eine Sicherheitslösung für Mailserver auf Basis von ClamAV und SpamAssassin für Mailserver-Betreiber angeboten. Dieser sitzt im idealfall zwischen "Internet" und Mailserver und fungiert somit dann wie der Name schon sagt als Gateway. Ich zeige folgend, wie ich das Mail Gateway mit meiner mailcow-Installation nutze.

Voraussetzungen

Was benötigen wir? Mindestens 2 Server. Einen mit einer mailcow-, der andere mit einer Proxmox Mail Gateway-Installation. Ich erkläre die einzelnen Schritte hier nicht, mailcow bietet dafür eine super Installations-Anleitung an. Bei mir läuft es auf einem Debian 10 System. Das Mail Gateway lässt sich über mehrere Wege installieren, entweder per ISO-Image, oder aber über zusätzliche Paketquellen direkt auf einem Debian 10. Ich setze hier eine Standard-Installation voraus, welche per A- und ggf. AAA-Record im DNS korrekt aufgelöst wird.

(Unbezahlte) Empfehlung: Ich bin seit langer Zeit sehr zufriedener Kunde bei Hetzner und nutze die dortige Hetzner-Cloud. Diese bietet eine direkte Einbindung des Proxmox Mail Gateway ISO-Images an. Wer noch kein Kunde bei Hetzner ist, deren Cloud aber mal testen möchte, kann sich gerne über diesen Link registrieren und erhält 20 Euro Startguthaben und tut mir nebenbei noch etwas gutes.

In mailcow sollte mindestens eine konfigurierte und funktionierende Domain hinterlegt sein.

Linux und die Idee der freien Software sind eng verwoben. Proprietäre Software kann zwar theoretisch für Linux vertrieben werden, das ideologische Umfeld und die geringe Verbreitung haben hier aber kein großes Ökosystem entstehen lassen. Drei prominente Ausnahmen möchte ich hier kurz vorstellen. Im zweiten Teil: moneyplex von Matrica.

Für mich ist die Möglichkeit, Onlinebanking über eine eigene Software und nicht im Browser zu erledigen einer der großen Vorteile der deutschen Bankenlandschaft (siehe auch: Onlinebanking – HBCI/FinTS einfordern). Der Zugriff via HBCI/FinTS ist  nicht nur komfortabel, weil man alle Konten in einer Software sammeln kann, sondern auch noch sehr gut für die Sicherheit. Man umgeht den Browser mit seinen notorischen zahlreichen Sicherheitslücken. Weiterhin erschwert man bei unbedarften Anwendern Phishing-Angriffe. Diese erfordern schließlich immer einen Aufruf einer gefakten Internetseite. Ist der Anwender jedoch so konditioniert, dass er Banking nie über den Browser macht, fällt er deutlich weniger auf solche Angriffe herein. Ich wechsle inzwischen eher die Bank, als auf HBCI zu verzichten.

moneyplex Homebanking

Wenige Alternativen

Im Homebanking Bereich gibt es nur wenige Alternativen. Die Ursache dafür dürfte in den vielen nationalen Spezifika in diesem Bereich liegen. Die mächtige HBCI-Schnittstelle gibt es nur in Deutschland, weshalb sich auch nur deutsche Nutzer und Entwickler dafür interessieren dürften. Die Schnittstelle soll zudem nicht ganz trivial in der Implementierung sein, weshalb das nichts für ein kleines GSoC Projekt oder eine Wochenendarbeit ist. Ständige Veränderungen erfordern trete Anpassungsleistungen. Unter Linux gibt es eigentlich nur zwei Möglichkeiten in drei Ausprägungen. KMyMoney und GnuCash greifen jeweils auf aqbanking zurück und daneben gibt es noch Hibiscus.

KMyMoney und GnuCash sind zwar mächtige Werkzeuge, aber die HBCI-Implementierung mittels aqbanking ist eine hakelige Geschichte. Die Synchronisation ist fehleranfällig, Überweisungen klappen nicht oder nicht zuverlässig und die Möglichkeit, nachträglich Buchungen im Verlauf zu manipulieren, disqualifiziert die Software im professionellen Einsatz. Um die Ausgaben für den Privatgebrauch im Blick zu behalten und ggf. automatisiert auszuwerten ist die aqbanking Implementierung ganz nett, da sie den manuellen Import des Zahlungsverkehrs erspart – mehr aber auch nicht.

Hibiscus hat seine Fanbasis. Ich persönlich bin mit dem Programm wegen der Java-Basis und der schwierigen Oberfläche nie warum geworden.

moneyplex von Matrica – kurz vorgestellt

Matrica gehört fast schon zu den Dinosauriern auf dem Markt. Die Firma gibt es seit 1998 – ein Umstand, den man Webauftritt und Softwaregestaltung deutlich anmerkt. Ich hatte das Programm nie wirklich auf dem Schirm, aber wurde in den Kommentaren unter einem Artikel (siehe: Wechselhürden zurück zu Linux) mal darauf aufmerksam gemacht. Als bei meiner Rückkehr zu Linux KMyMoney sich (nicht nur im Vergleich zu MoneyMoney) als extrem unzufriedenstellend herausstellte, fiel mir das wieder ein.

Monyplex gibt es gemessen an IT-Standards schon immer. Das ist ein nicht unwichtiger Aspekt bei Finanzverwaltung. Die Software gibt es in den Version Standard, Professional und Business. Die Standard-Version kostet 49,90 €, die Professional 59,90 € und die Business-Variante 139,90 €. Die meisten Anwender dürften mit der Standard-Version gut bedient sein, bei verstärktem Wertpapierhandel sollte man ggf. auf die Professional-Variante setzen. Alle paar Jahre kommen neue Hauptversionen, die dann eine Upgrade-Lizenz erfordern.

Die Installation erfolgt per Installationsroutine in einen Ort der Wahl, wo dann Programm und Daten zusammen liegen. Das ist nicht sonderlich schön, funktioniert aber dafür unter allen Distributionen gleich.

Die Oberfläche und Bedienlogik ist schwer gewöhnungsbedürftig und könnte eine Frischzellenkur vertragen. Lässt man sich auf die Oberfläche ein, kann man aber damit vernünftig arbeiten.

Warum moneyplex?

Schlicht und einfach, weil es funktioniert. Die Einrichtung meiner Banken klappte problemlos. Girokonten, Tagesgeldkonten, Kreditkarten und Depot wurden erkannt und reibungslos abgerufen. Insbesondere beim Depot versagten die anderen freien Lösungen kläglich, weil es sich die Nummer mit dem Girokonto teilt.

Wer bisher zufrieden mit KMyMoney, GnuCash oder Hibiscus arbeitet, braucht nicht wechseln, aber wer bisher um den Bereich unter Linux eher einen Bogen gemacht hat, sollte sich moneyplex mal angucken. Ich würde nicht mehr ohne arbeiten wollen.

Bilder:

Einleitungs- und Beitragsbild von Mudassar Iqbal via Pixabay 

Der Artikel Proprietäre Softwareperlen für Linux Teil II: moneyplex erschien zuerst auf [Mer]Curius