Martin Zambo wrote:
Hallo Sandy, Hallo Liste,
Auf dem Sytem läuft Suse 9.2 aktualisiert, Cyrus-IMAP der zur Clientseite
auch funktioniert.Nur kommen da keine Mails an, fetchmail holt ab und weiter kommen die mails dann nicht.
Das heisst, die Anwender können sich anmelden, sehen ihre alten Mails, es
kommen aber keine neuen herein?
Genau, so ist es.
Dann dürfte Cyrus normal funktionieren. Was steht denn in /etc/cyrus.conf als lmtpunix? So sieht es bei mir aus: lmtp cmd="lmtpd" listen="lmtp" prefork=0 lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=0
Nach dem Start von fetchmail:
sky:/home/martin # fetchmail 61 Nachrichten für xxxx-52-1 bei pop.1und1.com (678336 Oktetts). Nachricht xxxx-52-1@pop.1und1.com:1 von 61 wird gelesen (2752 Oktetts) ..
bleibt es so stehen es geht nicht weiter.
Werden die restlichen Mails abgeholt und erscheinen sie in der Ausgabe von
mailq?
Die Maiq ist heute wieder leer, die Mails von gestern sind irgend wie verschwunden.
Dann wurden Sie ausgeliefert oder gebouncet. Könntest du mal in /etc/sysconfig/fetchmail den Parameter "FETCHMAIL_SILENT=no" setzen, dann loggt fetchmail jede Mail.
EA50761C6F 492 Sat Jun 4 01:39:01 root@sky.pmz (temporary failure. Command output: couldn't connect to lmtpd: Bad file descriptor_ 421 4.3.0 deliver: couldn't connect to lmtpd_) root@sky.pmz
sky:/home/martin # postconf -n
luser_relay = mz@it-zambo.de
Das funktioniert leider nur solange, bis Spammer entdecken, dass alle Mails mit so einem Catch-all ausgeliefert werden. Dann hagelt es SPAM...
mailbox_command = /usr/lib/cyrus/bin/deliver
mailbox_command = kann leer bleiben, darum kümmert sich bereits mailbox_transport. Du könntest aber auch noch explizit angeben: fallback_transport = lmtp:unix:/var/lib/imap/socket/lmtp
mailbox_size_limit = 51200000 mailbox_transport = cyrus mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient mydestination = $myhostname, localhost.$mydomain myhostname = sky.pmz mynetworks = 10.0.0.0/24, 127.0.0.0/8
Hier würde ich noch die inet_interfaces = (all oder ip Adresse) reinbringen. Per Default lauscht Postfix nur auf localhost, jetzt würde ich aber nicht beschwören, ob er eine solche Default-Einstellung auch bei einer Übernahme macht. Mit "netstat -tulpen" findest du schnell heraus, auf welchen IPs und Ports welches Programm lauscht.
smtpd_sender_restrictions = hash:/etc/postfix/access
Ist in der Datei irgendetwas drin?
strict_rfc821_envelopes = yes transport_maps = hash:/etc/postfix/transport Steht hier irgendetwas drin?
Sinnvoll ist es bestimmt auch smtpd_recipient_restrictions explizit anzugeben.
master.cf # ========================================================================== # service type private unpriv chroot wakeup maxproc command + args # (yes) (yes) (yes) (never) (100) # ========================================================================== smtp inet n - n - - smtpd localhost:10025 inet n - n - - smtpd -o content_filter = smtp-amavis:[127.0.0.1]:10024
Ah, hier wird es interessant. Könntest du bitte prüfen, ob amavis überhaupt läuft? rcamavis status Mails kommen also über fetchmail und smtp herein und sollen gefiltert werden. Bei mir steht es genau umgekehrt. /etc/postfix/master.cf: smtp inet n - n - 2 smtpd -o content_filter=smtp:127.0.0.1:10024 localhost:10025 inet n - n - - smtpd -o content_filter= Mails kommen herein und werden mit dem content_filter über Port 10024 an amavis übergeben. In /etc/amavisd.conf steht dann: # SMTP SERVER (INPUT) PROTOCOL SETTINGS (e.g. with Postfix, Exim v4, ...) # (used when MTA is configured to pass mail to amavisd via SMTP or LMTP) $inet_socket_port = 10024; # accept SMTP on this local TCP port # POSTFIX, or SENDMAIL in dual-MTA setup, or EXIM V4 # (set host and port number as required; host can be specified # as IP address or DNS name (A or CNAME, but MX is ignored) $forward_method = 'smtp:127.0.0.1:10025'; # where to forward checked mail $notify_method = $forward_method; # where to submit notifications amavis verarbeitet die Mails also und schickt sie dann weiter an localhost:10025. Dort wiederum lauscht Postfix, diesmal ohne content_filter und übergibt die Mail an den Transport. /etc/postfix/main.cf: mailbox_transport=cyrus /etc/postfix/master.cf: cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} Das sollte es dann eigentlich gewesen sein. Wenn es bei dir hakt, auch wenn die oben genannten Einstellungen noch einmal alle geprüft sind, dann wird es allmählich Zeit, ans Eingemachte zu gehen, sprich, die Konfiguration auf das absolute Minimum zu beschränken, das zum Funktionieren zu bringen und dann die übrigen Funktionen wieder einfügen. Der erste Kandidat dafür wäre amavis. Das sieht bei dir etwas seltsam aus. Auf den ersten Blick komme ich nicht dahinter, wie die localhost:10025 jemals in Funktion tritt. Der scheint in der Luft zu hängen. Wenn du testweise mal amavis deaktivieren willst, dann kommentiere einfach mal die Optionen auf localhost:10025 aus. Siehst du eigentlich amavis-Meldungen im Log? Im Ablauf also: Internetmail -> SMTP Port 25 kommuniziert mit Postfix -> Postfix übergibt intern per localhost:10024 an amavisd -> Amavisd: prüft Mail auf Viren und Spam -> übergibt an localhost:10025 Postfix nimmt wieder entgegen auf localhost:10025 und leitet sie weiter über transport:cyrus , ruft also /usr/lib/cyrus/bin/deliver auf, um an Cyrus zu übergeben.
Wenn dort lmtp verwendet wird, sollte er natürlich genau übereinstimmen mit der Datei, die Cyrus dafür verwendet und Postfix sollte nicht chroot laufen. Bei mir wäre die richtige Datei /var/lib/imap/socket/lmtp.
Wie kann ich das prüfen?
Sollte nicht notwendig sein, aber ob es die richtige Datei ist, sollte in /etc/cyrus.conf stehen.
Nur mit einer korrekten Konfiguration. Die Mails hängen in der Queue, können aber nicht an Cyrus weitergeleitet werden. Sobald die Konfiguration stimmt und Postfix neu gestartet wird, werden auch die Mails wieder zugestellt.
Die Konfiguration lief unter suse 9.0 ohne Probleme.
Ich hatte nach dem Upgrade von 9.1 nach 9.2 das Problem, dass saslauthd nicht als Startdienst übernommen wurde und ich plötzlich nicht mehr in cyrus reinkam. Das konnte ich zum Glück recht schnell feststellen und durch das Starten des saslauthd beheben.
Beschreibe bitte mal präzise, WIE du upgedatet hast. Ich habe das Gefühl, dass es hier ein Problem gibt.
Rechner neu gestartet, von CD gebootet, dann statt Neuinstallation update ausgewählt. Nach dem das durchgelaufen ist habe ich ein Online Update gemacht, die rpmsave Dateien reaktiviert und damit die Konfigurationsdateien aus 9.0
Gab es noch größere Probleme mit den aktualisierten Konfigurationsdateien oder warum hast du die alten verwendet? Die vorhandenen sollten eigentlich korrekt angepasst sein durch das Upgrade. Hast du die durch das Upgrade erstellten Konfigurationsdateien aufgehoben? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com