[postfix-users] network_biopair_interop
Hallo zusammen,
ein Kunde hat mich auf folgendes Problem aufmerksam gemacht. Es wurde versucht, eine E-Mail an ihn zu schicken. Diese konnte nicht zugestellt werden. Neben der Fehlermeldung des sendenden Mailservers habe ich im Postfix-Log folgendes gefunden:
postfix/smtpd[21148]: connect from mail.keil-it.de[78.47.94.137] postfix/smtpd[21148]: setting up TLS connection from mail.keil-it.de[78.47.94.137] postfix/smtpd[21148]: warning: network_biopair_interop: error reading 5 bytes from the network: Connection reset by peer postfix/smtpd[21148]: SSL_accept error from mail.keil-it.de[78.47.94.137]: -1 postfix/smtpd[21148]: lost connection after STARTTLS from mail.keil-it.de[78.47.94.137] postfix/smtpd[21148]: disconnect from mail.keil-it.de[78.47.94.137]
Damit war die Sache fuer den sendenden Mailserver erledigt und die Mail wurde verworfen. Bei diesem Mailserver handelt es sich wohl um einen MDaemon 10.0.4, zumindest sagt er das ueber sich.
Die Fehlermeldung des Sendemailservers sieht so aus:
STARTTLS Ready to start TLS SSL negotiation failed, error code 0x80090308
Da diese network_biopair_interop Fehlermeldung nicht einmalig ist in meinen Maillogs, gibt es hier wohl ein generelles Problem. Andere Mailserver sind allerdings nicht so eingeschnappt wie der MDaemon und senden ihre Mail trotzdem.
postfix/smtpd[18283]: connect from mserv01.FH-Biberach.DE[193.196.3.7] postfix/smtpd[18283]: setting up TLS connection from mserv01.FH-Biberach.DE[193.196.3.7] postfix/smtpd[18283]: warning: network_biopair_interop: error reading 5 bytes from the network: Connection reset by peer postfix/smtpd[18283]: SSL_accept error from mserv01.FH-Biberach.DE[193.196.3.7]: -1 postfix/smtpd[18283]: lost connection after STARTTLS from mserv01.FH-Biberach.DE[193.196.3.7] postfix/smtpd[18283]: disconnect from mserv01.FH-Biberach.DE[193.196.3.7] postfix/smtpd[6855]: connect from mserv01.FH-Biberach.DE[193.196.3.7] postfix/smtpd[6855]: NOQUEUE: filter: RCPT from mserv01.FH-Biberach.DE[193.196.3.7]: xxx@xxx.de: Sender address triggers FILTER amavis:[127.0.0.1]:10024; from=xxx@xxx.de to=yyy@yyy.de proto=ESMTP helo=<mserv01.fh-biberach.de> ... postfix/smtpd[6855]: disconnect from mserv01.FH-Biberach.DE[193.196.3.7]
Recherechen im Internet haben ergeben, dass eventuell das Setting smtpd_tls_ask_ccert daran schuld sein koennte. Das ist bei mir auf "yes", da ich gerne die folgende Header sehe:
Received: from mail.xxx.de (mail.xxx.de [xxx.xxx.xxx.xxx]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.xxx.de", Issuer "CA Cert Signing Authority" (verified OK)) by mail.hot-chilli.net (Postfix) with ESMTPS id 4C8223CCACF for msebald@hot-chilli.net; Sun, 8 Mar 2009 21:34:42 +0100 (CET)
anstatt sowas:
Received: from mail2.hot-chilli.net (mail.xxx.net [IPv6:2a01:xxx:xxx:29b::x]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hot-chilli.net (Postfix) with ESMTPS id 26A3A3CCAC6 for msebald@hot-chilli.net; Tue, 10 Mar 2009 13:08:17 +0100 (CET)
Auch ansonsten macht es sicherlich Sinn, das Zertifikat zu pruefen. Wenn ich das richtig verstanden habe, fragt Postfix in dem Fall ja nur nach dem Zertifikat, macht aber auch ohne weiter.
Gut, vielleicht ist die Ursache ja auch ganz wo anders zu suchen.
Kann mir hier vielleicht jemand weiterhelfen?
Viele Gruesse, Martin
* Martin Sebald msebald@hot-chilli.net:
Recherechen im Internet haben ergeben, dass eventuell das Setting smtpd_tls_ask_ccert daran schuld sein koennte. Das ist bei mir auf "yes", da ich gerne die folgende Header sehe:
Stells ab, dann gehts
Hallo Ralf,
hui, die Antwort war mal mehr als schnell. ;-)
Recherechen im Internet haben ergeben, dass eventuell das Setting smtpd_tls_ask_ccert daran schuld sein koennte. Das ist bei mir auf "yes", da ich gerne die folgende Header sehe:
Stells ab, dann gehts
Also liegt es tatsaechlich daran? Ne andere Moeglichkeit gibt es nicht und ist das die empfohlene Vorgehensweise?
Warum ich das gerne an habe hatte ich ja geschildert. Nur hilft es mir natuerlich auch nicht, in Schoenheit zu sterben...
Viele Gruesse, Martin
* Martin Sebald msebald@hot-chilli.net:
Hallo Ralf,
hui, die Antwort war mal mehr als schnell. ;-)
Recherechen im Internet haben ergeben, dass eventuell das Setting smtpd_tls_ask_ccert daran schuld sein koennte. Das ist bei mir auf "yes", da ich gerne die folgende Header sehe:
Stells ab, dann gehts
Also liegt es tatsaechlich daran? Ne andere Moeglichkeit gibt es nicht und ist das die empfohlene Vorgehensweise?
Ich weiss jetzt nicht ob man das selektiv requesten kann...
Warum ich das gerne an habe hatte ich ja geschildert. Nur hilft es mir natuerlich auch nicht, in Schoenheit zu sterben...
;)
Hallo Ralf!
Recherechen im Internet haben ergeben, dass eventuell das Setting smtpd_tls_ask_ccert daran schuld sein koennte. Das ist bei mir auf "yes", da ich gerne die folgende Header sehe:
Stells ab, dann gehts
Also liegt es tatsaechlich daran? Ne andere Moeglichkeit gibt es nicht und ist das die empfohlene Vorgehensweise?
Ich weiss jetzt nicht ob man das selektiv requesten kann...
Du meinst, dass der Server nur bestimmte Clients nach dem Zertifikat fragt bzw bestimmte Clients nicht nach dem Zertifikat fragt?
Wuerde ja beides wenig Sinn machen. Denn im ersten Fall pflege ich eine Whitelist an Servern, die ich eh kenne (gut, ich koennte so u.U. eine MITM-Attack ausschliessen) und im zweiten Fall hab ich erstmal in die Sch**sse gelangt bevor dann die naechsten Mails alle ankommen.
Und in beiden Faellen muesste ich Listen pflegen...
Warum ich das gerne an habe hatte ich ja geschildert. Nur hilft es mir natuerlich auch nicht, in Schoenheit zu sterben...
;)
Trotzdem irgendwie unschoen. Ich bin ein grosser Fan eines aussagekraeftigen und "huebschen" Mailheaders. ;-) Nun steht da schlicht "No client certificate requested" und sonst nix... Im Logfile sieht es noch bitterer aus. Da werden nun alle TLS-Connections als untrusted ausgegeben. Bisher hat er ja bei passenden Zertifikaten eine "Trusted TLS-Connection" angegeben.
...Egal, wenn ich so die Loesung habe und Mails nun auch von zickigen Mailservern und -clients angenommen werden, den letzten Absatz einfach ignorieren. Ich weiss, dass ich hier viel Wind um an sich unwichtige Details mache. ;-)
Viele Gruesse, Martin
Zitat von Martin Sebald msebald@hot-chilli.net:
Hallo Ralf,
hui, die Antwort war mal mehr als schnell. ;-)
Recherechen im Internet haben ergeben, dass eventuell das Setting smtpd_tls_ask_ccert daran schuld sein koennte. Das ist bei mir auf "yes", da ich gerne die folgende Header sehe:
Stells ab, dann gehts
Also liegt es tatsaechlich daran? Ne andere Moeglichkeit gibt es nicht und ist das die empfohlene Vorgehensweise?
Warum ich das gerne an habe hatte ich ja geschildert. Nur hilft es mir natuerlich auch nicht, in Schoenheit zu sterben...
Es macht wenig Sinn den Client nach einem Zertifikat zu fragen welches eh nicht verwendet wird. Manche Clients verstehen alleine schon die Frage nach dem Zertifikat als "wen kein Cleint Zertifikat vorhanden nehmen wir die Mail nicht an", wahrscheinlich weil üblicherweise Client Zertifikate eingesetzt werden um Relaying ohne Benutzer/PWD zu erlauben.
Gruß
Andreas
Hallo!
Es macht wenig Sinn den Client nach einem Zertifikat zu fragen welches eh nicht verwendet wird. Manche Clients verstehen alleine schon die Frage nach dem Zertifikat als "wen kein Cleint Zertifikat vorhanden nehmen wir die Mail nicht an", wahrscheinlich weil üblicherweise Client Zertifikate eingesetzt werden um Relaying ohne Benutzer/PWD zu erlauben.
Naja, verwendet wird es schon. Immerhin wird es geprueft und das Ergebnis wird dann im Mailheader festgehalten.
Du hast natuerlich Recht, die Mail wird auch bei fehlgeschlagener Pruefung angenommen.
Ich fasse also nochmal zusammen: Empfehlenswert ist, dieses Feature nicht zu verwenden weil teilweise Clients (Server und echte Mailclients) diese Anfrage nicht verstehen und dann beleidigt abdrehen und die einzusendende Mail verwerfen?
Viele Gruesse, Martin
participants (3)
-
lst_hoe02＠kwsoft.de -
Martin Sebald -
Ralf Hildebrandt