Ich konnte das Problem lösen. Laut https://dnsviz.net/d/ormanns.net/dnssec/ war mein dritter Nameserver nicht mehr per IPv6 erreichbar. Nachdem ich das gefixt hatte, konnte ich auch wieder die TLSA-Records auflösen. Die Nameserver für ormanns.net sind in IPv4 als auch in IPv6 hinterlegt, wohingegen die Nameserver für syncookie.de nur in IPv4 eingetragen sind - daher rührte dann wohl das Phänomen, dass die Auflösung der TLSA-Records bei einer Domäne funktionierte und bei der anderen nicht...
Beiträge von Aleph
-
-
Wurde andersherum getestet, dass für beide Domänen die richtigen/selben DNS-Server zuständig sind? Ist das Problem reproduzierbar, wenn die Abfrage direkt an die IP-Adresse desjenigen DNS-Servers gerichtet wird, dessen Zonefile oben auszugsweise angegeben wurde (um jegliche Verwechslung auszuschließen, vom selben Host via 127.0.0.1 und danach von einem anderen aus)?
Ja, wenn ich den Master unter 127.0.0.1 abfrage, wird ebenfalls ein NXDOMAIN ausgegeben.
ein Tipp: lasse den private Key unverändert, dann bleiben auch die TLSA-Records die selben
Ja, auf die Möglichkeit bin ich kürzlich auch gestoßen, die kam, nachdem ich mir mein Skript gebaut hatte. Und da es bislang anderthalb Jahre lang lief, habe ich es nicht mehr angefasst.
Nichtsdestotrotz interessiert mich natürlich, warum nun auf einmal dieser Fehler auftritt.
-
Moin zusammen,
ich setze seit rund anderthalb Jahren DANE ein, was bislang auch recht problemlos funktioniert hat. Die Zertifikate liefert letsencrypt, und sobald ein neues Zertifikat erstellt wurde, rotiert ein Skript die TLSA-Records in den betroffenen Zonefiles meiner beiden Domains. So weit, so gut.
Seit Sonntag funktioniert das aber nur noch bei einer Domain, bei der anderen werden die TLSa-Records nicht mehr gefunden:
$ dig _443._tcp.syncookie.de IN TLSA @ormanns.net +short:
3 1 1 4F5FF30E3A1B43A88224689922E95B42305F422DBC7E42FE53B36CEE 8D1E9EC1
"$ dig _443._tcp.ormanns.net IN TLSA @ormanns.net +short" liefert hingegen nichts, und lasse ich "+short" weg, sehe ich, dass die Ausgabe ein NXDOMAIN ausspuckt.
Also schaue ich ins Zonefile. Dieses enthält u.a. folgende Records
Zitat_25._tcp.mail.ormanns.net. IN TLSA 3 1 1 9006b2b49d744761b5f27ffe9cb50d19ff2882ed04966e12780012a57e28204a
_443._tcp.mail.ormanns.net. IN TLSA 3 1 1 9006b2b49d744761b5f27ffe9cb50d19ff2882ed04966e12780012a57e28204a
_443._tcp.ormanns.net. IN TLSA 3 1 1 9006b2b49d744761b5f27ffe9cb50d19ff2882ed04966e12780012a57e28204a
_443._tcp.www.ormanns.net. IN TLSA 3 1 1 9006b2b49d744761b5f27ffe9cb50d19ff2882ed04966e12780012a57e28204a
_465._tcp.mail.ormanns.net. IN TLSA 3 1 1 9006b2b49d744761b5f27ffe9cb50d19ff2882ed04966e12780012a57e28204a
_587._tcp.mail.ormanns.net. IN TLSA 3 1 1 9006b2b49d744761b5f27ffe9cb50d19ff2882ed04966e12780012a57e28204a
Sieht für mich soweit erstmal okay aus, aber vielleicht hat das Zonefile ja einen anderen Fehler?
# named-checkzone ormanns.net /var/cache/bind/ormanns.net.zone
zone ormanns.net/IN: loaded serial 2018101744
OK
Das Zonefile scheint also auch zu passen. Mir gehen gerade ein bisschen die Ideen aus, wo ich noch ansetzen könnte - ich wäre daher für Input dankbar.
Beste Grüße,
Aleph
Nachtrag: bei mir läuft bind-9.14.8
-
chrko,
vielen Dank für den Hinweis. Tatsächlich zeigt ormanns.net | DNSViz den Fehler an, DNSSEC Analyzer - ormanns.net hingegen vermeldet keine Fehler.
Ich vermute den Fehler darin, dass BIND nicht die Serial erhöht, denn die Logs enthalten zwar für jede Stunde die folgenden Einträge, jedoch scheinen die Slaves kein Update zu erkennen und Aktualisieren daher auch die Zonefiles nicht.ZitatApr 4 17:58:02 ormanns.net named[17704]: zone ormanns.net/IN (signed): reconfiguring zone keys
Apr 4 17:58:02 ormanns.net named[17704]: zone ormanns.net/IN (signed): next key event: 04-Apr-2017 18:58:02.553Trotz dem gut geschriebenen Howto von gunnarh und diversen Googlesuchen bin ich hier noch nicht wirklich vorangekommen.
Zudem hat sich ein zweites Problem aufgetan - AFAIK muss ich update-policy auf "local" setzen, wenn ich automatische Key-Rollover haben will. Dann muss ich aber die Policy für meine Dyndns-Einträge deaktivieren...wie kann ich beides unter einen Hut bringen?
Code
Alles anzeigenzone "123.de" { type master; file "/var/cache/bind/123.de.zone.signed"; allow-query { any; }; update-policy local; # update-policy { # grant dyndns1.123.de name dyndns1.123.de A; # grant dyndns2.123.de name dyndns2.123.de A; # }; key-directory "/var/cache/bind"; inline-signing yes; auto-dnssec maintain; notify yes; };
Besten Dank vorab,
Aleph -
Sehr cool. Danke dir!
MfG Aleph
-
...danke dir. Doch, die Fehlermeldungen hatte ich angesehen, blöderweise hatte ich dann nur diesen einen Tab offen und den aktualisiert, woraufhin die Fehlermeldungen natürlich verschwanden...
MfG Aleph
-
Resolver die DNSSEC enabled auflösen liefern dir nur ein Servfail.
Zuhause verwendest Du offenkundig keinen DNSSEC fähigen ResolverDie DNSSEC Config ist fehlerhaft, siehe ormanns.net | DNSViz
Nachtrag: Hier siehst Du den Grund noch deutlicher: DNSSEC Analyzer - ormanns.net
gunnarh,
vielen Dank für deine Antwort.
Vorab: ich habe jetzt eben die beiden betroffenen Zonefiles neu signiert und named neu geladen, jetzt läuft alles wieder wie gehabt.
Zum Testen habe ich auf mehreren Systemen dig verwendet, dort, wo dig ein SERVFAIL aufgab, konnte die Domain auch nicht aufgelöst werden. Woanders gab es ein NOERROR, dort wurden die Domains dann natürlich auch aufgelöst.
Einerseits ist es jetzt gut, dass alles wieder läuft, andererseits wüsste ich natürlich schon gern, warum aus heiterem Himmel dieses Problem entstand. Mangels Fehlermeldungen kann ich es aber derzeit nicht wirklich nachvollziehen...
MfG Aleph
-
Guten Abend,
seit heute Mittag werden zwei meiner Domains (ormanns.net & row-records.de) auf verschiedenen Systemen (bspw. Dig (DNS lookup) resp. Dig (DNS lookup)) nicht mehr gefunden bzw. aufgelöst. dig liefert in dem Fall ein SERVFAIL, ping meldet "unknown host". Bei mir zuhause hingegen können die Adressen aufgelöst werden.
Ich habe seit dem 15.3. nichts an der BIND-Config geändert, ebenso loggte BIND keine Fehler. Mir fiel nur vorhin bei einem named-checkzone auf ormanns.net auf, dass die (vorhandenen) Keyfiles nicht gefunden werden konnten. Ein paar Minuten später versuchte ich es nochmal, und jetzt lief der Check ohne Fehler durch. Ebenso lieferte der Nameserver Predelegation Check der DENIC keine Fehler.
Die Zonefiles sehen wie folgt aus:
Code
Alles anzeigen$ORIGIN . $TTL 180 ormanns.net. IN SOA ns1.ormanns.net admin.ormanns.net ( 2017020354 ; serial number YYMMDDNN 28800 ; Refresh 7200 ; Retry 2419200 ; Expire 86400 ; Min TTL ) NS ns1.ormanns.net. NS ns2.ormanns.net. NS ns3.ormanns.net. A 37.120.182.194 $ORIGIN ormanns.net. ns1 A 37.120.182.194 ns2 A 37.120.169.47 ns3 A 188.68.37.238 194 IN PTR mail.ormanns.net. www IN CNAME ormanns.net. mail IN A 37.120.182.194 @ IN MX 10 mail @ IN TXT "v=spf1 mx -all" _dmarc IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@ormanns.net; ruf=mailto:dmarc@ormanns.net; fo=0; adkim=r; aspf=r; rf=afrf; sp=none" ormanns.net._domainkey IN TXT ( "v=DKIM1; k=rsa; s=email; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEnTADS3ns8dMdNmM6O4YrNRU/vuWUHBVgoYwyuO5kGgmlCnKE97oixHEthU0JJEHQQr9mFKo+2qlLYNtIv/qKjiG9GUbGR2M5dc6Vhsx+0lADwsvDyQCrDALxNGVYVtQCPRK+KpATt5zsIbSGTRRu/0ZA2o93I3w3YOIdfYDKqwIDAQAB" ) ; ----- DKIM key ormanns.net for ormanns.net $INCLUDE Kormanns.net.+007+38219.key $INCLUDE Kormanns.net.+007+64101.key
Code
Alles anzeigen$ORIGIN . $TTL 180 row-records.de. IN SOA ns1.row-records.de. admin.row-records.de. ( 2017020233 ; serial number YYMMDDNN 28800 ; Refresh 7200 ; Retry 2419200 ; Expire 86400 ; Min TTL ) NS ns1.row-records.de. NS ns2.row-records.de. NS ns3.row-records.de. A 37.120.182.194 $ORIGIN row-records.de 194 IN PTR row-records.de. @ IN TXT "v=spf1 mx -all" _dmarc IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@row-records.de; ruf=mailto:dmarc@row-records.de; fo=0; adkim=r; aspf=r; rf=afrf; sp=none" row-records.de._domainkey IN TXT ( "v=DKIM1; k=rsa; " "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnwdKk3haw9mRTZPxSemTZdA5Q4WiWhpD1TghIaBbU7DSxyaxXuxPYDzg2iR7xGI469B3MTZyezkmqjJJNsE+8LVpclwtZ7cz5DPP7LVLxiNHamO80L1wsFgKaG+zKDo6Dzkt5lE76y0cy5wEtQqdoNqx+I3/79XEg97MoES5faBc5IfQv8mu5Rnum2jE9r6tFZPhA1QcRzbF5c" "6ZfMJHOqKSH4zEhueokjGXU0Klt4fxER+paP3UTWzeCSidTJyoFXbxyTxb0b4z/J6C8CF4ri3BZF+0/bq6Gi7xmc6fiSDyNo2gW+8ax1UF0eGFV7CZXVCRQTqFU9IIoYE+NxOLZQIDAQAB" ) ; ----- DKIM key row-records.de for row-records.de $INCLUDE Krow-records.de.+008+12742.key $INCLUDE Krow-records.de.+008+49884.key ns1 A 37.120.182.194 ns2 A 37.120.169.47 ns3 A 188.68.37.238 mail IN A 37.120.182.194 @ IN MX 10 mail
Wie gesagt - die Config lief jetzt wochenlang ohne Probleme, zudem treten die Probleme nur bei 2 von 3 Domains auf. Ich bin gerade etwas ratlos, was ich noch checken könnte und wäre froh, falls jemand eine Idee hat.
MfG Aleph
-
.A., weiterhin vielen Dank für deine Bemühungen und den Input. Die Zertifikate würde ich an der Stelle erstmal so lassen (einfach um nicht ggf. eine weitere Baustelle aufzumachen) und später anpassen.
Ich nutze gnutls-3.3.26.
Mit dem Loglevel auf 4 und "tcpdump -X tcp port 25" habe ich mir dann eine Mail von Web.de aus geschickt. Den Output verlinke ich der Übersicht halber:
mail.log: https://ormanns.net/pub/netcup_maillog
tcpdump: https://ormanns.net/pub/netcup_tcpdumpAus der Ausgabe werde ich aber nicht wirklich schlau...
MfG Aleph
-
Guten Morgen,
Ist Dein Zertifikat OK? Hast Du einen TLSA-RR gesetzt?
Ja, das Zertifikat sollte in Ordnung sein. Die Warnings tauchen ja auch nur bei Verbindungsaufbauten von Web.de und GMX auf, bei allen anderen Mailservern läuft alles anstandslos durch.
Einen TLSA-Record habe ich nicht gesetzt.Ich wusste jetzt nicht, wie ich aus dem Output den Traffic zwischen STARTTLS und Verbindungsabbrucht herauslesen kann und habe daher alles auf Port 25 bis zum Eintreffen der Mail gesnifft.
tcpdump port 25:
Code
Alles anzeigen09:28:50.714641 IP mout.web.de.51830 > ormanns.net.smtp: Flags [S], seq 1492311459, win 29200, options [mss 1460,sackOK,TS val 233874067 ecr 0,nop,wscale 9], length 0 09:28:50.714749 IP ormanns.net.smtp > mout.web.de.51830: Flags [S.], seq 3114145185, ack 1492311460, win 28960, options [mss 1460,sackOK,TS val 3282632510 ecr 233874067,nop,wscale 7], length 0 09:28:50.720978 IP mout.web.de.51830 > ormanns.net.smtp: Flags [.], ack 1, win 58, options [nop,nop,TS val 233874068 ecr 3282632510], length 0 09:28:50.723340 IP ormanns.net.smtp > mout.web.de.51830: Flags [P.], seq 1:37, ack 1, win 227, options [nop,nop,TS val 3282632519 ecr 233874068], length 36: SMTP: 220 mail.ormanns.net ESMTP Postfix 09:28:50.729540 IP mout.web.de.51830 > ormanns.net.smtp: Flags [.], ack 37, win 58, options [nop,nop,TS val 233874070 ecr 3282632519], length 0 09:28:50.729697 IP mout.web.de.51830 > ormanns.net.smtp: Flags [P.], seq 1:19, ack 37, win 58, options [nop,nop,TS val 233874070 ecr 3282632519], length 18: SMTP: EHLO mout.web.de 09:28:50.729739 IP ormanns.net.smtp > mout.web.de.51830: Flags [.], ack 19, win 227, options [nop,nop,TS val 3282632525 ecr 233874070], length 0 09:28:50.729817 IP ormanns.net.smtp > mout.web.de.51830: Flags [P.], seq 37:190, ack 19, win 227, options [nop,nop,TS val 3282632525 ecr 233874070], length 153: SMTP: 250-mail.ormanns.net 09:28:50.736377 IP mout.web.de.51830 > ormanns.net.smtp: Flags [P.], seq 19:29, ack 190, win 60, options [nop,nop,TS val 233874072 ecr 3282632525], length 10: SMTP: STARTTLS 09:28:50.736505 IP ormanns.net.smtp > mout.web.de.51830: Flags [P.], seq 190:220, ack 29, win 227, options [nop,nop,TS val 3282632532 ecr 233874072], length 30: SMTP: 220 2.0.0 Ready to start TLS 09:28:50.742991 IP mout.web.de.51830 > ormanns.net.smtp: Flags [P.], seq 29:294, ack 220, win 60, options [nop,nop,TS val 233874074 ecr 3282632532], length 265: SMTP 09:28:50.745069 IP ormanns.net.smtp > mout.web.de.51830: Flags [P.], seq 220:3131, ack 294, win 235, options [nop,nop,TS val 3282632540 ecr 233874074], length 2911: SMTP 09:28:50.751374 IP mout.web.de.51830 > ormanns.net.smtp: Flags [.], ack 3131, win 71, options [nop,nop,TS val 233874076 ecr 3282632540], length 0 09:28:50.753104 IP mout.web.de.51830 > ormanns.net.smtp: Flags [P.], seq 294:420, ack 3131, win 71, options [nop,nop,TS val 233874076 ecr 3282632540], length 126: SMTP 09:28:50.753479 IP ormanns.net.smtp > mout.web.de.51830: Flags [P.], seq 3131:3182, ack 420, win 235, options [nop,nop,TS val 3282632549 ecr 233874076], length 51: SMTP 09:28:50.760725 IP mout.web.de.51830 > ormanns.net.smtp: Flags [P.], seq 420:451, ack 3182, win 71, options [nop,nop,TS val 233874078 ecr 3282632549], length 31: SMTP 09:28:50.760877 IP mout.web.de.51830 > ormanns.net.smtp: Flags [F.], seq 451, ack 3182, win 71, options [nop,nop,TS val 233874078 ecr 3282632549], length 0 09:28:50.764555 IP mout.web.de.63590 > ormanns.net.smtp: Flags [S], seq 799816265, win 29200, options [mss 1460,sackOK,TS val 233874079 ecr 0,nop,wscale 9], length 0 09:28:50.764630 IP ormanns.net.smtp > mout.web.de.63590: Flags [S.], seq 3700148863, ack 799816266, win 28960, options [mss 1460,sackOK,TS val 3282632560 ecr 233874079,nop,wscale 7], length 0 09:28:50.771000 IP mout.web.de.63590 > ormanns.net.smtp: Flags [.], ack 1, win 58, options [nop,nop,TS val 233874081 ecr 3282632560], length 0 09:28:50.774171 IP mout.web.de.51830 > ormanns.net.smtp: Flags [F.], seq 451, ack 3182, win 71, options [nop,nop,TS val 233874082 ecr 3282632549], length 0 09:28:50.774185 IP ormanns.net.smtp > mout.web.de.51830: Flags [.], ack 452, win 235, options [nop,nop,TS val 3282632570 ecr 233874078,nop,nop,sack 1 {451:452}], length 0 09:28:50.774223 IP ormanns.net.smtp > mout.web.de.51830: Flags [F.], seq 3182, ack 452, win 235, options [nop,nop,TS val 3282632570 ecr 233874078], length 0 09:28:50.774935 IP ormanns.net.smtp > mout.web.de.63590: Flags [P.], seq 1:37, ack 1, win 227, options [nop,nop,TS val 3282632570 ecr 233874081], length 36: SMTP: 220 mail.ormanns.net ESMTP Postfix 09:28:50.780410 IP mout.web.de.51830 > ormanns.net.smtp: Flags [.], ack 3183, win 71, options [nop,nop,TS val 233874083 ecr 3282632570], length 0 09:28:50.781356 IP mout.web.de.63590 > ormanns.net.smtp: Flags [.], ack 37, win 58, options [nop,nop,TS val 233874083 ecr 3282632570], length 0 09:28:50.781562 IP mout.web.de.63590 > ormanns.net.smtp: Flags [P.], seq 1:19, ack 37, win 58, options [nop,nop,TS val 233874083 ecr 3282632570], length 18: SMTP: EHLO mout.web.de 09:28:50.781590 IP ormanns.net.smtp > mout.web.de.63590: Flags [.], ack 19, win 227, options [nop,nop,TS val 3282632577 ecr 233874083], length 0 09:28:50.781675 IP ormanns.net.smtp > mout.web.de.63590: Flags [P.], seq 37:190, ack 19, win 227, options [nop,nop,TS val 3282632577 ecr 233874083], length 153: SMTP: 250-mail.ormanns.net 09:28:50.788456 IP mout.web.de.63590 > ormanns.net.smtp: Flags [P.], seq 19:62, ack 190, win 60, options [nop,nop,TS val 233874085 ecr 3282632577], length 43: SMTP: MAIL FROM:<testmail@web.de> SIZE=1400 09:28:50.806394 IP ormanns.net.smtp > mout.web.de.63590: Flags [P.], seq 190:204, ack 62, win 227, options [nop,nop,TS val 3282632602 ecr 233874085], length 14: SMTP: 250 2.1.0 Ok 09:28:50.812722 IP mout.web.de.63590 > ormanns.net.smtp: Flags [P.], seq 62:96, ack 204, win 60, options [nop,nop,TS val 233874091 ecr 3282632602], length 34: SMTP: RCPT TO:<testmail@ormanns.net> 09:28:50.853183 IP ormanns.net.smtp > mout.web.de.63590: Flags [.], ack 96, win 227, options [nop,nop,TS val 3282632649 ecr 233874091], length 0 09:28:50.856423 IP ormanns.net.smtp > mout.web.de.63590: Flags [P.], seq 204:255, ack 96, win 227, options [nop,nop,TS val 3282632652 ecr 233874091], length 51: SMTP: 250 2.1.5 Ok 09:28:50.862922 IP mout.web.de.63590 > ormanns.net.smtp: Flags [P.], seq 96:170, ack 255, win 60, options [nop,nop,TS val 233874104 ecr 3282632652], length 74: SMTP: Received: from [31.19.106.51] by 3capp-webde-bs03.server.lan (via HTTP); 09:28:50.862968 IP ormanns.net.smtp > mout.web.de.63590: Flags [.], ack 170, win 227, options [nop,nop,TS val 3282632658 ecr 233874104], length 0 09:28:50.869421 IP mout.web.de.63590 > ormanns.net.smtp: Flags [P.], seq 170:1499, ack 255, win 60, options [nop,nop,TS val 233874105 ecr 3282632658], length 1329: SMTP: Sun, 19 Mar 2017 09:28:50 +0100 09:28:50.869457 IP ormanns.net.smtp > mout.web.de.63590: Flags [.], ack 1499, win 249, options [nop,nop,TS val 3282632665 ecr 233874105], length 0 09:28:50.927057 IP ormanns.net.smtp > mout.web.de.63590: Flags [P.], seq 255:292, ack 1499, win 249, options [nop,nop,TS val 3282632722 ecr 233874105], length 37: SMTP: 250 2.0.0 Ok: queued as D07AA100522 09:28:50.935972 IP mout.web.de.63590 > ormanns.net.smtp: Flags [P.], seq 1499:1505, ack 292, win 60, options [nop,nop,TS val 233874122 ecr 3282632722], length 6: SMTP: QUIT 09:28:50.936015 IP ormanns.net.smtp > mout.web.de.63590: Flags [.], ack 1505, win 249, options [nop,nop,TS val 3282632731 ecr 233874122], length 0 09:28:50.937024 IP ormanns.net.smtp > mout.web.de.63590: Flags [P.], seq 292:307, ack 1505, win 249, options [nop,nop,TS val 3282632732 ecr 233874122], length 15: SMTP: 221 2.0.0 Bye 09:28:50.937051 IP ormanns.net.smtp > mout.web.de.63590: Flags [F.], seq 307, ack 1505, win 249, options [nop,nop,TS val 3282632732 ecr 233874122], length 0 09:28:50.943504 IP mout.web.de.63590 > ormanns.net.smtp: Flags [F.], seq 1505, ack 308, win 60, options [nop,nop,TS val 233874124 ecr 3282632732], length 0 09:28:50.943552 IP ormanns.net.smtp > mout.web.de.63590: Flags [.], ack 1506, win 249, options [nop,nop,TS val 3282632739 ecr 233874124], length 0
MfG Aleph
-
-
Zitat
Es ist möglich.
Magst du verraten, wie?
Hast Du Deine Konfiguration schon aufgeräumt?
Ja, ich habe die main.cf um die Einträge erleichtert, welche entweder auf dem Defaultwert standen oder in der aktuellen Version nicht mehr benötigt / unterstützt wurden (ich will nicht wissen, welche Version 2012 unter Debian angeboten wurde - daher rührte, dass ich immer noch Optionen drin hatte, die längst überholt waren):
postconf -n | grep tls | grep smtpd:
Codesmtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/fullchain.pem smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem smtpd_tls_key_file = /etc/letsencrypt/live/privkey.pem smtpd_tls_security_level = may
MfG Aleph
-
Ich habe mal die Loggingverbosity etwas heraufgesetzt, wobei nicht wirklich neue Infos bei herumkamen:
Codepostfix/smtpd[17496]: SSL_accept:SSLv3 flush data postfix/smtpd[17496]: Anonymous TLS connection established from unknown[212.227.15.14]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) postfix/smtpd[17496]: SSL3 alert read:fatal:insufficient security postfix/smtpd[17496]: warning: TLS library problem: error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:s3_pkt.c:1493:SSL alert number 71: postfix/smtpd[17496]: lost connection after STARTTLS from unknown[212.227.15.14] postfix/smtpd[17496]: disconnect from unknown[212.227.15.14] ehlo=1 starttls=1 commands=2
Laut dem RFC zu TLSv1.2 (https://www.ietf.org/rfc/rfc5246.txt) bedeutet der Fehler folgendes:
Codeinsufficient_security Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client. This message is always fatal.
Daraus schließe ich nun, dass GMX / Web.de unsichere Ciphers verwenden wollen, als mein Server zum Aufbau einer verschlüsselten Verbindung akzeptiert. Also bricht der Verbindungsaufbau ab und GMX / WEb.de versuchen es daraufhin noch einmal:
Codepostfix/smtpd[17496]: connect from unknown[212.227.15.14] postfix/smtpd[17496]: DC7CA1000D5: client=unknown[212.227.15.14] postfix/cleanup[17489]: DC7CA1000D5: message-id=<21373d0a-e8ae-1b45-3f8b-18e171719008@MEINSERVER>
Die Mail wird also letztendlich angenommen, wie ich auch schon im Eingangsposting schrieb.
1) Ist die Verbindung, über welche die Mail letztendlich zugestellt werden kann, demzufolge unverschlüsselt?
2) Falls ja, habe ich überhaupt irgendwelche Möglichkeiten, GMX / Web.de zum Aufbau einer sichereren Verbindung zu zwingen, ohne dass Mails dann nicht zugestellt werden können? Von "encrypt" wird ja abgeraten (Postfix Configuration Parameters)...Codesmtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/fullchain.pem smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem smtpd_tls_key_file = /etc/letsencrypt/live/privkey.pem smtpd_tls_security_level = may tls_preempt_cipherlist = yes (ob "yes" oder der Defaultwert "no" macht keinen Unterschied)
MfG Aleph
-
.A., vielen Dank für die Anmerkungen und Verbesserungsvorschläge. Ich verstehe sie allerdings so, dass es gerade eher um ein sauberes Configfile geht, unabhängig von meinem Problem - ist das korrekt?
Nichtsdestotrotz führe ich mir deine Vorschläge bei Gelgenheit gerne zu GemüteZu "smtp_bind_address" - der Server sendet auf einer zweiten IP-Adresse, da ich mit der von netcup bereitgestellten Adresse Probleme beim Versand an Yahoo hatte.
Bei dem Server handelt es sich übrigens um eine rein privat genutzt Kiste mit einer Handvoll Mailaccounts.
MfG Aleph
-
Zitat
Bist Du sicher, dass Du folgende Einstellungen möchtest?
Wenn du so direkt fragst - nein
Die Installation lief vorher rund 5 Jahre auf einem Debian-System und ich habe sie beim Umzug zu netcup so übernommen.Weißt Du, was Du damit bewirkst? Diese Werte sind recht eigenwillig.
Du meinst wahrscheinlich smtpd_tls_ask_ccert? Den Parameter habe ich testweise zurück auf den Defaultwert "no" gesetzt.
Bei den Session Caches kann ich ad hoc nichts eigenwilliges feststellen...ZitatAußerdem solltest Du Deine Konfiguration einmal dringend aufräumen.
Worauf genau beziehst du dich?
@ de_bonner: danke für den Input. Ich werde deine Config später mal mit meiner vergleichen (mir fiel gerade auf, dass du "smtpd_tls_auth_only = yes" zweimal drin hast).
MfG Aleph
-
killerbees19, danke für die schnelle Antwort.
Ich setze Postfix 3.1.2-r2 ein (shame on me dafür, dass ich diese Angabe im Startposting vergessen habe...).
postconf -d | grep cipher
Zitatlmtp_tls_ciphers = medium
lmtp_tls_exclude_ciphers =
lmtp_tls_mandatory_ciphers = medium
lmtp_tls_mandatory_exclude_ciphers =
milter_helo_macros = {tls_version} {cipher} {cipher_bits} {cert_subject} {cert_issuer}
smtp_tls_ciphers = medium
smtp_tls_exclude_ciphers =
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers =
smtpd_tls_ciphers = medium
smtpd_tls_exclude_ciphers =
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_exclude_ciphers =
tls_export_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH
tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
tls_low_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:+RC4:@STRENGTH
tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH
tls_null_cipherlist = eNULL:!aNULL
tls_preempt_cipherlist = no
tls_session_ticket_cipher = aes-256-cbc
tlsproxy_tls_ciphers = $smtpd_tls_ciphers
tlsproxy_tls_exclude_ciphers = $smtpd_tls_exclude_ciphers
tlsproxy_tls_mandatory_ciphers = $smtpd_tls_mandatory_ciphers
tlsproxy_tls_mandatory_exclude_ciphers = $smtpd_tls_mandatory_exclude_cipherspostconf -n | grep cipher
Zitattls_preempt_cipherlist = yes
Mit Hinblick auf Postfix Configuration Parameters verstehe ich das so, dass dieser Parameter darüber entscheidet, ob Server ("yes") oder Client ("no") darüber entscheiden, welche Chiffre zuerst genommen wird. Aktuell will mein Server TLS eine Cipher haben, welche Web.de und GMX nicht unterstützen, also wird im zweiten Anlauf dann eine unverschlüsselte Verbindung hergestellt. Oder missverstehe ich da was?
MfG Aleph
-
Guten Abend,
ich bemerke seit einiger Zeit, dass der Mailempfang von Web.de und GMX zu Fehlermeldungen im Log führt. Die Mails werden dann aber in einem neuen Versuch angenommen:
Zitat06:32:23 postfix/smtpd[3854]: connect from unknown[212.227.15.3]
06:32:23 postfix/smtpd[3854]: Untrusted TLS connection established from unknown[212.227.15.3]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
06:32:23 postfix/smtpd[3854]: warning: TLS library problem: error:1409442F:SSL routines:ssl3_read_bytes:tlsv1 alert insufficient security:s3_pkt.c:1493:SSL alert number 71:
06:32:23 postfix/smtpd[3854]: lost connection after STARTTLS from unknown[212.227.15.3]
06:32:23 postfix/smtpd[3854]: disconnect from unknown[212.227.15.3] ehlo=1 starttls=1 commands=2
06:32:23 postfix/smtpd[3854]: connect from unknown[212.227.15.3]
06:32:23 postfix/smtpd[3854]: ED2FC100670: client=unknown[212.227.15.3]
06:32:23 postfix/cleanup[3875]: ED2FC100670: message-id=<qdpvp8.j068tq0pvq5pgxl@douglas.de>
[...]
06:32:24 postfix/qmgr[16754]: ED2FC100670: from=<SRS0=M+gh=2V=bounce.news.douglas.de=g-9031013860-9250-902942603-1489296738553@srs.web.de>, size=79391, nrcpt=1 (queue active)
05:32:24 postfix/smtpd[3854]: disconnect from unknown[212.227.15.3] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
06:32:28 postfix/smtpd[3881]: connect from localhost[127.0.0.1]
06:32:28 postfix/smtpd[3881]: 25E3310067A: client=localhost[127.0.0.1]
06:32:28 postfix/cleanup[3875]: 25E3310067A: message-id=<qdpvp8.j068tq0pvq5pgxl@douglas.de>
06:32:28 postfix/qmgr[16754]: 25E3310067A: from=<SRS0=M+gh=2V=bounce.news.douglas.de=g-9031013860-9250-902942603-1489296738553@srs.web.de>, size=80414, nrcpt=1 (queue active)
06:32:28 postfix/smtpd[3881]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
[...]
06:32:28 postfix/qmgr[16754]: ED2FC100670: removed
06:32:29 dovecot: lda(USER@MEIN-SERVER.DE sieve: msgid=<qdpvp8.j068tq0pvq5pgxl@douglas.de>: stored mail into mailbox 'INBOX'
06:32:29 postfix/pipe[3882]: 25E3310067A: to=<USER@MEIN-SERVER.DE>, relay=dovecot, delay=1.2, delays=0.01/0.07/0/1.2, dsn=2.0.0, status=sent (delivered via dovecot service)
06:32:29 postfix/qmgr[16754]: 25E3310067A: removedIch verstehe die Log-Einträge wie folgt:
- Web.de versucht eine TLS-Verbindung aufzubauen, was fehlschlägt
- Web.de stellt die Mail daraufhin über eine unverschlüsselte Verbindung zuDie TLS-bezogenen Optionen von Postfix sind wie folgt gesetzt:
Code
Alles anzeigensender_canonical_maps = hash:/etc/postfix/sender_canonical smtp_bind_address = 37.120.182.194 smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtp_tls_CApath = /etc/ssl/certs smtp_tls_loglevel = 1 smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:$data_directory/smtp_tls_session_cache smtp_use_tls = yes smtpd_tls_CApath = /etc/ssl/certs smtpd_tls_ask_ccert = yes smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/fullchain.pem smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem smtpd_tls_eecdh_grade = strong smtpd_tls_key_file = /etc/letsencrypt/live/privkey.pem smtpd_tls_loglevel = 1 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:$data_directory/smtpd_tls_session_cache smtpd_use_tls = yes tls_preempt_cipherlist = yes tls_random_source = dev:/dev/urandom
Die Mails werden zwar zugestellt, es stört mich aber, dass (mal wieder...) nur Verbindungen mit Web.de und GMX nicht rund laufen. Ich stehe absolut auf dem Schlauch, wo ich bei der Fehlerbehebung (oder -suche) anfangen könnte - any idea?
MfG Aleph
-
Ich habe mir vor rund einer Woche für 1 € pro Monat eine zweite IP-Adresse besorgt. Laut dem netcup-Support werden zusätzliche Adressen generell aus einem anderen Pool vergeben.
Mit der neuen Adresse scheint nun alles wie gewünscht zu laufen - Testmails an Yahoo kamen an.Ein fader Beigeschmack bleibt natürlich, da mich dieses Problem pro Jahr weitere 12 € kostet.
MfG Aleph
-
Auch diesmal war die Antwort folgende:
ZitatHi,
Thank you for contacting Yahoo Mail.
We aren't able to guarantee
consistent Inbox delivery for your mail, but we've made appropriate
changes to the IP address(es) in our database. This should help with
delivering mail to the appropriate Yahoo Mail folder. How your
reputation is seen within the industry represents an extremely important
aspect toward achieving consistent Inbox delivery to your recipients.It's important to know that Yahoo Mail users are able to set their own preferences, including marking received email as spam.
For ways to improve your sending reputation, we suggest you review the following articles:
- Ensure uninterrupted SMTP access and prioritized deliverability
- Best practices for bulk mail senders and postmasters for sending to Yahoo Mail
- Yahoo Mail deliverability FAQs
Another option is to register for the Complaint Feedback Loop program.
Yahoo Mail offers a free program to help email senders minimize complaint rates. If you
participate, Yahoo Mail forwards complaints from our users about emails
sent from your organization. For more info, check out our help article
about the Yahoo Complaint Feedback Loop.Our privacy policies prevent us from divulging additional information, which means we're
unable to offer further help for your request.Thank you for your patience.
Regards,
Ich weise darauf hin, dass mittlerweile nur noch "appropriate changes" gemacht werden, ganz zu Beginn der Problematik waren es noch "significant changes". So oder so ist das natürlich alles Quark - die Mails sind nach wie vor in der Queue und deferred.
Nochmal die Checkliste, was Yahoo empfiehlt:- Opt out users who have marked your email as spam in the past. Enroll in the Yahoo Complaint Feedback Loop program to get that information.
-> Beim CFL-Programm habe ich mich registriert. Die paar Yahoo-Accounts, die Post von meinem Server bekommen, sind entweder mein Testaccount oder persönliche Kontakte der User auf meiner Kiste. Post mit Bezug auf die CFL habe ich noch nicht bekommen.
-
Check your email streams. Use separate IPs and
streams, depending on your email content type. If the IPs you're sending
your presumably valid email from are also sending unsolicited
commercial email, your sending reputation can be impacted.
-> Dürfte bei einem vorwiegend privat genutzten System wohl kaum relevant sein.
- Make sure your emails are DKIM signed. DKIM signature helps Yahoo authenticate that email is safe, secure and from the senders who claim to send it.
-> DKIM ist eingerichtet.
-
Control your email traffic. If you send emails at a
certain rate and suddenly have a spike of activity, you could get
flagged as a compromised sender and marked as spam. Instead, plan your
campaign and spread it out over a period of time.
-> Ich behalte meine Systeme mit Zabbix und tenshi, die auf einem separaten Logsystem laufen, im Blick. Ungewöhnliches Verhalten (hohe CPU- oder Netzauslastung) sollte mir somit eigentlich auffallen.
-
Check your email content. If the subject lines are
not helpful or appear to be generic, users may not be interested and
mark it as spam. When many users mark an email you send as spam, it can
impact your overall deliverability.
-> s.o., vorwiegend private Mails
-
Publish reverse DNS (PTR) records for your sending IPs.
Yahoo is more likely to downgrade an IP’s sending reputation if there
isn't a reverse DNS entry for your IP address. Not having a reverse DNS
entry can cause your mailing IP to look like a dynamically-assigned IP
instead of a static mail server.
-> ist gegeben
Ich habe eben eine Testmail an allaboutspam geschickt, das Ergebnis war, dass meine Mail scheinbar URLs enthält, welche bei URIBL gelistet sind. Sowohl meine IP-Adresse als auch meine Domains sind dort allerdings NICHT gelistet.
Da mir mittlerweile die Optionen ausgehen, werde ich mal bei netcup nachfragen, ob es möglich ist, eine zweite IP-Adresse aus einem _anderen_ Adressbereich zu erhalten. Vielleicht bringt es ja was, die Mails dann darüber zu senden.MfG Aleph
-
Kurzes Update: mittlerweile habe ich auch DMARC eingerichtet, die Tests auf ormanns.net Domain Health laufen ohne Warnungen oder Fehlermeldungen durch. E-Mails an Yahoo werden nach wie vor nicht zugestellt und die Supportanfragen (https://io.help.yahoo.com/contact/index?page=contact&locale=en_US&y=PROD_POST#). haben zuletzt auch nicht nennenswert weitergeholfen.
MfG Aleph