[postfix-users] postfix kann kein Reverse-Lookup mehr
Aloha,
seit ich mein Debian hier von i386 auf amd64 gezogen hab (cross-grade, keine Neuinstallation), schafft postfix kein Reverse-Lookup mehr. Forward (MX-Lookups, FQDNs aufloesen) funktioniert problemlos. Effekt; "450 4.7.1 Client host rejected: cannot find your hostname, [166.84.7.185]" wenn ich wie bisher reject_unknown_client nutzen moechte.
Environment: Debian Wheezy, amd64, postfix 2.9.6-2 (als amd64, nicht multiarch-i386)
Das chroot-Environment schaut IMHO gut aus:
# ls -1 /var/spool/postfix/lib/x86_64-linux-gnu/ ld-linux-x86-64.so.2 libgcc_s.so.1 libnss_compat-2.13.so libnss_compat.so.2 libnss_dns-2.13.so libnss_dns.so.2 libnss_files-2.13.so libnss_files.so.2 libnss_hesiod-2.13.so libnss_hesiod.so.2 libnss_nis-2.13.so libnss_nisplus-2.13.so libnss_nisplus.so.2 libnss_nis.so.2 libresolv-2.13.so libresolv.so.2
Wenn ich haendisch rein-chroote mit einem (amd64) busybox, funktioniert DNS sowohl Forward als auch Reverse: # chroot /var/spool/postfix/ /busybox nslookup 141.42.206.35 Server: 127.0.0.1 Address 1: 127.0.0.1 fsck
Name: 141.42.206.35 Address 1: 141.42.206.35 postfix.charite.de
Ich _vermute_, dass es postfix irgendwo in den Libraries aufhaengt (busybox ist ja nihct dynamisch gelinkt). Nur wo, und wie koennte ich das debuggen/beheben? Per debug_peer_list einem Client zuschauen hat mich nicht erhellt. Postfix de- und re-installieren hat auch nix gebracht.
Dankbar fuer sachdienliche Hinweise...
postconf: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases append_dot_mydomain = no biff = no command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/lib/postfix debug_peer_list = 166.84.7.185/32 default_destination_concurrency_limit = 1 inet_interfaces = all inet_protocols = ipv4, ipv6 initial_destination_concurrency = 1 local_destination_concurrency_limit = 2 mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 message_size_limit = 41943040 mydestination = fsck.waldner.priv.at, localhost, localhost.localdomain, localhost, <snip> myhostname = fsck.waldner.priv.at mynetworks = 127.0.0.0/8 <snip> myorigin = /etc/mailname recipient_delimiter = + setgid_group = postdrop smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) smtpd_discard_ehlo_keywords = silent-discard, dsn smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, check_helo_access hash:/etc/postfix/helo_restrictions, permit smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/reject_rcpts, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_rbl_client sbl.spamhaus.org, reject_rbl_client xbl.spamhaus.org, reject_unauth_pipelining, check_policy_service inet:127.0.0.1:60000, permit_auth_destination smtpd_sender_restrictions = permit_mynetworks, hash:/etc/postfix/reject_senders, reject_unknown_sender_domain soft_bounce = yes transport_maps = hash:/etc/postfix/transport virtual_alias_domains = <snip> virtual_alias_maps = hash:/etc/postfix/virtual
(ein paar x.x.x.x bzw. <snip>s wo ich Domains/Netze nicht preisgeben moechte)
cheers, &rw
Am 14.05.2013 22:15, schrieb Robert Waldner:
Aloha,
seit ich mein Debian hier von i386 auf amd64 gezogen hab (cross-grade, keine Neuinstallation), schafft postfix kein Reverse-Lookup mehr. Forward (MX-Lookups, FQDNs aufloesen) funktioniert problemlos. Effekt; "450 4.7.1 Client host rejected: cannot find your hostname, [166.84.7.185]" wenn ich wie bisher reject_unknown_client nutzen moechte.
Schreib doch mal deinen Rechnernamen mit seiner public IP in /etc/hosts rein. Ich glaub so ein Problem hatte ich auch schon mal und das war die Lösung.
Am 15.05.2013 05:46, schrieb Jochen:
Am 14.05.2013 22:15, schrieb Robert Waldner:
Aloha,
seit ich mein Debian hier von i386 auf amd64 gezogen hab (cross-grade, keine Neuinstallation), schafft postfix kein Reverse-Lookup mehr. Forward (MX-Lookups, FQDNs aufloesen) funktioniert problemlos. Effekt; "450 4.7.1 Client host rejected: cannot find your hostname, [166.84.7.185]" wenn ich wie bisher reject_unknown_client nutzen moechte.
Schreib doch mal deinen Rechnernamen mit seiner public IP in /etc/hosts rein. Ich glaub so ein Problem hatte ich auch schon mal und das war die Lösung. _______________________________________________ postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users
was sagt den dig ?, spekulation,wenn du kein ipv6 lan hast, schalt es im os ab und configuriere postfix auf ipv4
Best Regards MfG Robert Schetterer
On Wed, 15 May 2013 07:13:59 +0200, Robert Schetterer writes:
Am 15.05.2013 05:46, schrieb Jochen:
Am 14.05.2013 22:15, schrieb Robert Waldner:
seit ich mein Debian hier von i386 auf amd64 gezogen hab (cross-grade, keine Neuinstallation), schafft postfix kein Reverse-Lookup mehr. Forward (MX-Lookups, FQDNs aufloesen) funktioniert problemlos. Effekt; "450 4.7.1 Client host rejected: cannot find your hostname, [166.84.7.185]" wenn ich wie bisher reject_unknown_client nutzen moechte.
Schreib doch mal deinen Rechnernamen mit seiner public IP in /etc/hosts rein. Ich glaub so ein Problem hatte ich auch schon mal und das war die Lösung.
Probiert, macht keinen Unterschied.
was sagt den dig ?,
dig ist gegen so viel Zeug gelinkt (libxml, libgeoip etc.), das krieg ich im postfix-chroot so schnell nicht hin. "Draussen" geht sowieso alles, wie's soll.
spekulation,wenn du kein ipv6 lan hast, schalt es im os ab und configuriere postfix auf ipv4
Ich fahre tatsaechlich Dual-Stack hier ;)
cheers, &rw
dig ist gegen so viel Zeug gelinkt (libxml, libgeoip etc.), das krieg ich im postfix-chroot so schnell nicht hin. "Draussen" geht sowieso alles, wie's soll.
Postfix im chroot - hat es denn da eine vernünftige nsswitch.conf und resolv.conf?
Gruß, Jan
On Wed, 15 May 2013 16:42:20 +0200, "Jan P. Kessler" writes:
dig ist gegen so viel Zeug gelinkt (libxml, libgeoip etc.), das krieg ich im postfix-chroot so schnell nicht hin. "Draussen" geht sowieso alles, wie's soll.
Postfix im chroot - hat es denn da eine vernünftige nsswitch.conf und resolv.conf?
Es sind die selben, die ausserhalb des chroot einwandfrei funktionieren:
$ md5sum /etc/nsswitch.conf /var/spool/postfix/etc/nsswitch.conf /etc/resolv.conf /var/spool/postfix/etc/resolv.conf 109e33e2c91d1853b5bc56078a96aa18 /etc/nsswitch.conf 109e33e2c91d1853b5bc56078a96aa18 /var/spool/postfix/etc/nsswitch.conf 2bd3354f2bfba7b29b08f5558df2df1b /etc/resolv.conf 2bd3354f2bfba7b29b08f5558df2df1b /var/spool/postfix/etc/resolv.conf
resolv.conf (Richtung lokaler Bind halt): search waldner.priv.at <snip ein paar andere search-domains> nameserver 127.0.0.1
$ egrep -v "^($|#)" /etc/nsswitch.conf passwd: compat group: compat shadow: compat hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis
(Mit nsswitch.conf hatte ich noch nicht zu tun bisher.)
cheers, &rw
Postfix im chroot - hat es denn da eine vernünftige nsswitch.conf und resolv.conf?
Es sind die selben, die ausserhalb des chroot einwandfrei funktionieren:
$ md5sum /etc/nsswitch.conf /var/spool/postfix/etc/nsswitch.conf /etc/resolv.conf /var/spool/postfix/etc/resolv.conf 109e33e2c91d1853b5bc56078a96aa18 /etc/nsswitch.conf 109e33e2c91d1853b5bc56078a96aa18 /var/spool/postfix/etc/nsswitch.conf 2bd3354f2bfba7b29b08f5558df2df1b /etc/resolv.conf 2bd3354f2bfba7b29b08f5558df2df1b /var/spool/postfix/etc/resolv.conf
Nur zur Sicherheit vll nochmal einen "ls -l". Ich hatte mal versehentlich eine resolv.conf mit 0600 permissions platziert. Mit dem Ergebnis, dass die Lookups als superuser funktionierten, aber für verschiedene Dienste nicht mehr.
hosts: files dns
(Mit nsswitch.conf hatte ich noch nicht zu tun bisher.)
Das ist die entscheidende Zeile. Ist so, wie sie sein sollte.
Wenn Du wegen der Libs tiefer rein willst, musst Du wohl mit strace & Co ran: http://www.postfix.org/DEBUG_README.html#man_trace
Mein Beileid ;)
On Wed, 15 May 2013 22:52:50 +0200, "Jan P. Kessler" writes:
Postfix im chroot - hat es denn da eine vernünftige nsswitch.conf und resolv.conf?
Es sind die selben, die ausserhalb des chroot einwandfrei funktionieren:
Nur zur Sicherheit vll nochmal einen "ls -l". Ich hatte mal versehentlich eine resolv.conf mit 0600 permissions platziert. Mit dem Ergebnis, dass die Lookups als superuser funktionierten, aber für verschiedene Dienste nicht mehr.
# sudo -u postfix ls -l /etc/nsswitch.conf /var/spool/postfix/etc/nsswitch.conf /etc/resolv.conf /var/spool/postfix/etc/resolv.conf -rw-r--r-- 1 root root 465 May 15 17:27 /etc/nsswitch.conf -rw-r--r-- 1 root root 90 Mar 14 12:53 /etc/resolv.conf -rw-r--r-- 1 root root 465 May 15 17:27 /var/spool/postfix/etc/nsswitch.conf -rw-r--r-- 1 root root 90 May 15 17:27 /var/spool/postfix/etc/resolv.conf
Sieht also gut aus, und postfix kommt auch im restlichen Directoy-Tree bis zu den Files.
Wenn Du wegen der Libs tiefer rein willst, musst Du wohl mit strace & Co ran: http://www.postfix.org/DEBUG_README.html#man_trace
Oerks. Bei unkomplizierter einfacher Software wie postfix ... ;)
cheers, &rw
* Robert Waldner waldner@waldner.priv.at:
seit ich mein Debian hier von i386 auf amd64 gezogen hab (cross-grade, keine Neuinstallation), schafft postfix kein Reverse-Lookup mehr. Forward (MX-Lookups, FQDNs aufloesen) funktioniert problemlos. Effekt; "450 4.7.1 Client host rejected: cannot find your hostname, [166.84.7.185]" wenn ich wie bisher reject_unknown_client nutzen moechte.
Environment: Debian Wheezy, amd64, postfix 2.9.6-2 (als amd64, nicht multiarch-i386)
Das chroot-Environment schaut IMHO gut aus:
Hast Du denn chroot mal ausgeschaltet (IIRC 5. Spalte beim smtpd in master.cf) und geschaut, ob das Problem damit verschwindet?
Ciao Stefan
P.S: Falls es am chroot liegt: Du hast nicht zufällig /var oder /var/spool/postfix mit "noexec" oder "nosuid" gemountet?
On Thu, 16 May 2013 07:31:02 +0200, Stefan =?utf-8?Q?F=C3=B6rster?= writes:
seit ich mein Debian hier von i386 auf amd64 gezogen hab (cross-grade, keine Neuinstallation), schafft postfix kein Reverse-Lookup mehr. Forward (MX-Lookups, FQDNs aufloesen) funktioniert problemlos. Effekt; "450 4.7.1 Client host rejected: cannot find your hostname, [166.84.7.185]" wenn ich wie bisher reject_unknown_client nutzen moechte.
Environment: Debian Wheezy, amd64, postfix 2.9.6-2 (als amd64, nicht multiarch-i386)
Das chroot-Environment schaut IMHO gut aus:
Hast Du denn chroot mal ausgeschaltet (IIRC 5. Spalte beim smtpd in master.cf) und geschaut, ob das Problem damit verschwindet?
Guter Hinweis, jetzt grad getestet - ohne chroot funktioniert auch der Reverse-Lookup.
P.S: Falls es am chroot liegt: Du hast nicht zufällig /var oder /var/spool/postfix mit "noexec" oder "nosuid" gemountet?
/var ist direkt auf dem root-FS auf der Kiste:
/dev/... on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
cheers, &rw
Hallo zusammen,
Tue, 14 May 2013 22:15:46 +0200 From: Robert Waldner waldner@waldner.priv.at To: postfix-users@de.postfix.org :
Ich _vermute_, dass es postfix irgendwo in den Libraries aufhaengt (busybox ist ja nihct dynamisch gelinkt). Nur wo, und wie koennte ich das debuggen/beheben?
schau doch mal, ob alle notwendigen Bibliotheken in der chroot-Umgebung vorhanden sind und die richtigen Rechte haben.
$ ldd /path/to/smtpd
Für die Rejections ist doch der smtpd zuständig, oder?
Grüße Lars
* Lars Täuber taeuber@bbaw.de:
Tue, 14 May 2013 22:15:46 +0200 From: Robert Waldner waldner@waldner.priv.at To: postfix-users@de.postfix.org :
Ich _vermute_, dass es postfix irgendwo in den Libraries aufhaengt (busybox ist ja nihct dynamisch gelinkt). Nur wo, und wie koennte ich das debuggen/beheben?
schau doch mal, ob alle notwendigen Bibliotheken in der chroot-Umgebung vorhanden sind und die richtigen Rechte haben.
$ ldd /path/to/smtpd
Für die Rejections ist doch der smtpd zuständig, oder?
Ich hab hier noch kein wheezy, aber eigentlich sollte das Debian-Skript das chroot von selber korrekt zusammenbauen, unpassende Lib-Versionen entfernen etc. Code steht im Init-Skript, Lektüre empfohlen.
Ciao Stefan
root@happy:~# find /var/spool/postfix/ -type f /var/spool/postfix/pid/inet.smtp /var/spool/postfix/pid/unix.spfcheck /var/spool/postfix/pid/unix.trace /var/spool/postfix/pid/unix.smtp /var/spool/postfix/pid/inet.127.0.0.1:10031 /var/spool/postfix/pid/unix.cleanup /var/spool/postfix/pid/inet.submission /var/spool/postfix/pid/unix.lmtp-amavis /var/spool/postfix/pid/unix.defer /var/spool/postfix/pid/unix.flush /var/spool/postfix/pid/unix.local /var/spool/postfix/pid/inet.smtps /var/spool/postfix/pid/unix.showq /var/spool/postfix/pid/inet.127.0.0.1:10027 /var/spool/postfix/pid/unix.dovecot /var/spool/postfix/pid/master.pid /var/spool/postfix/pid/inet.127.0.0.1:10025 /var/spool/postfix/pid/unix.bounce /var/spool/postfix/etc/resolv.conf /var/spool/postfix/etc/nsswitch.conf /var/spool/postfix/etc/hosts /var/spool/postfix/etc/localtime /var/spool/postfix/etc/services /var/spool/postfix/etc/ssl/certs/ca-certificates.crt /var/spool/postfix/lib/libnss_hesiod-2.11.3.so /var/spool/postfix/lib/libnss_nis-2.11.3.so /var/spool/postfix/lib/libnss_dns-2.11.3.so /var/spool/postfix/lib/libnss_nisplus-2.11.3.so /var/spool/postfix/lib/libnss_files-2.11.3.so /var/spool/postfix/lib/libnss_compat-2.11.3.so
On Thu, 16 May 2013 11:15:12 +0200, Lars =?UTF-8?B?VMOkdWJlcg==?= writes:
schau doch mal, ob alle notwendigen Bibliotheken in der chroot-Umgebung vorhanden sind und die richtigen Rechte haben.
$ ldd /path/to/smtpd
Davon gibt's nur 2 im chroot (libresolv.so.2, libc.so.6), die restlichen 15 nicht.
Vergleiche ich das mit dem chroot auf einer anderen Kiste, auch Debian Wheezy/amd64, finde ich keinen Unterschied: find /var/spool/postfix/lib/x86_64-linux-gnu/ -type f | sort | xargs md5sum >/tmp/x2
Für die Rejections ist doch der smtpd zuständig, oder?
Das sagen zumindest das Log und auch strace.
Aber ich bin der Sache nun naeher: ein `ln -s x86_64-linux-gnu x86_64` in /var/spool/postfix/lib, und das Reverse-Lookup geht wieder. Stutzig gemacht hat mich: 13099 open("/lib64/tls/x86_64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/lib64/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/lib64/x86_64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/lib64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/usr/lib64/tls/x86_64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/usr/lib64/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/usr/lib64/x86_64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/usr/lib64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/lib/tls/x86_64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/lib/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/lib/x86_64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/usr/lib/tls/x86_64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/usr/lib/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/usr/lib/x86_64/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) 13099 open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)
Wobei ich noch dahinterkommen muss, warum der nicht in x86_64-linux-gnu sucht im chroot... (warum's so hinkopiert wird, ist nach kurzem Blick ins chroot-Setup klar).
cheers, &rw
participants (6)
-
Jan P. Kessler -
Jochen -
Lars Täuber -
Robert Schetterer -
Robert Waldner -
Stefan Förster