PHP mail() schickt keine Mails - sendmail config?!

[RemoteC]

Servus!

Nachdem ich jetzt jede Menge Tutorials/Anleitung/Troubleshootings durchforstet habe wie man sendmail zum laufen bringt bin ich mit meinem Latein am Ende und hoffe, dass ihr mir helfen könnt.

PHP macht mir bei mail() keine Fehlermeldung, auch nicht in den logs.

In /var/log/mail steht für jedes mal wenn ich das PHP-Testskript aufrufe etwas in der Art (zur Anonymisierung habe ich meine Domain entfernt, E-Mail sollte an eine GMX-Adresse gehen)

Sep 25 21:18:15 webserver postfix/pickup[32488]: 479C26224: uid=30 from=<website@mydomain.at>
Sep 25 21:18:15 webserver postfix/cleanup[1611]: 479C26224: message-id=<20110925191815.479C26224@webserver.mydomain.LOCAL>
Sep 25 21:18:15 webserver postfix/qmgr[3962]: 479C26224: from=<website@mydomain.at>, size=369, nrcpt=1 (queue active)
Sep 25 21:18:15 webserver postfix/smtp[1476]: connect to mx1.gmx.net[213.165.64.102]: Network is unreachable (port 25)
Sep 25 21:18:15 webserver postfix/smtp[1476]: connect to mx0.gmx.net[213.165.64.100]: Network is unreachable (port 25)
Sep 25 21:18:15 webserver postfix/smtp[1476]: 479C26224: to=<adresse-existiert@gmx.at>, relay=none, delay=0.06, delays=0.06/0/0/0, dsn=4.4.1, status=deferred (connect to mx0.gmx.net[213.165.64.100]: Network is unreachable)

Zur Info: webserver.mydomain.LOCAL ist der lokale Servername

Also habe ich mich einmal umgeschaut ob es am Port 25 liegt, im Log der Firewall ist nichts zu sehen und ein telnet localhost 25 bringt folgendes Ergebnis

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 webserver.mydomain.LOCAL ESMTP Postfix

Sollte da nicht eigentlich "ESMTP sendmail ..." stehen? Brauche ich das überhaupt, ich will ja keine E-Mails empfangen sondern nur senden.

php.ini ist wie folgt konfiguriert

sendmail_path = /usr/sbin/sendmail -t -i -F website@[I]mydomain.at[/I] -f website@[I]mydomain.at[/I]
sendmail_from = website@[I]mydomain.at[/I]

Diese Konfiguration habe ich vom PHP-Manual (direkter Link) - Das entspricht meiner Situation: Postfix (lt. logs & telnet) und der Server steht 'hinter' einem ISA-Server als Firewall. Oder ist (wieder mal ...) der ISA-Server an allem Schuld und der Linux-Webserver ohnehin richtig konfiguriert? Wie könnte ich das Testen bzw. was wäre am ISA-Server zu ändern?

lg

 

[bitmuncher]

Zum Senden mit der mail()-Funktion brauchst du auf jeden Fall einen SMTP-Server. Bei dir läuft aber offenbar nicht sendmail sondern Postfix. Die Meldung

Network is unreachable

weist darauf hin, dass der Mailserver mxN.gmx.net nicht erreichen kann. Sofern daran keiner Firewall Schuld ist, würde ich darauf tippen, dass dein Postfix-Server nur auf dem Loopback-Device lauscht. Von dort kann er natürlich keine Daten an einen externen Host senden. Um das zu ändern solltest du 'inet_interfaces' auf 'all' setzen und mit der Firewall den eingehenden Traffic auf Port 25 blocken, so dass du kein offenes Mailrelay eröffnest.

iptables -A INPUT -p tcp --dport 25 -j DROP

 

[RemoteC]

inet_interfaces war auf localhost (/etc/postfix/main.cf), habe das jetzt auf all geändert und die Firewall mit iptables wie von dir gepostet eingestellt.

Mail wird immer noch nicht verschickt.

In der /var/log/mail steht immer noch Sep 25 23:52:23 webserver postfix/smtp[5130]: connect to mx0.gmx.net[213.165.64.100]: Network is unreachable (port 25)

In der mailq steht auch ein "connect to [..] Network is unreachable" für alle Testmails die ich per PHP-Skript oder Konsole geschrieben habe.

Wenn ich mit mailx eine E-Mail an meine GMX-Adresse schreibe erscheinen nach ca. 40s die selben Fehlmeldungen. Selbes Spiel wenn ich "/usr/lib/sendmail -v adresse@gmx.at < /etc/motd" mache :-\

Ein mailx an root funktioniert aber, zumindest habe ich dann eine E-Mail mit entsprechenden Subject und Text in /var/mail/root (genauso wie Meldungen über die nicht zugestellten E-Mails).

 

[bitmuncher]

Was sagt denn deine Postfix-Einstellung für 'mynetworks'?

 

[mime]

Network is unreachable

weist darauf hin, dass der Mailserver mxN.gmx.net nicht erreichen kann. Sofern daran keiner Firewall Schuld ist, würde ich darauf tippen, dass dein Postfix-Server nur auf dem Loopback-Device lauscht. Von dort kann er natürlich keine Daten an einen externen Host senden.

Was?

kira:/home/mime # netstat -tlnp | grep 25     
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      22287/master

Natürlich kann ich damit Mails an extern schicken (In diesem Fall werden alle Mails an einen Smarthost weiter gegeben). "man route"

@RemoteC

der Server steht 'hinter' einem ISA-Server als Firewall. Oder ist (wieder mal ...) der ISA-Server an allem Schuld

Würde ich als wahrscheinlichste Ursache sehen. Der wird eventuell ausgehenden Traffic auf Port 25 nicht erlauben.

HTH

Micha

 

[bitmuncher]

@mime: Das ganze über eine Route zu lösen, ist natürlich auch eine Möglichkeit. Viele Wege führen nach Rom.

 

[mime]

@mime: Das ganze über eine Route zu lösen, ist natürlich auch eine Möglichkeit. Viele Wege führen nach Rom.

Du hast mich falsch verstanden. Dazu muss nicht extra eine Route gesetzt werden. Deine default Route gilt auch für das loopback. Auch das schickt Pakete, die nicht in "sein" Netz gehören, an das default Gateway.

Micha

 

[bitmuncher]

Wenn sowas über das Loopback möglich ist, kann man es nicht mehr als vertrauenswürdiges Device einstufen. Wenn bei dir also die Route wirklich so eingestellt ist, solltest du das Loopback genauso behandeln wie jedes andere Netzwerk-Interface. Ich würde sowas jedenfalls bei einem Server als Sicherheitsschwäche einstufen. Der Gateway für localhost sollte immer auf localhost gesetzt sein.

Nachtrag: Hab das mal auf einem Rechner getestet. Ergebnis: Die Default-Route greift nicht für das Loopback-Device.

root@testmachine4:/home/bitmuncher# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
123.123.123.0    *               255.255.255.0   U     0      0        0 eth0
default         123.123.123.1    0.0.0.0         UG    0      0        0 eth0
root@testmachine4:/home/bitmuncher# ping -I lo web.de
PING web.de (213.165.64.75) from 81.169.134.15 lo: 56(84) bytes of data.
^C
--- web.de ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1014ms
root@testmachine4:/home/bitmuncher# ping -I eth0 web.de
PING web.de (213.165.64.75) from 81.169.134.15 eth0: 56(84) bytes of data.
64 bytes from web.de (213.165.64.75): icmp_seq=1 ttl=57 time=15.5 ms
64 bytes from web.de (213.165.64.75): icmp_seq=2 ttl=57 time=15.8 ms
^C
--- web.de ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 15.569/15.716/15.863/0.147 ms

 

[mime]

Wenn sowas über das Loopback möglich ist, kann man es nicht mehr als vertrauenswürdiges Device einstufen.

Es geht um ausgehenden Traffic.

Ich würde sowas jedenfalls bei einem Server als Sicherheitsschwäche einstufen.

Warum?

Der Gateway für localhost sollte immer auf localhost gesetzt sein.

Ohh...wie denn?

root@testmachine4:/home/bitmuncher# ping -I lo web.de

Gut...ich lese dir "man ping" mal vor...

-I interface address
Set source address to specified interface address.

Du solltest dich also wirklich nicht wundern, dass du darauf keine Antwort bekommst. Damit setzt du die SRC-Addresse und nicht das ausgehende Interface.

Micha

 

[RemoteC]

Was sagt denn deine Postfix-Einstellung für 'mynetworks'?

mynetworks ist auskommentiert, sprich default Einstellung und die ist mynetworks_style = subnet

 

[bitmuncher]

Gut...ich lese dir "man ping" mal vor...

Dann lese ich einfach mal weiter...

       -I interface address
              Set  source  address  to  specified  interface  address. [b]Argument may be numeric IP
              address or name of device.[/b] When pinging IPv6  link-local  address  this  option  is
              required.

Zum Warum sollte das Loopback nicht nach aussen connecten können: Es erspart einem die Überwachung von Traffic, der garantiert vertrauenswürdig ist, was je nach IDS und Komplexität der Regelsätze jede Menge Rechenleistung spart. Ausserdem sollte ein an localhost gebundener Service nicht durch einen eingeschleusten Bot missbrauchbar sein (z.B. SMTP-Service).

@RemoteC: mynetworks sollte immer auf die IPs gesetzt sein, von denen "trusted clients" kommen. Also empfiehlt es sich hier localhost (soweit ich mich erinnere ist das der Default-Wert) sowie die IP-Adressen der Netzwerk-Interface einzutragen.

 

[RemoteC]

Schön langsam steig ich aus, könnte auch daran liegen dass nach stundenlanger Fehlersuche meine Motivation noch weiter zu recherchieren schwindet.

1.) War nun das
iptables -A INPUT -p tcp --dport 25 -j DROP
unnötig?

2.) Meinst du mit Netzwerk-Interfaces den ISA-Server? Das ist ja der einzige Server mit dem der Webserver über SMTP kommunizieren soll.

3.) Muss die E-Mail Adresse, die ich als "from" angebe überhaupt existieren? Wenn ja: Muss die am Webserver konfiguriert sein oder kann das eine x-beliebige E-Mail Adresse sein?

4.) Ich glaub immer mehr, dass der ISA-Server einfach keine Kommunikation des Webservers auf Port 25 zulässt, es gibt in dem Netzwerk auch einen eigenen Mailserver und der wird wohl der einzige sein, dem Port 25 geöffnet ist.

 

[mime]

Dann lese ich einfach mal weiter...

       -I interface address
              Set  source  address  to  specified  interface  address. [B]Argument may be numeric IP
              address or name of device.[/B] When pinging IPv6  link-local  address  this  option  is
              required.

Ja, wenn du ein device angibst, dann holt er sich die Addresse vom device. ping benutzt nicht das mit "-I" angegebene als "outgoing device" sondern als SRC-Address.

Zum Warum sollte das Loopback nicht nach aussen connecten können: Es erspart einem die Überwachung von Traffic, der garantiert vertrauenswürdig ist

Das Loopback conneted nicht nach draußen. Der Traffic wird lokal auf das entsprechende, für diese route zuständige, device "geroutet".

Micha

 

[mime]

4.) Ich glaub immer mehr, dass der ISA-Server einfach keine Kommunikation des Webservers auf Port 25 zulässt, es gibt in dem Netzwerk auch einen eigenen Mailserver und der wird wohl der einzige sein, dem Port 25 geöffnet ist.

mime@null:~% telnet mx0.gmx.net 25
Trying 213.165.64.100...
Connected to mx0.gmx.net.
Escape character is '^]'.
220 mx0.gmx.net GMX Mailservices ESMTP {mx084}

und bei dir?

http://blog.devnull.ch/2009/05/12/postfix-mit-ausgehendem-smarthost-mit-smtp-authentication/

Micha

 

[RemoteC]

Trying 213.165.64.100...
telnet: connect to address 213.165.64.100: Network is unreachable

Als Smarthost soll ich den (Windows) Mail-Server einstellen? Von dem hab ich leider keine Zugangsdaten, andere Baustelle

 

[bitmuncher]

Ja, wenn du ein device angibst, dann holt er sich die Addresse vom device. ping benutzt nicht das mit "-I" angegebene als "outgoing device" sondern als SRC-Address.

Ok, da hast du Recht. Ping löst über den Device-Namen offenbar wirklich nur die IP auf. Aber... Solange du nicht den GW mittels ifconfig oder route setzt, wird Traffic des Loopbacks nicht auf einen Gateway gelenkt. Sonst hättest du in der Routing-Tabelle einen Eintrag der Form:

default    123.123.123.1               0.0.0.0   UG     0      0        0 lo

123.123.123.1 ist hier der Router/GW. Üblicherweise hast du einen solchen Eintrag aber nur für das LAN-Device und nicht für das Loopback. Somit greift auf dem Device lo der Default-Gateway auch nicht. Der Default-Gateway wird immer per Device definiert und greift nicht global. Legst du z.B. ein virtuelles zweites Device an, wird auch für dieses ein zweiter Routing-Eintrag in die Routing-Tabelle eingefügt, in der der Default-Gateway definiert ist. Ist dies nicht der Fall, geht auch kein Traffic des virtuellen Devices zum Gateway.

Ausserdem weiss ich ziemlich sicher, dass mein Postfix noch nie Emails versenden konnte, wenn ich den nur auf dem Loopback lauschen liess. Ich hatte erst vor ein paar Tagen dieses "Problem" auf einem Webserver. Auch dort war es umgehend behoben, nachdem ich inet_interfaces auf all gesetzt hatte.

@RemoteC: Wenn Postfix am richtigen Netzwerk-Device lauscht und die lokalen IPs als mynetworks eingetragen sind, sollte er auch Mails senden können. Geht es dann noch immer nicht, macht eine lokal laufende oder vorgeschaltete Firewall Probleme. Ausserdem weist dein Telnet-Output ja auch darauf hin.

 

[mime]

Solange du nicht den GW mittels ifconfig oder route setzt, wird Traffic des Loopbacks nicht auf einen Gateway gelenkt. Sonst hättest du in der Routing-Tabelle einen Eintrag der Form:

default    123.123.123.1               0.0.0.0   UG     0      0        0 lo

123.123.123.1 ist hier der Router/GW. Üblicherweise hast du einen solchen Eintrag aber nur für das LAN-Device und nicht für das Loopback. Somit greift auf dem Device lo der Default-Gateway auch nicht. Der Default-Gateway wird immer per Device definiert und greift nicht global.

Quak! Die default route wird benutzt, wenn es für die Zieladresse eines IP Paketes keine bekannte route gibt. Das Interface in der default route sagt, über welches Interface diese Pakete raus gehen sollen. Du hast immer nur eine default route. Diese gilt auch für Lo.

Legst du z.B. ein virtuelles zweites Device an, wird auch für dieses ein zweiter Routing-Eintrag in die Routing-Tabelle eingefügt,

Ja, natürlich wird für das Netz in dem sich die IP befindet eine route angelegt.

in der der Default-Gateway definiert ist. Ist dies nicht der Fall, geht auch kein Traffic des virtuellen Devices zum Gateway.

Das ist einfach falsch.

kira:/home/mime # route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth1

Meine routing table. Wie du siehst, nur ein default gw. Jetzt musst du dich doch nur noch fragen, was mit Packeten aus dem 192.168.1.0 Netz passiert, wenn es für die Zieladresse eines IP Paketes keine bekannte route gibt. Ganz genau, die werden über das default gateway weiter geschickt. So verhält sich das auch mit Paketen von lo.

Ausserdem weiss ich ziemlich sicher, dass mein Postfix noch nie Emails versenden konnte, wenn ich den nur auf dem Loopback lauschen liess.

Tausend andere Mailserver können das. Bei den meisten Distributionen lauscht der SMTPd doch nur noch auf lo. Da gehen Mails raus.

Micha

 

[mime]

Trying 213.165.64.100...
telnet: connect to address 213.165.64.100: Network is unreachable

Als Smarthost soll ich den (Windows) Mail-Server einstellen? Von dem hab ich leider keine Zugangsdaten, andere Baustelle

Du kannst den Mailserver in dem Netz nicht benutzen? Wo bist du denn da überhaupt und was machst du da? So wirst du nicht weiter kommen. Die Firewall will dich wohl nicht mit anderen Mailservern sprechen lassen.

Micha

 

[bitmuncher]

Du hast immer nur eine default route. Diese gilt auch für Lo.

bitmuncher:/home/bitmuncher# route
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
85.0.0.0        *               255.0.0.0       U     0      0        0 eth0
default         85.214.32.2     0.0.0.0         UG    0      0        0 eth0
default         85.214.32.1     0.0.0.0         UG    0      0        0 eth0

Nur eine Default-Route? Also ich hab hier für jedes Interface (es handelt sich um eth0 und eth0:1) jeweils einen Default-Gateway. Und wie du siehst ist hier keine GW für 127.0.0.0/255.0.0.0 gesetzt, so wie es bei dir der Fall ist. Kein GW für lo = keine Verbindung nach aussen.

 

[mime]

bitmuncher:/home/bitmuncher# route
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
85.0.0.0        *               255.0.0.0       U     0      0        0 eth0
default         85.214.32.2     0.0.0.0         UG    0      0        0 eth0
default         85.214.32.1     0.0.0.0         UG    0      0        0 eth0

Nur eine Default-Route?

Ja, ich hätte "in der regel" dazu schreiben sollen.

Also ich hab hier für jedes Interface (es handelt sich um eth0 und eth0:1) jeweils einen Default-Gateway.

Nein, du hast einfach 2 default routen. Das kann man z.B. für Autofailover so machen. Die zweite Default Route wird dann verwendet, wenn die erste einen Timeout liefert. Dazu musst du aber "/proc/sys/net/ipv4/route/gc_timeout" runter setzen (sonst macht das bei 300 Sekunden timeout nicht wirklich Spaß) und CONFIG_IP_ROUTE_MULTIPATH muss aktiviert sein.

Du hast nicht für jedes interface eine eigene default route. Die routing table wird von oben nach unten abgearbeitet.

Und wie du siehst ist hier keine GW für 127.0.0.0/255.0.0.0 gesetzt, so wie es bei dir der Fall ist.

Du bist auf nem Debian, richtig? Da wird von "/sbin/route" das loopback schon ewig nicht mehr angezeigt.
Für dich also:

mime@thoe:~$ /sbin/ip route list table all | grep /8

Kein GW für lo = keine Verbindung nach aussen.

Du hast doch ein GW. Darüber gehen alle Pakete, für die es keine bekannte route gibt. Das gilt auch für Pakete von lo.

Micha