-
Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.
Postfix und cyrus "reden" nicht richtig miteinande
- Ersteller bit-bastards
- Erstellt am
- Status
OP
Achso, sag das doch ;-)
Sorry bin noch Linux-anfänger
Das funktioniert jetzt auch, super danke nochmals
Jetzt hab ich nur noch ein Problem: seit der Neuinstallation funktioniert der Apache2 nicht mehr (aber da werd ich erst mal googlen und bei Bedarf einen neuen Tread aufmachen.
Also danke nochmals
Sorry bin noch Linux-anfänger
Das funktioniert jetzt auch, super danke nochmals
Jetzt hab ich nur noch ein Problem: seit der Neuinstallation funktioniert der Apache2 nicht mehr (aber da werd ich erst mal googlen und bei Bedarf einen neuen Tread aufmachen.
Also danke nochmals
OP
ja, der Mailserver funzt. nur noch eine Frage:
fetchmail loggt ja alle 2 Minuten (awaking und sleeping), das wird auf Dauer ein bissl viel, oder?
Wie kann ich das ändern, daß zb nur bei Fehlern geloggt wird?
fetchmail loggt ja alle 2 Minuten (awaking und sleeping), das wird auf Dauer ein bissl viel, oder?
Wie kann ich das ändern, daß zb nur bei Fehlern geloggt wird?
OP
super. danke. das hat mir sehr weitergeholfen. Ihr seid echt klasse
:-D
:-D
OP
tja, ich glaub da hab ich mich zu früh gefreut.
ich habe wieder das read time out problem auf dem lmtp *seufz
aber was habe ich eigentlich geändert?
mit apt-get wollte ich meinen server updaten. Allerdings gab es probleme mit dem paket kvirc.
ich denke mal kvirc ist wohl ein irc client, den ich nicht unbedingt brauche.
dann hat apt auch 17 pakete ersetzt (xfree, genau weiß ich es nicht mehr)
und apache2-prefork durch apache-worker ersetzt.
mein apache läuft jetzt zwar, aber der mailserver nicht mehr.
alle mails hängen bei postfix im queue
Status:
connect to /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp]: read timeout
ich versteh hier nix mehr, ehrlich gesagt. *seufz
vielleicht kann sich ja einer von euch zusammenreimen, was hier passiert ist.
an den postfix, cyrus conf hab ich nix geändert.
fetchmail läuft noch im daemon modus und holt all 2 minuten die mails von gmx ab.
In der message log steht wie schon einmal gehabt der cyrus dberror.
Dieser Fehler trat das erste mal auf, während das Update via Apt lief.
danke vorab schon mal für eure hilfe
ich habe wieder das read time out problem auf dem lmtp *seufz
aber was habe ich eigentlich geändert?
mit apt-get wollte ich meinen server updaten. Allerdings gab es probleme mit dem paket kvirc.
ich denke mal kvirc ist wohl ein irc client, den ich nicht unbedingt brauche.
dann hat apt auch 17 pakete ersetzt (xfree, genau weiß ich es nicht mehr)
und apache2-prefork durch apache-worker ersetzt.
mein apache läuft jetzt zwar, aber der mailserver nicht mehr.
alle mails hängen bei postfix im queue
Status:
connect to /var/lib/imap/socket/lmtp[/var/lib/imap/socket/lmtp]: read timeout
ich versteh hier nix mehr, ehrlich gesagt. *seufz
vielleicht kann sich ja einer von euch zusammenreimen, was hier passiert ist.
an den postfix, cyrus conf hab ich nix geändert.
fetchmail läuft noch im daemon modus und holt all 2 minuten die mails von gmx ab.
In der message log steht wie schon einmal gehabt der cyrus dberror.
Dieser Fehler trat das erste mal auf, während das Update via Apt lief.
danke vorab schon mal für eure hilfe
hast du SUSEconfig ausgeführt ? und wenn ja, hoffentlich hast du den Schalter deaktiviert, das SUSE den postfix konfiguriert!! Sonst war alles für die Katz. Dieses SuSEconfig schraubt dann nämlich an deinen conf's rum.
Sieh mal nach *.rpmnew,*.rpmorig,*.rpmsave,*.YastSave,*.SuSEconfig Dateien im /etc und /etc/postfix Ordner.
ad apt:
Was für ein Problem (MELDUNG) hattest du?
Sieh mal nach *.rpmnew,*.rpmorig,*.rpmsave,*.YastSave,*.SuSEconfig Dateien im /etc und /etc/postfix Ordner.
ad apt:
Was für ein Problem (MELDUNG) hattest du?
OP
also ne meldung von apt gab es eigentlich nicht (bis auf das er kein update machen kann wegen kvirc). also habe ich kvirc gelöscht
dann ging das update.
wenn ich in der apt.log reinschaue und auch in die messages dann sehe ich, das der erste fehler von cyrus (dberror) in dem zeitraum aufgetreten ist, als das update lief. nicht am anfang und nicht am ende des updates sondern mittendrin. das update dauerte iemlich lange, weil es viele pakete waren, aber man kann sagen, daß so ziemlich mittig im update der erste fehler auftrat. am ende des updates führt apt doch auch suseconfig usw aus.
falls es so wäre wie du befürchtest (das suse die postfix konfiguration umgeändert hat) müßte dann der fehler nicht am ende des updates aufgetreten sein?
in /etc/postfix gibt es u.a. folgende dateien:
main.cf
main.cf.2004-07-08 (zu diesem zeitpunkt lief der mailserver noch)
main.cf.suseconfig
main.cf.default
main.cf.rpmnew
canonical.rpmnew
was macht dich so sicher, daß suse den postfix verorgelt hat?
in messages gibt es wieder diesen dberror von cyrus.
vielleicht stimmt beim cyrus was nicht. hmm. was aber wieder komisch ist:
mails vom client ins internet verschicken funzt.
das abholen via fetchmail bis in die postfix queue auch
also kann das doch gar nicht soooo schlimm sein was suse oder apt oder wer auch immer da angerichtet hat.
da fällt mir noch was ein, ich habe ja die conf dateien von cyrus postfix und fetchmail vorsichtshalber gesichtert. aber auch das zurückkopieren dieser dateien mit anschließendem reload/restart von cyrus und postfix hilft nicht weiter, der fehler bleibt.
dann ging das update.
wenn ich in der apt.log reinschaue und auch in die messages dann sehe ich, das der erste fehler von cyrus (dberror) in dem zeitraum aufgetreten ist, als das update lief. nicht am anfang und nicht am ende des updates sondern mittendrin. das update dauerte iemlich lange, weil es viele pakete waren, aber man kann sagen, daß so ziemlich mittig im update der erste fehler auftrat. am ende des updates führt apt doch auch suseconfig usw aus.
falls es so wäre wie du befürchtest (das suse die postfix konfiguration umgeändert hat) müßte dann der fehler nicht am ende des updates aufgetreten sein?
in /etc/postfix gibt es u.a. folgende dateien:
main.cf
main.cf.2004-07-08 (zu diesem zeitpunkt lief der mailserver noch)
main.cf.suseconfig
main.cf.default
main.cf.rpmnew
canonical.rpmnew
was macht dich so sicher, daß suse den postfix verorgelt hat?
in messages gibt es wieder diesen dberror von cyrus.
vielleicht stimmt beim cyrus was nicht. hmm. was aber wieder komisch ist:
mails vom client ins internet verschicken funzt.
das abholen via fetchmail bis in die postfix queue auch
also kann das doch gar nicht soooo schlimm sein was suse oder apt oder wer auch immer da angerichtet hat.
da fällt mir noch was ein, ich habe ja die conf dateien von cyrus postfix und fetchmail vorsichtshalber gesichtert. aber auch das zurückkopieren dieser dateien mit anschließendem reload/restart von cyrus und postfix hilft nicht weiter, der fehler bleibt.
SuSEconfig setzt Rechte von Dateien anhand von /etc/permissions*
SuSEconfig mach das was in /etc/sysconfig/* steht, wenn dort deine Einträge von postfix, fetchmail, etc standen werden die immer wieder eingesetzt. Wir haben aber nicht via Yast konfiguriert, sondern nach guter alter Linux-Methode direkt an den configs.
die main.cf-2004* ist die letzt funktionierende Konfig, die zurücksichern.
die rpmnew Dateien entstehen bei Neu-Installation eines rpm. Du solltest nach jedem update mal rcrpmconfigcheck aufrufen, das zeigt dir welche configs geändert wurden.
bei apt kannst du abstellen, das SuSEconfig aufgerufen wird, dann steuerst du das selber: /etc/apt/apt.conf.d/post.conf ist die Datei (Scripts::Options::RunPostScript false
ich tippe mal, das irgendwelche Rechte von SuSEconfig verbogen wurden.
Wenn du die Dateien ermittelt hast kannst du in /etc/permissions.local dafür sorgen, das diese Dateien DEINE Rechte erhalten (z.Bsp. cdrecord, cdrdao werden immer ohne SUID gesetzt,...)
Prüfe das nochmal.
mit sdiff -s alt neu kannst du die betroffenen configs ja mal checken.
das apt-update hat dir nicht neue db* Pakete installiert ?
SuSEconfig mach das was in /etc/sysconfig/* steht, wenn dort deine Einträge von postfix, fetchmail, etc standen werden die immer wieder eingesetzt. Wir haben aber nicht via Yast konfiguriert, sondern nach guter alter Linux-Methode direkt an den configs.
die main.cf-2004* ist die letzt funktionierende Konfig, die zurücksichern.
die rpmnew Dateien entstehen bei Neu-Installation eines rpm. Du solltest nach jedem update mal rcrpmconfigcheck aufrufen, das zeigt dir welche configs geändert wurden.
bei apt kannst du abstellen, das SuSEconfig aufgerufen wird, dann steuerst du das selber: /etc/apt/apt.conf.d/post.conf ist die Datei (Scripts::Options::RunPostScript false
ich tippe mal, das irgendwelche Rechte von SuSEconfig verbogen wurden.
Wenn du die Dateien ermittelt hast kannst du in /etc/permissions.local dafür sorgen, das diese Dateien DEINE Rechte erhalten (z.Bsp. cdrecord, cdrdao werden immer ohne SUID gesetzt,...)
Prüfe das nochmal.
mit sdiff -s alt neu kannst du die betroffenen configs ja mal checken.
das apt-update hat dir nicht neue db* Pakete installiert ?
zum besseren Verständnis deines email Servers:
incomming mail:
GMX --> fetchmail --> postfix --> cyrus --> email-Client
outgoing mail
email-Client --> postfix --> GMX
local mail
email-Client --> postfix --> cyrus --> email-Client
deshalb geht outgoing
Dein Problem ist die postfix --> cyrus Schnittstelle
incomming mail:
GMX --> fetchmail --> postfix --> cyrus --> email-Client
outgoing mail
email-Client --> postfix --> GMX
local mail
email-Client --> postfix --> cyrus --> email-Client
deshalb geht outgoing
Dein Problem ist die postfix --> cyrus Schnittstelle
OP
moin!
also saslauthd scheint zu laufen.
in der y2log.suseconfig steht unter anderem:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running in full featured mode.
Reading /etc/sysconfig and updating the system...
skipping modules
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
Finished.
postdrop: warning: unable to look up public/pickup: No such file or directory
weiter unten:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module postfix only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.postfix...
Rebuilding /etc/aliases.db.
No changes for /etc/postfix/master.cf
Setting up postfix local as MDA...
Setting SPAM protection to "off"...
No changes for /etc/postfix/main.cf
Finished.
und das hier:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module postfix only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.postfix...
No changes for /etc/postfix/master.cf
Setting up cyrus-imapd via lmtp as MDA...
[1m *** WARNING ***
adding postfix user to group mail
*** WARNING ***
[m Setting SPAM protection to "off"...
No changes for /etc/postfix/main.cf
Finished.
jetzt, wo du die permissions ansprichst fällt mir ein, daß er beim updaten rechte geändert hat.
zb:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module permissions only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.permissions...
Checking permissions and ownerships - using the permissions files
/etc/permissions.d/apache2
/etc/permissions.d/cups-client
/etc/permissions.d/kdebase3
/etc/permissions.d/kdelibs3
/etc/permissions.d/kpopup
/etc/permissions.d/mailman
/etc/permissions.d/postfix
/etc/permissions.d/squid
/etc/permissions.d/susehelp
/etc/permissions.d/tetex
/etc/permissions
/etc/permissions.easy
/etc/permissions.local
setting /var/lib/texmf/ to root:root 1755. (wrong permissions 0755)
setting /var/lib/texmf/db/ to root:root 1755. (wrong permissions 0755)
setting /var/adm/backup to root:root 0700. (wrong permissions 0755)
Finished.
ich glaube das waren noch mehr, aber ich weiß nicht in welche log er das geschrieben haben könnte.
in der /etc/permissions.local steht nichts drin
aber in /etc/permissions.d/postfix steht:
/usr/sbin/sendmail root.root 0755
/etc/postfix/sasl_passwd root.root 0600
/etc/postfix/sasl_passwd.db root.root 0600
/var/spool/postfix root.root 0755
/var/spool/postfix/active postfix.root 0700
/var/spool/postfix/bounce postfix.root 0700
/var/spool/postfix/corrupt postfix.root 0700
/var/spool/postfix/defer postfix.root 0700
/var/spool/postfix/deferred postfix.root 0700
/var/spool/postfix/flush postfix.root 0700
/var/spool/postfix/hold postfix.root 0700
/var/spool/postfix/incoming postfix.root 0700
/var/spool/postfix/private postfix.root 0700
/var/spool/postfix/maildrop postfix.maildrop 0730
/var/spool/postfix/public postfix.maildrop 0710
/var/spool/postfix/pid root.root 0755
/var/spool/postfix/saved postfix.root 0700
/var/spool/postfix/trace postfix.root 0700
/usr/sbin/postalias root.root 0755
/usr/sbin/postcat root.root 0755
/usr/sbin/postconf root.root 0755
/usr/sbin/postfix root.root 0755
/usr/sbin/postkick root.root 0755
/usr/sbin/postlock root.root 0755
/usr/sbin/postlog root.root 0755
/usr/sbin/postmap root.root 0755
/usr/sbin/postsuper root.root 0755
/usr/sbin/postdrop root.maildrop 2755
/usr/sbin/postqueue root.maildrop 2755
ist das so ok?
in der apt.conf habe ich suseconfig auf false gesetzt. frage mich nur warum es sowas gibt, wenn es anscheinend mehr schadet als nützt...
also saslauthd scheint zu laufen.
in der y2log.suseconfig steht unter anderem:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running in full featured mode.
Reading /etc/sysconfig and updating the system...
skipping modules
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
postdrop: warning: unable to look up public/pickup: No such file or directory
Finished.
postdrop: warning: unable to look up public/pickup: No such file or directory
weiter unten:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module postfix only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.postfix...
Rebuilding /etc/aliases.db.
No changes for /etc/postfix/master.cf
Setting up postfix local as MDA...
Setting SPAM protection to "off"...
No changes for /etc/postfix/main.cf
Finished.
und das hier:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module postfix only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.postfix...
No changes for /etc/postfix/master.cf
Setting up cyrus-imapd via lmtp as MDA...
[1m *** WARNING ***
adding postfix user to group mail
*** WARNING ***
[m Setting SPAM protection to "off"...
No changes for /etc/postfix/main.cf
Finished.
jetzt, wo du die permissions ansprichst fällt mir ein, daß er beim updaten rechte geändert hat.
zb:
Starting SuSEconfig, the SuSE Configuration Tool...
Running in verbose mode.
Running module permissions only
Reading /etc/sysconfig and updating the system...
Executing /sbin/conf.d/SuSEconfig.permissions...
Checking permissions and ownerships - using the permissions files
/etc/permissions.d/apache2
/etc/permissions.d/cups-client
/etc/permissions.d/kdebase3
/etc/permissions.d/kdelibs3
/etc/permissions.d/kpopup
/etc/permissions.d/mailman
/etc/permissions.d/postfix
/etc/permissions.d/squid
/etc/permissions.d/susehelp
/etc/permissions.d/tetex
/etc/permissions
/etc/permissions.easy
/etc/permissions.local
setting /var/lib/texmf/ to root:root 1755. (wrong permissions 0755)
setting /var/lib/texmf/db/ to root:root 1755. (wrong permissions 0755)
setting /var/adm/backup to root:root 0700. (wrong permissions 0755)
Finished.
ich glaube das waren noch mehr, aber ich weiß nicht in welche log er das geschrieben haben könnte.
in der /etc/permissions.local steht nichts drin
aber in /etc/permissions.d/postfix steht:
/usr/sbin/sendmail root.root 0755
/etc/postfix/sasl_passwd root.root 0600
/etc/postfix/sasl_passwd.db root.root 0600
/var/spool/postfix root.root 0755
/var/spool/postfix/active postfix.root 0700
/var/spool/postfix/bounce postfix.root 0700
/var/spool/postfix/corrupt postfix.root 0700
/var/spool/postfix/defer postfix.root 0700
/var/spool/postfix/deferred postfix.root 0700
/var/spool/postfix/flush postfix.root 0700
/var/spool/postfix/hold postfix.root 0700
/var/spool/postfix/incoming postfix.root 0700
/var/spool/postfix/private postfix.root 0700
/var/spool/postfix/maildrop postfix.maildrop 0730
/var/spool/postfix/public postfix.maildrop 0710
/var/spool/postfix/pid root.root 0755
/var/spool/postfix/saved postfix.root 0700
/var/spool/postfix/trace postfix.root 0700
/usr/sbin/postalias root.root 0755
/usr/sbin/postcat root.root 0755
/usr/sbin/postconf root.root 0755
/usr/sbin/postfix root.root 0755
/usr/sbin/postkick root.root 0755
/usr/sbin/postlock root.root 0755
/usr/sbin/postlog root.root 0755
/usr/sbin/postmap root.root 0755
/usr/sbin/postsuper root.root 0755
/usr/sbin/postdrop root.maildrop 2755
/usr/sbin/postqueue root.maildrop 2755
ist das so ok?
in der apt.conf habe ich suseconfig auf false gesetzt. frage mich nur warum es sowas gibt, wenn es anscheinend mehr schadet als nützt...
OP
ach nochwas:
mail_create_config war und ist deaktiviert, normalerweise dürfte suse doch dann an den postfix *.conf dateien nichts ändern, oder irre ich mich da?
mail_create_config war und ist deaktiviert, normalerweise dürfte suse doch dann an den postfix *.conf dateien nichts ändern, oder irre ich mich da?
ad yast:
wenn no_mail_config gesetzt ist, werden keine neuen postfix configs erzeugt, OK
ad apt:
nicht in apt.conf sondern in der psot.conf
bei einem kernel-update soll SuSEconfig laufen wegen mkinitrd und evtl lilo. Das ist sicherer.
ad permissions.local:
da schreibst du DEINE Rechte Änderungen rein. Diese datei wird immer am Schluss aufgerufen und überschreibt die Eingaben aus permissions.{easy,secure,paranoid}
Auf welchem Level dein System arbeitet wird in yast eingestellt. Du solltest secure wählen.
zu deinem Problem:
Setting up cyrus-imapd via lmtp as MDA...
da wurden cyrus configs geändert. Vielleicht wurde die Zeile mit dem prefork=1 geändert. Bzw. den Pfad zu dem lmtp.
Ich weiss jetzt nicht mehr ob dein mailserver mit deliver=cyrus oder via lmtp zuletzt funktioniert hat.
CYRUS.CONF PRÜFEN ...
Wenn du deinen Mailserver neu startest sind diese services erforderlich:
rcpostfix start
rcfetchmail start
rcsaslauthd start
rccyrus start
rcamavis start (falls du das nutzt)
die Meldungen von cyrus werden in /var/log/messages protokolliert
die Meldungen von postfix,fetchmail werden in /var/log/mail* protokolliert.
wenn no_mail_config gesetzt ist, werden keine neuen postfix configs erzeugt, OK
ad apt:
nicht in apt.conf sondern in der psot.conf
bei einem kernel-update soll SuSEconfig laufen wegen mkinitrd und evtl lilo. Das ist sicherer.
ad permissions.local:
da schreibst du DEINE Rechte Änderungen rein. Diese datei wird immer am Schluss aufgerufen und überschreibt die Eingaben aus permissions.{easy,secure,paranoid}
Auf welchem Level dein System arbeitet wird in yast eingestellt. Du solltest secure wählen.
zu deinem Problem:
Setting up cyrus-imapd via lmtp as MDA...
da wurden cyrus configs geändert. Vielleicht wurde die Zeile mit dem prefork=1 geändert. Bzw. den Pfad zu dem lmtp.
Ich weiss jetzt nicht mehr ob dein mailserver mit deliver=cyrus oder via lmtp zuletzt funktioniert hat.
CYRUS.CONF PRÜFEN ...
Wenn du deinen Mailserver neu startest sind diese services erforderlich:
rcpostfix start
rcfetchmail start
rcsaslauthd start
rccyrus start
rcamavis start (falls du das nutzt)
die Meldungen von cyrus werden in /var/log/messages protokolliert
die Meldungen von postfix,fetchmail werden in /var/log/mail* protokolliert.
OP
@ apt:
natürlich in der post.conf. hab ich ja auch so gemacht.
cyrus funktionierte via lmtp. deliver= cyrus könnte man aber später evtl auch probieren, wenn alle stricke reißen sollten. welches der beiden möglichkeiten hat denn vor bzw nachteile?
die permissions habe ich nun auf secure gestellt (war easy)
hier mal die cyrus.conf. der pfad zum lmtp war auch so eingestellt, als der mailserver lief (allerdings bin ich mir bei prefork=0 nicht sicher):
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd="ctl_cyrusdb -r"
# this is only necessary if using idled for IMAP IDLE
# idled cmd="idled"
}
# UNIX sockets start with a slash and are put into /var/lib/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd="imapd" listen="imap" prefork=0
# imaps cmd="imapd -s" listen="imaps" prefork=0
pop3 cmd="pop3d" listen="pop3" prefork=0
# pop3s cmd="pop3d -s" listen="pop3s" prefork=0
sieve cmd="timsieved" listen="sieve" prefork=0
# at least one LMTP is required for delivery
# lmtp cmd="lmtpd" listen="lmtp" prefork=0
lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=0
# this is only necessary if using notifications
# notify cmd="notifyd" listen="/var/lib/imap/socket/notify" proto="udp" prefork=1
}
EVENTS {
# this is required
checkpoint cmd="ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd="cyr_expire -E 3" at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd="tls_prune" at=0400
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL messages older then 30 days.
# enter 'man 8 ipurge' for more details
# cleanup cmd="ipurge -d 30 -f" period=60
}
natürlich in der post.conf. hab ich ja auch so gemacht.
cyrus funktionierte via lmtp. deliver= cyrus könnte man aber später evtl auch probieren, wenn alle stricke reißen sollten. welches der beiden möglichkeiten hat denn vor bzw nachteile?
die permissions habe ich nun auf secure gestellt (war easy)
hier mal die cyrus.conf. der pfad zum lmtp war auch so eingestellt, als der mailserver lief (allerdings bin ich mir bei prefork=0 nicht sicher):
# standard standalone server implementation
START {
# do not delete this entry!
recover cmd="ctl_cyrusdb -r"
# this is only necessary if using idled for IMAP IDLE
# idled cmd="idled"
}
# UNIX sockets start with a slash and are put into /var/lib/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd="imapd" listen="imap" prefork=0
# imaps cmd="imapd -s" listen="imaps" prefork=0
pop3 cmd="pop3d" listen="pop3" prefork=0
# pop3s cmd="pop3d -s" listen="pop3s" prefork=0
sieve cmd="timsieved" listen="sieve" prefork=0
# at least one LMTP is required for delivery
# lmtp cmd="lmtpd" listen="lmtp" prefork=0
lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=0
# this is only necessary if using notifications
# notify cmd="notifyd" listen="/var/lib/imap/socket/notify" proto="udp" prefork=1
}
EVENTS {
# this is required
checkpoint cmd="ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd="cyr_expire -E 3" at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd="tls_prune" at=0400
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL messages older then 30 days.
# enter 'man 8 ipurge' for more details
# cleanup cmd="ipurge -d 30 -f" period=60
}
- Status