Hallo Liste,
ich habe hier ein merkwürdiges Problem, das verdächtig danach aussieht, als ob es mit der Marketing-Initiative von Telekom, GMX und web.de zu tun hätte:
Ich betreibe diverse Mail-Domains, verteilt auf zwei Server, einer mit CentOS 5, der andere mit CentOS 6. Ansonsten sind beide gleich konfiguriert: Sendmail, Cyrus IMAP, Squirrelmail, ein CACert-SSL-Zertifikat für alles und opportunistische SMTP-Verschlüsselung. Das hat auch alles prima funktioniert. Wer konnte hat verschlüsselt übertragen, die anderen (darunter GMX und web.de) unverschlüsselt.
Seit ca. 2013-08-05 14:30 schlugen dann auf dem CentOS-5-Server erst vereinzelt, dann durchgehend, Verbindungsversuche von mout.web.de und mout.gmx.net so fehl:
Aug 5 15:05:44 gimli sendmail[15250]: STARTTLS=server, error: accept failed=0, SSL_error=1, errno=0, retry=-1 Aug 5 15:05:44 gimli sendmail[15250]: STARTTLS=server: 15250:error:1409442F:SSL routines:SSL3_READ_BYTES:tlsv1 alert insufficient security:s3_pkt.c:1092:SSL alert number 71 Aug 5 15:05:44 gimli sendmail[15250]: r75D5gfM015250: mout.gmx.net [212.227.17.20] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
Die sendenden Server haben die Zustellung auch nicht unverschlüsselt wiederholt, sondern die Mails als unzustellbar zurückgeschickt. Erst seit ich STARTTLS für diese Server in der Access-DB mittels
Srv_Features:mout.web.de S Srv_Features:mout.gmx.net S
gesperrt habe, bekommen die auf dem CentOS-5-Server liegenden Domains wieder Mail von GMX und web.de.
Der CentOS-6-Server hat hingegen keine solchen Probleme:
Aug 9 19:42:32 posthamster sendmail[9072]: STARTTLS=server, relay=mout.gmx.net [212.227.17.20], version=TLSv1/SSLv3, verify=NOT, cipher=DHE-RSA-AES128-SHA, bits=128/128
Natürlich unterscheiden sich die Paketversionen:
gimli posthamster CentOS 5.9 6.4 sendmail 8.13.8-8.1.el5_7 8.14.4-8.el6.x86_64 openssl 0.9.8e-26.el5_9.1 1.0.0-27.el6_4.2.x86_64
Ideen?
aTdHvAaNnKcSe Tilman
Hallo Tilman,
ich habe hier ein merkwürdiges Problem, das verdächtig danach aussieht, als ob es mit der Marketing-Initiative von Telekom, GMX und web.de zu tun hätte:
Evtl. versuchen die Provider Ihre Sicherheit durch "PFS" - Perfect Forward Security zu verbessern.
...
Der CentOS-6-Server hat hingegen keine solchen Probleme:
Aug 9 19:42:32 posthamster sendmail[9072]: STARTTLS=server, relay=mout.gmx.net [212.227.17.20], version=TLSv1/SSLv3, verify=NOT, cipher=DHE-RSA-AES128-SHA, bits=128/128
Natürlich unterscheiden sich die Paketversionen:
gimli posthamsterCentOS 5.9 6.4 sendmail 8.13.8-8.1.el5_7 8.14.4-8.el6.x86_64 openssl 0.9.8e-26.el5_9.1 1.0.0-27.el6_4.2.x86_64
Ideen?
Dies setzt voraus, das in openssl eine Schlüsselvereinbarung nach Diffie-Hellmann möglich ist.
Mach mal 'openssl ciphers' in der shell, hier muss DHE-... oder noch besser (aber unwahrscheinlich) ECDH-... als eine Möglichkeit auftauchen.
Vergleiche mal openssl auf CentOS 5 und CentOS 6...
Die Provider wollen nämlich "cipher=DHE-RSA-AES128-SHA, bits=128/128" sprechen...
Grüße Klaus.
--
------------------------------------------ e-Mail : klaus@tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------
Hallo Klaus,
Am 14.08.2013 10:27, schrieb Klaus Tachtler:
Evtl. versuchen die Provider Ihre Sicherheit durch "PFS" - Perfect Forward Security zu verbessern.
[...]
Dies setzt voraus, das in openssl eine Schlüsselvereinbarung nach Diffie-Hellmann möglich ist.
Mach mal 'openssl ciphers' in der shell, hier muss DHE-... oder noch besser (aber unwahrscheinlich) ECDH-... als eine Möglichkeit auftauchen.
Vergleiche mal openssl auf CentOS 5 und CentOS 6...
Die Provider wollen nämlich "cipher=DHE-RSA-AES128-SHA, bits=128/128" sprechen...
CentOS 5: [ts@gimli ~]$ openssl ciphers DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:KRB5-DES-CBC3-MD5:KRB5-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:KRB5-RC4-MD5:KRB5-RC4-SHA:RC4-SHA:RC4-MD5:RC4-MD5:KRB5-DES-CBC-MD5:KRB5-DES-CBC-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-KRB5-RC4-MD5:EXP-KRB5-RC4-SHA:EXP-RC4-MD5:EXP-RC4-MD5
CentOS 6: [ts@gimli ~]$ ssh posthamster openssl ciphers DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:KRB5-DES-CBC3-SHA:KRB5-DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:KRB5-RC4-SHA:KRB5-RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:KRB5-DES-CBC-SHA:KRB5-DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-RC4-MD5:EXP-KRB5-RC4-SHA:EXP-KRB5-RC4-MD5
DHE-RSA-AES128-SHA ist also bei beiden drin.
[ts@gimli ~]$ openssl ciphers | tr ':' '\n' | sort > gimli-ciphers [ts@gimli ~]$ ssh posthamster openssl ciphers | tr ':' '\n' | sort > posthamster-ciphers [ts@gimli ~]$ diff -u gimli-ciphers posthamster-ciphers --- gimli-ciphers 2013-08-14 11:48:18.000000000 +0200 +++ posthamster-ciphers 2013-08-14 11:48:27.000000000 +0200 @@ -1,13 +1,19 @@ AES128-SHA AES256-SHA -DES-CBC3-MD5 +CAMELLIA128-SHA +CAMELLIA256-SHA DES-CBC3-SHA -DES-CBC-MD5 DES-CBC-SHA DHE-DSS-AES128-SHA DHE-DSS-AES256-SHA +DHE-DSS-CAMELLIA128-SHA +DHE-DSS-CAMELLIA256-SHA +DHE-DSS-SEED-SHA DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA +DHE-RSA-CAMELLIA128-SHA +DHE-RSA-CAMELLIA256-SHA +DHE-RSA-SEED-SHA EDH-DSS-DES-CBC3-SHA EDH-DSS-DES-CBC-SHA EDH-RSA-DES-CBC3-SHA @@ -22,8 +28,6 @@ EXP-KRB5-RC4-MD5 EXP-KRB5-RC4-SHA EXP-RC2-CBC-MD5 -EXP-RC2-CBC-MD5 -EXP-RC4-MD5 EXP-RC4-MD5 KRB5-DES-CBC3-MD5 KRB5-DES-CBC3-SHA @@ -31,7 +35,10 @@ KRB5-DES-CBC-SHA KRB5-RC4-MD5 KRB5-RC4-SHA -RC2-CBC-MD5 -RC4-MD5 +PSK-3DES-EDE-CBC-SHA +PSK-AES128-CBC-SHA +PSK-AES256-CBC-SHA +PSK-RC4-SHA RC4-MD5 RC4-SHA +SEED-SHA
D.h. auf CentOS 6 sind ein paar (nicht alle) MD5-Varianten weggefallen, dafür sind die Verschlüsselungsverfahren Camellia und SEED sowie PSK als Schlüsselaustauschverfahren dazugekommen. Das sollte eigentlich alles kein Problem sein.
Außerdem interpretiere ich die Fehlermeldung so, dass mein CentOS 5 Server die von GMX bzw. web.de angebotenen Verfahren für unzureichend hält - nicht umgekehrt. Eine Dokumentation, was die Meldung offiziell besagen soll, habe ich allerdings nicht gefunden.
Grüße, Tilman
Hallo Tilman,
Außerdem interpretiere ich die Fehlermeldung so, dass mein CentOS 5 Server die von GMX bzw. web.de angebotenen Verfahren für unzureichend hält - nicht umgekehrt. Eine Dokumentation, was die Meldung offiziell besagen soll, habe ich allerdings nicht gefunden.
Ich habe folgendes noch gefunden: http://comments.gmane.org/gmane.linux.devices.blueonyx.user/13490
Kann es sein, dass die Zertifikate auf dem CentOS5 und CentOS6 Server unterschiedlich sind?
Grüße Klaus.
--
------------------------------------------ e-Mail : klaus@tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------
Hallo Klaus,
Am 14.08.2013 14:27, schrieb Klaus Tachtler:
Ich habe folgendes noch gefunden: http://comments.gmane.org/gmane.linux.devices.blueonyx.user/13490
Kann es sein, dass die Zertifikate auf dem CentOS5 und CentOS6 Server unterschiedlich sind?
CentOS 5:
[ts@gimli ~]$ openssl x509 -in /etc/pki/tls/certs/server.crt -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 131562 (0x201ea) Signature Algorithm: sha1WithRSAEncryption Issuer: O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root Validity Not Before: Jul 1 11:12:39 2013 GMT Not After : Jul 1 11:12:39 2015 GMT Subject: CN=mail.pxnet.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) [...] X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Key Usage: critical Digital Signature, Key Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication, Netscape Server Gated Crypto, Microsoft Server Gated Crypto Authority Information Access: OCSP - URI:http://ocsp.cacert.org/
X509v3 CRL Distribution Points: URI:http://crl.cacert.org/class3-revoke.crl [...]
CentOS 6:
[ts@posthamster ~]$ openssl x509 -in /etc/pki/tls/certs/server.crt -noout -text Certificate: Data: Version: 3 (0x2) Serial Number: 65595 (0x1003b) Signature Algorithm: sha1WithRSAEncryption Issuer: O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root Validity Not Before: Jul 10 15:36:22 2012 GMT Not After : Jul 10 15:36:22 2014 GMT Subject: CN=mail.phnxsoft.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) [...] X509v3 extensions: X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication, Netscape Server Gated Crypto, Microsoft Server Gated Crypto X509v3 Key Usage: Digital Signature, Key Encipherment Authority Information Access: OCSP - URI:http://ocsp.cacert.org/ [...]
Zumindest die Key-Länge ist also gleich. Zwei Unterschiede sehe ich:
- "Key Usage" ist beim CentOS-5-Zertifikat als "critical" markiert und beinhaltet "Key Agreement", beim CentOS-6-Zertifikat nicht.
- Das CentOS-5-Zertifikat hat einen CRL Distribution Point, das CentOS-6-Zertifikat nicht.
Kann es daran liegen?
Grüße, Tilman
Hallo Tilman,
da die Zertifikate unterschiedlich sind, wäre es einen Versuch Wert, auch ein neueres Zertifikat von CACert.org für die CentOS 5 Maschine auszustellen (inklusive neuem Schlüssel mit 2048 Byte Schlüssellänge) und es dann einfach mal ausprobieren? / CN=mail.pxnet.com
Es kostet, ja außer ein bisschen Arbeit nichts, bei CACert.org!
Zumindest die Key-Länge ist also gleich. Zwei Unterschiede sehe ich:
"Key Usage" ist beim CentOS-5-Zertifikat als "critical" markiert und beinhaltet "Key Agreement", beim CentOS-6-Zertifikat nicht.
Das CentOS-5-Zertifikat hat einen CRL Distribution Point, das CentOS-6-Zertifikat nicht.
Kann es daran liegen?
Grüße, Tilman
Grüße Klaus.
--
------------------------------------------ e-Mail : klaus@tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hallo Klaus,
Am 16.08.2013 07:41, schrieb Klaus Tachtler:
da die Zertifikate unterschiedlich sind, wäre es einen Versuch Wert, auch ein neueres Zertifikat von CACert.org für die CentOS 5 Maschine auszustellen (inklusive neuem Schlüssel mit 2048 Byte Schlüssellänge)
Die Schlüssellänge ist es ja offensichtlich nicht. Sonst dürfte es bei der CentOS-6-Maschine auch nicht funktionieren.
und es dann einfach mal ausprobieren? / CN=mail.pxnet.com
Es kostet, ja außer ein bisschen Arbeit nichts, bei CACert.org!
Das ist ja nicht alles. Jeder negativ ausfallende Test bedeutet den Verlust (mindestens) einer Kundenmail. Da würde ich schon gerne erst einmal wissen, ob es überhaupt am Zertifikat liegt oder an etwas ganz anderem, z.B. an der OpenSSL-Version.
Gibt es denn nirgends eine Info, was diese Fehlermeldung eigentlich bedeutet? Kann man also nur mit "trial and horror" versuchen, sie wegzubekommen?
Viele Grüße, Tilman
Hallo Tilman,
Hallo Klaus,
Am 16.08.2013 07:41, schrieb Klaus Tachtler:
da die Zertifikate unterschiedlich sind, wäre es einen Versuch Wert, auch ein neueres Zertifikat von CACert.org für die CentOS 5 Maschine auszustellen (inklusive neuem Schlüssel mit 2048 Byte Schlüssellänge)
Die Schlüssellänge ist es ja offensichtlich nicht. Sonst dürfte es bei der CentOS-6-Maschine auch nicht funktionieren.
Die Schlüssellänge ist für den Fehler egal, jedoch für neue Schlüssel sollten keine 1024, sonder mindestens 2048 Byte verwendet werden.
und es dann einfach mal ausprobieren? / CN=mail.pxnet.com
Es kostet, ja außer ein bisschen Arbeit nichts, bei CACert.org!
Das ist ja nicht alles. Jeder negativ ausfallende Test bedeutet den Verlust (mindestens) einer Kundenmail. Da würde ich schon gerne erst einmal wissen, ob es überhaupt am Zertifikat liegt oder an etwas ganz anderem, z.B. an der OpenSSL-Version.
Man kann postfix so konfigurieren, dass er immer bei einm Problem/Fehler nicht mit einem 5xx, sonder 4xx Fehlercode reagiert. Dann solltest Du auch testen können, ohen e-Mails von Kunden (mit einem ordentlichen e-Mail setup) zu verlieren.
Der Schalter in der /etc/main.cf heisst: soft_bounce = yes
Gibt es denn nirgends eine Info, was diese Fehlermeldung eigentlich bedeutet? Kann man also nur mit "trial and horror" versuchen, sie wegzubekommen?
Nein, ich habe auch bei google aktuell nichts dazu gefunden.
Viele Grüße, Tilman
Grüße Klaus.
--
------------------------------------------ e-Mail : klaus@tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------
Hallo Klaus,
Am 18.08.2013 14:39, schrieb Klaus Tachtler:
und es dann einfach mal ausprobieren? / CN=mail.pxnet.com
Es kostet, ja außer ein bisschen Arbeit nichts, bei CACert.org!
Das ist ja nicht alles. Jeder negativ ausfallende Test bedeutet den Verlust (mindestens) einer Kundenmail. Da würde ich schon gerne erst einmal wissen, ob es überhaupt am Zertifikat liegt oder an etwas ganz anderem, z.B. an der OpenSSL-Version.
Man kann postfix so konfigurieren, dass er immer bei einm Problem/Fehler nicht mit einem 5xx, sonder 4xx Fehlercode reagiert. Dann solltest Du auch testen können, ohen e-Mails von Kunden (mit einem ordentlichen e-Mail setup) zu verlieren.
Tja, leider habe ich keinen Zugriff auf die Mailausgangsserver von GMX und web.de, um diese Einstellung dort vorzunehmen. :-)
Will sagen: auf meinem eigenen Server (der übrigens kein Postfix einsetzt) habe ich keinen Einfluss darauf, wie die Server bei GMX und web.de (die übrigens soweit ich sehe auch kein Postfix einsetzen) auf das Fehlschlagen der SSL-Aushandlung reagieren.
Vielleicht sollte ich die Marketing-Lösung wählen: ich behalte die Einstellung in der Access-DB des CentOS-5-Servers bei, dass mout.web.de und mout.gmx.net kein STARTTLS angeboten wird, und sage meinen Kunden, dass web.de und GMX leider die verschlüsselte Übertragung zu uns nicht unterstützen. :-)
Grüße, Tilman
Hallo Tilman,
Tja, leider habe ich keinen Zugriff auf die Mailausgangsserver von GMX und web.de, um diese Einstellung dort vorzunehmen. :-)
Nun, das ist auch nicht notwendig, wenn DU (so nahm ich an) Dein eigener MailServer auf Deinem CentOS5-Server ein Postfix ist.
Will sagen: auf meinem eigenen Server (der übrigens kein Postfix einsetzt) habe ich keinen Einfluss darauf, wie die Server bei GMX und web.de (die übrigens soweit ich sehe auch kein Postfix einsetzen) auf das Fehlschlagen der SSL-Aushandlung reagieren.
Du hast auf dem CentOS5-Server keinen Postfix im Einsatz? Was hast Du den im Einsatz?
Vielleicht sollte ich die Marketing-Lösung wählen: ich behalte die Einstellung in der Access-DB des CentOS-5-Servers bei, dass mout.web.de und mout.gmx.net kein STARTTLS angeboten wird, und sage meinen Kunden, dass web.de und GMX leider die verschlüsselte Übertragung zu uns nicht unterstützen. :-)
Das wäre aber nicht ganz richtig, da GMX und Web.de das ja tun, nur Dein CentOS5-Server es nicht annimmt...
Grüße, Tilman
Grüße Klaus.
--
------------------------------------------ e-Mail : klaus@tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------
Hallo Klaus,
Am 20.08.2013 09:43, schrieb Klaus Tachtler:
Tja, leider habe ich keinen Zugriff auf die Mailausgangsserver von GMX und web.de, um diese Einstellung dort vorzunehmen. :-)
Nun, das ist auch nicht notwendig, wenn DU (so nahm ich an) Dein eigener MailServer auf Deinem CentOS5-Server ein Postfix ist.
Das verstehe ich nicht. Wie soll ich (selbst wenn ich Postfix hätte) auf meinem Server beeinflussen, was der sendende Server macht, wenn die SSL-Aushandlung fehlschlägt?
Will sagen: auf meinem eigenen Server (der übrigens kein Postfix einsetzt) habe ich keinen Einfluss darauf, wie die Server bei GMX und web.de (die übrigens soweit ich sehe auch kein Postfix einsetzen) auf das Fehlschlagen der SSL-Aushandlung reagieren.
Du hast auf dem CentOS5-Server keinen Postfix im Einsatz? Was hast Du den im Einsatz?
Wie ich schon im Ausgangsposting des Threads schrieb: Sendmail, Cyrus IMAP, Squirrelmail Aber das ist ja nur ein Nebenproblem. Ich bin sicher, es gibt auch bei Sendmail eine Option, die dem "soft_bounce = yes" von Postfix entspricht. Ich sehe nur nicht, was das bringen sollte, da mein Server ja gar nicht so weit kommt, ein Bounce generieren zu wollen. Er sieht nur einen Connect, STARTTLS und eine fehlschlagende SSL-Aushandlung, mehr nicht.
Vielleicht sollte ich die Marketing-Lösung wählen: ich behalte die Einstellung in der Access-DB des CentOS-5-Servers bei, dass mout.web.de und mout.gmx.net kein STARTTLS angeboten wird, und sage meinen Kunden, dass web.de und GMX leider die verschlüsselte Übertragung zu uns nicht unterstützen. :-)
Das wäre aber nicht ganz richtig, da GMX und Web.de das ja tun, nur Dein CentOS5-Server es nicht annimmt...
Ist das so? Für mich sieht es eher so aus, als ob mein CentOS-5- Server es durchaus täte, nur GMX und web.de die von ihm angebotene Verschlüsselung als "insufficient" ablehnen. Aber damit sind wir wieder bei der ungeklärten Frage, was die Meldung denn nun eigentlich wirklich bedeutet. Vielleicht sollte ich mir mal die OpenSSL-Quellen besorgen und nachschauen.
Mit allen anderen Sendern funktioniert es jedenfalls schon seit Jahren und nach wie vor völlig problemlos:
[ts@gimli ~]$ grep -c "STARTTLS=server" /var/log/maillog* /var/log/maillog:1753 /var/log/maillog.1:8462 /var/log/maillog.2:19844 /var/log/maillog.3:34259 /var/log/maillog.4:7279 [...]
Es sind nur mout.web.de und mout.gmx.net, die rumzicken.
Grüße, Tilman
Hallo Tilman,
Das verstehe ich nicht. Wie soll ich (selbst wenn ich Postfix hätte) auf meinem Server beeinflussen, was der sendende Server macht, wenn die SSL-Aushandlung fehlschlägt?
Wie ich schon im Ausgangsposting des Threads schrieb: Sendmail, Cyrus IMAP, Squirrelmail Aber das ist ja nur ein Nebenproblem. Ich bin sicher, es gibt auch bei Sendmail eine Option, die dem "soft_bounce = yes" von Postfix entspricht. Ich sehe nur nicht, was das bringen sollte, da mein Server ja gar nicht so weit kommt, ein Bounce generieren zu wollen. Er sieht nur einen Connect, STARTTLS und eine fehlschlagende SSL-Aushandlung, mehr nicht.
Nun, was ich meinte, war die Antwort auf die Möglichkeit mal ein neues Zertifikat auszuprobieren und dabei nicht alle Kunden e-Mails die in der Zeit eingehen würden zu verlieren.
Grüße Klaus.
--
------------------------------------------ e-Mail : klaus@tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------
Hallo Klaus,
Am 20.08.2013 17:10, schrieb Klaus Tachtler:
[...] Ich bin sicher, es gibt auch bei Sendmail eine Option, die dem "soft_bounce = yes" von Postfix entspricht. Ich sehe nur nicht, was das bringen sollte, da mein Server ja gar nicht so weit kommt, ein Bounce generieren zu wollen. Er sieht nur einen Connect, STARTTLS und eine fehlschlagende SSL-Aushandlung, mehr nicht.
Nun, was ich meinte, war die Antwort auf die Möglichkeit mal ein neues Zertifikat auszuprobieren und dabei nicht alle Kunden e-Mails die in der Zeit eingehen würden zu verlieren.
Schon klar. Aber genau das ginge eben nur durch Eingriff auf Seiten web.de bzw. GMX.
Ablauf:
1. mout.web.de findet im DNS meinen CentOS-5-Server mail.pxnet.com als MX für eine meiner Kundendomains.
3. mout.web.de baut eine TCP-Verbindung zu mail.pxnet.com Port 25 auf.
4. mail.pxnet.com bietet im Banner ESMTP an.
5. mout.web.de sendet EHLO.
6. mail.pxnet.com bietet in der Antwort STARTTLS an.
7. mout.web.de sendet STARTTLS.
8. Die SSL-Aushandlung schlägt (warum auch immer) mit "tlsv1 alert insufficient security" fehl.
9. mout.web.de generiert eine Unzustellbarkeitsnachricht.
An welcher Stelle sollte da die Option "soft_bounce = yes" bzw. ihr Softbounce-Äquivalent greifen? Der letzte Punkt, an dem mein CentOS-5-Server noch Einfluss auf den Ablauf nehmen kann, ist 6. Das ist meine momentane Behelfslösung: "wenn sendender Server = mout.web.de, dann kein STARTTLS anbieten" Damit findet aber kein Test des Zertifikats statt.
Wenn ich ein neues Zertifikat mit mout.web.de testen will, muss ich mout.web.de STARTTLS anbieten. Wenn der Test dann negativ ausfällt, lande ich ohne weitere Einflussmöglichkeit meines Servers bei Punkt 9, d.h. die Mail geht verloren.
Grüße, Tilman
Hallo Tilman,
Hallo Klaus,
Am 20.08.2013 17:10, schrieb Klaus Tachtler:
[...] Ich bin sicher, es gibt auch bei Sendmail eine Option, die dem "soft_bounce = yes" von Postfix entspricht. Ich sehe nur nicht, was das bringen sollte, da mein Server ja gar nicht so weit kommt, ein Bounce generieren zu wollen. Er sieht nur einen Connect, STARTTLS und eine fehlschlagende SSL-Aushandlung, mehr nicht.
Nun, was ich meinte, war die Antwort auf die Möglichkeit mal ein neues Zertifikat auszuprobieren und dabei nicht alle Kunden e-Mails die in der Zeit eingehen würden zu verlieren.
Schon klar. Aber genau das ginge eben nur durch Eingriff auf Seiten web.de bzw. GMX.
Ablauf:
mout.web.de findet im DNS meinen CentOS-5-Server mail.pxnet.com als MX für eine meiner Kundendomains.
mout.web.de baut eine TCP-Verbindung zu mail.pxnet.com Port 25 auf.
mail.pxnet.com bietet im Banner ESMTP an.
mout.web.de sendet EHLO.
mail.pxnet.com bietet in der Antwort STARTTLS an.
mout.web.de sendet STARTTLS.
Die SSL-Aushandlung schlägt (warum auch immer) mit "tlsv1 alert insufficient security" fehl.
Ich bin mir nicht sicher, es wäre auszuprobieren - wenn an dieser Stelle Dein Mailserver mit einem 5xx-Code reagiert (ist das so?!?) dann würde der soft_bounce = yes diesen in einen 4xx-Code verwandeln. Wenn das mit dem 5xx-Code NICHT so ist, dann gebe ich Dir recht, hast Du keine Einflussmöglichkeit.
- mout.web.de generiert eine Unzustellbarkeitsnachricht.
An welcher Stelle sollte da die Option "soft_bounce = yes" bzw. ihr Softbounce-Äquivalent greifen? Der letzte Punkt, an dem mein CentOS-5-Server noch Einfluss auf den Ablauf nehmen kann, ist 6. Das ist meine momentane Behelfslösung: "wenn sendender Server = mout.web.de, dann kein STARTTLS anbieten" Damit findet aber kein Test des Zertifikats statt.
Wenn ich ein neues Zertifikat mit mout.web.de testen will, muss ich mout.web.de STARTTLS anbieten. Wenn der Test dann negativ ausfällt, lande ich ohne weitere Einflussmöglichkeit meines Servers bei Punkt 9, d.h. die Mail geht verloren.
Grüße, Tilman
Grüße Klaus.
--
------------------------------------------ e-Mail : klaus@tachtler.net Homepage: http://www.tachtler.net DokuWiki: http://www.dokuwiki.tachtler.net ------------------------------------------
Hallo Liste,
Am 14.08.2013 10:10, schrieb /me:
Ich betreibe diverse Mail-Domains, verteilt auf zwei Server, einer mit CentOS 5, der andere mit CentOS 6. Ansonsten sind beide gleich konfiguriert: Sendmail, Cyrus IMAP, Squirrelmail, ein CACert-SSL-Zertifikat für alles und opportunistische SMTP-Verschlüsselung. [...] Seit ca. 2013-08-05 14:30 schlugen dann auf dem CentOS-5-Server erst vereinzelt, dann durchgehend, Verbindungsversuche von mout.web.de und mout.gmx.net so fehl:
Aug 5 15:05:44 gimli sendmail[15250]: STARTTLS=server, error: accept failed=0, SSL_error=1, errno=0, retry=-1 Aug 5 15:05:44 gimli sendmail[15250]: STARTTLS=server: 15250:error:1409442F:SSL routines:SSL3_READ_BYTES:tlsv1 alert insufficient security:s3_pkt.c:1092:SSL alert number 71 Aug 5 15:05:44 gimli sendmail[15250]: r75D5gfM015250: mout.gmx.net [212.227.17.20] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA
[...]
Der CentOS-6-Server hat hingegen keine solchen Probleme:
Aug 9 19:42:32 posthamster sendmail[9072]: STARTTLS=server, relay=mout.gmx.net [212.227.17.20], version=TLSv1/SSLv3, verify=NOT, cipher=DHE-RSA-AES128-SHA, bits=128/128
Natürlich unterscheiden sich die Paketversionen:
gimli posthamsterCentOS 5.9 6.4 sendmail 8.13.8-8.1.el5_7 8.14.4-8.el6.x86_64 openssl 0.9.8e-26.el5_9.1 1.0.0-27.el6_4.2.x86_64
Des Rätsels Lösung findet sich hier:
http://web.gxis.de/tiki/tiki-view_blog_post.php?postId=159
Mit dem dort beschriebenen Workaround einer Diffie-Hellman- Konfigurationsdatei für Sendmail funktioniert TLS auch mit GMX und web.de.
Es lag also an der Sendmail-Version bzw. an einem Bug, der in Sendmail 8.14.4 behoben ist und in 8.13.8 noch nicht.
Danke allen Tippgebern on- und offlist.
-
Klaus Tachtler -
Tilman Schmidt