wir betreiben in der firma einen mailgateway. der soll den ganzen schmutz (spam, phishing etc.) soweit wie möglich von den mitarbeitern fernhalten, weil die meistens ziemlich kindlich reagieren und allen scheiss öffnen und auch überall draufklicken was sie in der mailbox oder den emails sehen.
gut, die verlassen sich halt drauf, dass meine kolleginnen, kollegen und ich dass ganze böse zeug von ihnen fernhalten.
damit der mailgateway das schlechte vom guten unterscheiden kann, macht der verschiedene prüfungen. das fängt damit an, dass er erstmal versucht rauszubekommen, wer ihm da eigentlich ein mail andeckeln will und in wessem auftrag der andere mailserver handelt.es hört dann damit auf, dass das einzelne email durchgekramt wird, ob da irgendwas drin ist, was wir nicht haben wollen.
kann man sich so ein bisschen vorstellen, wie passkontrolle und zollkontrolle an einer staatsgrenze (falls sich da noch welche dran erinnern können).
mit dem rauskriegen, wer da ein mail einliefern will und unter wessen flagge fängt das elend schonmal an.
das macht der mailgateway mit hilfe des wunderbaren, mysteriösen dns im grossen, weiten internet. und da muss der mailgateway korrekte und schlüssige angaben finden, sonst kommt ihm die kontaktaufnahme des anderen mailservers suspekt vor. und mit suspekten objekten darf unser mailgateway nicht reden. das haben wir e-mail administratoren ihm verboten.
email braucht im wesentlichen drei angaben aus dem dns, nämlich den / die mx-record(s) der sender domain, die a-records für die versendenden hosts und die ptr-records der sendenden hosts. und die müssen zueinander passen!
optional kann eine vierte angabe aushelfen, der spf-record der domain.
und auch die informationen zu subdomains müssen sich im dns finden lassen! es reicht nicht die infos für firma.com zu veröffentlichen, wenn man auch mails für marketing.firma.com versendet. wenn marketing.firma.com im dns inexistent ist, gibt’s probleme mit der mailzustellung.
im prinzip ist das recht easy, das korrekt einzustellen.
die praxis zeigt gerade bei kmu, die sich in die hände von irgendwelchen dienstleistern oder consultants begeben müssen, weil keine eigene it, ein erschreckendes bild von fehlkonfigurationen.
fast jeden tag schlägt bei uns ein supportfall auf, bei dem wir emails von einem absender nicht entgegennehmen. bei der analyse stellen wir dann bei der hälfte der fälle fest, dass consultants, dienstleister oder admins nicht in der lage sind, valide angaben im dns zu hinterlegen.
ganz besonders schlimm wird’s bei firmen die microsofts office365 benutzen. obwohl microsoft nun fast „grossmuttertauglich“ in den dokus zu office365 beschrieben hat, wie man das setup für email machen soll, machen es die von den kmu beauftragten „office365-consultants“ nicht. man könnte denken, die können nicht lesen oder nur maximal 5 absätze lesen. und wenn ich dann erfahre, was die für ihren pfusch für stundensätze aufrufen, dann verschlägt es mir fast den atem. da wo ich herkomme, nennen wir sowas betrug!
hier nun mein appell an e-mail admins, consultants und sonstige typen die mit der einrichtung von e-mail zu tun haben:
BITTE CHECKT EURE DNS-ANGABEN!
PRÜFT DIE AB UND ZU MAL NACH!
DENKT BEI UMSTELLUNGEN DARAN, DIE DNS-ANGABEN ANZUPASSEN!
und wenn ihr unsicher seid, oder nicht wisst was man da wie einstellen soll: recherchiert im internet oder fragt jemanden, der davon ahnung hat. eure kunden / e-mailbenutzer werden euch dankbar sein.