Über Microservices und Jabberbots

Bei unserer Unternehmensfortbildung am 30. November und 1. Dezember haben wir in kleineren Gruppen an diversen Projekten gearbeitet. Eines der Themen war die Integration unserer intern verwendeten Services (Wiki, Ticketsystem, u.ä.) in einen Jabberbot. Davon versprechen wir uns, dass häufig genutzte Tasks automatisiert werden können, wie etwa:

  • Nach Kunden im CRM suchen, um diese beispielsweise schnell und einfach anrufen zu können.
  • Im Ticketsystem Tickets kommentieren oder schließen.
  • In der Zeiterfassung Zeit auf bestimmte Projekte buchen.

Dass sich über Jabber nicht alle Features der darunter liegenden Tools abbilden lassen, war uns dabei von Anfang an bewusst und sollte auch gar nicht Ziel des Bots sein.

Eine weitere grundsätzliche Herausforderung besteht darin, die abgefragten Informationen so aufzubereiten, dass sie vom Benutzer verwendet werden können. Im Gegensatz zu einer Webseite bietet Jabber nur sehr eingeschränkte Möglichkeiten, Text zu formatieren und zwischen Informationen zu verlinken. Unser Bot wird sich daher auf das wesentliche beschränken müssen. Bei Tickets können so etwa nur die Betreffzeile und einige weitere ausgewählte Attribute angezeigt werden. Wer mehr braucht, gelangt über einen Link zum vollständigen Ticket – im Browser.

Um auch anderen Mitarbeitern die Möglichkeit zu geben, eigene Services in den Bot zu integrieren, haben wir uns nach einer kleinen Architekturphase dazu entschieden, dass der Bot an sich keinerlei eigene Funktionalität beinhaltet, sondern alle seine Befehle an eine Reihe von Microservices delegiert. Diese sollen über eine REST-Schnittstelle angesprochen werden und ihren eigenen Funktionsumfang selbst beschreiben können. Dies ermöglicht dem Bot, beliebige Services zu integrieren, ohne diese im Vorfeld kennen zu müssen. Unsere Benutzer sollen die Möglichkeit haben, für ihren Account eigene Services anhand einer HTTP-URL hinzuzufügen. Der Vorteil hiervon ist, dass jeder spielerisch eigene Services entwickeln und aktivieren kann, ohne über unser Sysadmin-Team Module beim Bot neuladen lassen zu müssen. Auch können Programmierfehler (sleep() im Modul, o.ä.) nicht die Stabilität des Bots gefährden.

Soweit unsere aktuelle Idee. Es gibt zwar auch schon einen sehr frühen Prototypen (auf Basis von errbot), der auch bereits externe Services verwenden kann. Allerdings fehlen auch noch viele Sachen, allen voran natürlich tatsächliche Services für viele unserer Tools. Ich bin aber zuversichtlich, dass wir mit vergleichsweise wenig Entwicklungsaufwand einen einsatzfähigen Bot basteln können. Hoffentlich gibt es dazu dann einmal ein Update inkl. Sourcecode, wenn dies soweit ist.

Gunnar Beutner

Autor: Gunnar Beutner

Vor seinem Eintritt bei NETWAYS arbeitete Gunnar bei einem großen deutschen Hostingprovider, wo er bereits viel Erfahrung in der Softwareentwicklung für das Servermanagement sammeln konnte. Bei uns kümmert er sich vor allem um verschiedene Kundenprojekte, aber auch eigene Tools wie inGraph oder Icinga2.

Unternehmensfortbildung NETWAYS-Style

Als ich am 01. September meine Ausbildung bei NETWAYS begonnen habe, bemerkte ich sofort die kollegiale und angenehme Atmosphäre unter den Kollegen. Diese positive Ausstrahlung hält noch bis heute an, dennoch kommt sie nicht von Ungefähr. Viele Events und Abendveranstaltungen werden immer als Team besucht. Um den Zusammenhalt noch weiter zu stärken gab es vom 30.11 – 01.12 die Premiere der ersten „NETWAYS Startupdays“, welche eine teamübergreifende Zusammenarbeit in den Vordergrund stellen soll.

Im Vorfeld wurden zahlreiche Ideen gesammelt und am Donnerstag vom jeweiligen Ideengeber als Pitch vorgestellt:

  • NWS Marketing, neue Unternehmensbroschüre
  • Interner Shop
  • NETWAYS Konferenz Ticket Plattform
  • Control Panel Raspberry PIs, Dashing Container
  • Icinga 2 SNMP Monitoring
  • Chatbot
  • Donation Backend / Platform based on Blockchain

Nach dem Pitch konnte sich jeder Mitarbeiter einem „Ideenteam“ anschließen, dabei war es wichtig, dass sich Teams aus unterschiedlichen Abteilungen bilden um neue, frische Ideen zu generieren. Gleich nach der Teambildung verteilten sich die Arbeitsgruppen im Büro und haben mit der Arbeit begonnen. Was mir sehr gut gefallen hat, war die interdisziplinäre Arbeit zwischen den technischen und nicht technischen Abteilungen. Durch diesen Mix konnten Ideen gefunden werden welche man durch eventuelle festgefahrene Denkweisen nicht generieren hätte können. Zum Mittagessen gab es eine bayerische Spezialität: Weißwurst mit Breze.  Am zweiten Tag wurde engagiert weitergearbeitet, bis es „NETWAYS-typisch“ ein zünftiges Mittagessen gab. Gut gestärkt ging es in die finale Phase und das NETWAYS-Team hat sich im Schulungs- und Trainingszentrum eingefunden um anschließend die ausgearbeiteten Ideen und bis dahin umgesetzten Themen vorzustellen.

This slideshow requires JavaScript.

 

Philipp Dorschner

Autor: Philipp Dorschner

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, “back to the roots” quasi!

NETWAYS Web Services: Connect to your own Domain!

This entry is part of 10 in the series NETWAYS Web Services

Our team has continued to improve the NETWAYS Web Services products for providing more comfort to our customers. Now any app can be run under its own Domain Name in combination with its own SSL certificate. This option is available for the following products:

The implementation within the product is quite simple. After your app has been created successfully, you will find a new webform in your app’s Access tab. Here is an example of a Request Tracker app:

As the webform shows, customers simply have to enter a registered Domain Name and their SSL Certificate as well as their SSL Key. The implementation in the app will be done by our NWS platform fully automated. Customers only need to take care about the quality and correctness of the certificate and to make sure they enter the DNS record correctly on their Domain Name Server. The IP address needed will be indicated underneath the webform in the information section. Furthermore, it is still possible to set an additional CName for your app. This means that your customized Domain Name and the CName can be used in parallel. Furthermore, the platform generated standard URL will stay valid and customers can always go back to the initial settings by removing their entries from the webform.

After clicking the save button, the app will be restarted and all changes will be taken into production immediately.

The bonus of this option is clear: Anybody working with your apps will be glad to use easy to read and memorize URLs. Furthermore, company identity and culture is even more important today than ever. So why not also provide your SuiteCRM, Rocket.Chat or Nextcloud with a well branded URL?

More information can be found on our NWS homepage, in any of our product sections or by contacting us via the NWS livechat.

Important note: All NWS products are up for a 30 day free trial!

Nicole Lang

Autor: Nicole Lang

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest Bücher und zockt auch mal gerne.

12 years of OSMC – The conference is open

***For English Version please scroll down.***

Nachdem der erste Tag mit vier ausgebuchten Workshops erfolgreich zu Ende ging, gab es beim ersten gemeinsamen Abendessen bereits die Möglichkeit, sich kennen zu lernen und auszutauschen. Zu späterer Stunde wurde die Runde zwar kleiner, aber keinesfalls langweiliger. Weiter ging es in der gemütlich eingerichteten Konferenzlounge, wo der erste Abend seinen fröhlichen Ausklang fand.
Nach der ersten Nacht in den renovierten Hotelzimmern im Holiday Inn, kamen am Mittwoch Morgen die restlichen Teilnehmer gut in Nürnberg an und mit Bernd’s Opening fiel auch endlich der Startschuss für die Vorträge der 12. OSMC. 16 spannende, witzige und lehrreiche Vorträge waren geboten. Hierzu erfahrt ihr alle Details von Dirk und selbstverständlich – wie gewohnt – nach der Konferenz auf unserem YouTube Channel und auf Slideshare.
Neben den Vorträgen ist die OSMC auch für das reichliche Essen bekannt was freilich in diesem Jahr auch nicht zu kurz kam. Nach den gesunden Pausensnacks, konnte beim Mittagessen nach Belieben ausgiebig geschlemmt werden, um sich von den Vorträgen des Vormittags zu erholen und Kraft für den langen Tag zu tanken.
Heute Abend findet schließlich ein weiteres Highlight statt. Die OSMC Abendveranstaltung im Nachtkind meets Guilia. Freut euch schon jetzt auf ein außergewöhnliches Get Together im Herzen Nürnbergs mit einigen spaßigen Überraschungen.  Wer nun an die Evening Events der letzten OSMC’s denkt, wird sich auch auf den traditionellen nächtlichen Marsch von der Abendveranstaltungslocation zum berühmt berüchtigten “Checkpoint Jenny”(*). Die alten Hasen haben bereits entdeckt, dass an besagtem Platz kein Schild mit der Aufschrift “Checkpoint Jenny” zu finden war. Stattdessen prangte hier nun ein “Lambada” Schild. “Häää, wo ist die Jenny?!?”, dachten sich wohl viele. Unsere geliebte Jenny musste den Laden leider verkaufen. Nun gut, selbe Location, neuer Name, aber wir werden bleiben. Und da wir damals eh schon einen 20 Jahresvertrag (mindestens 20) abgeschlossen haben, werden wir auch den neuen Namen akzeptieren und wie gewohnt unsere Tradition fortführen, das wäre doch gelacht!
Wir jedenfalls sind schon voller Vorfreude auf das Event und gespannt, was die nächsten Tage noch so bringen werden. Wir halten euch wie immer auf dem neuesten Stand. 🙂

*: Anm. der Redaktion: Weltberühmte, erstklassige” Late Night Lounge” gegenüber des Konferenzhotels, welche all denjenigen, die von der Abendveranstaltung nicht genug kriegen konnten, stets eine herzliche, gemütliche Atmosphäre bis tief in die Nacht bietet.

___________________________________________________________________________________________________________________________________________________________

After the four fully booked workshops on the first conference day, our first dinner was the perfect setting for getting to know each other and for exchanging experiences. The group shrunk throughout the evening, but our mood didn`t! After dinner we ended the day in the comfortable and cozy conference lounge.

The first night was spent in the newly refurbished rooms of the Holiday Inn, and on Wednesday morning the rest of the attendees arrived in Nuremberg. Bernd`s opening launched the talks in the 12th OSMC. 16 exciting, fun and informative talks awaited us. Dirk will give you all the details on them, and you will of course- as usual- find them on our YouTube channel and on our slide-share after the conference.

Beside the talks the OSMC is known for lots of food, and this year is no exception. After healthy snacks in the breaks, everyone could feast on the generous lunch buffet, and gain strength for the afternoon talks.

Tonight, another highlight takes place. The OSMC evening event at Nachtkind meets Guilia. You can look forward to an extraordinary get together in the heart of Nuremberg with several fun surprises.

But the ones` who look back upon the evening events of the last OSMC`s will remember the nightly walk from the evening event to our notorious “Checkpoint Jenny” (*). Our “regulars” have already noticed that the “Checkpoint Jenny” sign is missing and that a “Lambada” sign hangs in its´ place.  Many attendees thought (and twittered) about the missing Jenny. Unfortunately our beloved Jenny had to sell her bar. So, same location, different name, but we are staying.  And since we “signed” a contract for at least 20 years back then, we will accept the new name and stick with our tradition. We are looking forward to the event, and are excited to see what awaits us in the next few days. We will of course keep you posted!

*: World famous, first class “Late night lounge” vis-à-vis the conference hotel, that offers a welcoming atmosphere for those who didn`t get enough of the evening event.

Julia Hackbarth

Autor: Julia Hackbarth

Julia hat 2017 ihre Ausbildung zum Office Manager bei NETWAYS absolviert und währenddessen das Events&Marketing Team kennen und lieben gelernt. Besondere Freude bereiten ihr bei NETWAYS die tolle Teamarbeit und vielseitige Herausforderungen. Privat nutzt Julia ihre freie Zeit, um so oft wie möglich über’s Handballfeld zu flitzen und sich auszutoben. In ihrer neuen Rolle als Marketing Managerin freut sie sich auf spannende Aufgaben und hofft, dass ihr die Ideen für kreative Texte nicht so schnell ausgehen.

Most awaited OSMC is here!!

Hello! Your long wait is over and finally OSMC day starts. As the day begins with the following workshops Icinga 2 – Distributed Monitoring by Lennart Betz, Ansible – Configuration Management by Thilo Wening, Timesseries & Analysis with Graphite and Grafana by Markus Waldmüller and Elastic Stack – Modern Logfile Management by Thomas Widhalm. WOW! Lot more to know.
Bernd will kick start the Day 2 & 3 with so much exciting talks, Alba Ferri Fitó from Vodafone, Martin Schurz from T-Systems, Rihards Olups from Nokia, James Shubin from Red Hat and the long list of the speakers across the world. The day will follow by “evening event” where you can socialize with the fellow with the same interest.
Last day of conference is the “Hackathon Day”.

Download our OSMC App and Enjoy the conference.

 

 

 

Keya Kher

Autor: Keya Kher

Keya hat im Oktober ihr Praktikum im Marketing bei NETWAYS gestartet. Letzten Dezember startete Sie gemeinsam mit Ihrem Mann das “Abenteuer Deutschland”. Seitdem lernt Sie fleißig deutsch und fühlt sich bei NETWAYS schon jetzt pudelwohl. Sie hat schon viele Erfahrungen im Social Media Marketing und ist gerade dabei auch im Grafikdesign ein Profi zu werden. Wenn sie nicht gerade dabei ist, sich kreativ auszuleben, entdeckt sie die Stadt und schmökert gerne im ein oder anderen Büchlein. Ihr Favorit ist hierbei “The Shiva Trilogy”.

Postfix – SPF, DKIM und DMARC

In der heutigen Zeit werden E-Mails oftmals nicht mehr über einen einzelnen Server verschickt. Wie sollten große Anbieter es sonst schaffen alle E-Mails Ihrer Millionen Nutzer zeitnah abzuhandeln? Spätestens wenn es zu Versand von Newslettern kommt, wird auf mehrere Server zurückgegriffen, damit zum Beispiel E-Mails der Mitarbeiter nicht in einer Warteschlange landen mit 100.000 Newslettern.

Damit diese Server vom Empfänger verifiziert werden können wurden die Mechanismen SPF, sowie DKIM eingeführt. Basierend auf diesen beiden kam später noch DMARC hinzu. Im folgenden möchte ich beschreiben, wie man diese Mechanismen mit Postfix verbindet und entsprechende Informationen publiziert.

 

SPF – Sender Policy Framework

Fangen wir mit SPF an. Bei SPF wird im DNS einer Domain ein TXT-Record hinterlegt. Dort gibt man in einer bestimmten Syntax an, welche Server für diese Domain verifiziert sind. Beispielhaft sieht ein SPF Record in etwa so aus:

v=spf1 ip4:1.2.3.4 ip4:1.2.3.5 a:mx.domain.tld include:other-domain.tld ?all

Dieser sagt aus, dass Mails von der IPv4 Adresse 1.2.3.4 und 1.2.3.5 verschickt werden dürfen, sowie vom Server hinter dem A-Record mx.domain.tld. Zudem sollen die Einstellungen der Domain other-domain.tld included werden und über alle anderen soll keine weiter Aussage getroffen werden mit ?all. Mit “-all” würde man den Versand über alle anderen Mailserver verbieten. Dies kann jedoch zu Problemen führen in Szenarien, wie Beispielsweise bei der Weiterleitung von Mails. Bitte beim include aufpassen, hier gibt man einiges aus der Hand, wenn “other-domain.tld” nicht von einem selbst verwaltet wird.

SPF mit Postfix verbinden

apt-get install postfix-policyd-spf-python

Anschließend öffnen wir die Datei /etc/postfix/master.cf und fügen folgendes hinzu:

postfix-policyd-spf unix – n n – 0 spawn user=policyd-spf argv=/usr/bin/policyd-spf

Und um die policy auch zu verwenden, editieren wir die smtpd_recipient_restrictions in /etc/postfix/main.cf. Bitte beachtet, dass ihr diese unbedingt NACH reject_unauth_destination einfügt.

smtpd_recipient_restrictions = … reject_unauth_destination check_policy_service unix:private/postfix-policyd-spf …

Danach restarten wir postfix. Bei eingehenden Mails sollte nun ein Header enthalten sein, der in etwa wie folgt aussieht:

Received-SPF: Pass (sender SPF authorized) …

Weitere Einstellungen kann man noch unter /etc/postfix-policyd-spf-python/policyd-spf.conf vornehmen.

 

DKIM – DomainKeys Iidentified Mail

DKIM verfolgt ebenfalls das Ziel den Absender zu verifizieren, jedoch mit anderem Ansatz. Dabei werden Headerdaten, die man auch selbst definieren kann mittels eines privaten Schlüssels signiert, während sich der öffentliche Schlüssel im DNS der jeweiligen Domain befindet. Wo dieser genau zu finden ist, bestimmt der Selector – dazu aber gleich noch mehr. Sollte man die Headerdaten, welche signiert werden sollen, selbst definiert, sollte man unbedingt darauf achten, dass es Header sind, die im Verlauf des Versands nicht verändert werden, mehr dazu aber auch im RFC6376 – Abschnitt 5.4.

Beide Verfahren dienen nur dazu den Absender zu verifizieren, es bietet daher keinen Spamschutz im eigentlichen Sinn, wie manche sich vielleicht erhoffen. Sie sind aber relativ schnell eingerichtet und manche Mailserver und Dienste bewerten Mails mit gültigem SPF und DKIM besser, daher ist die Einrichtung kein absolutes “Muss”, aber dennoch ein “Nice-to-have”.

OpenDKIM mit Postfix verbinden

apt-get install opendkim opendkim-tools

Bevor wir nun mit opendkim und postfix weiter machen generieren wir erst einmal Keys, die wir verwenden möchten:

mkdir -p /etc/opendkim/keyfiles/domain1.tld
cd /etc/opendkim/keyfiles/domain1.tld
opendkim-genkey -s mail -d domain1.tld

Damit werden zum einen die Datei mail.private generiert, die den privaten Schlüssel beinhaltet, sowie mail.txt. welche den öffentlichen Schlüssel beinhaltet. Der oben genannte Selector ist “mail”. Den öffentlichen Schlüssel können wir daher schon im DNS der Domain domain1.tld hinterlegen. Dabei handelt es sich um einen Textrecord, der in unserem Beispiel unter mail._domainkey.domain.tld hinterlegt sein muss. Ist dies erledigt geht es weiter in der Konfiguration.

Anschließend ist die Datei /etc/opendkim.conf wichtig, hier wird die zentrale Konfiguration von opendkim vorgenommen. Beispielsweise so kann eine Konfiguration aussehen:

Mode sv
AutoRestart Yes
AutoRestartRate 10/1h
UMask 002
UserID opendkim:opendkim
Syslog yes
KeyTable /etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Canonicalization relaxed/relaxed
LogResults yes
LogWhy yes
SyslogSuccess yes
Socket inet:10080@localhost
SignatureAlgorithm rsa-sha256

Wichtig sind hier zum einen der Port, zum anderen aber natürlich die beiden Parameter KeyTable und SigningTable. Weitere Konfigurationsparameter kann man in der Dokumentation der offiziellen Seite von opendkim nachlesen. Gehen wir aber weiter in unserem Beispiel. Ein Keytable kann z.B. wie folgt aussehen:

mail._domainkey.% %:mail:/etc/opendkim/keyfiles/domain.tld/mail.private

Das “%” in diesem Beispiel ist ein Platzhalter für die jeweilige Domain. Es werden daher alle Domains mit dem privaten Schlüssel signiert, welcher unter /etc/opendkim/keyfiles/domain.tld/mail.private liegt. Als selector wird “mail” verwendet. Sollte man für jede Domain einen anderen Key verwenden, was auch im Normalfall so ist, dann kann man einfach folgende Änderungen vornehmen:

mail._domainkey.domain1.tld domain1.tld:mail:/etc/opendkim/keyfiles/domain1.tld/mail.private
mail._domainkey.domain2.tld domain2.tld:mail:/etc/opendkim/keyfiles/domain2.tld/mail.private

Kommen wir zum SigningTable. Hier wird festgelegt, welche Mails mit welchem Eintrag im KeyTable signiert werden.

*@domain1.tld mail._domainkey.domain1.tld
*@domain2.tld mail._domainkey.domain2.tld

Auch hier kann man aber mit Wildcards und Platzhaltern arbeiten und Beispielsweise folgenden Eintrag setzen.

* mail._domainkey.%

Damit wird jede Mail signiert, mit mail._domainkey.<Name der Domain>

Will man nun noch postfix mit opendkim verbinden, ist es relativ einfach. Hier werden einfach entsprechende Einträge in der /etc/postfix/main.cf angehängt:

milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:10080
non_smtpd_milters = inet:localhost:10080

Danach einfach noch beide Services restarten und schon werden alle Mails entsprechend signiert.

 

DMARC – Domain-based Message Authentication, Reporting & Conformance

Mit DKIM und SPF haben wir schon zwei Mechanismen, mit denen ich als Absender gewisse Informationen weitergeben kann. Was der Empfänger damit anstellt ist jedoch ihm selbst überlassen. Lehnt Mailserver A eine Mail ab, weil der SPF Check fehlschlägt, lässt Mailserver B die Mail mit höherem Spamscore vielleicht durch. Die Bewertung liegt beim Empfänger, der neben SPF und DKIM noch viele weitere Checks implementiert hat um Spam entsprechend abzuwehren. Die Entscheidung, was nun mit der Mail im besten Fall passieren soll, soll DMARC dem Empfänger erleichtern und dem Sender ein wenig mehr Möglichkeiten geben.

Als Absender hinterlege ich im DNS einen entsprechenden Eintrag. Hier gibt es einige Variablen und zugehörige Optionen, die man setzen kann. Der Empfänger hingegen kann diese Empfehlung, die vom wirklichen Inhaber der Domain kommt nutzen um zu entscheiden was er mit der Mail passieren soll. Der DMARC Eintrag von Google sieht Beispielsweise wie folgt aus:

v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-reports@google.com

Dies dient lediglich als Beispiel, wer mehr über die Parameter und Optionen lesen möchte sollte den zugehröigen RFC7489 genauer ansehen

Damit ist auch schon alles getan, was man als Absender machen kann. Wichtig dabei ist der p-Parameter, der auf none (keine Aussage, Entscheidung liegt weiter beim Empfänger), quarantine (Dem Empfänger wird geraten bei einem fehlerhaften Check die Mail als Spam zu betrachten und ggf. in einen Spamordner zu verschieben), oder reject (Die Mail soll auf SMTP Ebene bereits abgelehnt werden) gesetzt werden kann. Es ist schwer hierbei eine Empfehlung oder ähnliches auszusprechen, da es immer auf den Fall an sich ankommt, welche Features man von DMARC im gegebenen Szenario verwenden möchte.

OpenDMARC mit Postfix verbinden

apt-get install opendmarc

Anschließend editieren wir die Datei /etc/default/opendmarc. Hier sind schon einige Beispiele angegeben und sind auch sehr selbsterklärend. Wir tragen folgendes ein:

SOCKET=”inet:12345@localhost”

Nun editieren wir noch die Konfiguration von DMARC, welche unter /etc/opendmarc.conf zu finden ist.

AuthservID mx.domain.tld
PidFile /var/run/opendmarc.pid
RejectFailures false
Syslog true
SyslogFacility mail
TrustedAuthservIDs localhost,mx.domain.tld
IgnoreHosts /etc/opendmarc/ignore.hosts
UMask 002
UserID
FailureReports false
AutoRestart true
HistoryFile /var/log/opendmarc.log
RecordAllMessages true
SoftwareHeader true

Danach editieren wir noch /etc/opendmarc/ignore.hosts

127.0.0.1

Die Option “SoftwareHeader true” ist eher für eure ersten Tests von Vorteil, da ihr in einem weiteren Header die verwendete Version und verarbeitete E-Mail sehen könnt:

DMARC-Filter: OpenDMARC Filter v1.3.1 mx.domain.tld A3DF6FFB75

Anschließend geht es an die Integration von OpenDMARC in Postfix. Da es sich hierbei um einen Mailfilter handelt, wird er an der bereits bekannten Stelle in der main.cf nach unserem DKIM Milter eingetragen.

smtpd_milters = inet:localhost:10080, inet:localhost:12345
non_smtpd_milters = inet:localhost:10080, inet:localhost:12345

Danach starten wir OpenDMARC und restarten Postfix. Nun sollten E-Mails einen Header enthalten, der in etwa so aussieht, falls der DMARC-Check erfolgreich war:

Authentication-Results: mx.domain.tld; dmarc=pass header.from=sender-domain.tld

Angemerkt sei, dass opemdmarc seit Version 1.3 auch selbst SPF Checks ausführen kann, falls es also bei jemandem Probleme geben sollte mit postfix-policyd-spf, kann auch der eigene SPF Check verwendet werden.

Fabian Rothlauf

Autor: Fabian Rothlauf

Fabian kehrte nach seinem fünfjährigen Ausflug nach Weimar zurück in seine Geburtsstadt Nürnberg und hat im September 2016 bei NETWAYS als Systems Engineer im Hosting Support angefangen. Der Mopsliebhaber, der schon seit seinem 16. Lebensjahr ein Faible für Adminaufgaben hat, liebt außerdem Grillen, Metal und Computerspiele. An seinem Beruf reizt ihn vor allem die Abwechslung, gute Weiterentwicklungsmöglichketen und dass es selten mal einen Stillstand gibt. Nachdem er die Berufsschulzeit bereits mit Eric und Georg genießen durfte, freut er sich bei NETWAYS nun auf weitere nette Kollegen, interessante Aufgaben und neue Blickwinkel.