Autor: Carsten 23. Februar 2015 2 Kommentare

Seit wir unseren neuen Server, einen VPS bei Contabo haben, bekommen wir für angenehm wenig Geld relativ viel Leistung. Auf dem VPS betreiben wir auch einen Mailserver, der (basierend auf einem Debian) für verschiedene Domains Mails ausliefert und annimmt.

Die Tage fiel mir auf, dass einige Mails, vornehmlich solche an @gmail.com oder @live.de mit Fehlermeldungen zurückkamen:

empfaenger@gmail.com
SMTP error from remote mail server after end of data:
host gmail-smtp-in.l.google.com [2a00:1450:4013:c01::1b]:
550-5.7.1 [2a02:c200:1:10:3:0:6175:1 12] Our system has detected that this
550-5.7.1 message is likely unsolicited mail. To reduce the amount of spam sent
550-5.7.1 to Gmail, this message has been blocked. Please visit
550-5.7.1 http://support.google.com/mail/bin/answer.py?hl=en&answer=188131 for
550 5.7.1 more information. lj18si16872950wic.58 - gsmtp

In erster Instanz sah es so aus, als würden unsere Mails als SPAM klassifiziert. Die Ursachenforschung begann.

Google verwendet diverse Dienste/Protokolle, um festzustellen, ob es sich bei einer eingehenden Mail um SPAM oder normale Post handelt. Hierzu zählen z.a. DKIM und SPF. Eigentlich sollte unsere Domain SPF unterstützen und einen gültigen Record zurückliefern. Die Domain heißt „ff-holsterhausen.de“, der Mailserver identifiziert sich unter dem Namen „hora.tempus-vivit.net“ und der IP 213.136.68.159.

Die erste Anlaufstelle ist das Linux-Tool dig, mit dem man DNS-Informationen abfragen kann. Eine Abfrage auf die Domain zeigte folgendes:

user@tempus-vivit.net:# dig ff-holsterhausen.de any

; <<>> DiG 9.9.5-8-Debian <<>> ff-holsterhausen.de any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36513
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ff-holsterhausen.de.           IN      ANY

;; ANSWER SECTION:
ff-holsterhausen.de.    2560    IN      SOA     ns.namespace4you.de. hostmaster.ff-holsterhausen.de. 1424690369 16384 2048 1048576 2560
ff-holsterhausen.de.    3600    IN      A       213.136.68.159
ff-holsterhausen.de.    3600    IN      MX      50 ff-holsterhausen.de.
ff-holsterhausen.de.    86400   IN      NS      ns2.namespace4you.de.
ff-holsterhausen.de.    86400   IN      NS      ns.namespace4you.de.
ff-holsterhausen.de.    3600    IN      TXT     "v=spf1 mx a ptr ip4:213.136.68.159 mx:hora.tempus-vivit.net ~all"

;; Query time: 23 msec
;; SERVER: 213.136.95.10#53(213.136.95.10)
;; WHEN: Mon Feb 23 15:06:36 CET 2015
;; MSG SIZE  rcvd: 253

Soweit sah alles gut aus, die SPF-Records wurden also ausgeliefert. Eine kurze Prüfung auf http://tools.bevhost.com/spf/ zeigte auch alles im grünen Bereich. Praktischerweise gibt es auch mailbasierte Tests. Hierfür muss man einfach eine Mail an check-auth@verifier.port25.com schicken und bekommt die Antwort ein paar Minuten später per Mail zurück: SPF Softfail!

==========================================================
Summary of Results
==========================================================
SPF check:          softfail
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    softfail
SpamAssassin check: ham

==========================================================
Details:
==========================================================

HELO hostname:  hora.tempus-vivit.net
Source IP:      2a02:c200:1:10:3::6175:1
mail-from:      cschumann@ff-holsterhausen.de

----------------------------------------------------------
SPF check details:
----------------------------------------------------------
Result:         softfail (SPF-Result: SoftFail)
ID(s) verified: smtp.mailfrom=cschumann@ff-holsterhausen.de
DNS record(s):
    ff-holsterhausen.de. SPF (no records)
    ff-holsterhausen.de. 2260 IN TXT "v=spf1 mx a ip4:213.136.68.159 mx:hora.tempus-vivit.net ~all"
    ff-holsterhausen.de. 2261 IN MX 50 ff-holsterhausen.de.
    ff-holsterhausen.de. AAAA (no records)
    ff-holsterhausen.de. AAAA (no records)

Der geübte Leser sieht aber in dieser Mail auch schon die Ursache des Problems, alle anderen (und ich) müssen mehrfach lesen: Source IP: 2a02:c200:1:10:3::6175:1

Offensichtlich versucht der EXIM-Mailserver die E-Mail über IPv6 zu versenden. Der SPF-Record ist aber nur für IPv4 definiert und der Reverse-DNS ebenfalls:

user@tempus-vivit.net:# nslookup 213.136.68.159
Server:         213.136.95.10
Address:        213.136.95.10#53

Non-authoritative answer:
159.68.136.213.in-addr.arpa     name = hora.tempus-vivit.net.

Authoritative answers can be found from:

user@tempus-vivit.net:# nslookup 2a02:c200:1:10:3::6175:1
Server:         213.136.95.10
Address:        213.136.95.10#53

Non-authoritative answer:
1.0.0.0.5.7.1.6.0.0.0.0.3.0.0.0.0.1.0.0.1.0.0.0.0.0.2.c.2.0.a.2.ip6.arpa        name = vmd6175.contabo.host.

Somit ist die Ursache gefunden. Die IPv6 Adresse ist schnell in die SPF-Zeile eingetragen [Siehe Update unten], aber wo zum Teufel wird der RDNS konfiguriert in der Contabo-Oberfläche???

Eine Mail schafft klarheit: Nirgendwo. Man muss den gewünschten Eintrag dem Contabo-Support per Mail mitteilen, sodass diese den Eintrag vornehmen können. Immerhin reagiert der Support äußerst schnell auf derartige Anfragen.

Alternativ kann man übrigens auch EXIM die Nutzung von IPv6 verbieten. Dies erfolgt über den Eintrag disable_ipv6 = true in der Datei main/00_exim-localmacros.

Update April 2019:
Inzwischen kann man die IPv6 RDNS-Einträge auch über die Weboberfläche von Contabo administrieren. Nach dem Login in den Kundencenter findet man die Einträge unter dem Menüpunkt Reverse-DNS-Verwaltung