|
| 1 | +# info@pycologne.de kommt wieder an |
| 2 | + |
| 3 | +Wer uns in den letzten Jahren an `info@pycologne.de` geschrieben hat, hat |
| 4 | +niemanden erreicht. Nicht "wir haben es übersehen", sondern buchstäblich |
| 5 | +niemanden: der Mailserver hinter der Domain hat jede Nachricht an diese Adresse |
| 6 | +abgelehnt. Seit heute gibt es dahinter ein echtes Postfach, und die Adresse |
| 7 | +steht wieder auf unserer [Kontaktseite](/contact). |
| 8 | + |
| 9 | +Aufgefallen ist es beim Aufräumen unserer alten Kanäle. In unserem GitHub-Profil |
| 10 | +und auf unserer Facebook-Seite stand `info@pycologne.de` als offizieller |
| 11 | +Kontakt, also haben wir das Naheliegende getan und einmal selbst hingeschrieben. |
| 12 | +Zurück kam kein Postfach, sondern eine Fehlermeldung: |
| 13 | + |
| 14 | +``` |
| 15 | +554 5.7.1 <info@pycologne.de>: Relay access denied |
| 16 | +``` |
| 17 | + |
| 18 | +Das ist die Antwort eines Mailservers, der für eine Domain zwar zuständig |
| 19 | +gemeldet ist, für die angefragte Adresse aber kein Ziel kennt. Die MX-Einträge |
| 20 | +der Domain zeigten auf Server, die niemand aus der heutigen Orga kennt und auf |
| 21 | +die niemand von uns Zugriff hat, freundlich betreut von jemandem, der irgendwann |
| 22 | +in der Vergangenheit einmal geholfen hat. Damit war die Adresse jahrelang eine |
| 23 | +Attrappe. Wie viele Anfragen von Vortragswilligen, Sponsoren oder |
| 24 | +Interessierten dort verpufft sind, wissen wir nicht und werden es auch nie |
| 25 | +erfahren. |
| 26 | + |
| 27 | +Der Weg heraus war der gleiche wie bei der Website: nicht mehr an einer |
| 28 | +Einzelperson hängen, sondern an einer Organisation. Die Website läuft seit Mai beim |
| 29 | +[Python Software Verband](https://python-verband.org/), der uns das Hosting |
| 30 | +sponsort, und dort liegt jetzt auch die Mail. Betrieben wird sie von |
| 31 | +[Flying Circus](https://flyingcircus.io/), gehostet in Deutschland, mit einem |
| 32 | +Webmail-Zugang, damit sich von der Adresse auch antworten lässt und nicht bloß |
| 33 | +weiterleiten. |
| 34 | + |
| 35 | +Der interessante Teil steckt danach im Kleingedruckten. Eine Mail zu empfangen |
| 36 | +ist einfach, eine Mail so zu versenden, dass die Gegenseite sie nicht für |
| 37 | +Fälschung hält, ist es nicht. Drei Einträge im DNS regeln das: |
| 38 | + |
| 39 | +- **SPF** sagt, welche Server im Namen der Domain senden dürfen. |
| 40 | +- **DKIM** hängt jeder Mail eine Signatur an, die zu einem Schlüssel im DNS |
| 41 | + passen muss. |
| 42 | +- **DMARC** sagt, was mit Mail passieren soll, die daran scheitert. Unser Eintrag |
| 43 | + steht auf `p=reject`, also: wegwerfen. |
| 44 | + |
| 45 | +Das ist die scharfe Einstellung, und wer sie setzt, kann sich damit auch selbst |
| 46 | +aussperren. Deshalb war die letzte Prüfung nicht "ist die Mail angekommen", |
| 47 | +sondern ein Blick in die Kopfzeilen der angekommenen Mail: |
| 48 | + |
| 49 | +``` |
| 50 | +dkim=pass spf=pass dmarc=pass |
| 51 | +``` |
| 52 | + |
| 53 | +Diese drei Wörter kann man in jedem Mail-Programm selbst nachsehen, meist unter |
| 54 | +"Original anzeigen" oder "Quelltext". Sie stehen in der Zeile |
| 55 | +`Authentication-Results`, und sie sind das Urteil des empfangenden Servers |
| 56 | +darüber, ob er die Absenderadresse glaubt. Bei uns steht dort jetzt dreimal |
| 57 | +`pass`, auch für eine Nachricht, die über die Weiterleitung gelaufen ist. |
| 58 | + |
| 59 | +Was noch fehlt: die weiteren Postfächer für die Orga, damit nicht wieder alles an |
| 60 | +einer Person hängt. Genau dieser Fehler hat uns die Adresse gekostet. |
0 commit comments