Exim4 "unrouteable address"
Paul Muster
ich hätt' da gern a'mal ein Problem:
Mein Exim4 ist ganz brav, wenn ich ihn teste:
# exim4 -bt loca...@domain.tld
R: system_aliases for loca...@domain2.tld2
R: userforward for loca...@domain2.tld2
R: procmail for loca...@domain2.tld2
R: maildrop for loca...@domain2.tld2
loca...@domain2.tld2
<-- loca...@domain.tld
router = maildrop, transport = maildrop_pipe
Auch
# exim4 -d -bt loca...@domain.tld
sieht ganz wunderbar aus, ich erspare es euch aber aufgrund der Länge
erstmal. Nur im echten Leben nimmt er die Mails nicht an:
2010-09-06 18:18:37 H=<Host> [<IP>] F=<From> rejected RCPT
<loca...@domain.tld>: Unrouteable address
Ich habe nun einen Nachmittag lang dazu recherchiert und die Konfig des
alten mit der des neuen Servers verglichen, finde aber nix. Wo soll ich
suchen?
Danke & viele Grüße
Paul
Sven Hartge
> Auch
exim4 -bv getestet? Nur weil eine Adresse routebar ist, muss sie nicht
(für exim) verifizierbar sein. Je nach Option an ACL oder Router kann so
eine Situation entstehen.
S°
--
Sig lost. Core dumped.
Paul Muster
> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>> Mein Exim4 ist ganz brav, wenn ich ihn teste:
>> Auch
>
>> # exim4 -d -bt loca...@domain.tld
>
>> sieht ganz wunderbar aus, ich erspare es euch aber aufgrund der Länge
>> erstmal. Nur im echten Leben nimmt er die Mails nicht an:
>
>> 2010-09-06 18:18:37 H=<Host> [<IP>] F=<From> rejected RCPT
>> <loca...@domain.tld>: Unrouteable address
>
>> Ich habe nun einen Nachmittag lang dazu recherchiert und die Konfig des
>> alten mit der des neuen Servers verglichen, finde aber nix. Wo soll ich
>> suchen?
>
> exim4 -bv getestet? Nur weil eine Adresse routebar ist, muss sie nicht
> (für exim) verifizierbar sein. Je nach Option an ACL oder Router kann so
> eine Situation entstehen.
Jetzt ja:
# exim4 -bv loca...@domain.tld
loca...@domain.tld verified
Ich finde, auch das sieht gut aus.
Und -bh hab ich nun auch mal benutzt, falls in einer ACL was kaputt wäre:
# exim4 -bh 217.72.192.248 -bt loca...@domain.tld
(217.72.192.248 sollte ein Mailout von web.de sein)
und auch da kommt er zielsicher zu Maildrop, nachdem er den Alias zu
loca...@domain2.tld2 aufgelöst hat:
R: maildrop for loca...@domain2.tld2
calling maildrop router
routed by maildrop router
loca...@domain2.tld2
<-- loca...@domain.tld
router = maildrop, transport = maildrop_pipe
Alles sehr seltsam.
Florian Weimer
> # exim4 -bh 217.72.192.248 -bt loca...@domain.tld
>
> (217.72.192.248 sollte ein Mailout von web.de sein)
Probiere mal:
# exim4 -bh 217.72.192.248 -d+all
und gib danach von Hand den SMTP-Dialog ein. Das sollte Dir zeigen,
welche ACL-Prüfung fehlschlägt.
--
Suche NNTP-Peers für de.*, Big8 (insbesondere comp.*),
möglichst ohne Binaries. Bei Interesse bitte Mail.
Paul Muster
> * Paul Muster:
>> # exim4 -bh 217.72.192.248 -bt loca...@domain.tld
>>
>> (217.72.192.248 sollte ein Mailout von web.de sein)
>
> Probiere mal:
>
> # exim4 -bh 217.72.192.248 -d+all
>
> und gib danach von Hand den SMTP-Dialog ein. Das sollte Dir zeigen,
> welche ACL-Prüfung fehlschlägt.
Ah, es wird wärmer:
| 20:47:57 5153 domain2.tld2 in "+local_domains"? yes (matched
"+local_domains" - cached)
| 20:47:57 5153 checking for local user
| 20:47:57 5153 seeking password data for user "localpart": cache not
available
| 20:47:58 5153 getpwnam(localpart) failed: Bad file descriptor
| 20:47:58 5153 getpwnam() returned NULL (user not found)
| 20:47:58 5153 lowuid_aliases router skipped: localpart is not a local
user
| 20:47:58 5153 --------> local_user router <--------
(Zu dem "getpwnam 'failed: Bad file descriptor'" finde ich keinerlei
brauchbare Treffer...)
Allerdings:
# getent passwd localpart
localpart:x:1007:1007:Vorname Nachname,,,:/home/localpart:/bin/bash
Ich finde, den User gibt es durchaus. Auch wenn er "nur" im LDAP auf dem
anderen Server ist und über
# grep passwd /etc/nsswitch.conf
passwd: files ldap
herangeholt wird.
Was passt hier nicht?
Florian Weimer
> (Zu dem "getpwnam 'failed: Bad file descriptor'" finde ich keinerlei
> brauchbare Treffer...)
Du könntest noch strace bemühen. Ich weiß auch nicht wirklich, woran
das liegen könnte.
Paul Muster
> * Paul Muster:
Ja, siehe http://paste.debian.net/88242/
Exim scheint in /etc/passwd nach dem lokalen User zu suchen. Den gibt es
da aber nicht... Und dann scheint es noch zahlreiche Fragen an
/etc/hosts zu haben.
mfG Paul
Thomas Hochstein
> (Zu dem "getpwnam 'failed: Bad file descriptor'" finde ich keinerlei
> brauchbare Treffer...)
Rechteproblem?
Ich nehme an, Du führtest Deine Tests als root aus, und Exim läuft als
"exim" (oder Debian-Exim o.ä.)? Was passiert, wenn Du die Tests wie
-bt oder -bv als Exim-Benutzer (also Debian-Exim o.ä.) ausführst?
(Mit dem Einbinden von Benutzern via LDAP habe ich eher wenig
Erfahrung, v.a. kann ich nicht ohne weiteres sagen, ob das für Exim
transparent auf Systemebene geschehen sollte.)
-thh
--
Informationen rund um E-Mail und Mailserver:
<http://th-h.de/infos/email/>
Paul Muster
> Paul Muster schrieb:
>> (Zu dem "getpwnam 'failed: Bad file descriptor'" finde ich keinerlei
>> brauchbare Treffer...)
>
> Rechteproblem?
>
> Ich nehme an, Du führtest Deine Tests als root aus, und Exim läuft als
> "exim" (oder Debian-Exim o.ä.)? Was passiert, wenn Du die Tests wie
> -bt oder -bv als Exim-Benutzer (also Debian-Exim o.ä.) ausführst?
Habe das mal gemacht (und dazu Debian-exim temporär eine Shell
verpasst), aber das Ergebnis bleibt.
> (Mit dem Einbinden von Benutzern via LDAP habe ich eher wenig
> Erfahrung, v.a. kann ich nicht ohne weiteres sagen, ob das für Exim
> transparent auf Systemebene geschehen sollte.)
Ich stelle gerade fest, dass bestimmte Systemuser an bestimmten Stellen
nicht aufgelöst werden:
# ps aux
[...]
104 [...] /usr/sbin/exim4 -bd -q30m ...
clamav [...] /usr/sbin/clamd
dovecot [...] imap-login
108 [...] /usr/bin/fetchmail ...
[...]
an anderer Stelle passt das aber durchaus:
# la /etc/exim4/passwd.client
-rw-r----- 1 root Debian-exim 112 22. Jun 17:46 /etc/exim4/passwd.client
# la /etc/fetchmailrc
-rw------- 1 fetchmail root 1081 6. Sep 16:14 /etc/fetchmailrc
Übrigens werden die E-Mails, die Fetchmail einsammelt, problemlos
zugestellt:
2010-09-07 13:06:59 1Osvzq-0006ve-3g <= sen...@example.com H=localhost
(<hostname>) [127.0.0.1] P=esmtp S=<size> id=<ID>
2010-09-07 13:07:16 1Osvzq-0006ve-3g => localpart <localpart@localhost>
R=maildrop T=maildrop_pipe
Das liegt wohl daran, dass für localhost anders(?) geprüft wird, ob der
Empfänger existiert...
Danke & mfG Paul
Sven Hartge
> # ps aux
> [...]
> 104 [...] /usr/sbin/exim4 -bd -q30m ...
> clamav [...] /usr/sbin/clamd
> dovecot [...] imap-login
> 108 [...] /usr/bin/fetchmail ...
> [...]
Das hängt damit zusammen, dass die Namen länger als 8 Zeichen sind.
Paul Muster
> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
Gut, das hat also mit meinem Problem bzw. dem Problem meines Exim nichts
zu tun.
Danke für die Info.
Viele Grüße
Paul
Jakob Hirsch
>>> (Zu dem "getpwnam 'failed: Bad file descriptor'" finde ich keinerlei
>>> brauchbare Treffer...)
>> Du könntest noch strace bemühen. Ich weiß auch nicht wirklich, woran
>> das liegen könnte.
> Ja, siehe http://paste.debian.net/88242/
das "close(-1) = -1 EBADF (Bad file descriptor)" in Zeile 10 sieht
dannach aus, daß es vorher mal ein open() gab, dessen rückgabewert nicht
geprüft wurde (der ist eben -1, wenn es nicht geklappt hat). Also mal in
dem strace-output davor schauen, was dort der Fehler war.
Kann es evt. sein, daß für den ldap-lookup eine config-datei gebraucht
wird, die der exim-user nicht lesen darf?
Klappt denn ein "getent passwd localpart" als exim-user?
> Exim scheint in /etc/passwd nach dem lokalen User zu suchen. Den gibt es
> da aber nicht... Und dann scheint es noch zahlreiche Fragen an
> /etc/hosts zu haben.
Ohne jetzt in den Exim-Code geschaut zu haben, würde ich mal sagen, daß
Exim einfach die libc nutzt, die dann solches Zeug macht...
Paul Muster
> Paul Muster, 2010-09-06 22:32:
>>>> (Zu dem "getpwnam 'failed: Bad file descriptor'" finde ich keinerlei
>>>> brauchbare Treffer...)
>>> Du könntest noch strace bemühen. Ich weiß auch nicht wirklich, woran
>>> das liegen könnte.
>> Ja, siehe http://paste.debian.net/88242/
>
> das "close(-1) = -1 EBADF (Bad file descriptor)" in Zeile 10 sieht
> dannach aus, daß es vorher mal ein open() gab, dessen rückgabewert nicht
> geprüft wurde (der ist eben -1, wenn es nicht geklappt hat). Also mal in
> dem strace-output davor schauen, was dort der Fehler war.
> Kann es evt. sein, daß für den ldap-lookup eine config-datei gebraucht
> wird, die der exim-user nicht lesen darf?
Ob er die wirklich braucht, weiß ich nicht. Er scheitert jedenfalls dreimal:
# grep open exim_local_delivery.log | grep "\-1"
open("/root/ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("/root/.ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
open("ldaprc", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or
directory)
(Und vorher scheitert er noch an /etc/exim4/exim4.conf, das ist unter
Debian aber ok, denn er findet dann /var/lib/exim4/config.autogenerated)
Und die globale ldap.conf findet er auch, das sollte doch reichen:
open("/etc/ldap/ldap.conf", O_RDONLY|O_LARGEFILE) = 4
Wenn man als Debian-exim testet, sieht das sehr ähnlich aus, dazu kommt
aber noch:
open("/etc/libnss-ldap.secret", O_RDONLY) = -1 EACCES (Permission denied)
Haben wir da nun das Problem gefunden?
Wenn ich Debian-exim Zugriff auf die Datei gebe, ändert sich allerdings
nichts an der Meldung...
> Klappt denn ein "getent passwd localpart" als exim-user?
Ja:
Debian-exim@server2:~$ getent passwd localpart
localpart:x:1007:1007:Vorname Nachname,,,:/home/localpart:/bin/bash
>> Exim scheint in /etc/passwd nach dem lokalen User zu suchen. Den gibt es
>> da aber nicht... Und dann scheint es noch zahlreiche Fragen an
>> /etc/hosts zu haben.
>
> Ohne jetzt in den Exim-Code geschaut zu haben, würde ich mal sagen, daß
> Exim einfach die libc nutzt, die dann solches Zeug macht...
Ok, muss ich dann in Richtung pam_ldap, nsswitch.conf noch was korrigieren?
Sven Hartge
> Wenn man als Debian-exim testet, sieht das sehr ähnlich aus, dazu kommt
> aber noch:
> open("/etc/libnss-ldap.secret", O_RDONLY) = -1 EACCES (Permission denied)
Aha! Du brauchst, wenn du für NSS-Lookups ein Passwort benutzt, also
keinen anonymous bind machst, _zwingend_ den nscd!
Paul Muster
> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
Hmm, schau an, schon geht's. Ich werde aber erst noch die Nacht drüber
schlafen, bevor ich das DNS wieder umstelle.
An irgendwas erinnere ich mich... warst du das nicht?... Ah, nein, der
andere Sven:
http://groups.google.de/group/de.comp.os.unix.networking.misc/browse_thread/thread/c88aa3862bcb3b31/680e5eb5d325e7b6
Sven Hartge
> Sven Hartge schrieb:
>> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>>> Wenn man als Debian-exim testet, sieht das sehr ähnlich aus, dazu kommt
>>> aber noch:
>>
>>> open("/etc/libnss-ldap.secret", O_RDONLY) = -1 EACCES (Permission denied)
>>
>> Aha! Du brauchst, wenn du für NSS-Lookups ein Passwort benutzt, also
>> keinen anonymous bind machst, _zwingend_ den nscd!
> Hmm, schau an, schon geht's. Ich werde aber erst noch die Nacht drüber
> schlafen, bevor ich das DNS wieder umstelle.
DNS? DNS?!?
nscd für DNS ist eine mehr als lausige Idee. Bitte _niemals_ benutzen.
nscd stellt man so ein, dass es nur für User und Group benutzt wird.
Alternativ kannst du dir die bessere Alternative libpam-ldapd und
libnss-ldapd ansehen. (Wichtig ist das 'd' am Ende.)
Juergen P. Meier
> nscd für DNS ist eine mehr als lausige Idee. Bitte _niemals_ benutzen.
> nscd stellt man so ein, dass es nur für User und Group benutzt wird.
Amen.
> Alternativ kannst du dir die bessere Alternative libpam-ldapd und
> libnss-ldapd ansehen. (Wichtig ist das 'd' am Ende.)
Kann exim denn nicht selbst LDAP?
Die Kruecke ueber lokale Userkonten zu gehen ist auf einem Relay
nicht wirklich eine Gute Idee[tm].
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Paul Muster
> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>> Hmm, schau an, schon geht's. Ich werde aber erst noch die Nacht drüber
>> schlafen, bevor ich das DNS wieder umstelle.
>
> DNS? DNS?!?
>
> nscd für DNS ist eine mehr als lausige Idee. Bitte _niemals_ benutzen.
> nscd stellt man so ein, dass es nur für User und Group benutzt wird.
Nein, nein. Ich meinte, ich werde noch ein bisschen drüber nachdenken
und testen, bevor ich im DNS von der IP-Adresse des alten auf die des
neuen Servers umstelle.
> Alternativ kannst du dir die bessere Alternative libpam-ldapd und
> libnss-ldapd ansehen. (Wichtig ist das 'd' am Ende.)
Mache ich.
Danke & mfG Paul
Paul Muster
>>> Wenn man als Debian-exim testet, sieht das sehr ähnlich aus, dazu kommt
>>> aber noch:
>>> open("/etc/libnss-ldap.secret", O_RDONLY) = -1 EACCES (Permission denied)
>> Aha! Du brauchst, wenn du für NSS-Lookups ein Passwort benutzt, also
>> keinen anonymous bind machst, _zwingend_ den nscd!
>
> Hmm, schau an, schon geht's.
Tja, denkste! (So langsam nervt Exim mich ein wenig.)
# exim4 -bh 217.72.192.248
sagt fröhlich "250 Accepted", genauso tut es als Exim-User:
Debian-exim@server2:~$ /usr/sbin/exim4 -bh 217.72.192.248
Aber echte Mails weist er weiterhin zurück:
2010-09-08 09:31:31 H=<Host> [<IP>] F=<From> rejected RCPT
<loca...@domain.tld>: Unrouteable address
Was könnte ihm jetzt noch nicht passen?
Sven Hartge
>> nscd für DNS ist eine mehr als lausige Idee. Bitte _niemals_ benutzen.
>> nscd stellt man so ein, dass es nur für User und Group benutzt wird.
> Amen.
>> Alternativ kannst du dir die bessere Alternative libpam-ldapd und
>> libnss-ldapd ansehen. (Wichtig ist das 'd' am Ende.)
> Kann exim denn nicht selbst LDAP?
Doch, aber wenn man eben lokale User will, dann geht es via libc->NSS.
> Die Kruecke ueber lokale Userkonten zu gehen ist auf einem Relay nicht
> wirklich eine Gute Idee[tm].
Amen.
Paul Muster
>>> nscd für DNS ist eine mehr als lausige Idee. Bitte _niemals_ benutzen.
>>> nscd stellt man so ein, dass es nur für User und Group benutzt wird.
>
>> Amen.
JFTR: Dieser Sollzustand ist bereits der Fall.
>>> Alternativ kannst du dir die bessere Alternative libpam-ldapd und
>>> libnss-ldapd ansehen. (Wichtig ist das 'd' am Ende.)
>
>> Kann exim denn nicht selbst LDAP?
>
> Doch, aber wenn man eben lokale User will, dann geht es via libc->NSS.
>
>> Die Kruecke ueber lokale Userkonten zu gehen ist auf einem Relay nicht
>> wirklich eine Gute Idee[tm].
>
> Amen.
Ja, ihr habt ja beide völlig recht, die reine Lehre ist das nicht.
Allerdings brauche ich momentan noch lokale User, weil bspw.
Spamassassin user-spezifisch lernt. Und jeder User hat einen .mailfilter
in seinem Home. Und die Maildirs liegen auch im Home.
Aber wieso zickt Exim in dieser Umgebung plötzlich so? Wo klemmt es?
(Siehe mein Posting von 9:40h.)
Sven Hartge
> Sven Hartge schrieb:
>> Juergen P. Meier <nospa...@jors.net> wrote:
>>> Sven Hartge <sh-...@svenhartge.de>:
>>>> nscd für DNS ist eine mehr als lausige Idee. Bitte _niemals_ benutzen.
>>>> nscd stellt man so ein, dass es nur für User und Group benutzt wird.
>>
>>> Amen.
> JFTR: Dieser Sollzustand ist bereits der Fall.
>>>> Alternativ kannst du dir die bessere Alternative libpam-ldapd und
>>>> libnss-ldapd ansehen. (Wichtig ist das 'd' am Ende.)
>>
>>> Kann exim denn nicht selbst LDAP?
>>
>> Doch, aber wenn man eben lokale User will, dann geht es via libc->NSS.
>>
>>> Die Kruecke ueber lokale Userkonten zu gehen ist auf einem Relay nicht
>>> wirklich eine Gute Idee[tm].
>>
>> Amen.
> Ja, ihr habt ja beide völlig recht, die reine Lehre ist das nicht.
> Allerdings brauche ich momentan noch lokale User, weil bspw.
> Spamassassin user-spezifisch lernt. Und jeder User hat einen
> .mailfilter in seinem Home. Und die Maildirs liegen auch im Home.
Lösung: spamassassin in eine MySQL-Datenbank lernen lassen. Das ist
sogar performanter als eine lokale BDB zu benutzen.
Und der .mailfilter braucht keine echten User. Die Maildirs auch nicht,
dass läßt sich alles "virtuell" abbilden. Ist zwar ein wenig
Umstellungsarbeit, zugegeben, aber du ersparst dir auf lange Sicht den
Import der User via PAM und NSS.
> Aber wieso zickt Exim in dieser Umgebung plötzlich so? Wo klemmt es?
> (Siehe mein Posting von 9:40h.)
Tja, leider sind da zu wenig Infos von deiner Umgebung, also wie die
Konfig-Dateien aussehen, wie das LDAP genau konfiguriert ist, etc. Es
gibt da einfach zu viele Variablen, die unbekannt sind.
Paul Muster
> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>> Aber wieso zickt Exim in dieser Umgebung plötzlich so? Wo klemmt es?
>> (Siehe mein Posting von 9:40h.)
>
> Tja, leider sind da zu wenig Infos von deiner Umgebung, also wie die
> Konfig-Dateien aussehen, wie das LDAP genau konfiguriert ist, etc. Es
> gibt da einfach zu viele Variablen, die unbekannt sind.
Ok, die liefere ich natürlich gerne. Aber liegt es denn überhaupt (noch
immer) an LDAP, wie kann ich das feststellen?
Wie geschrieben, auch als Debian-exim klappt der Trockenlauf nun,
nachdem ich auf deinen Hinweis hin nscd installiert habe:
Debian-exim@server2:~$ /usr/sbin/exim4 -bh 217.72.192.248
[...]
250 Accepted
Viele Grüße
Paul
Paul Muster
> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>> Aber wieso zickt Exim in dieser Umgebung plötzlich so? Wo klemmt es?
>> (Siehe mein Posting von 9:40h.)
>
> Tja, leider sind da zu wenig Infos von deiner Umgebung, also wie die
> Konfig-Dateien aussehen, wie das LDAP genau konfiguriert ist, etc. Es
> gibt da einfach zu viele Variablen, die unbekannt sind.
Auf einen Hinweis per PM hin habe ich rootbinddn für libnss-ldap nun
ausgeschaltet --- und Exim funktioniert genauso viel oder wenig wie
vorher (bzw. wie nach der Installation von nscd), es sagt "250 Accepted"
beim Testen mit -bh, sagt weiterhin "verified" bei -bv und "Unrouteable"
bei echten Einlieferungen.
Noch jemand eine Idee? Soll ich nochmal eine Runde mit strace drehen?
Sven Hartge
Sicherlich nicht verkehrt.
Den rootbinddn brauchst du auch nur, wenn deine User via passwd ihr
Kennwort im LDAP setzen können sollen bzw. wenn root selbst via adduser
neue User im LDAP erzeugen können soll.
Bei Debian steckt da die Debconf-Frage, ob der lokale Admin auch Admin
im LDAP sein soll, dahinter.
Jakob Hirsch
> vorher (bzw. wie nach der Installation von nscd), es sagt "250 Accepted"
> beim Testen mit -bh, sagt weiterhin "verified" bei -bv und "Unrouteable"
> bei echten Einlieferungen.
>
> Noch jemand eine Idee? Soll ich nochmal eine Runde mit strace drehen?
Ja, aber vorher mal mit
# exim -bdf -d+all -oX 26
starten und in einem anderem terminal mit
$ telnet 0 26
probieren.
Paul Muster
Das funktioniert einfach. Er nimmt die Mail an, die er bei "normaler"
Einlieferung verwirft, und übergibt sie ordentlich an Maildrop. Auch,
wenn ich von einem Host einliefere, der nicht in relay_hosts steht.
Irgendwann zwischendrin meint er
> 17:32:16 7329 checking for local user
> 17:32:16 7329 seeking password data for user "localpart": using cached result
> 17:32:16 7329 getpwnam() succeeded uid=1007 gid=1007
und ist zufrieden.
Auch wenn ich den Daemon normal auf Port 25/tcp starte und per telnet
einliefere, tut es. Warum macht er das nicht, wenn ein anderer
Mailserver ganz normal bei ihm einliefert?
Wie kann ich das loglevel für den normal laufenden Daemon hochdrehen, in
der Hoffnung, dass der mir sagt, was er für ein Problem hat?
Ich finde dazu den Parameter log_level und die Info, dass 6 das
derzeitige Maximum ist. Aber wo auch immer ich den Parameter einbaue, er
gefällt dem Exim nicht.
mfG Paul
Paul Muster
> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>> Auf einen Hinweis per PM hin habe ich rootbinddn für libnss-ldap nun
>> ausgeschaltet --- und Exim funktioniert genauso viel oder wenig wie
>> vorher (bzw. wie nach der Installation von nscd), es sagt "250
>> Accepted" beim Testen mit -bh, sagt weiterhin "verified" bei -bv und
>> "Unrouteable" bei echten Einlieferungen.
>
>> Noch jemand eine Idee? Soll ich nochmal eine Runde mit strace drehen?
>
> Sicherlich nicht verkehrt.
Hm, meine Frage war etwas unüberlegt: Bei der bisherigen Fehlersuche
habe ich strace auf Einlieferungs-Simulationen mit exim -bh angewandt.
Diese funktionieren ja jetzt. Da würde es nicht viel bringen, den
funktionierenden Test mit strace zu betrachten, oder?
Sollte ich nun strace auf den Daemon-Prozess anwenden (und eine
Einlieferung beobachten)? Geht sowas?
> Den rootbinddn brauchst du auch nur, wenn deine User via passwd ihr
> Kennwort im LDAP setzen können sollen bzw. wenn root selbst via adduser
> neue User im LDAP erzeugen können soll.
Ja, diese Möglichkeit möchte ich später nutzen (können), aber nicht vom
Mailserver aus. Von daher ist es kein Problem, dort auf rootbinddn zu
verzichten.
> Bei Debian steckt da die Debconf-Frage, ob der lokale Admin auch Admin
> im LDAP sein soll, dahinter.
Ja, ich habe den rootbinddn aber direkt in libnss-ldap.conf erschlagen,
da weiß man, was man hat. *g*
Sven Hartge
> Sven Hartge schrieb:
>> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>>> Auf einen Hinweis per PM hin habe ich rootbinddn für libnss-ldap nun
>>> ausgeschaltet --- und Exim funktioniert genauso viel oder wenig wie
>>> vorher (bzw. wie nach der Installation von nscd), es sagt "250
>>> Accepted" beim Testen mit -bh, sagt weiterhin "verified" bei -bv und
>>> "Unrouteable" bei echten Einlieferungen.
>>> Noch jemand eine Idee? Soll ich nochmal eine Runde mit strace
>>> drehen?
>> Sicherlich nicht verkehrt.
> Hm, meine Frage war etwas unüberlegt: Bei der bisherigen Fehlersuche
> habe ich strace auf Einlieferungs-Simulationen mit exim -bh angewandt.
> Diese funktionieren ja jetzt. Da würde es nicht viel bringen, den
> funktionierenden Test mit strace zu betrachten, oder? Sollte ich nun
> strace auf den Daemon-Prozess anwenden (und eine Einlieferung
> beobachten)? Geht sowas?
Klar. strace -f -p PID_VOM_PROZESS. Das "-f" ist wichtig, damit er auch
forks() folgt.
Oder eben, wie in anderem Artikel geschrieben, den Dämons selbst direkt
im Vordergrund starten und dort dann auch -d+all angeben.
Jakob Hirsch
> Auch wenn ich den Daemon normal auf Port 25/tcp starte und per telnet
> einliefere, tut es. Warum macht er das nicht, wenn ein anderer
> Mailserver ganz normal bei ihm einliefert?
Was soll denn der Unterschied zwischen "per Telnet" und "ganz normal von
einem anderen Mailserver" sein?
Ansonsten: daemon beenden, exim mit "-bdf -d+all" starten (evt. mit
"strace -f -o /tmp/exim.strace" davor) und eine Test-Einlieferung von
einem anderen Host aus machen.
Du bist schon sicher, daß der daemon mit der aktuellen config läuft?
> Ich finde dazu den Parameter log_level und die Info, dass 6 das
Wo hast du das her? Steht nicht in der exim-spec.
Paul Muster
> Paul Muster, 2010-09-08 18:46:
>> Auch wenn ich den Daemon normal auf Port 25/tcp starte und per telnet
>> einliefere, tut es. Warum macht er das nicht, wenn ein anderer
>> Mailserver ganz normal bei ihm einliefert?
>
> Was soll denn der Unterschied zwischen "per Telnet" und "ganz normal von
> einem anderen Mailserver" sein?
Ersteres bezeichnet meine Einlieferungsversuche per telnet von Hand,
letzteres die Einlieferungsversuche von bspw. mailout-de.gmx.net.
> Ansonsten: daemon beenden, exim mit "-bdf -d+all" starten (evt. mit
> "strace -f -o /tmp/exim.strace" davor) und eine Test-Einlieferung von
> einem anderen Host aus machen.
Ich habe heute viele, viele Tests gemacht:
1. Server gebootet, damit alle Caches (insbes. nscd) leer sind
2. Exim-Daemon ganz normal über init-Script gestartet
3. Einlieferung funktioniert nicht
Log:
2010-09-09 22:18:25 H=mailout-de.gmx.net (mail.gmx.net) [213.165.64.23]
F=<from> rejected RCPT <loca...@domain.tld>: Unrouteable address
strace -f -p <PID>:
http://paste.debian.net/88964/
4. Daemon über init-Script gestoppt
5. Daemon aus root-Shell mit "-bdf -d+all -Xo 25" gestartet
6. Einlieferung funktioniert nicht
Log:
2010-09-09 22:25:18 1OtngM-0000hM-Dj unable to set gid=1007 or uid=1007
(euid=104): userforward router (recipient is loca...@domain2.tld2)
2010-09-09 22:25:18 1OtngM-0000hM-Dj internal problem in userforward
router (recipient is loca...@domain2.tld2): failure to transfer data
from subprocess: status=0100 readerror='Success'
strace -f -e trace=open,close,read,write exim -bdf -d+all -oX 25:
http://paste.debian.net/88959/
Daran finde ich das filehandle(?) Nummer 8 komisch. Es wird in Zeile 10
geöffnet, in 14 _und_ 30 geschlossen, dann in 31 fehlt das handle?
Sollte da nicht noch irgendwo vor oder nach Z 30 ein open("<Datei>",
<Parameter>) = 8 stehen?
(Gekürzt habe ich zahlreiche Zeilen wie 11 und 12, in denen in das
handle 2 geloggt wird.)
7. Daemon über init-Script gestartet
2010-09-09 23:19:40 1OtngM-0000hM-Dj => postmaster
<loca...@domain2.tld2> R=local_user T=maildir_home
2010-09-09 23:19:40 1OtngM-0000hM-Dj Completed
Das ist die Mail von oben bei 6.!!!
8. weitere Einlieferung:
2010-09-09 23:19:40 End queue run: pid=4362
2010-09-09 23:20:08 1OtoXL-00018m-GN <= FROM H=mailout-de.gmx.net
(mail.gmx.net) [213.165.64.23] P=smtp S=943 id=2010090921...@gmx.net
2010-09-09 23:20:08 1OtoXL-00018m-GN => localpart
<loca...@domain2.tld2> R=local_user T=maildir_home
2010-09-09 23:20:08 1OtoXL-00018m-GN Completed
Tut. *ARGH*
Aber warum jetzt plötzlich? Und wie lange?
> Du bist schon sicher, daß der daemon mit der aktuellen config läuft?
Ja, denn wenn ich bspw. u.g. Parameter log_level in die Konfig. packe,
startet der Daemon nicht.
>> Ich finde dazu den Parameter log_level und die Info, dass 6 das
>
> Wo hast du das her? Steht nicht in der exim-spec.
Aus einer wohl veralteten Doku:
http://www.exim.org/exim-html-3.20/doc/html/spec_51.html#SEC862
(Ja, mittlerweile habe ich das "3.20" auch gesehen.)
Paul Muster
> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>> Sollte ich nun strace auf den Daemon-Prozess anwenden (und eine
>> Einlieferung beobachten)? Geht sowas?
> Klar.
Ja, danke. Sorry, dass ich hier nach Debugging-Grundlagen frage.
Nun, im anderen Posting geht es wieder um die eigentliche Sache, den
Mailserver.
Jakob Hirsch
>> Was soll denn der Unterschied zwischen "per Telnet" und "ganz normal von
>> einem anderen Mailserver" sein?
> Ersteres bezeichnet meine Einlieferungsversuche per telnet von Hand,
> letzteres die Einlieferungsversuche von bspw. mailout-de.gmx.net.
Hm, ok. Aber was sollte da unterschiedlich sein? Die Kommandos sind ja
die selben, solange du die selben Adressen benutzt. Und irgendwelche
> 2010-09-09 22:18:25 H=mailout-de.gmx.net (mail.gmx.net) [213.165.64.23]
> F=<from> rejected RCPT <loca...@domain.tld>: Unrouteable address
Hm, die Meldung "Unrouteable address" ist auch merkwürdig. Das kommt
eigentlich nur, wenn kein router die Adresse bearbeiten konnte (d.h. bei
keinem die Bedingungen erfüllt waren).
> 4. Daemon über init-Script gestoppt
> 5. Daemon aus root-Shell mit "-bdf -d+all -Xo 25" gestartet
> 6. Einlieferung funktioniert nicht
>
> Log:
>
> 2010-09-09 22:25:18 1OtngM-0000hM-Dj unable to set gid=1007 or uid=1007
> (euid=104): userforward router (recipient is loca...@domain2.tld2)
> 2010-09-09 22:25:18 1OtngM-0000hM-Dj internal problem in userforward
> router (recipient is loca...@domain2.tld2): failure to transfer data
> from subprocess: status=0100 readerror='Success'
Naja, das sieht schonmal nicht gut aus, oder?
> strace -f -e trace=open,close,read,write exim -bdf -d+all -oX 25:
> http://paste.debian.net/88959/
> Daran finde ich das filehandle(?) Nummer 8 komisch. Es wird in Zeile 10
> geöffnet, in 14 _und_ 30 geschlossen, dann in 31 fehlt das handle?
Das close(8) in Zeile 30 ist ein anderer Prozess (pid 2712 vs. 2690).
> (Gekürzt habe ich zahlreiche Zeilen wie 11 und 12, in denen in das
> handle 2 geloggt wird.)
>
> Tut. *ARGH*
Gelegentlich Probleme bei einer deiner userdb-Komponenten.
Du kannst ja mal ein paar Dutzend Test-Auslieferungen machen (z.B. mit
swaks).
Sven Hartge
> Sven Hartge schrieb:
>> Paul Muster <exp-3...@news.muster.dyndns.info> wrote:
>>> Sollte ich nun strace auf den Daemon-Prozess anwenden (und eine
>>> Einlieferung beobachten)? Geht sowas?
>> Klar.
> Ja, danke. Sorry, dass ich hier nach Debugging-Grundlagen frage.
Nun, man kann ja nicht alles wissen. Und für die Zukunft bist du ja nun
gewappnet ;)
Paul Muster
> 6. Einlieferung funktioniert nicht
> 2010-09-09 22:25:18 1OtngM-0000hM-Dj unable to set gid=1007 or uid=1007
> (euid=104): userforward router (recipient is loca...@domain2.tld2)
> 2010-09-09 22:25:18 1OtngM-0000hM-Dj internal problem in userforward
> router (recipient is loca...@domain2.tld2): failure to transfer data
> from subprocess: status=0100 readerror='Success'
Da haben wir ein Problem mit dem userforward-Router, sehe ich das richtig?
> 7. Daemon über init-Script gestartet
> 2010-09-09 23:19:40 1OtngM-0000hM-Dj => postmaster
> <loca...@domain2.tld2> R=local_user T=maildir_home
> 2010-09-09 23:19:40 1OtngM-0000hM-Dj Completed
>
> Das ist die Mail von oben bei 6.!!!
Und hier liefert Exim nun über den Router local_user aus, anstatt über
userforward. Hä?
> 8. weitere Einlieferung:
> 2010-09-09 23:19:40 End queue run: pid=4362
> 2010-09-09 23:20:08 1OtoXL-00018m-GN <= FROM H=mailout-de.gmx.net
> (mail.gmx.net) [213.165.64.23] P=smtp S=943 id=2010090921...@gmx.net
> 2010-09-09 23:20:08 1OtoXL-00018m-GN => localpart
> <loca...@domain2.tld2> R=local_user T=maildir_home
> 2010-09-09 23:20:08 1OtoXL-00018m-GN Completed
>
> Tut. *ARGH*
Und da auch über local_user. Die ~/.forward ist aber die ganze Zeit da.
Oder verstehe ich hier die Logs falsch?
Viele Grüße
Paul
Paul Muster
> On 09.09.2010 23:26, Paul Muster wrote:
>>> Was soll denn der Unterschied zwischen "per Telnet" und "ganz normal von
>>> einem anderen Mailserver" sein?
>> Ersteres bezeichnet meine Einlieferungsversuche per telnet von Hand,
>> letzteres die Einlieferungsversuche von bspw. mailout-de.gmx.net.
>
> Hm, ok. Aber was sollte da unterschiedlich sein? Die Kommandos sind ja
> die selben, solange du die selben Adressen benutzt.
Tja... ich verstehe es ja auch nicht.
> Und irgendwelche
?
>> 2010-09-09 22:18:25 H=mailout-de.gmx.net (mail.gmx.net) [213.165.64.23]
>> F=<from> rejected RCPT <loca...@domain.tld>: Unrouteable address
>
> Hm, die Meldung "Unrouteable address" ist auch merkwürdig. Das kommt
> eigentlich nur, wenn kein router die Adresse bearbeiten konnte (d.h. bei
> keinem die Bedingungen erfüllt waren).
Da stellt sich dann die Frage, warum das bei Trockenübungen mit -bt und
-bv nicht auffällt. (Hat das womöglich was mit u.g. no_verify zu tun?)
>> 4. Daemon über init-Script gestoppt
>> 5. Daemon aus root-Shell mit "-bdf -d+all -Xo 25" gestartet
>> 6. Einlieferung funktioniert nicht
>>
>> Log:
>>
>> 2010-09-09 22:25:18 1OtngM-0000hM-Dj unable to set gid=1007 or uid=1007
>> (euid=104): userforward router (recipient is loca...@domain2.tld2)
>> 2010-09-09 22:25:18 1OtngM-0000hM-Dj internal problem in userforward
>> router (recipient is loca...@domain2.tld2): failure to transfer data
>> from subprocess: status=0100 readerror='Success'
>
> Naja, das sieht schonmal nicht gut aus, oder?
Nein, sicherlich. Aber
http://artfiles.org/exim.org/exim-html-4.40/doc/html/FAQ_0.html#TOC66
hilft mir nicht weiter, denn der Router userforward _hat_ bereits
no_verify gesetzt.
(Falls das jemandem auffällt: Ja, ich habe irgendwann vorgestern abend
des Testuser gewechselt, sodass der jetzige eine ~/.forward hat (also
Router userforward), während der vorher eine ~/.maildrop hatte (Router
maildrop). Das Verhalten hat sich aber nicht relevant verändert.)
>> strace -f -e trace=open,close,read,write exim -bdf -d+all -oX 25:
>> http://paste.debian.net/88959/
>> Daran finde ich das filehandle(?) Nummer 8 komisch. Es wird in Zeile 10
>> geöffnet, in 14 _und_ 30 geschlossen, dann in 31 fehlt das handle?
>
> Das close(8) in Zeile 30 ist ein anderer Prozess (pid 2712 vs. 2690).
Ah, ok. Dann fehlt doch aber trotzdem irgendwo das open dafür.
Schließlich schließt 2690 sein 8 in Z 14, will dann in Z 31 aber wieder
daraus lesen(!?) und schließt es in Z 50 nochmal.
>> (Gekürzt habe ich zahlreiche Zeilen wie 11 und 12, in denen in das
>> handle 2 geloggt wird.)
>>
>> Tut. *ARGH*
Äh, Moment. Er verwendet unterschiedliche Router, oder? (Siehe
Parallel-Posting.)
> Gelegentlich Probleme bei einer deiner userdb-Komponenten.
> Du kannst ja mal ein paar Dutzend Test-Auslieferungen machen (z.B. mit
> swaks).
Ja, ich melde mich. (*ächts* ;-)
Danke & viele Grüße
Paul
PS. Ich sach's euch, nachher ist das eine völlig offensichtliche
Kleinigkeit. Dann beiße ich mir.. äh, lassen wir das. ;-)