• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Fetchmail streikt seit Update auf opensuse 13.2

norritt

Member
Hallo zusammen,

ich habe Ende letzter Woche ein Update von opensuse 13.1 auf opensuse 13.2 durchgeführt. Seitdem habe ich anscheinend Probleme mit meinem lokalen Mailserver. Der Server aggregiert für mich die Mails aus allen meinen Mailkonten bei verschiedenen Mail Service Providern. Ich nutze das Trio:

  • postfix
  • fetchmail
  • cyrus

Zunächst war mir das Problem nicht aufgefallen, da fetchmail nach dem Update noch selektiv Mails von *einigen* der Konten abgeholt hat (warum auch immer :???: ) . Zusätzlich sei erwähnt das die Ursprüngliche Einrichtung unter opensuse 12.1 stattfand und seitdem nur im Rahmen von (leider recht häufigen) Kompatibilitätsproblemen bei Distributionsupgrades aktualisiert wurde.

Soviel zur Vorgeschichte, jetzt ans Eingemachte:

Laut Logfile laufen alle drei Services laufen einwandfrei. (Hierzu war ein wenig Handarbeit nötig, zunächst gab es einige SSL Probleme, da yast beim Update meine Zertifikate in ein Verzeichnis delete.me verschoben und smpt_tls_CAFile, smtpd_tls_CAfile, smtpd_tls_CApath, smtpd_tls_cert_file, smtps_tls_key_file durch Leereinträge ersetzt hatte. Die analogen Einträge für smtp_tls_* waren durch andere vermutlich von yast generierte Einträge ersetzt worden.)

Code:
cube:/etc/postfix # systemctl status cyrus
cyrus.service - LSB: The cyrus-imapd mail system
   Loaded: loaded (/etc/init.d/cyrus)
   Active: active (running) since Tue 2016-04-26 21:18:08 CEST; 14s ago
  Process: 12413 ExecStop=/etc/init.d/cyrus stop (code=exited, status=0/SUCCESS)
  Process: 12421 ExecStart=/etc/init.d/cyrus start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/cyrus.service
           ââ12429 /usr/lib/cyrus/bin/master -d
           ââ12434 idled

Apr 26 21:18:08 cube ctl_cyrusdb[12430]: done recovering cyrus databases
Apr 26 21:18:08 cube master[12433]: about to exec /usr/lib/cyrus/bin/idled
Apr 26 21:18:08 cube master[12429]: unable to setsocketopt(IP_TOS): Operation not supported
Apr 26 21:18:08 cube master[12429]: ready for work
Apr 26 21:18:08 cube master[12435]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb
Apr 26 21:18:08 cube ctl_cyrusdb[12435]: checkpointing cyrus databases
Apr 26 21:18:08 cube ctl_cyrusdb[12435]: archiving database file: /var/lib/imap/mailboxes.db
Apr 26 21:18:08 cube ctl_cyrusdb[12435]: archiving database file: /var/lib/imap/annotations.db
Apr 26 21:18:08 cube ctl_cyrusdb[12435]: done checkpointing cyrus databases
Apr 26 21:18:08 cube master[12429]: process 12435 exited, status 0

cube:/etc/postfix # systemctl status postfix
postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled)
   Active: active (running) since Tue 2016-04-26 21:16:37 CEST; 2min 4s ago
  Process: 12143 ExecStopPost=/etc/postfix/system/cond_slp deregister (code=exited, status=0/SUCCESS)
  Process: 12132 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
  Process: 12385 ExecStartPost=/etc/postfix/system/cond_slp register (code=exited, status=0/SUCCESS)
  Process: 12380 ExecStartPost=/etc/postfix/system/wait_qmgr 60 (code=exited, status=0/SUCCESS)
  Process: 12305 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
  Process: 12302 ExecStartPre=/etc/postfix/system/update_postmaps (code=exited, status=0/SUCCESS)
  Process: 12299 ExecStartPre=/etc/postfix/system/update_chroot (code=exited, status=0/SUCCESS)
  Process: 12296 ExecStartPre=/etc/postfix/system/config_postfix (code=exited, status=0/SUCCESS)
  Process: 12293 ExecStartPre=/bin/echo Starting mail service (Postfix) (code=exited, status=0/SUCCESS)
 Main PID: 12378 (master)
   CGroup: /system.slice/postfix.service
           ââ12378 /usr/lib/postfix/master -w
           ââ12379 pickup -l -t fifo -u
           ââ12381 qmgr -l -t fifo -u

Apr 26 21:16:36 cube echo[12293]: Starting mail service (Postfix)
Apr 26 21:16:37 cube postfix/master[12378]: daemon started -- version 2.11.3, configuration /etc/postfix
Apr 26 21:16:37 cube systemd[1]: Started Postfix Mail Transport Agent.

systemctl status fetchmail
fetchmail.service - A remote-mail retrieval utility
   Loaded: loaded (/usr/lib/systemd/system/fetchmail.service; enabled)
   Active: active (running) since Tue 2016-04-26 21:18:02 CEST; 59min ago
 Main PID: 12409 (fetchmail)
   CGroup: /system.slice/fetchmail.service
           ââ12409 /usr/bin/fetchmail -d 900 -f /etc/fetchmailrc

Apr 26 21:18:02 cube systemd[1]: Started A remote-mail retrieval utility.

Richtig seltsam wirds jetzt: Nachdem mir heute aufgefallen ist, dass meine Mails auf einigen Konten nicht mehr abgerufen werden, habe ich nochmal ein Update via "zypper up" gestartet und neu gebootet. Nach dem Neustart wurden die Mails von *einem* der zuvor von fetchmail ignorierten Konten abgeholt. Seitdem tut sich aber gar nichts mehr, sprich mittlerweile werden gar keine Mails mehr abgeholt, von keinem Konto.

Testweise habe ich fetchmail mal per Hand gestartet:

Code:
fetchmail -vvvvv -P pop3s -u <USER> securepop.t-online.de
Alte UID-Liste aus securepop.t-online.de: <leer>
Leere UID-Liste: <leer>
Geben Sie das Passwort für <USER>@securepop.t-online.de ein:
fetchmail: 6.3.26 fragt securepop.t-online.de ab (Protokoll auto) um Di 26 Apr 2016 21:35:59 CEST: Abfrage gestartet
fetchmail: 6.3.26 fragt securepop.t-online.de ab (Protokoll IMAP) um Di 26 Apr 2016 21:35:59 CEST: Abfrage gestartet
Versuche, mit 194.25.134.110/995 zu verbinden...verbunden.
fetchmail: Socket-Fehler beim Abholen von <USER>@securepop.t-online.de
fetchmail: 6.3.26 fragt ab securepop.t-online.de (Protokoll IMAP) um Di 26 Apr 2016 21:37:00 CEST: Abfrage beendet
fetchmail: 6.3.26 fragt securepop.t-online.de ab (Protokoll POP3) um Di 26 Apr 2016 21:37:00 CEST: Abfrage gestartet
Versuche, mit 194.25.134.110/995 zu verbinden...verbunden.
fetchmail: Socket-Fehler beim Abholen von <USER>@securepop.t-online.de
fetchmail: 6.3.26 fragt ab securepop.t-online.de (Protokoll POP3) um Di 26 Apr 2016 21:38:00 CEST: Abfrage beendet
fetchmail: 6.3.26 fragt securepop.t-online.de ab (Protokoll POP2) um Di 26 Apr 2016 21:38:00 CEST: Abfrage gestartet
Versuche, mit 194.25.134.110/995 zu verbinden...verbunden.
fetchmail: Socket-Fehler beim Abholen von <USER>@securepop.t-online.de
fetchmail: 6.3.26 fragt ab securepop.t-online.de (Protokoll POP2) um Di 26 Apr 2016 21:39:00 CEST: Abfrage beendet
fetchmail: 6.3.26 fragt ab securepop.t-online.de (Protokoll auto) um Di 26 Apr 2016 21:39:00 CEST: Abfrage beendet
Vereinigte UID-Liste aus securepop.t-online.de: <leer>
fetchmail: Abfragestatus=2 (SOCKET)
fetchmail: normale Beendigung, Status 2

Scheinbar wird die Verbindung zur Gegenstelle zwar aufgebaut und die Authentifiziierung klappt, beim Abholen der Mails tritt aber dann ein Problem auf. Leider ist die Logausgabe nicht wirklich hilfreich. Ich habe fast die Vermutung das es sich um ein lokales Problem bei der Kommunikation zwischen Postfix, Fetchmail und Cyrus handelt.

Die Services scheinen aber alle ordnungsgemäß zulaufen, hier der Vollständigkeit halber auch nochmal die Ausgabe von netstat:

Code:
cube:~ # netstat -tulpn | grep LISTEN
tcp        0      0 10.11.12.1:53           0.0.0.0:*               LISTEN      1773/named
tcp        0      0 192.168.1.1:53          0.0.0.0:*               LISTEN      1773/named
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1773/named
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      1647/vsftpd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1670/sshd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      13285/master
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      1773/named
tcp        0      0 0.0.0.0:636             0.0.0.0:*               LISTEN      1743/slapd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      1733/smbd
tcp        0      0 0.0.0.0:42590           0.0.0.0:*               LISTEN      1904/rpc.statd
tcp        0      0 0.0.0.0:47711           0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:993             0.0.0.0:*               LISTEN      13321/master
tcp        0      0 0.0.0.0:2049            0.0.0.0:*               LISTEN      -
tcp        0      0 0.0.0.0:995             0.0.0.0:*               LISTEN      13321/master
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN      1743/slapd
tcp        0      0 127.0.0.1:10025         0.0.0.0:*               LISTEN      13285/master
tcp        0      0 0.0.0.0:1194            0.0.0.0:*               LISTEN      12238/openvpn
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      1733/smbd
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      13321/master
tcp        0      0 127.0.0.1:3310          0.0.0.0:*               LISTEN      2077/clamd
tcp        0      0 0.0.0.0:143             0.0.0.0:*               LISTEN      13321/master
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/systemd
tcp        0      0 0.0.0.0:2000            0.0.0.0:*               LISTEN      13321/master
tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN      1923/perl
tcp        0      0 0.0.0.0:20048           0.0.0.0:*               LISTEN      1886/rpc.mountd
tcp        0      0 :::53                   :::*                    LISTEN      1773/named
tcp        0      0 :::22                   :::*                    LISTEN      1670/sshd
tcp        0      0 ::1:25                  :::*                    LISTEN      13285/master
tcp        0      0 ::1:953                 :::*                    LISTEN      1773/named
tcp        0      0 :::59100                :::*                    LISTEN      1904/rpc.statd
tcp        0      0 :::636                  :::*                    LISTEN      1743/slapd
tcp        0      0 :::445                  :::*                    LISTEN      1733/smbd
tcp        0      0 :::993                  :::*                    LISTEN      13321/master
tcp        0      0 :::2049                 :::*                    LISTEN      -
tcp        0      0 :::995                  :::*                    LISTEN      13321/master
tcp        0      0 :::389                  :::*                    LISTEN      1743/slapd
tcp        0      0 ::1:10025               :::*                    LISTEN      13285/master
tcp        0      0 :::139                  :::*                    LISTEN      1733/smbd
tcp        0      0 :::110                  :::*                    LISTEN      13321/master
tcp        0      0 :::143                  :::*                    LISTEN      13321/master
tcp        0      0 :::111                  :::*                    LISTEN      1/systemd
tcp        0      0 :::2000                 :::*                    LISTEN      13321/master
tcp        0      0 :::80                   :::*                    LISTEN      1781/httpd2-prefork
tcp        0      0 :::20048                :::*                    LISTEN      1886/rpc.mountd
tcp        0      0 :::55538                :::*                    LISTEN      -

Folgende Zeile aus dem Cyrus Log hatte mich zunächst stutzig gemacht:

Code:
Apr 26 21:18:08 cube master[12429]: unable to setsocketopt(IP_TOS): Operation not supported

Allerdings startet der service trotzdem (ich kann mich auch mit Thunderbird verbinden und auf das IMAP Konto zugreifen). Eine Googlesuche zu dem Thema hatte diverse sehr allte Problemberichte insebesondere im Zusammenhang mit Debian zu Tage geführt, soweit ich das beurteilen kann haben die Infos in den Suchergebnissen nichts mit meine Problematik zu tun.

Hat jemand von euch eventuell eine zündende Idee, was hier schiefläuft? Ich steh momentan auf dem Schlauch.
 
OP
N

norritt

Member
Code:
$ fetchmail -v
fetchmail: no mailservers have been specified.

$  fetchmail -v securepop.t-online.de
Enter password for <USER>@securepop.t-online.de:
fetchmail: 6.3.26 querying securepop.t-online.de (protocol auto) at Wed Apr 27 15:34:24 2016: poll started
fetchmail: 6.3.26 querying securepop.t-online.de (protocol IMAP) at Wed Apr 27 15:34:24 2016: poll started
Trying to connect to 194.25.134.110/143...connection failed.
fetchmail: connection to securepop.t-online.de:imap [194.25.134.110/143] failed: Connection refused.
Trying to connect to 194.25.134.46/143...connection failed.
fetchmail: connection to securepop.t-online.de:imap [194.25.134.46/143] failed: Connection refused.
fetchmail: Connection errors for this poll:
name 0: connection to securepop.t-online.de:imap [194.25.134.110/143] failed: Connection refused.
name 1: connection to securepop.t-online.de:imap [194.25.134.46/143] failed: Connection refused.
IMAP connection to securepop.t-online.de failed: Connection refused
fetchmail: 6.3.26 querying securepop.t-online.de (protocol IMAP) at Wed Apr 27 15:34:25 2016: poll completed
fetchmail: 6.3.26 querying securepop.t-online.de (protocol POP3) at Wed Apr 27 15:34:25 2016: poll started
Trying to connect to 194.25.134.46/110...connection failed.
fetchmail: connection to securepop.t-online.de:pop3 [194.25.134.46/110] failed: Connection refused.
Trying to connect to 194.25.134.110/110...connection failed.
fetchmail: connection to securepop.t-online.de:pop3 [194.25.134.110/110] failed: Connection refused.
fetchmail: Connection errors for this poll:
name 0: connection to securepop.t-online.de:pop3 [194.25.134.46/110] failed: Connection refused.
name 1: connection to securepop.t-online.de:pop3 [194.25.134.110/110] failed: Connection refused.
POP3 connection to securepop.t-online.de failed: Connection refused
fetchmail: 6.3.26 querying securepop.t-online.de (protocol POP3) at Wed Apr 27 15:34:25 2016: poll completed
fetchmail: 6.3.26 querying securepop.t-online.de (protocol POP2) at Wed Apr 27 15:34:25 2016: poll started
Trying to connect to 194.25.134.46/109...connection failed.
fetchmail: connection to securepop.t-online.de:pop2 [194.25.134.46/109] failed: Connection refused.
Trying to connect to 194.25.134.110/109...connection failed.
fetchmail: connection to securepop.t-online.de:pop2 [194.25.134.110/109] failed: Connection refused.
fetchmail: Connection errors for this poll:
name 0: connection to securepop.t-online.de:pop2 [194.25.134.46/109] failed: Connection refused.
name 1: connection to securepop.t-online.de:pop2 [194.25.134.110/109] failed: Connection refused.
POP2 connection to securepop.t-online.de failed: Connection refused
fetchmail: 6.3.26 querying securepop.t-online.de (protocol POP2) at Wed Apr 27 15:34:25 2016: poll completed
fetchmail: 6.3.26 querying securepop.t-online.de (protocol auto) at Wed Apr 27 15:34:25 2016: poll completed
fetchmail: Query status=2 (SOCKET)
fetchmail: normal termination, status 2

Hier schlägt die Authentifizierung fehl, weil offenbar kein TLS verwendet wird. Dem könnte man vermutlich entgegenwirken indem "option ssl ..." angegeben wird (vor dem Update lief es aber mit dieser fetchmailrc). Wie man an der Ausgabe des fetchmailaufrufs in meinem Originalpost sehen kann, tritt aber selbst bei erfolgreicher Authentifizierung (d.h. bei Angabe des Parameters fetchmail -P pop3s ...), anschliessend ein (Socket-)Fehler auf.

Code:
fetchmail: 6.3.26 fragt securepop.t-online.de ab (Protokoll POP3) um Di 26 Apr 2016 21:37:00 CEST: Abfrage gestartet
Versuche, mit 194.25.134.110/995 zu verbinden...verbunden.
fetchmail: Socket-Fehler beim Abholen von <USER>@securepop.t-online.de
fetchmail: 6.3.26 fragt ab securepop.t-online.de (Protokoll POP3) um Di 26 Apr 2016 21:38:00 CEST: Abfrage beendet

Wichtig ist in obigem Listing Zeile 2:
Versuche, mit 194.25.134.110/995 zu verbinden...verbunden.

Für mich sieht das so aus als kann fetchmail nicht mit postfix bzw. postfix nicht mit cyrus kommunizieren. Daher wird der Abholvorgang nach erfolgreicher Authentifizeriung abgebrochen. Gibt man "-P pop3s" nicht manuell an, funktioniert nichtmal die Authentifizierung. Im Prinzip sind es also zwei Probleme, wobei der Socketfehler nach erfolgreicher Authentifizierung das Problem ist, das mir am meisten Kopfzerbrechen macht. Die Verwendung von POP3s kann man vermutlich durch Anpassen der Optionen in der fetchmailrc erzwingen.

Die /etc/fetchmailrc sieht so aus:

Code:
poll "<SERVER1> with protocol AUTO : user "<USER@SERVER1>" password "<SECRET>" is "<LOCALUSER>" here ;
poll "<SERVER2> with protocol AUTO : user "<USER@SERVER2>" password "<SECRET>" is "<LOCALUSER>" here ;
...

Ich hatte testweise auch schonmal "with protocol AUTO" in "with service pop3s" geändert bringt aber auch nix.
 

drcux

Hacker
man fetchmail sagt, das es kein -p pop3s kennt, du musst als Option "ssl" mitgeben:

poll "<SERVER1> with protocol pop3 : user "<USER@SERVER1>" password "<SECRET>" is "<LOCALUSER>" here ssl;

Wenn du deine fetchmailrc testen willst:

sudo -u fetchmail fetchmail -v -f /etc/fetchmailrc

Wenn der Nutzer unter dem fetchmail als Dienst läuft auch fetchmail heißt,
 
OP
N

norritt

Member
drcux schrieb:
man fetchmail sagt, das es kein -p pop3s kennt,

Ja stimmt, du musst ein grosses "P" angeben also -P pop3s

-p = Protokoll
-P = Service (fetchmail nutzt dann /etc/services um die korrekte Portnummer zu ermitteln)

Allerdings vermute ich dass hier wirklich nur der Port geändert wird. Der Socketfehler aus dem Log oben tritt dann vermutlich auf, weil fetchmail trotzdem eine unverschlüsselte Verbindung aufbaut und der TLS Handshake fehlschlägt.

drcux schrieb:
du musst als Option "ssl" mitgeben:

poll "<SERVER1> with protocol pop3 : user "<USER@SERVER1>" password "<SECRET>" is "<LOCALUSER>" here ssl;

Ja das war des Rätsels Lösung (zumindest was fetchmail angeht). Die Mails wurden von meinen Konten abgeholt, hängen aber jetzt in der postfix queue fest (deferred), weil der Update es wohl für nötig hielt zusätzlich noch dovecot einzurichten. Das hab ich mit zypper rm dovecot zwar wieder behoben, allerdings mag postfix seither scheinbar nicht mehr mit cyrus sprechen. Ich vermute ein Problem in der main.cf oder master.cf folgendes hat sich geändert:

master.cf
Während dem update wurde folgende Zeile hinzugefügt, allerdings ist sie auskommentiert und somit wirkungslos:
Code:
#tlsmgr    unix  -       -       n       1000?   1       tlsmgr

In der main.cf hat das Update ordentlich gewütet, ich vermute die Änderungen hier sind Ursache für das Problem mit cyrus. Ich habe Screenshots von einem Diff angefügt links eine ältere Version der main.cf aus einem Backup vor dem Update, rechts die aktuelle Version (einige Änderungen beschränken sich auf Whitspacedifferenzen um das Gleichheitszeichen herum). Testweise habe ich mal die alte Konfiguration zurückkopiert, leider mit bescheidenem Erfolg. Eine neue Mail von einem meiner Mailkonten wurde wieder zugestellt aber 78 Mail stecken noch in der queue fest.

drcux schrieb:
man fetchmail sagt, das es kein -p pop3s kennt,

Ja stimmt, du musst ein großes "P" angeben also -P pop3s

-p = Protokoll
-P = Service (fetchmail nutzt dann /etc/services um die korrekte Portnummer zu ermitteln)

Allerdings vermute ich dass hier wirklich nur der Port geändert wird. Der Socketfehler aus dem Log oben tritt dann vermutlich auf weil fetch mail trotzdem eine unverschlüsselte Verbindung aufbaut und der TLS Handshake fehlschlägt.

drcux schrieb:
du musst als Option "ssl" mitgeben:

poll "<SERVER1> with protocol pop3 : user "<USER@SERVER1>" password "<SECRET>" is "<LOCALUSER>" here ssl;

Ja das war des Rätsels Lösung (zumindest was fetchmail angeht). Die Mails wurden von meinen Konten abgeholt, hängen aber jetzt in der postfix queue fest (deferred), weil der Update es wohl für nötig hielt zusätzlich noch dovecot einzurichten. Das hab ich mit zypper rm dovecot zwar wieder behoben, allerdings mag postfix seither scheinbar nicht mehr mit cyrus sprechen. Ich vermute ein Problem in der main.cf oder master.cf folgendes hat sich geändert:

master.cf
Während dem update wurde folgende Zeile hinzugefügt, allerdings ist sie auskommentiert und somit wirkungslos:
Code:
#tlsmgr    unix  -       -       n       1000?   1       tlsmgr

In der main.cf hat das Update ordentlich gewütet, ich vermute die Änderungen hier sind Ursache für das Problem mit cyrus. Ich habe Screenshots von einem Diff angefügt links eine ältere Version der main.cf aus einem Backup vor dem Update, rechts die aktuelle Version (einige Änderungen beschränken sich auf Whitspacedifferenzen um das Gleichheitszeichen herum). Testweise habe ich mal die alte Konfiguration zurückkopiert, leider mit bescheidenem Erfolg. Eine neue Mail von einem Meiner Mailkonten wurde wieder zugestellt aber 78 Mail stecken noch in der queue fest.

main.cf_001.png

main.cf_002.png

main.cf_003.png
 

drcux

Hacker
Na, wenn neue Mails jetzt wieder sauber zugestellt werden, dann schubs postqueue an...

Die wichtigste Änderung scheint übrigens "mailbox_transport" zu sein.
 
OP
N

norritt

Member
Ja das seltsame ist mit den Mails in der queue verweigert postfix standhaft die Zustellung.

Code:
postqueue -fv
postqueue: name_mask: all
postqueue: inet_addr_local: configured 3 IPv4 addresses
postqueue: inet_addr_local: configured 3 IPv6 addresses
2016-04-29T12:37:42.905817+02:00 cube postfix/error[7642]: <HEXVALUE>: to=<TARGET>, orig_to=<TARGET>, relay=none, delay=140167, delays=140166/0.05/0/0.02, dsn=4.3.0, status=deferred (mail transport unavailable)
...
 
OP
N

norritt

Member
Strike, ich hab das letzte Problem gerade gefunden.

Postfix hat versucht die Mails in der queue über amavis an cyrus zu leiten. Der Amavis check wurde beim Update im Rahmen der unerwünschten Dovecotinstallation aktiviert. Ich habe dann nachträglich, nach der Dovecot-Deinstallation, den Check durch amavis wieder deaktiviert. Allerdings hingen die "deferred-Mails" zu diesem Zeitpunkt schon in der Postfix-Queue. Alle neuen Mails sind dann mit der geänderten Konfiguration "Amavis deaktiviert" verarbeitet und korrekt zugestellt worden. Letztendlich konnte ich die Mails in der Queue zustellen, indem ich folgende auskommentierte Zeilen in der master.cf wieder aktiviert habe:

Code:
amavis    unix  -       -       n       -       4       smtp
...
localhost:10025 inet   n       -       n       -       -       smtpd
  -o content_filter=
  -o smtpd_delay_reject=no
  -o smtpd_client_restrictions=permit_mynetworks,reject
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o smtpd_data_restrictions=reject_unauth_pipelining
  -o smtpd_end_of_data_restrictions=
  -o smtpd_restriction_classes=
  -o mynetworks=127.0.0.0/8
  -o smtpd_error_sleep_time=0
  -o smtpd_soft_error_limit=1001
  -o smtpd_hard_error_limit=1000
  -o smtpd_client_connection_count_limit=0
  -o smtpd_client_connection_rate_limit=0
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks,no_address_mappings
  -o local_header_rewrite_clients=
  -o local_recipient_maps=
  -o relay_recipient_maps=
 
Oben