bunfried 10 Geschrieben 7. September 2009 Melden Teilen Geschrieben 7. September 2009 Ich hab einen fully-patched-SBS 2003 mit Exchange 2003 und ein massives Relay-Problem, obwohl alle relay-Möglichkeiten deaktiviert sind -> siehe attachments!!!!:shock: Das Problem tritt erst seit kurzem auf, aber dafür umso heftiger. Gestern mußte ich über 110.000 Mails eliminieren..... Bin im Moment ziemlich ratlos und hab den SMTP-Port auf der Firewall deaktiviert, damit der Server nicht abschmiert.:confused: Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 7. September 2009 Melden Teilen Geschrieben 7. September 2009 Hallo. Wer sagt, dass es sich um Relay Problem handelt? Es könnte sich genauso um einen verseuchten Server, Client oder ein Backscatter Problem handeln. Mit den gelieferten Infos kann dazu keine Aussage getroffen werden. Was passiert also genau auf dem System? LG Günther Zitieren Link zu diesem Kommentar
bunfried 10 Geschrieben 7. September 2009 Autor Melden Teilen Geschrieben 7. September 2009 Nachdem mir diese Website (Third Party Relay Check RBL.JP????????? RBL.JP) bestätigt, daß ich ein Relay-Problem habe und ein ident konfigurierter Server ohne Probleme diesen Test besteht, glaube ich an ein relay-Problem. Außerdem hab ich seitdem ich SMTP auf der Firewall geschlossen habe, keine SPAM-Mail mehr in der Queue. Und laut Firewall versucht gerade die halbe Welt e-Mails über meinen Server weiterzusenden...:cry: 1 2009-09-07 09:47:32 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 213.4.129.21:60134 192.168.1.51:25 ACCESS BLOCK 3 2009-09-07 09:47:24 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 209.85.212.177:55896 192.168.1.51:25 ACCESS BLOCK 5 2009-09-07 09:47:23 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 66.135.197.24:33644 192.168.1.51:25 ACCESS BLOCK 7 2009-09-07 09:47:08 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 213.4.129.21:56706 192.168.1.51:25 ACCESS BLOCK 8 2009-09-07 09:47:07 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 209.85.212.177:62526 192.168.1.51:25 ACCESS BLOCK 9 2009-09-07 09:47:04 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 85.124.152.3:18970 192.168.1.51:25 ACCESS BLOCK 10 2009-09-07 09:47:03 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 195.62.26.18:11615 192.168.1.51:25 ACCESS BLOCK 11 2009-09-07 09:47:03 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 195.62.26.18:11613 192.168.1.51:25 ACCESS BLOCK 12 2009-09-07 09:46:59 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 66.135.197.24:33644 192.168.1.51:25 ACCESS BLOCK 13 2009-09-07 09:46:56 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 80.237.210.104:53695 192.168.1.51:25 ACCESS BLOCK 15 2009-09-07 09:46:47 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 213.4.129.21:54158 192.168.1.51:25 ACCESS BLOCK 16 2009-09-07 09:46:44 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 66.135.197.24:65185 192.168.1.51:25 ACCESS BLOCK 17 2009-09-07 09:46:43 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 209.85.212.177:62526 192.168.1.51:25 ACCESS BLOCK 18 2009-09-07 09:46:42 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 195.62.26.18:11615 192.168.1.51:25 ACCESS BLOCK 19 2009-09-07 09:46:42 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 195.62.26.18:11613 192.168.1.51:25 ACCESS BLOCK 20 2009-09-07 09:46:35 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 80.237.210.104:53695 192.168.1.51:25 ACCESS BLOCK 21 2009-09-07 09:46:31 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 213.4.129.21:24875 192.168.1.51:25 ACCESS BLOCK 23 2009-09-07 09:46:22 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 209.85.212.177:62526 192.168.1.51:25 ACCESS BLOCK 24 2009-09-07 09:46:17 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=2] 62.179.121.37:5229 192.168.1.51:25 ACCESS BLOCK 25 2009-09-07 09:46:07 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 80.121.153.19:42619 192.168.1.51:25 ACCESS BLOCK 26 2009-09-07 09:46:07 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 213.4.129.21:36431 192.168.1.51:25 ACCESS BLOCK 28 2009-09-07 09:45:50 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP 66.135.197.24:65185 192.168.1.51:25 ACCESS BLOCK 29 2009-09-07 09:45:46 notice Firewall priority:11, from WAN to LAN1, TCP, service others, DROP [count=3] 213.4.129.21:33823 192.168.1.51:25 ACCESS BLOCK Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 7. September 2009 Melden Teilen Geschrieben 7. September 2009 Hallo. Nachdem mir diese Website (Third Party Relay Check RBL.JP????????? RBL.JP) bestätigt Und an welcher Stelle (Position) tritt das Problem auf? Gibt es vor dem Exchange noch ein SMTP Tool (SPAM Filter etc)? Und bitte sei doch nicht so geizig mit deinen Infos. Wenn du zum Arzt gehst, beschreibst du ihm ja auch, dass dir die Furunkel auf der linken A.. -Backe bei Sitzen Probleme bereitet. Oder rufst du deine Arzt an: "Hallo Doc, mir tuts weh, rate mal wo, und mach sofort etwas dagegen?" LG Günther Zitieren Link zu diesem Kommentar
bunfried 10 Geschrieben 7. September 2009 Autor Melden Teilen Geschrieben 7. September 2009 Die Frage ist eher wo es nicht auftritt.:shock: Mail Relay testing. Connecting to MAILSERVER for test ... <<< 220 DOMAIN Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at Mon, 7 Sep 2009 09:58:41 +0200 >>> HELO h.rbl.jp <<< 250 DOMAIN Hello [192.168.1.1] Relay test 0 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@h.rbl.jp> <<< 250 2.1.0 rlychk@h.rbl.jp....Sender OK >>> RCPT TO: <rlytest@rbl.jp> <<< 250 2.1.5 rlytest@rbl.jp relay accepted!! Relay test 1 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk> <<< 250 2.1.0 rlychk@DOMAIN....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 2 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <> <<< 250 2.1.0 <>....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 3 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 4 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@[iP]> <<< 250 2.1.0 rlychk@[iP]....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 5 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <rlytest%h.rbl.jp@MAILSERVER> <<< 250 2.1.5 rlytest%h.rbl.jp@MAILSERVER relay accepted!! Relay test 6 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <rlytest%h.rbl.jp@[iP]> <<< 250 2.1.5 rlytest%h.rbl.jp@[iP] relay accepted!! Relay test 10 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <"rlytest@h.rbl.jp"@MAILSERVER> <<< 250 2.1.5 "rlytest@h.rbl.jp"@MAILSERVER relay accepted!! Relay test 11 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <"rlytest@h.rbl.jp"@[iP]> <<< 250 2.1.5 "rlytest@h.rbl.jp"@[iP] relay accepted!! Relay test 12 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <@MAILSERVER:rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 13 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <@[iP]:rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Relay test 15 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <h.rbl.jp!rlytest@MAILSERVER> <<< 250 2.1.5 h.rbl.jp!rlytest@MAILSERVER relay accepted!! Relay test 16 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@MAILSERVER> <<< 250 2.1.0 rlychk@MAILSERVER....Sender OK >>> RCPT TO: <h.rbl.jp!rlytest@[iP]> <<< 250 2.1.5 h.rbl.jp!rlytest@[iP] relay accepted!! Relay test 19 >>> RSET <<< 250 2.0.0 Resetting >>> MAIL FROM: <rlychk@localhost> <<< 250 2.1.0 rlychk@localhost....Sender OK >>> RCPT TO: <rlytest@h.rbl.jp> <<< 250 2.1.5 rlytest@h.rbl.jp relay accepted!! Closing connection ... >>> QUIT <<< 221 2.0.0 DOMAIN Service closing transmission channel Relay test result All tests performed, 14 relays accepted. Zitieren Link zu diesem Kommentar
bunfried 10 Geschrieben 9. September 2009 Autor Melden Teilen Geschrieben 9. September 2009 Lösung gefunden: Die Firewall war der Übeltäter. Das Routing hat es scheinbar zu gut gemeint und den externen Traffic direkt ins LAN geroutet. Dort ist das Relay ja zugänglich. Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 9. September 2009 Melden Teilen Geschrieben 9. September 2009 Hallo. Danke für die Rückmeldung. Die Firewall war der Übeltäter [stichelei an] .. und wer hat die Firewall konfiguriert? [stichelei aus] ;) LG Günther Zitieren Link zu diesem Kommentar
bunfried 10 Geschrieben 9. September 2009 Autor Melden Teilen Geschrieben 9. September 2009 Das hab ich überhört.;) Aber mit der ZyWall USG 100 steh ich sowieso auf Kriegsfuß. Der Zywall-Support (!) hat mir zwar bestätigt, daß die config in Ordnung ist. Aber ich hab trotzdem immer wieder Routingprobleme gehabt. Aber was da jetzt los war, weiß ich noch nicht. :nene: Zitieren Link zu diesem Kommentar
GuentherH 61 Geschrieben 9. September 2009 Melden Teilen Geschrieben 9. September 2009 Hallo. Aber mit der ZyWall USG 100 steh ich sowieso auf Kriegsfuß Wieso? Man muss nur mit der richtigen Denkweise arbeiten. Wie lautet den die NAT - Regel (ah, heißt jetzt ja "Virtual Server" ;))? LG Günther Zitieren Link zu diesem Kommentar
bunfried 10 Geschrieben 9. September 2009 Autor Melden Teilen Geschrieben 9. September 2009 Wieso? Man muss nur mit der richtigen Denkweise arbeiten. Die Umstellung war gar nicht so ohne. Aber wie gesagt, sogar laut Zyxel war die config einwandfrei. Ich bekomm jetzt sogar eine Teststellung in Taiwan, weil ich die IPsec-VPN-Verbindungen nicht so performen wie gehabt. Zitieren Link zu diesem Kommentar
djmaker 95 Geschrieben 9. September 2009 Melden Teilen Geschrieben 9. September 2009 Mache in den Relay-Einschränkungen den Haken bei "Jedem Computer . . . ." raus. Wir hatten trotz einer sauber konfigurierten PIX-Firewall und einem sauber konfigurierten Exchange (mit sicheren und mehrmals geänderten PWs) bei einem Kunden das gleiche Problem. Dieses wurde wie oben gelöst. Viren etc.konnten in diesem Fall ziemlich sicher ausgeschlossen werden. Zitieren Link zu diesem Kommentar
bunfried 10 Geschrieben 9. September 2009 Autor Melden Teilen Geschrieben 9. September 2009 Mache in den Relay-Einschränkungen den Haken bei "Jedem Computer . . . ." raus. Hab ich probiert, aber das relay war trotzdem offen. Ich werd mal prüfen welche Routing-Einträge für den "Tag der offenen Tür" verantwortlich sind. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.