Postfix stellt Mails an einen bestimmten Benutzer nicht zu
Liebe Liste,
ich hoffe ihr könnt mir helfen. Suche nun schon seit Tagen nach einer Lösung und es ist mir echt ein Rätsel.
Ich habe einen Postfix Server auf Debian Jessie am Laufen. Version postfix 2.11.3 mit Paket postfix-ldap.
Als imap Server kommt Cyrus 2.4.17 zum Einsatz.
Ich möchte euch nicht mit endlosen Konfigdateien belasten, daher hier nur erstmal der Auszug aus den Logs, wo es wohl hakt.
Der Server nimmt die Mail an und stellt sie nur für einen bestimmten neu angelegten Benutzer nicht zu. Alles andere wird zugestellt. Diese Mails befinden sich nun schon seit Tagen in der Queue. Es gibt auch keine Rückmeldung wie sonst, dass die Mails nicht zugestellt werden können.
So sieht die Mailzustellung normalerweise aus:
root@server:/# grep 80D41241356 /var/log/mail.log
Apr 25 11:39:11 server postfix/smtpd[12439]: 80D41241356: client=kes.domain.de[IP] Apr 25 11:39:11 server postfix/cleanup[12442]: 80D41241356: message-id=3808909c-c8fa-7d93-b2e4-a225ffa7a48b@domain.de Apr 25 11:39:11 server postfix/qmgr[12406]: 80D41241356: from=admin@domain.de, size=997, nrcpt=1 (queue active) Apr 25 11:39:11 server postfix/pipe[12445]: 80D41241356: to=admin@domain.de, orig_to=admin@domain.de, relay=cyrus, delay=0.1, delays=0/0.02/0/0.08, dsn=2.0.0, status=sent (delivered via cyrus service) Apr 25 11:39:11 server postfix/qmgr[12406]: 80D41241356: removed
Bei diesem Benutzer bleibt die Mail in der Queue hängen, es passiert nichts weiter:
root@server:/# grep 706AB240FC4 /var/log/mail.log Apr 25 11:38:45 server postfix/smtpd[12439]: 706AB240FC4: client=kes.domain.de[IP] Apr 25 11:38:45 server postfix/cleanup[12442]: 706AB240FC4: message-id=ff5eecc9-73a3-e605-1567-21c9814f3f4b@domain.de Apr 25 11:38:45 server postfix/qmgr[12406]: 706AB240FC4: from=admin@domain.de, size=1006, nrcpt=1 (queue active)
Nach Einschalten diverser Debuglevel bekomme ich dies hier, erst wieder die erste Mail:
Apr 29 11:28:57 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: atest Apr 29 11:28:57 server postfix/local[15680]: *set_eugid: euid 3005 egid 201**7* Apr 29 11:28:57 server postfix/local[15680]: *set_eugid: euid 110 egid 116* Apr 29 11:28:57 server postfix/local[15680]: deliver_dotforward: path /home/atest/.forward expand_status 0 look_status -1 Apr 29 11:28:57 server postfix/local[15680]: deliver_mailbox[3]: local atest recip atest@server.domain.de exten deliver atest@server.domain.de exp_from
und hier die nicht zugestellte Mail:
Apr 29 11:30:36 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: mvogt Apr 29 11:30:36 server postfix/local[15680]:*set_eugid: euid 3146 egid 2017*
danach passiert nichts mehr.
Hat jemand eine Idee nach was ich noch suchen könnte, warum kommt es hier nicht zur zweiten Zeile?
Info: /etc/groups: postfix:x:116:und /etc/passwd postfix:x:110:116:
Ich hatte auch schon versucht, den Benutzer ganz neu anzulegen, gleiches Prinzip. Es kann also auch sein, dass es nicht mehr möglich ist für irgendeinen neuen Benutzer eine neue Mailbox anzulegen.
Was hatte ich ganz am Anfang getan?
Dies war ein neuer Benutzer für den ich nur ein Forwarding per Mailalias im openldap-Server eingetragen hatte. Dies hat funktioniert, bis er doch eine Mailbox wollte. Diesen Fall hatte ich noch nie. Der Server läuft schon seit ca. 2013 anstandslos durch.* *
Bitte gebt Bescheid, falls ich noch andere Infos hinzufügen soll, danke!
herzliche Grüße
Sylvia* *
als Nachtrag, da hat die Mailinglistensoftware die Formatierung versucht gerade zu biegen:
die zwei Zeilen sehen im Original so aus:
Apr 29 11:28:57 server postfix/local[15680]: set_eugid: euid 3005 egid 2017 Apr 29 11:28:57 server postfix/local[15680]: set_eugid: euid 110 egid 116
und hier die nicht zugestellte Mail:
Apr 29 11:30:36 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: mvogt Apr 29 11:30:36 server postfix/local[15680]:set_eugid: euid 3146 egid 2017
Am 07.05.2019 um 11:28 schrieb Sylvia Gelman:
Liebe Liste,
ich hoffe ihr könnt mir helfen. Suche nun schon seit Tagen nach einer Lösung und es ist mir echt ein Rätsel.
Ich habe einen Postfix Server auf Debian Jessie am Laufen. Version postfix 2.11.3 mit Paket postfix-ldap.
Als imap Server kommt Cyrus 2.4.17 zum Einsatz.
Ich möchte euch nicht mit endlosen Konfigdateien belasten, daher hier nur erstmal der Auszug aus den Logs, wo es wohl hakt.
die belasten nicht, die sind sogar nötig... Für die Konfig einfach die Ausgabe von 'postconf -n' posten.
Der Server nimmt die Mail an und stellt sie nur für einen bestimmten neu angelegten Benutzer nicht zu. Alles andere wird zugestellt. Diese Mails befinden sich nun schon seit Tagen in der Queue. Es gibt auch keine Rückmeldung wie sonst, dass die Mails nicht zugestellt werden können.
Die Logs unten helfen mir nicht wirklich weiter, sie erscheinen mir unvollständig.
Daher rate ich mal ins Blaue (Es ist lange her, dass ich mit Cyrus gearbeitet habe):
Cyrus hat eine eigene Benutzerliste. Eventuell hast du nur Postfix den Benutzer bekannt gemacht aber nicht Cyrus?
Das würde sich auch damit decken, dass der Benutzer nun eine Mailbox wollte: die Mail wird von Postfix angenommen, da der Benutzer existiert, kann die Mail mangels Mailbox aber nicht Cyrus übergeben.
Es müsste aber eine Fehlermeldung im Log dazu geben, evtl eine die die Queue-ID nicht beinhaltet und daher über ein grep nach selbiger nicht zu finden ist.
So sieht die Mailzustellung normalerweise aus:
root@server:/# grep 80D41241356 /var/log/mail.log
Apr 25 11:39:11 server postfix/smtpd[12439]: 80D41241356: client=kes.domain.de[IP] Apr 25 11:39:11 server postfix/cleanup[12442]: 80D41241356: message-id=3808909c-c8fa-7d93-b2e4-a225ffa7a48b@domain.de Apr 25 11:39:11 server postfix/qmgr[12406]: 80D41241356: from=admin@domain.de, size=997, nrcpt=1 (queue active) Apr 25 11:39:11 server postfix/pipe[12445]: 80D41241356: to=admin@domain.de, orig_to=admin@domain.de, relay=cyrus, delay=0.1, delays=0/0.02/0/0.08, dsn=2.0.0, status=sent (delivered via cyrus service) Apr 25 11:39:11 server postfix/qmgr[12406]: 80D41241356: removed
Bei diesem Benutzer bleibt die Mail in der Queue hängen, es passiert nichts weiter:
root@server:/# grep 706AB240FC4 /var/log/mail.log Apr 25 11:38:45 server postfix/smtpd[12439]: 706AB240FC4: client=kes.domain.de[IP] Apr 25 11:38:45 server postfix/cleanup[12442]: 706AB240FC4: message-id=ff5eecc9-73a3-e605-1567-21c9814f3f4b@domain.de Apr 25 11:38:45 server postfix/qmgr[12406]: 706AB240FC4: from=admin@domain.de, size=1006, nrcpt=1 (queue active)
Nach Einschalten diverser Debuglevel bekomme ich dies hier, erst wieder die erste Mail:
Apr 29 11:28:57 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: atest Apr 29 11:28:57 server postfix/local[15680]: *set_eugid: euid 3005 egid 201**7* Apr 29 11:28:57 server postfix/local[15680]: *set_eugid: euid 110 egid 116* Apr 29 11:28:57 server postfix/local[15680]: deliver_dotforward: path /home/atest/.forward expand_status 0 look_status -1 Apr 29 11:28:57 server postfix/local[15680]: deliver_mailbox[3]: local atest recip atest@server.domain.de exten deliver atest@server.domain.de exp_from
und hier die nicht zugestellte Mail:
Apr 29 11:30:36 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: mvogt Apr 29 11:30:36 server postfix/local[15680]:*set_eugid: euid 3146 egid 2017*
danach passiert nichts mehr.
Hat jemand eine Idee nach was ich noch suchen könnte, warum kommt es hier nicht zur zweiten Zeile?
Info: /etc/groups: postfix:x:116:und /etc/passwd postfix:x:110:116:
Ich hatte auch schon versucht, den Benutzer ganz neu anzulegen, gleiches Prinzip. Es kann also auch sein, dass es nicht mehr möglich ist für irgendeinen neuen Benutzer eine neue Mailbox anzulegen.
Was hatte ich ganz am Anfang getan?
Dies war ein neuer Benutzer für den ich nur ein Forwarding per Mailalias im openldap-Server eingetragen hatte. Dies hat funktioniert, bis er doch eine Mailbox wollte. Diesen Fall hatte ich noch nie. Der Server läuft schon seit ca. 2013 anstandslos durch.*
Bitte gebt Bescheid, falls ich noch andere Infos hinzufügen soll, danke!
herzliche Grüße
Sylvia*
Hallo Kai (jetzt nochmal an alle),
danke für deine Nachricht! Es sieht für mich so aus als ob der Cyrus darauf überhaupt nicht reagiert, weil die Anfrage bei ihm garnicht an kommt. Der Benutzer hat eine Mailbox aus der heraus auch geschickt werden kann. Der postfix/local scheint ja der letzte Prozess zu sein bevor es an Cyrus weitergegeben wird.
Das Log ist leider nicht unvollständig, dies sind die letzten 2 Zeilen die bei der nicht zugestellten Mail auftauchen: Apr 29 11:30:36 glia postfix/local[15680]: deliver_dotforward[3]: set user_attr: michavogt Apr 29 11:30:36 glia postfix/local[15680]: set_eugid: euid 3146 egid 2017
dann kommt nichts mehr...
ein funktionierender Logeintrag: Apr 29 11:28:57 glia postfix/local[15680]: deliver_dotforward[3]: set user_attr: atest Apr 29 11:28:57 glia postfix/local[15680]: set_eugid: euid 3005 egid 2017 Apr 29 11:28:57 glia postfix/local[15680]: set_eugid: euid 110 egid 116 Apr 29 11:28:57 glia postfix/local[15680]: deliver_dotforward: path /home/atest/.forward expand_status 0 look_status -1 Apr 29 11:28:57 glia postfix/local[15680]: deliver_mailbox[3]: local atest recip atest@server.rt.e-technik.domain.de exten deliver atest@glia.rt.e-technik.domain.de exp_from Apr 29 11:28:57 glia postfix/local[15680]: been_here: mailbox atest: 0 Apr 29 11:28:57 glia postfix/local[15680]: connect to subsystem private/cyrus
viele Grüße
Sylvia
postconf -n
alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, ldap:/etc/postfix/aliases.ldap append_dot_mydomain = no biff = no broken_sasl_auth_clients = yes canonical_maps = config_directory = /etc/postfix delay_warning_time = 4h inet_interfaces = all mailbox_command = mailbox_size_limit = 0 mailbox_transport = cyrus masquerade_domains = rt.e-technik.domain.de rtr.domain.de message_size_limit = 104857600 mydestination = $myhostname, localhost, mailhost, mailhost.$mydomain, localhost.$mydomain, $mydomain, $myorigin, domain.de, rtr.domain.de mydomain = rt.e-technik.domain.de myhostname = server.rt.e-technik.domain.de mynetworks = IP/25 127.0.0.0/8 myorigin = /etc/mailname readme_directory = no recipient_delimiter = + relay_domains = hash:/etc/postfix/relay_domains relayhost = mailout.hrz.tu-darmstadt.de relocated_maps = hash:/etc/postfix/relocated smtp_tls_CAfile = /etc/ldap/ssl/TU-CAcertN.pem smtp_tls_loglevel = 1 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_banner = $myhostname ESMTP smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination smtpd_relay_restrictions = permit_mynetworks,permit_sasl_authenticated,defer_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = smtpd_sasl_security_options = noanonymous, noplaintext smtpd_sasl_tls_security_options = noanonymous smtpd_tls_CAfile = /etc/ldap/ssl/TU-CAcertN.pem smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ldap/ssl/server.pem smtpd_tls_key_file = /etc/ldap/ssl/serverkey.pem smtpd_tls_loglevel = 1 smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_use_tls = yes virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf
Am 07.05.19 um 11:44 schrieb Kai Fürstenberg:
Am 07.05.2019 um 11:28 schrieb Sylvia Gelman:
Liebe Liste,
ich hoffe ihr könnt mir helfen. Suche nun schon seit Tagen nach einer Lösung und es ist mir echt ein Rätsel.
Ich habe einen Postfix Server auf Debian Jessie am Laufen. Version postfix 2.11.3 mit Paket postfix-ldap.
Als imap Server kommt Cyrus 2.4.17 zum Einsatz.
Ich möchte euch nicht mit endlosen Konfigdateien belasten, daher hier nur erstmal der Auszug aus den Logs, wo es wohl hakt.
die belasten nicht, die sind sogar nötig... Für die Konfig einfach die Ausgabe von 'postconf -n' posten.
Der Server nimmt die Mail an und stellt sie nur für einen bestimmten neu angelegten Benutzer nicht zu. Alles andere wird zugestellt. Diese Mails befinden sich nun schon seit Tagen in der Queue. Es gibt auch keine Rückmeldung wie sonst, dass die Mails nicht zugestellt werden können.
Die Logs unten helfen mir nicht wirklich weiter, sie erscheinen mir unvollständig.
Daher rate ich mal ins Blaue (Es ist lange her, dass ich mit Cyrus gearbeitet habe):
Cyrus hat eine eigene Benutzerliste. Eventuell hast du nur Postfix den Benutzer bekannt gemacht aber nicht Cyrus?
Das würde sich auch damit decken, dass der Benutzer nun eine Mailbox wollte: die Mail wird von Postfix angenommen, da der Benutzer existiert, kann die Mail mangels Mailbox aber nicht Cyrus übergeben.
Es müsste aber eine Fehlermeldung im Log dazu geben, evtl eine die die Queue-ID nicht beinhaltet und daher über ein grep nach selbiger nicht zu finden ist.
So sieht die Mailzustellung normalerweise aus:
root@server:/# grep 80D41241356 /var/log/mail.log
Apr 25 11:39:11 server postfix/smtpd[12439]: 80D41241356: client=kes.domain.de[IP] Apr 25 11:39:11 server postfix/cleanup[12442]: 80D41241356: message-id=3808909c-c8fa-7d93-b2e4-a225ffa7a48b@domain.de Apr 25 11:39:11 server postfix/qmgr[12406]: 80D41241356: from=admin@domain.de, size=997, nrcpt=1 (queue active) Apr 25 11:39:11 server postfix/pipe[12445]: 80D41241356: to=admin@domain.de, orig_to=admin@domain.de, relay=cyrus, delay=0.1, delays=0/0.02/0/0.08, dsn=2.0.0, status=sent (delivered via cyrus service) Apr 25 11:39:11 server postfix/qmgr[12406]: 80D41241356: removed
Bei diesem Benutzer bleibt die Mail in der Queue hängen, es passiert nichts weiter:
root@server:/# grep 706AB240FC4 /var/log/mail.log Apr 25 11:38:45 server postfix/smtpd[12439]: 706AB240FC4: client=kes.domain.de[IP] Apr 25 11:38:45 server postfix/cleanup[12442]: 706AB240FC4: message-id=ff5eecc9-73a3-e605-1567-21c9814f3f4b@domain.de Apr 25 11:38:45 server postfix/qmgr[12406]: 706AB240FC4: from=admin@domain.de, size=1006, nrcpt=1 (queue active)
Nach Einschalten diverser Debuglevel bekomme ich dies hier, erst wieder die erste Mail:
Apr 29 11:28:57 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: atest Apr 29 11:28:57 server postfix/local[15680]: *set_eugid: euid 3005 egid 201**7* Apr 29 11:28:57 server postfix/local[15680]: *set_eugid: euid 110 egid 116* Apr 29 11:28:57 server postfix/local[15680]: deliver_dotforward: path /home/atest/.forward expand_status 0 look_status -1 Apr 29 11:28:57 server postfix/local[15680]: deliver_mailbox[3]: local atest recip atest@server.domain.de exten deliver atest@server.domain.de exp_from
und hier die nicht zugestellte Mail:
Apr 29 11:30:36 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: mvogt Apr 29 11:30:36 server postfix/local[15680]:*set_eugid: euid 3146 egid 2017*
danach passiert nichts mehr.
Hat jemand eine Idee nach was ich noch suchen könnte, warum kommt es hier nicht zur zweiten Zeile?
Info: /etc/groups: postfix:x:116:und /etc/passwd postfix:x:110:116:
Ich hatte auch schon versucht, den Benutzer ganz neu anzulegen, gleiches Prinzip. Es kann also auch sein, dass es nicht mehr möglich ist für irgendeinen neuen Benutzer eine neue Mailbox anzulegen.
Was hatte ich ganz am Anfang getan?
Dies war ein neuer Benutzer für den ich nur ein Forwarding per Mailalias im openldap-Server eingetragen hatte. Dies hat funktioniert, bis er doch eine Mailbox wollte. Diesen Fall hatte ich noch nie. Der Server läuft schon seit ca. 2013 anstandslos durch.*
Bitte gebt Bescheid, falls ich noch andere Infos hinzufügen soll, danke!
herzliche Grüße
Sylvia*
Hallo Sylvia,
Am 07.05.2019 um 12:13 schrieb Sylvia Gelman:
danke für deine Nachricht! Es sieht für mich so aus als ob der Cyrus darauf überhaupt nicht reagiert, weil die Anfrage bei ihm garnicht an kommt. Der Benutzer hat eine Mailbox aus der heraus auch geschickt werden kann. Der postfix/local scheint ja der letzte Prozess zu sein bevor es an Cyrus weitergegeben wird.
Das hat miteinander nichts zu tun. Ich kann auch ohne Mailbox senden, wenn ich mag, solange ich einen Zugang zum smtpd habe. Der hat mit einer Mailbox nichts zu tun.
Das Log ist leider nicht unvollständig, dies sind die letzten 2 Zeilen die bei der nicht zugestellten Mail auftauchen: Apr 29 11:30:36 glia postfix/local[15680]: deliver_dotforward[3]: set user_attr: michavogt Apr 29 11:30:36 glia postfix/local[15680]: set_eugid: euid 3146 egid 2017
dann kommt nichts mehr...
Ich bin immer noch nicht überzeugt, dass Cyrus den user kennt, bzw. auch eine Mailbox für diesen hat.
Was gibt denn 'mailq' aus?
Im cyradm, ist die Mailbox mit 'listmailbox' gelistet?
Hallo Kai,
Das hat miteinander nichts zu tun. Ich kann auch ohne Mailbox senden, wenn ich mag, solange ich einen Zugang zum smtpd habe. Der hat mit einer Mailbox nichts zu tun.
Da hast du natürlich völlig Recht!
Ich bin immer noch nicht überzeugt, dass Cyrus den user kennt, bzw. auch eine Mailbox für diesen hat.
Was gibt denn 'mailq' aus?
Die 12 hängenden Mails ala:
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 1AD5F240CBB 1012 Tue Apr 30 15:59:14 sgelman@domain.de michavogt@server.rt.e-technik.domain.de
AFECC240FAC 1021 Thu Apr 25 17:36:29 sgelman@domain.de michavogt@server.rt.e-technik.domain.de
8D67B24092E 6732 Wed May 1 22:39:31 noreply@hrz.domain.de michavogt@server.rt.e-technik.domain.de
9B5BE2412F2 6398 Wed May 1 22:39:33 noreply@hrz.domain.de michavogt@server.rt.e-technik.domain.de
E57042401C0 983 Thu Apr 25 17:21:36 sgelman@domain.de michavogt@server.rt.e-technik.domain.de
6591B240C30 1850 Thu May 2 08:35:09 stefan@domain.de michavogt@server.rt.e-technik.domain.de
4B1C92401BE 3621 Mon May 6 16:01:46 sylvia@domain.de mvogt@server.rt.e-technik.domain.de
usw.
Im cyradm, ist die Mailbox mit 'listmailbox' gelistet?
ja beide Accounts. Ich habe ja nochmal alles neu gemacht, mit den üblichen Mitarbeiterrechten:
user/michavogt (\HasChildren) user/michavogt/Drafts (\HasNoChildren) user/michavogt/Junk (\HasNoChildren) user/michavogt/Outbox (\HasNoChildren) user/michavogt/Sent (\HasNoChildren) user/michavogt/Templates (\HasNoChildren) user/michavogt/Trash (\HasNoChildren) user/mvogt (\HasChildren) user/mvogt/Drafts (\HasNoChildren) user/mvogt/Sent (\HasNoChildren) user/mvogt/Templates (\HasNoChildren)
Die Rechte unter /var/spool/cyrus/mail/m/user stimmen bei den Accounts auch.
viele Grüße
Sylvia
Am 08.05.2019 um 10:20 schrieb Sylvia Gelman:
Hallo Kai,
Das hat miteinander nichts zu tun. Ich kann auch ohne Mailbox senden, wenn ich mag, solange ich einen Zugang zum smtpd habe. Der hat mit einer Mailbox nichts zu tun.
Da hast du natürlich völlig Recht!
Ich bin immer noch nicht überzeugt, dass Cyrus den user kennt, bzw. auch eine Mailbox für diesen hat.
Was gibt denn 'mailq' aus?
Die 12 hängenden Mails ala:
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 1AD5F240CBB 1012 Tue Apr 30 15:59:14 sgelman@domain.de michavogt@server.rt.e-technik.domain.de
AFECC240FAC 1021 Thu Apr 25 17:36:29 sgelman@domain.de michavogt@server.rt.e-technik.domain.de
8D67B24092E 6732 Wed May 1 22:39:31 noreply@hrz.domain.de michavogt@server.rt.e-technik.domain.de
9B5BE2412F2 6398 Wed May 1 22:39:33 noreply@hrz.domain.de michavogt@server.rt.e-technik.domain.de
E57042401C0 983 Thu Apr 25 17:21:36 sgelman@domain.de michavogt@server.rt.e-technik.domain.de
6591B240C30 1850 Thu May 2 08:35:09 stefan@domain.de michavogt@server.rt.e-technik.domain.de
4B1C92401BE 3621 Mon May 6 16:01:46 sylvia@domain.de mvogt@server.rt.e-technik.domain.de
usw.
Im cyradm, ist die Mailbox mit 'listmailbox' gelistet?
ja beide Accounts. Ich habe ja nochmal alles neu gemacht, mit den üblichen Mitarbeiterrechten:
user/michavogt (\HasChildren) user/michavogt/Drafts (\HasNoChildren) user/michavogt/Junk (\HasNoChildren) user/michavogt/Outbox (\HasNoChildren) user/michavogt/Sent (\HasNoChildren) user/michavogt/Templates (\HasNoChildren) user/michavogt/Trash (\HasNoChildren) user/mvogt (\HasChildren) user/mvogt/Drafts (\HasNoChildren) user/mvogt/Sent (\HasNoChildren) user/mvogt/Templates (\HasNoChildren)
Die Rechte unter /var/spool/cyrus/mail/m/user stimmen bei den Accounts auch.
mich irritiert, dass es keine Logeinträge gibt. Mich irritiert auch, dass unter mailq keine Angaben zur Verzögerung eingetragen sind. Normalerweise steht da, warum es länger dauert oder ob die Mail of HOLD steht.
Du könntest Postfix mal anschubsen, die Mails nochmal zuzustellen (postfix flush) und das Log, das dann folgt, zu beobachten. Dabei aber nicht nur auf Postfix achten sondern auch auf Cyrus. Evtl. vorher den Loglevel von Cyrus höhersetzen.
Irgendwo muss es einen Logeintrag geben, was und warum oder nicht mit der Mail passiert.
In den Logs fehlt auch noch was: Da die Mails in der Warteschlange stehen, müsste es vom qmgr einen Eintrag "queued as XXXXX" geben.
Erst danach werden die Mail an den LDA weiter gereicht. Ein eventueller Fehler dürfte kurz danach erscheinen.
Also die Bitte an dich, nochmal eine Mail einzuliefern und das komplette Log (ausgehend von "connect"), dass dabei entsteht, zu posten.
Hallo Kai,
vielen Dank für die Hinweise. postfix flush habe ich natürlich schon x-mal versucht. In Kurzform:
May 8 11:46:01 glia postfix/qmgr[25181]: 1AD5F240CBB: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: AFECC240FAC: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: 8D67B24092E: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: 9B5BE2412F2: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: E57042401C0: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: 6591B240C30: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: 4B1C92401BE: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: 887BE2414AF: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: 1017B24014C: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: 56DBF240F35: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: 78BE1240A20: skipped, still being delivered May 8 11:46:01 glia postfix/qmgr[25181]: C133624159E: skipped, still being delivered
nach Einschalten des -vv bei qmgr, kommt das Log unten heraus.
mich irritiert, dass es keine Logeinträge gibt. Mich irritiert auch, dass unter mailq keine Angaben zur Verzögerung eingetragen sind. Normalerweise steht da, warum es länger dauert oder ob die Mail of HOLD steht.
ja das irritiert mich ja auch, es müsste schon längst der Sender informiert worden sein, dass die Mail nicht zugestellt werden konnte.
Evtl. vorher den Loglevel von Cyrus höhersetzen.
Wo setze ich den Loglevel von Cyrus höher? Finde dazu nichts.
danke und viele Grüße
Sylvia
May 8 11:48:02 glia postfix/qmgr[25573]: trigger_server_accept_local: trigger arrived May 8 11:48:02 glia postfix/qmgr[25573]: master_notify: status 0 May 8 11:48:02 glia postfix/qmgr[25573]: request: 70 (F) May 8 11:48:02 glia postfix/qmgr[25573]: request: 65 (A) May 8 11:48:02 glia postfix/qmgr[25573]: request: 68 (D) May 8 11:48:02 glia postfix/qmgr[25573]: request: 73 (I) May 8 11:48:02 glia postfix/qmgr[25573]: request: 0 (?) May 8 11:48:02 glia postfix/qmgr[25573]: request ignored May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_enable_all May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_scan_start: start incoming queue scan May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_enable_all May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_scan_start: start deferred queue scan May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred May 8 11:48:02 glia postfix/qmgr[25573]: master_notify: status 1 May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 1AD5F240CBB May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/1AD5F240CBB May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 1AD5F240CBB May 8 11:48:02 glia postfix/qmgr[25573]: 1AD5F240CBB: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 1AD5F240CBB after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 1AD5F240CBB May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found D May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/D May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/D May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 9 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/9 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/9 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 4 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/4 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/4 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found F May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/F May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/F May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found E May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/E May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/E May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 8 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/8 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/8 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found B May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/B May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/B May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found C May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/C May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/C May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 3 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/3 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/3 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 1 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/1 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/1 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 7 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/7 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/7 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 5 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/5 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/5 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 2 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/2 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/2 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found A May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/A May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/A May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 6 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_push: open deferred/6 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred/6 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close deferred May 8 11:48:02 glia postfix/qmgr[25573]: done deferred queue scan May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip .. May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found AFECC240FAC May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/AFECC240FAC May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active AFECC240FAC May 8 11:48:02 glia postfix/qmgr[25573]: AFECC240FAC: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup AFECC240FAC after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer AFECC240FAC May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 8D67B24092E May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/8D67B24092E May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 8D67B24092E May 8 11:48:02 glia postfix/qmgr[25573]: 8D67B24092E: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 8D67B24092E after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 8D67B24092E May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 9B5BE2412F2 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/9B5BE2412F2 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 9B5BE2412F2 May 8 11:48:02 glia postfix/qmgr[25573]: 9B5BE2412F2: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 9B5BE2412F2 after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 9B5BE2412F2 May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found E57042401C0 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/E57042401C0 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active E57042401C0 May 8 11:48:02 glia postfix/qmgr[25573]: E57042401C0: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup E57042401C0 after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer E57042401C0 May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 6591B240C30 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/6591B240C30 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 6591B240C30 May 8 11:48:02 glia postfix/qmgr[25573]: 6591B240C30: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 6591B240C30 after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 6591B240C30 May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 4B1C92401BE May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/4B1C92401BE May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 4B1C92401BE May 8 11:48:02 glia postfix/qmgr[25573]: 4B1C92401BE: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 4B1C92401BE after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 4B1C92401BE May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: skip . May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 887BE2414AF May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/887BE2414AF May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 887BE2414AF May 8 11:48:02 glia postfix/qmgr[25573]: 887BE2414AF: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 887BE2414AF after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 887BE2414AF May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 1017B24014C May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/1017B24014C May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 1017B24014C May 8 11:48:02 glia postfix/qmgr[25573]: 1017B24014C: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 1017B24014C after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 1017B24014C May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 56DBF240F35 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/56DBF240F35 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 56DBF240F35 May 8 11:48:02 glia postfix/qmgr[25573]: 56DBF240F35: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 56DBF240F35 after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 56DBF240F35 May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found B9725240D4F May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/B9725240D4F May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active B9725240D4F May 8 11:48:02 glia postfix/qmgr[25573]: B9725240D4F: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup B9725240D4F after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer B9725240D4F May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found 78BE1240A20 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/78BE1240A20 May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active 78BE1240A20 May 8 11:48:02 glia postfix/qmgr[25573]: 78BE1240A20: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup 78BE1240A20 after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer 78BE1240A20 May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_next: found C133624159E May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: queue incoming May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_feed: incoming/C133624159E May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_message_alloc: active C133624159E May 8 11:48:02 glia postfix/qmgr[25573]: C133624159E: skipped, still being delivered May 8 11:48:02 glia postfix/qmgr[25573]: wakeup C133624159E after 60 secs May 8 11:48:02 glia postfix/qmgr[25573]: qmgr_active_defer: defer C133624159E May 8 11:48:02 glia postfix/qmgr[25573]: watchdog_start: 0x557f178e7bf0 May 8 11:48:02 glia postfix/qmgr[25573]: scan_dir_pop: close incoming May 8 11:48:02 glia postfix/qmgr[25573]: done incoming queue scan
Hallo Sylvia,
Sylvia Gelman, 07.05.19:
danke für deine Nachricht! Es sieht für mich so aus als ob der Cyrus darauf überhaupt nicht reagiert, weil die Anfrage bei ihm garnicht an kommt. Der Benutzer hat eine Mailbox aus der heraus auch geschickt werden kann. Der postfix/local scheint ja der letzte Prozess zu sein bevor es an Cyrus weitergegeben wird.
Das Log ist leider nicht unvollständig, dies sind die letzten 2 Zeilen die bei der nicht zugestellten Mail auftauchen: Apr 29 11:30:36 glia postfix/local[15680]: deliver_dotforward[3]: set user_attr: michavogt Apr 29 11:30:36 glia postfix/local[15680]: set_eugid: euid 3146 egid 2017
dann kommt nichts mehr...
ein funktionierender Logeintrag: Apr 29 11:28:57 glia postfix/local[15680]: deliver_dotforward[3]: set user_attr: atest Apr 29 11:28:57 glia postfix/local[15680]: set_eugid: euid 3005 egid 2017 Apr 29 11:28:57 glia postfix/local[15680]: set_eugid: euid 110 egid 116 Apr 29 11:28:57 glia postfix/local[15680]: deliver_dotforward: path /home/atest/.forward expand_status 0 look_status -1
Mich irritieren postfix' Aussagen zu "dotforward" ein wenig.
Existiert im Home-Verzeichnis des problematischen Beenutzers eine .forward-Datei? Wenn ja: Was ist darin aufgeführt? Funktioniert die Zustellung bzw. gibt es andere Meldungen im Log, wenn Du die Datei aus dem Weg räumst?
Mit freundlichen Grüßen Christian Schmidt
Hallo Christian,
Mich irritieren postfix' Aussagen zu "dotforward" ein wenig.
Existiert im Home-Verzeichnis des problematischen Beenutzers eine .forward-Datei? Wenn ja: Was ist darin aufgeführt? Funktioniert die Zustellung bzw. gibt es andere Meldungen im Log, wenn Du die Datei aus dem Weg räumst?
Es gibt keine .forward Datei in den Verzeichnissen und wir benutzen diese Methode auch nicht. Ehrlich gesagt hat mich der Eintrag auch irritiert. In der Postfix Konfiguration finde ich hierzu auch nur folgendes:
postfix-files:$readme_directory/FORWARD_SECRECY_README:f:root:-:644 postfix-files:$readme_directory/XFORWARD_README:f:root:-:644 postfix-files:$html_directory/FORWARD_SECRECY_README.html:f:root:-:644 postfix-files:$html_directory/XFORWARD_README.html:f:root:-:644
viele Grüße
Sylvia
Am 08.05.2019 um 10:29 schrieb Sylvia Gelman:
Es gibt keine .forward Datei in den Verzeichnissen und wir benutzen diese Methode auch nicht. Ehrlich gesagt hat mich der Eintrag auch irritiert. In der Postfix Konfiguration finde ich hierzu auch nur folgendes:
postfix-files:$readme_directory/FORWARD_SECRECY_README:f:root:-:644 postfix-files:$readme_directory/XFORWARD_README:f:root:-:644 postfix-files:$html_directory/FORWARD_SECRECY_README.html:f:root:-:644 postfix-files:$html_directory/XFORWARD_README.html:f:root:-:644
Falls dein Problem noch nicht gelöst ist, es sieht so aus, als ob die local-Prozesse einfach hängen bleiben.
Mögliche Ansätze (nach steigendem Aufwand):
1. ls -lRa auf das Benutzer-Home-Verzeichnis und mit anderen vergleichen.
2. Rechner booten.
3. Rechner booten und Filesystem-Check.
4. Hängende Prozesse rausfinden und tracen.
Gruß Jost
participants (4)
-
Christian Schmidt -
Jost Krieger -
Kai Fürstenberg -
Sylvia Gelman