IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: MailServer (Seite 5 von 7)

DMARC und Mailinglisten: Warum Signaturen brechen und wie ARC das löst

Wer eine strenge DMARC-Policy veröffentlicht und gleichzeitig Mailinglisten nutzt, wird früher oder später feststellen: Die eigenen Mails werden auf der Liste zugestellt, aber beim Empfänger abgelehnt. Das liegt nicht an einem Konfigurationsfehler, sondern an der Art wie Mailinglisten funktionieren.

Das Problem

DKIM signiert nicht nur den Body einer E-Mail, sondern auch bestimmte Header wie den Betreff. Mailinglisten-Manager wie Mailman verändern die Mail aber auf dem Weg zum Empfänger. Sie hängen einen Identifier an den Betreff ([liste-name]), fügen einen Footer mit Abmelde-Link an den Body an und setzen eigene Header. Jede dieser Änderungen bricht die DKIM-Signatur.

SPF schlägt ebenfalls fehl, weil die Mail jetzt vom Listserver kommt und nicht mehr vom Mailserver des ursprünglichen Absenders. Die IP des Listservers steht nicht im SPF-Record der Absender-Domain.

DMARC prüft ob mindestens DKIM oder SPF bestehen und das Alignment stimmt. Beides schlägt fehl. Bei einer Policy von p=reject wird die Mail vom empfangenden Server abgelehnt. Der Absender bekommt einen Bounce, der Empfänger sieht die Mail nie.

Workarounds der Listenbetreiber

Mailinglisten-Manager haben verschiedene Strategien entwickelt um das Problem zu umgehen:

From-RewritingDer Absender wird auf die Listenadresse umgeschrieben. DMARC-Alignment passt dann zur Listendomain. Nachteil: Man sieht nicht mehr wer die Mail geschrieben hat.
Subject-Tag weglassenKein [liste] im Betreff. Schont die DKIM-Signatur, aber der Betreff allein reicht nicht, die Signatur kann trotzdem brechen wenn der Body verändert wird.
Footer weglassenKein Abmelde-Link im Body. Schont DKIM, aber Listenbetreiber brauchen den Footer oft aus rechtlichen Gründen.
DKIM re-signingDie Liste signiert die Mail neu mit ihrer eigenen Domain. Funktioniert, aber die originale Signatur des Absenders geht verloren.

Keiner dieser Workarounds ist sauber. Entweder geht Information verloren oder die Authentizität leidet.

ARC: Die eigentliche Lösung

Authenticated Received Chain (RFC 8617) wurde genau für dieses Problem entwickelt. Die Idee: Jeder Zwischenserver (wie ein Listserver) speichert die Authentifizierungsergebnisse der eingehenden Mail in einem ARC-Header und signiert diesen. Der empfangende Server kann dann die Kette zurückverfolgen und sehen, dass die Mail beim Eintritt in die Liste noch gültig war.

Drei Header bilden die Kette:

ARC-Authentication-Results: i=1; lists.example.org;
  dkim=pass header.d=kernel-error.de;
  spf=pass smtp.mailfrom=kernel-error@kernel-error.com;
  dmarc=pass header.from=kernel-error.de

ARC-Message-Signature: i=1; a=rsa-sha256; d=lists.example.org; ...
ARC-Seal: i=1; a=rsa-sha256; d=lists.example.org; cv=none; ...

ARC-Authentication-Results enthält die Ergebnisse zum Zeitpunkt der Annahme. ARC-Message-Signature signiert die Nachricht in ihrem aktuellen Zustand. ARC-Seal signiert die gesamte ARC-Kette und verhindert Manipulation.

Der empfangende Mailserver prüft die ARC-Kette. Wenn er dem Listserver vertraut und die Kette gültig ist, kann er die Mail trotz gebrochener DKIM-Signatur zustellen. Gmail, Microsoft und Yahoo werten ARC bereits aus. rspamd unterstützt ARC-Validierung und ARC-Signing von Haus aus.

In der Praxis

Mailman 3 unterstützt ARC-Signing. Bei Mailman 2 lässt sich ARC über einen vorgeschalteten Milter nachrüsten. Wer rspamd als Milter einsetzt, kann ARC dort aktivieren und braucht keinen separaten Dienst.

Die Empfehlung für Listenbetreiber: ARC-Signing aktivieren und den Betreff nicht verändern (statt [liste] den List-Id-Header nutzen, den alle modernen Mailclients auswerten können). Für Absender mit p=reject: ARC reduziert das Problem erheblich, löst es aber nur wenn die Gegenseite ARC auch prüft. In der Übergangsphase hilft es, bekannte Listserver per DMARC-Whitelist von der Policy auszunehmen.

Fragen? Einfach melden.

Postfix mit DANE und DNSSEC absichern

Meine Domains sind schon lange per DNSSEC gesichert. Für den Webserver hatte ich auch schnell TLSA-Records veröffentlicht, damit die TLS-Verbindung per DANE abgesichert ist. Seit Postfix 2.11 beherrscht auch der MTA die Prüfung von TLSA-Records — damit lässt sich ausgehende E-Mail-Verschlüsselung kryptographisch verifizieren, ohne sich auf das CA-System verlassen zu müssen.

Postfix konfigurieren

Zwei Zeilen in der main.cf reichen, damit Postfix beim Versand TLSA-Records prüft:

postconf -e "smtp_dns_support_level = dnssec"
postconf -e "smtp_tls_security_level = dane"

smtp_dns_support_level = dnssec weist den SMTP-Client an, DNSSEC-validierte DNS-Antworten zu verlangen. smtp_tls_security_level = dane aktiviert die TLSA-Prüfung — Postfix sucht automatisch nach TLSA-Records für den Zielserver. Gibt es keinen TLSA-Record oder kein DNSSEC, fällt Postfix auf opportunistisches TLS zurück. Die Kommunikation mit Servern ohne DANE leidet also nicht. Details stehen in der Postfix DANE-Dokumentation.

TLSA-Record erstellen

Der TLSA-Record enthält einen Hash des TLS-Zertifikats (oder des Public Keys), den der Empfänger-Mailserver im DNS veröffentlicht. So erzeugt man den SHA-256-Hash des Public Keys aus dem Zertifikat:

openssl x509 -in postfix.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256

Den Hash trägt man als TLSA-Record in die DNS-Zone ein — für Port 25 (SMTP) und optional Port 465 (Implicit TLS):

_25._tcp.smtp.kernel-error.de.  3600 IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1
_465._tcp.smtp.kernel-error.de. 3600 IN TLSA 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Die Felder 3 1 1 bedeuten: DANE-EE (End Entity, kein CA-Vertrauen nötig), SPKI (nur Public Key, nicht das ganze Zertifikat), SHA-256. Der TTL von 3600 Sekunden ist bewusst kurz — bei einem Zertifikatswechsel soll der alte Record schnell ablaufen. Mehr zum Aufbau von TLSA-Records steht in RFC 7672.

Testen

Mit posttls-finger (Teil von Postfix) lässt sich prüfen, ob die DANE-Verifikation funktioniert:

posttls-finger -t30 -T180 -c -L verbose,summary kernel-error.de

Die entscheidende Zeile in der Ausgabe:

Verified TLS connection established to smtp.kernel-error.de[...]:25:
  TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Verified statt Untrusted — der TLSA-Record stimmt mit dem Zertifikat überein, die Verbindung ist DANE-verifiziert. Im Postfix-Log sieht man denselben Unterschied:

smtp[3779]: Verified TLS connection established to mx02.example.de[...]:25
smtp[3779]: Untrusted TLS connection established to smtp2.example.de[...]:25

Verified = DANE-geprüft und in Ordnung. Untrusted = TLS aktiv, aber kein gültiger TLSA-Record vorhanden — die Verschlüsselung funktioniert trotzdem, nur ohne kryptographische Verifikation des Zertifikats.

Warum DANE besser ist als das CA-System

DANE verankert das Vertrauen im DNS statt bei Certificate Authorities. Der Domaininhaber veröffentlicht den Hash seines Zertifikats selbst — DNSSEC schützt den Record vor Manipulation. Keine CA kann ein falsches Zertifikat für die Domain ausstellen und damit die Verbindung aufbrechen. Das Ganze kostet nichts außer einem DNS-Record und funktioniert für jeden, der DNSSEC betreibt.

Zum Vergleich: Das damalige „E-Mail made in Germany“ (EmiG) setzte auf eine TÜV-Zertifizierung, die sich nur große Provider leisten konnten. Sicherheit nur für Unternehmen mit Budget — das ist das Gegenteil von dem, was ich unterstütze.


Update August 2014: Ich habe Mailgraph um DANE-Graphen erweitert, um den Anteil verifizierter Verbindungen zu visualisieren.

Siehe auch: TLSA/DANE-Records prüfen, TLSA- und DANE-Records manuell prüfen: Schritt für Schritt mit OpenSSL, Postfix und DANE: „Server certificate not verified" debuggen, Postfix: Eingehende E-Mails ohne TLS ablehnen

Fragen? Einfach melden.

Grobe Schnitzer im der DNS Konfiguration testen.

Da habe ich doch gerade noch einen Tipp bekommen (danke Felix). Möchte man „mal eben“ seine DNS Konfiguration inkl. Mailserver testen wird einem ein solcher Test über die Webseite www.dnsinspect.com angeboten.

Der Test geht natürlich jetzt nichts ins absolute Detail aber die ganz groben Fehler findet er dann schon. Auch so Dinge wie PRT – HELO/EHLO – Hostname oder postmaster und abuse Adresse. Zu gesprächige Nameserver usw. usw. usw…

Einfach zum Spaß mal eure Domain reinwerfen und schauen was passiert .-)

http://www.dnsinspect.com/kernel-error.de

Fragen? Einfach melden.

Schönes Tool zum Testen / Prüfen seines SPF oder DMARC RECORDS

Die Webseite https://dmarcian.com stellt zwei sehr schöne Möglichkeiten zur Verfügung um seinen >> DMARC-RECORD << und oder seinen >> SPF-RECORD << zu testen.

Am besten gefällt mir dabei der SPF Test, denn dieser sammelt auch gleich alle nötigen DNS Lookups zusammen und visualisiert sie einem recht ansprechend.

Bunte Bilder *wwwööööööööööhhhhhhhhhyyyyyyyyy*

Ja, wenn es hilft schick mir eine E-Mail und ich sage dir ob deine Konfiguration sauber ist.

Viel Spaß!

Siehe auch: SPF-Record einrichten

Fragen? Einfach melden.

SPF-Record einrichten: Wie du festlegst, wer für deine Domain Mails versenden darf

Siehe auch: SPF Records

SPF (Sender Policy Framework, RFC 7208) legt per DNS fest, welche Server für eine Domain E-Mails versenden dürfen. Empfangende Mailserver prüfen bei jeder eingehenden Mail, ob die IP-Adresse des sendenden Servers im SPF-Record der Absenderdomain steht. Steht sie nicht drin, wird die Mail je nach Policy abgewiesen oder markiert.

Aufbau eines SPF-Records

Ein SPF-Record ist ein TXT-Record im DNS der Domain. Ein typisches Beispiel:

kernel-error.de.  IN  TXT  "v=spf1 ip4:148.251.30.205 ip6:2a01:4f8:262:4716::25 mx -all"

Wichtig: Der alte DNS-Record-Typ IN SPF ist seit RFC 7208 (2014) abgeschafft. Nur IN TXT verwenden.

Mechanismen

Jeder Mechanismus definiert eine Regel, gegen die die IP des sendenden Servers geprüft wird:

ip4:148.251.30.205Diese IPv4-Adresse darf senden. Auch Netze möglich: ip4:148.251.30.0/24
ip6:2a01:4f8:...Diese IPv6-Adresse darf senden
mxAlle IP-Adressen der MX-Records der Domain dürfen senden
aDie IP-Adresse des A/AAAA-Records der Domain darf senden
a:smtp.example.deDie IP-Adresse eines bestimmten Hosts darf senden
include:example.deDie SPF-Policy einer anderen Domain mit einbeziehen (z.B. für externe Dienstleister)
redirect=example.deGesamte SPF-Policy von einer anderen Domain übernehmen

Nicht mehr verwenden: Der ptr-Mechanismus ist seit RFC 7208 explizit nicht empfohlen. Er erzeugt unnötige Reverse-DNS-Abfragen und ist fehleranfällig.

Qualifier: Was passiert bei einem Treffer?

Vor jedem Mechanismus kann ein Qualifier stehen, der bestimmt, was mit der Mail passiert:

+ (Pass)Erlaubt (Standard, wenn kein Qualifier angegeben)
- (Fail)Nicht erlaubt — Mail soll abgewiesen werden
~ (SoftFail)Nicht erlaubt, aber nicht hart ablehnen — Mail markieren
? (Neutral)Keine Aussage — wie kein SPF

Hardfail oder Softfail?

Am Ende des SPF-Records steht der Catch-All-Mechanismus all mit einem Qualifier:

  • -all (Hardfail) — alle Server die nicht explizit gelistet sind, dürfen nicht senden. Empfänger soll ablehnen.
  • ~all (Softfail) — alle nicht gelisteten Server sind verdächtig, aber nicht definitiv verboten. Mail wird zugestellt, aber markiert.

In der Praxis: -all ist die klare Empfehlung, wenn man weiß, welche Server für die Domain senden. ~all war lange der konservative Ansatz, weil manche Empfänger SPF-Fails zu aggressiv behandelten. Seit DMARC den Umgang mit SPF-Ergebnissen standardisiert hat, ist das kein Argument mehr. Wer DMARC einsetzt, sollte -all verwenden.

Das 10-Lookup-Limit

RFC 7208 erlaubt maximal 10 DNS-Abfragen pro SPF-Prüfung. Jeder include, mx, a und redirect zählt als Lookup. ip4 und ip6 verursachen keine Abfrage, die stehen direkt im Record.

Das wird schnell zum Problem, wenn man externe Dienstleister einbindet. Ein include:_spf.google.com zieht allein schon 3-4 weitere Lookups nach sich. Wer Office 365, Google Workspace und einen Newsletter-Dienst kombiniert, sprengt das Limit leicht. Die Fehlermeldung:

PermError SPF Permanent Error: Too many DNS lookups

Lösung: Den SPF-Record so schlank wie möglich halten. Wo möglich ip4/ip6 statt include verwenden, das verbraucht keine Lookups. Externe Dienstleister nach IP-Ranges fragen statt blind deren Include-Ketten zu übernehmen.

SPF-Record testen

# SPF-Record abfragen
dig TXT kernel-error.de +short

# Ergebnis prüfen — sollte den v=spf1 Record zeigen
# Mehrere TXT-Records sind normal (SPF, DMARC, DKIM Policy etc.)

Für einen vollständigen Check mit Lookup-Zählung eignen sich Online-Tools wie kitterman.com/spf oder mxtoolbox.com. Die zeigen auch verschachtelte Includes auf und warnen bei Überschreitung des 10-Lookup-Limits.

SPF allein reicht nicht

SPF prüft die IP-Adresse gegen den Envelope-From (die Adresse aus dem SMTP-MAIL FROM-Kommando), nicht gegen den From:-Header, den der Empfänger sieht. Ein Angreifer kann also eine Mail mit gefälschtem From:-Header senden, solange der Envelope-From eine Domain ist, die er kontrolliert. Der Empfänger sieht den gefälschten Absender, SPF sagt trotzdem „Pass“.

Genau dieses Problem löst DMARC: Es prüft, ob die Domain im From:-Header mit der SPF-Domain (Alignment) oder der DKIM-Signatur übereinstimmt. Erst SPF + DKIM + DMARC zusammen ergeben eine vollständige E-Mail-Authentifizierung. Fragen? Einfach melden.

DMARC einrichten: Policy, Alignment und Reporting für deine Domain

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) baut auf SPF und DKIM auf. Es löst zwei Probleme, die SPF und DKIM allein offen lassen: Erstens kann der Absender festlegen, was mit Mails passieren soll, die weder SPF noch DKIM bestehen. Zweitens bekommt der Absender Berichte darüber, wie seine Mails bei den Empfängern ankommen.

DMARC-Record aufbauen

DMARC wird als TXT-Record unter _dmarc.domain.de im DNS veröffentlicht. Ein Beispiel:

_dmarc.kernel-error.de.  IN TXT  "v=DMARC1; p=quarantine; adkim=s; aspf=s; pct=100; rua=mailto:postmaster@kernel-error.de; ruf=mailto:postmaster@kernel-error.de"

Die einzelnen Parameter:

v=DMARC1Protokollversion (immer DMARC1)
p=quarantinePolicy für die Hauptdomain (siehe unten)
sp=quarantinePolicy für Subdomains (optional, erbt sonst von p)
adkim=sDKIM-Alignment: s = strict, r = relaxed
aspf=sSPF-Alignment: s = strict, r = relaxed
pct=100Prozent der Mails, auf die die Policy angewendet wird
rua=mailto:...Adresse für aggregierte Berichte (täglich, XML)
ruf=mailto:...Adresse für forensische Berichte (pro Vorfall)

Alignment: Wofür DMARC wirklich da ist

SPF prüft den Envelope-From, DKIM prüft die signierende Domain. Beides sagt nichts über den From:-Header aus, den der Empfänger tatsächlich sieht. DMARC schließt diese Lücke mit dem sogenannten Alignment: Es verlangt, dass mindestens eine der beiden Prüfungen (SPF oder DKIM) zur Domain im From:-Header passt.

Strict (s) bedeutet: Die Domains müssen exakt übereinstimmen. Relaxed (r) erlaubt auch Subdomains (z.B. mail.kernel-error.de passt zu kernel-error.de). Für die meisten Setups ist strict die richtige Wahl, solange alle ausgehenden Mails über die Hauptdomain signiert werden.

Policy-Stufen

Der p-Parameter legt fest, was der Empfänger mit Mails machen soll, die weder SPF noch DKIM bestehen:

p=noneNur beobachten, nichts tun. Gut zum Einstieg, um über die Reports erstmal zu sehen was passiert.
p=quarantineAls Spam markieren. Die Mail wird zugestellt, landet aber im Spam-Ordner.
p=rejectAblehnen. Die Mail wird gar nicht erst angenommen.

Der empfohlene Weg: Mit p=none anfangen und die Reports auswerten. Wenn alles sauber aussieht, auf quarantine hochdrehen. Wenn auch das stabil läuft, auf reject gehen. Mit pct kann man die Policy schrittweise ausrollen, z.B. erst auf 10% der Mails anwenden und dann langsam erhöhen.

Reporting

Die aggregierten Reports (rua) kommen einmal am Tag als komprimierte XML-Dateien per Mail. Darin steht, welche IPs Mails mit deiner Domain versendet haben und ob SPF/DKIM bestanden oder durchgefallen sind. Das ist Gold wert: Man sieht sofort, ob jemand die Domain missbraucht oder ob ein legitimer Dienst falsch konfiguriert ist.

Die XML-Dateien sind nicht besonders lesefreundlich. Zum Auswerten eignet sich dmarcian.com (XML hochladen, menschenlesbare Übersicht bekommen) oder man baut sich eine eigene Auswertung. Für größere Setups gibt es Open-Source-Tools wie parsedmarc, die Reports automatisch verarbeiten und in Elasticsearch oder eine Datenbank schieben.

Die forensischen Reports (ruf) liefern Details zu einzelnen fehlgeschlagenen Mails. In der Praxis schicken die meisten großen Provider (Google, Microsoft) allerdings keine forensischen Reports mehr, aus Datenschutzgründen. Die aggregierten Reports reichen für die meisten Fälle aus.

Cross-Domain-Reporting

Wer mehrere Domains betreibt und die Reports zentral an eine Adresse schicken will, muss aufpassen. Soll der Report für kernel-error.com an postmaster@kernel-error.de gehen, muss die Empfänger-Domain das erlauben. Dafür braucht es einen zusätzlichen TXT-Record in der Zone von kernel-error.de:

kernel-error.com._report._dmarc.kernel-error.de.  IN TXT  "v=DMARC1"

Dieser Record sagt: „kernel-error.de akzeptiert DMARC-Reports für kernel-error.com.“ Ohne diesen Eintrag ignorieren Empfänger die Report-Adresse, weil sie in einer fremden Domain liegt.

DMARC testen

# DMARC-Record abfragen
dig TXT _dmarc.kernel-error.de +short

Einen vollständigen Check inklusive SPF und DKIM bekommt man über mxtoolbox.com oder ähnliche Online-Tools. Einfach eine Testmail an die Prüfadresse schicken und den Report abwarten.

Das Zusammenspiel

DMARC funktioniert nur zusammen mit SPF und DKIM. Alle drei zusammen ergeben eine vollständige E-Mail-Authentifizierung: SPF legt fest welche Server senden dürfen, DKIM signiert die Mail kryptografisch und DMARC verknüpft beides mit einer Policy und liefert Feedback. Wer das Ganze mit rspamd betreibt, hat Auswertung und Enforcement gleich mit dabei. Fragen? Einfach melden.

Outlook Autodiscover für IMAP/SMTP: Wie die automatische Kontoeinrichtung funktioniert

Benutzer wollen ihr E-Mail-Postfach einrichten. Sie geben E-Mail-Adresse und Passwort ein — den Rest soll der Client erledigen. Bei Exchange mit Active Directory funktioniert das seit Jahren automatisch. Aber was, wenn der Mailserver Postfix und Dovecot heißt und kein Exchange in Sicht ist?

Microsoft Outlook unterstützt auch für IMAP und SMTP die automatische Konfiguration per Autodiscover. Man muss nur wissen, wo Outlook nachschaut — und dort die richtigen Antworten bereithalten.

Outlook Autodiscover für IMAP und SMTP – automatische Mailkonto-Konfiguration über DNS, HTTPS und XML

Wo Outlook nach der Konfiguration sucht

Outlook arbeitet eine feste Reihenfolge ab. Sobald ein Schritt eine gültige Konfiguration liefert, ist die Einrichtung fertig. Schlägt ein Schritt fehl, geht es zum nächsten:

1. Active Directory (SCP) — Ist der Rechner Domänenmitglied, fragt Outlook per LDAP nach einem Service Connection Point. Dort steht normalerweise die URL des Exchange-Servers. Für reine IMAP-Setups irrelevant.

2. HTTPS auf der E-Mail-Domain — Outlook versucht https://example.org/autodiscover/autodiscover.xml. Funktioniert nur, wenn der Webserver der Domain den Pfad bedient.

3. HTTPS auf autodiscover.<domain> — Outlook versucht https://autodiscover.example.org/autodiscover/autodiscover.xml. Das ist der Weg, den wir nutzen. Ein Webserver unter diesem Hostnamen mit gültigem TLS-Zertifikat — mehr braucht es nicht.

4. HTTP-Redirect — Outlook versucht http://autodiscover.example.org/autodiscover/autodiscover.xml und folgt einem 301/302-Redirect. Weniger sicher, aber ein Fallback.

5. DNS SRV-Record — Outlook fragt _autodiscover._tcp.example.org und folgt dem SRV-Eintrag. Bei einem SRV-Verweis auf eine andere Domain zeigt Outlook eine Sicherheitsabfrage: „Konfiguration von dieser Webseite zulassen?“ Einmalig bestätigen, danach läuft es.

6. Lokale XML-Datei — Outlook sucht auf dem Rechner nach einer vorinstallierten Konfigurationsdatei. Für Firmenumgebungen mit Software-Verteilung relevant.

7. Manueller Assistent — Wenn nichts funktioniert hat, öffnet Outlook den Konfigurationsassistenten. Genau das wollen wir vermeiden.

Was Outlook per POST schickt und erwartet

Outlook macht einen HTTP-POST auf /autodiscover/autodiscover.xml und schickt im Body ein XML mit der E-Mail-Adresse des Benutzers:

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
  <Request>
    <EMailAddress>benutzer@example.org</EMailAddress>
    <AcceptableResponseSchema>
      http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a
    </AcceptableResponseSchema>
  </Request>
</Autodiscover>

Die Antwort enthält IMAP- und SMTP-Einstellungen. Der Clou: Weil Outlook die E-Mail-Adresse im POST mitschickt, kann ein PHP-Script sie auslesen und als <LoginName> in die Antwort einsetzen. Ohne diesen Trick würde Outlook nur den Teil vor dem @ als Benutzernamen verwenden — bei Mailservern, die die volle E-Mail-Adresse als Login erwarten, ein Problem.

Multi-Domain per DNS SRV-Record

Ein Autodiscover-Webserver reicht für beliebig viele Maildomains. Jede zusätzliche Domain braucht nur einen SRV-Record im DNS:

_autodiscover._tcp.example.org.  IN SRV 0 0 443 autodiscover.kernel-error.de.

Outlook folgt dem SRV-Record, zeigt einmalig die Sicherheitsabfrage, und hat danach die komplette Konfiguration. Das PHP-Script auf dem Zielserver beantwortet Anfragen für alle Domains — die E-Mail-Adresse kommt ja im POST mit.

Umsetzung und aktuelle Konfiguration

Die konkrete Einrichtung — nginx-Konfiguration, PHP-Script und DNS — beschreibe ich im Nachfolgebeitrag: Outlook Autodiscover für IMAP und SMTP konfigurieren. Dort steht auch das Update von 2026 mit den Korrekturen am PHP-Script (GET-Absicherung, XSS-Schutz) und der Zusammenlegung mit Thunderbird Autoconfig.

Wer seine Konfiguration testen will: Microsoft bietet unter testconnectivity.microsoft.com den „Microsoft Remote Connectivity Analyzer“ an. Dort den Autodiscover-Test auswählen und die eigene E-Mail-Adresse eingeben.

Fragen? Gerne per Kontaktformular.

Nachfolger für RFC-Ignorant.Org

Na also…

Es ist ein ordentlicher Nachfolger für rfc-ignorant.org gefunden! Der Hosting-Provider manitu hat auch bereits eine Domain gestellt: rfc-ignorant.de

Noch ist die Liste „leer“. Keine Anfrage wird daher negativ bewertet. Denn noch kann man sie bereits in seine Konfiguration aufnehmen. Die neuen Zonen sind:

Old zone New zone
dsn.rfc-ignorant.org > dsn.bl.rfc-ignorant.de
postmaster.rfc-ignorant.org > postmaster.bl.rfc-ignorant.de
abuse.rfc-ignorant.org > abuse.bl.rfc-ignorant.de
whois.rfc-ignorant.org > whois.bl.rfc-ignorant.de
bogusmx.rfc-ignorant.org > bogusmx.bl.rfc-ignorant.de
fulldom.rfc-ignorant.org > fulldom.bl.rfc-ignorant.de

 

So gefällt es mir.

 

 

Siehe auch: Die Akte IGNORANT

Fragen? Einfach melden.

Postfix nach hause telefonieren

Ich war mal wieder auf so einem lustigen Postfixvortrag… Die verschiedenen Möglichkeiten der Spamabwehr waren natürlich wieder Thema. Der Vortragende ist dabei tierisch auf sender adress verification abgegangen. Er hat es quasie als Lösung aller Probleme verkauft. Puhh, ich habe mich bald an der Mate verschluckt. Ich mein… OK in ganz besonderen Fällen kann es möglicherweise helfen (mir fallen zwar gerade keine ein aber…) und früher ging da vielleicht mal was. Im Grunde macht diese Art der „Spamabwehr“ nur Stress.

Sender adress verification / callback verification / callout verification???

Versucht jemand eine E-Mail einzuliefern, versucht Postfix vor der Annahme der E-Mails zuerst selbst eine E-Mail an den Absender zuzustellen. Klappt dieses nimmt er die E-Mail an und wenn es nicht geht, dann nicht. Kommt also eine E-Mail vom Absender: spam@spamgott.net versucht Postfix diesem Absender eine E-Mail zuzustellen. Es wird also geprüft ob es die Domain überhaupt gibt, dann wird geschaut ob es einen MX-RECORD gibt, dann wird versucht eine Verbindung zu diesem Server aufzubauen. Ist es nicht möglich würde Postfix die jeweilige Meldung an den einliefernden „durchreichen“. Damit würden E-Mails nicht abgewiesen nur weil der Maileingangsserver des vermeintlichen Absenders gerade Stress hat oder dort Greylisting aktiviert ist. Wäre es möglich eine E-Mail einzuliefern wird die E-Mail erst überhaupt angekommen und die Absenderadresse in folgender Datei abgelegt:

/var/lib/postfix/verify_cache.db

Aktiviert wird der ganze Foo in der Postfix Konfigurationsdatei /etc/postfix/main.cf:

smtpd_recipient_restrictions =
….........,
reject_unverified_sender,
….........,

Klingt alles erst einmal ganz gut, oder? Ne überhaupt nicht…. Die Idee ist nett aber wenn man sich nun mal vorstellt eine Domain wird zum versenden von Spam missbraucht, dann schlagen bei diesem Server nicht nur die ganzen Bounce E-Mails auf, sondern zusätzlich noch der ganze Verification Krims. Es soll auch Absender geben die man wirklich nicht erreichen kann (sinnfrei, ist mir auch klar). Diese E-Mails kommen natürlich nicht an…. Versucht immer mal wieder jemand E-Mails an Empfänger zuzustellen, welche es nicht gibt, machen Mailserver gerne mal für eine gewisse Zeit dicht. Was ebenfalls nicht gut ist.

Und mal im Ernst, niemand will wirklich Strom, Traffic und Hardwareleistung bezahlen für den Mist. Wenn man sich einfach nur unnötige Last auf sein System ziehen will, wäre SETI@home mein Tipp! Mit etwas Hirnschmalz in seine Konfiguration gibt es deutlich bessere und effektivere Möglichkeiten. Dieser Weg ist einfach mal wieder der Versuch die Arbeit anderen aufzuhalsen.

Siehe auch: SPF-Record einrichten

Fragen? Einfach melden.

Zu pingelig?

Klar, nach RFC müssen bestimmte Dinge bei einem Mailserver zusammenpassen.

Nach RFC1912 – Section 2.1 muss der Rückwärts aufgelöster Hostname zu dessen Vorwärtsauflösung passen.

Als Beispiel:
Wenn ich nachfrage welcher DNS Name zur IPv4 Adresse 10.2.3.4 gehört und darauf die Antwort bekomme, es ist: test.example.com…. Ja dann muss auf die Frage welche IPv4 Adresse zum DNS Namen test.example.com gehört auch die Antwort kommen: 10.2.3.4

Aus Sicht des testenden ist die Wahrscheinlichkeit schon höher dass beide Systeme unter der gleichen Kontrolle stehen. Zusätzlich haben Bots in einem Botnetz extrem selten die Möglichkeit diese Einträge passend zu setzten und der Administrator des Systems hält sich nicht nur die RFCs sondern konfiguriert zudem ordentlich. Es ist daher ebenfalls wahrscheinlich dass er sich bei seinen sonstigen Konfigurationen auch Mühe gegeben hat. Dieses lässt sein System zusätzlich sicherer gegen Missbrauch erscheinen.

Weiter im Text…
Denn nach RFC 2821, Section 3.6 muss der im HELO/EHLO angegebene DNS Name nicht nur ein gültiger Fully Qualified Domain Name (FQDN) sein, sondern er muss zusätzlich zum Hostname des einliefernden Mailservers passen. So lässt sich nun ersehen dass nicht nur IP und DNS unter der gleiche Kontrolle zu sein scheinen, sondern gleichfalls das Mailsystem.

Der Admin scheint also zu wissen was er tut und hat auch die Kontrolle über das System.

Ich prüfe dieses nun bei jeder einzuliefernden E-Mail. Ist nicht alles korrekt, wird die E-Mail abgelehnt. In den letzten Wochen tauchen genau hier gehäuft Unstimmigkeiten auf und dieses nicht bei kleinen „Wurstbuden“ sondern auch bei den ganz Großen! Natürlich ist es kein zwingender Grund E-Mails auf dieser Basis abzuweisen…. Da die Sysadmins der Mailserver, vor allem der ganz GROSSEN, ja Fachleute sind… Sollte man von diesen erwarten können sich an diese einfachen Vorgaben zu halten, oder? — Oder ist es wirklich zu pingelig?

 

 

 

Siehe auch: DMARC einrichten

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑