Am Wed, 03 Aug 2005 17:50:06 +0200 schrieb Torsten E. : Hallo ihr "Helfer" Wenn ihr das lest (was ich in dem Moment des schreibens hoffe) hat das senden über postfix funktioniert! Mein Fehler war wie von Euch vermutet der Eintrag: inet_interfaces = 127.0.0.1 ::1 Vielen Dank, der Thread ist somit beendet Gruß Johannes

Johannes Kaindlstorfer scribbled on 03.08.2005 14:11:

[...]

...

Provider hab ich eingetragen Name und Passwort sind nicht notwendig smtp Ports offen? nachdem kein telnet server 25 vom client möglich ist und vom server direkt schon bezweifle ich das schon, firewall läuft keine inet_interfaces sind gesetzt

Dann setze doch in der /etc/postfix/main.cf die Option: inet_interfaces = 192.168.0.1 127.0.0.1 ::1, oder einfach inet_interfaces = all (192er IP-Adresse selbstredend anpassen) und starte postfix neu.

...

Gruß Johannes

Gruß Torsten

-- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

David Haller wrote:

...

...

Dann setze doch in der /etc/postfix/main.cf die Option: inet_interfaces = 192.168.0.1 127.0.0.1 ::1, oder einfach inet_interfaces = all (192er IP-Adresse selbstredend anpassen) und starte postfix neu.

Ich hoffe, du hast nicht "all" verwendet, denn damit ist dein Mailserver auch aus dem Internet erreichbar, und das willst du nicht (Stichwort offenes Relay). Setz' das nur auf localhost, also "127.0.0.0/8" (welche IPv4 Notationen man da verwenden kann weiss ich nicht) bzw. "::1" (IPv6) und die internen Interface(s) bzw. IPs, z.B. "192.168.0.1" oder "192.168.0.0/24".

Leider hat er nicht geschrieben, ob der Server selbst am Internet hängt oder über einen Router reingeht. Auch ist nicht bekannt, welche Restriktionen er in der main.cf gesetzt hat. Per default ist Postfix jedoch kein Open Relay.

Fuer das Abholen von Mails per fetchmail reicht das, denn fetchmail redet natuerlich nur _lokal_ ueber lo / 127.0.0.1 / ::1 mit postfix.

Es ging hier um das Abschicken von Mails von Clients im internen Netzwerk, deshalb gehe ich stark davon aus, dass a) der Server nur interne IP Adressen hat b) inet_interfaces deshalb nur nicht offizielle IPs beinhaltet c) der Server nicht aus dem Internet erreichbar ist, wenn vom Router kein Port-Forwarding auf den Server eingerichtet ist. Wenn das nicht der Fall ist, sollte die Serverkonfiguration jedenfalls restriktiver gesetzt werden. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com

Dieter Kluenter wrote:

...

Leider hat er nicht geschrieben, ob der Server selbst am Internet hängt oder über einen Router reingeht. Auch ist nicht bekannt, welche Restriktionen er in der main.cf gesetzt hat. Per default ist Postfix jedoch kein Open Relay.

Da muss ich ernsthaft widersprechen. Stelle dir folgendes Szenario vor:

DSL-Router -->LAN-Switch --> Mailserver

Auf dem Router ist Portforwarding für Port 25 eingerichtet, main.cf ist mit der Defaulteinstellung

inet_interfaces = 127.0.0.1,192.168.0.1 mynetworks = 127.0.0.0/8,192.168.0.0/24 smtpd_recipient-restrictions = permit_mynetworks,

konfiguriert. Das ist ein offenes Relay, denn der Router maskiert eingehende Verbindungen, die ins LAN geroutet werden, mit seiner lokalen IP. Solche und ähnliche Einstellungen findest du zuhauf.

Hallo Dieter, wenn er so ein Port-Forwarding eingerichtet hat, dann hat die Verbindung, die vom Internet aufgebaut wird, NICHT die IP des Routers, sondern direkt die IP des Clients aus dem Internet. Nur, wenn der Mailserver selber eine offizielle IP hat und kein eingrenzendes permit_mynetworks gesetzt ist, können IPs aus dem Subnetz der offiziellen IP den Server als Relay nutzen. Dieses verschwenderische Glück haben aber nur Amerikaner oder Leute, die den Server hosten lassen. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com

Dieter Kluenter wrote:

...

Hallo Dieter, wenn er so ein Port-Forwarding eingerichtet hat, dann hat die Verbindung, die vom Internet aufgebaut wird, NICHT die IP des Routers, sondern direkt die IP des Clients aus dem Internet.

Hast du schon mal ein tcpdump in einer solchen Konstellation laufen lassen? Bei meinem Router (Netgear) werden die IP's maskiert. Ebenfalls bei einem mit SuSE Firewall II und pppoe eingerichteten Bastionsrechner. Da bin ich zum erstenmal darüber gestolpert.

Heftig. Mir reicht es, ins Log des Mailservers zu schauen, wo die Client-IPs auftauchen. und das sind ganz normal die offiziellen IPs der Clients, nicht die der Firewall. Auch die RBL-Clients laufen sauber. Auch netstat zeigt, dass Verbindungen auf einen Rechner mit Port-Forwarding mit der offiziellen IP stattfinden. Meine Tests liefen mit Borderware Firewall-Server und IPCop. Keine Probleme. Jeden Tag die Taiwaner mit Relay-Versuchen, aber keine Probleme.

...

Nur, wenn der Mailserver selber eine offizielle IP hat und kein eingrenzendes permit_mynetworks gesetzt ist, können IPs aus dem Subnetz der offiziellen IP den Server als Relay nutzen. Dieses verschwenderische Glück haben aber nur Amerikaner oder Leute, die den Server hosten lassen.

Die offizielle IP hat der Router, durch Portforwarding ins LAN und Masquerading des lokalen Netztes gegenüber der bösen Welt können sich ja alle Rechner des lokalen Netzes mit anderen offiziellen IP's verbinden, und alle Pakete aus der bösen Welt werden ins LAN geroutet und bei Portforwarding auch alle Pakete mit synchronize Bit.

Kann es sein, dass du die von einigen Router-Herstellern beworbene "DMZ-Fähigkeit" von Billig-Routern meinst, wo DMZ gleichgesetzt ist mit "exposed Host"? Davon habe ich auch gehört. ;-) Port-Forwarding leitet nur die SYN-Pakete weiter, die auf dem Port des Routers eintreffen, was ja der Sinn der Sache ist. Den Rest der Verbindung erledigt Stateful Inspection. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com

Dieter Kluenter wrote:

...

...

Hast du schon mal ein tcpdump in einer solchen Konstellation laufen lassen? Bei meinem Router (Netgear) werden die IP's maskiert. Ebenfalls bei einem mit SuSE Firewall II und pppoe eingerichteten Bastionsrechner. Da bin ich zum erstenmal darüber gestolpert.

Heftig. Mir reicht es, ins Log des Mailservers zu schauen, wo die Client-IPs auftauchen. und das sind ganz normal die offiziellen IPs der Clients, nicht die der Firewall.

Über die Geschichte mit SFW2 bin ich gestolpert, als mich ein Bekannter mit der Mitteilung anrief, T-Online wolle seinen Account sperren, da er ein offenes Relay betreibe. Nachdem ich den Datenverkehr mit tcpdump aufgezeichnet und mit ethereal ausgewertet hatte, fielen mir die maskierten Adressen auf.Dann wurde in main.cf die recipient_restrictions mynetwork herausgenommen und nur noch sasl_authenticated erlaubt, danach war Ruhe und mein Bekannter konnte seinen Account behalten.

Welche IPs sind denn in den Logs des Servers aufgetaucht? Dann müssten dort ja ebenfalls die lokale IP des Routers als Client erscheinen. Auch die Blacklists müssten dann ins Leere laufen. Gut auf jeden Fall, dass du darüber schreibst, dann kann ich das in Zukunft im Hinterkopf berücksichtigen, falls ich so einen Fall debuggen muss.

Es handelt sich zwar um preiswerte DSL und WLAN Router, aber ich meine nicht die DMZ-Fähigkeit sondern NAT.

Viele der Hardware-Router verwenden ja auch iptables, daher ist deine Erfahrung schon etwas beunruhigend.

...

Port-Forwarding leitet nur die SYN-Pakete weiter, die auf dem Port des Routers eintreffen, was ja der Sinn der Sache ist. Den Rest der Verbindung erledigt Stateful Inspection.

Etwas anderes habe ich auch nicht behauptet.

Wollte nur sichergehen, dass wir beide von der gleichen Sache sprechen. Erklären kann ich mir das eigentlich nur, wenn auf dem Router ein SMTP-Proxy läuft, der die Verbindung cached und als Mittelmann fungiert. So etwas machen aber eigentlich nur gute Firewalls, rätsel... Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com

Hi zusammen, Ich kann nicht wiederstehen und muss auch meinen Senf dazugeben. Dieter Kluenter schrieb :

Hi,

Sandy Drobic writes:

...

Dieter Kluenter wrote:

[...]

...

...

Über die Geschichte mit SFW2 bin ich gestolpert, als mich ein Bekannter mit der Mitteilung anrief, T-Online wolle seinen Account sperren, da er ein offenes Relay betreibe. Nachdem ich den Datenverkehr mit tcpdump aufgezeichnet und mit ethereal ausgewertet hatte, fielen mir die maskierten Adressen auf.Dann wurde in main.cf die recipient_restrictions mynetwork herausgenommen und nur noch sasl_authenticated erlaubt, danach war Ruhe und mein Bekannter konnte seinen Account behalten.

Welche IPs sind denn in den Logs des Servers aufgetaucht? Dann müssten dort ja ebenfalls die lokale IP des Routers als Client erscheinen. Auch die Blacklists müssten dann ins Leere laufen.

Habe ich nicht geprüft, da ich nicht vor der Kiste sass, ich habe mir nur den Mitschnitt von tcpdump angesehen, der mit per Mail zugesandt wurde.

Ja ist definitiv so. Postfix sieht bei NAT die IP des Routers, der dann im lokalen Netz liegt, und leitet die Mail weiter. Siehe auch: http://www.gordano.com/kb.htm?q=781

...

Gut auf jeden Fall, dass du darüber schreibst, dann kann ich das in Zukunft im Hinterkopf berücksichtigen, falls ich so einen Fall debuggen muss.

...

Es handelt sich zwar um preiswerte DSL und WLAN Router, aber ich meine nicht die DMZ-Fähigkeit sondern NAT.

Viele der Hardware-Router verwenden ja auch iptables, daher ist deine Erfahrung schon etwas beunruhigend.

...

...

Port-Forwarding leitet nur die SYN-Pakete weiter, die auf dem Port des Routers eintreffen, was ja der Sinn der Sache ist. Den Rest der Verbindung erledigt Stateful Inspection.

Etwas anderes habe ich auch nicht behauptet.

Wollte nur sichergehen, dass wir beide von der gleichen Sache sprechen. Erklären kann ich mir das eigentlich nur, wenn auf dem Router ein SMTP-Proxy läuft, der die Verbindung cached und als Mittelmann fungiert. So etwas machen aber eigentlich nur gute Firewalls, rätsel... Dann kann es auch passieren. Postfix sieht die IP des Proxies.

Ich kann hier nur von dem berichten was ich bei Freunden und Bekannten gesehen habe. Ich selbst mache nur Portforwarding für zwei OpenVPN Netze. Wenn einige Leute also über dyndns oder ähnliche Nameservices im Netz erreichbar sind, vielleicht sogar noch einen MX Record für ihre dyndns domain eingerichtet haben, dazu noch Portforwarding auf ihren Mailserver, dann sollten diese den Traffic im lokalen Netz mal eingehend prüfen.

Gruss Werner

Am Donnerstag, den 04.08.2005, 08:41 +0200 schrieb Sandy Drobic:

Dieter Kluenter wrote:

...

DSL-Router -->LAN-Switch --> Mailserver

Auf dem Router ist Portforwarding für Port 25 eingerichtet, main.cf ist mit der Defaulteinstellung

inet_interfaces = 127.0.0.1,192.168.0.1 mynetworks = 127.0.0.0/8,192.168.0.0/24 smtpd_recipient-restrictions = permit_mynetworks,

konfiguriert. Das ist ein offenes Relay, denn der Router maskiert eingehende Verbindungen, die ins LAN geroutet werden, mit seiner lokalen IP. Solche und ähnliche Einstellungen findest du zuhauf.

Hallo Dieter, wenn er so ein Port-Forwarding eingerichtet hat, dann hat die Verbindung, die vom Internet aufgebaut wird, NICHT die IP des Routers, sondern direkt die IP des Clients aus dem Internet.

Kommt drauf an. Wenn man auf dem Router Pakete umschreibt, dann landet der Router im Absender. Du kennst vielleicht folgendes Problem: - Der Router ist ein alter PC und enthält zusätzlich einen Webserver - Nach installation eines Paketfilters können alle Leute von drausen per blabla.dyndns.foo auf den Webserver. - Man selber kommt per 192.168.0.1 auf den Webserver - Man selbst kommt NICHT per blabla.dyndns.foo auf den Webserver Diese Thematik ist zumindest für die SuseFW2 gültig gewesen, solange ich sie kannte, und gilt auch jetzt wieder für meine Shorewall. Man kann zweierlei Dinge tun: - Man installiert sich einen DNS, der blabla.dyndns.foo unterschiedlich auflöst - Man schreibt Pakete auf dem Server um Wenn man sich für letzteres entscheidet, dann schlagen in der DMZ alle Pakete mit dem Router als Absender auf. Hat man das lokale Netzwerk als Relay erlaubt, ist es somit offen und BUMMS. Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/