Mailstation als Zentrale Sammelstelle einrichten

[jahlives]

@Heatseeker
Irgendwie scheint getmail den -l Parameter heute zu akzeptieren Wieso auch immer aber ich habe die Emails jetzt 3 fach im Postfach. Sooft wie ich getmail manuell aufgerufen habe.
Und nachdem ich statt -l wieder -d verwendet habe wurden die Emails nach dem folgenden getmail-Lauf vom Server gelöscht.

 

[Heatseeker]

Ähhh moment -d löschen? Ich habe doch in meiner .sh Datei den aufruf von getmail mit -q und -d !!! Dann löscht der vielleicht deshalb!!!
Gleich mal testen. Machnmal sieht man ja den Wald vor lauter Bäumen nicht...

 

[Heatseeker]

Ahhh, ich Idiot!

Natürlich klappts damit. Habe nicht damit gerechnet, das getmail die Option "nicht löschen" zweimal gegeben werden sollte. Bzw. im Wiki wird "löschen" zweimal übergeben. Einmal in der Conig datei und dann nachher nochmal im script.
Naja, nun komm ich erstmal weiter! Danke für deine Hilfe!

 

[itari]

Ahhh, ich Idiot!

Natürlich klappts damit. Habe nicht damit gerechnet, das getmail die Option "nicht löschen" zweimal gegeben werden sollte. Bzw. im Wiki wird "löschen" zweimal übergeben. Einmal in der Conig datei und dann nachher nochmal im script.
Naja, nun komm ich erstmal weiter! Danke für deine Hilfe!

Wenn da was im Wiki zu verbessern wäre, dann bitte tu es. Niemand ist besser in der Materie, als der, der es gerade ausprobiert.

Itari

PS. Jeder kann, darf und sollte das Wiki pflegen

 

[Heatseeker]

Okay, dann werd ich das mal probieren. Aber weist du ob man einfach den Parameter -l oder -d weglassen kann wenns eh in der Config steht?

Dann kann ich auch gleich noch korrigieren, dass ab und zu "home" statt "homes" steht ;-)

So, ist geändert und mit einem Kommentar versehen.

 

[Heatseeker]

So nun klappt auch cron (mails werden in der tat abgholt), nur wundere ich mich, das ich keine /var/log/dovecot-info.log Datei habe. Ist das normal?

 

[jahlives]

So nun klappt auch cron (mails werden in der tat abgholt), nur wundere ich mich, das ich keine /var/log/dovecot-info.log Datei habe. Ist das normal?

Wieso eine dovecot-info.log? Afaik wird getmail die Emails nach dem Spamfiltern direkt in die Mailboxen stellen. Da wird Dovecot eigentlich nicht involviert. Man kann zwar Dovecot auch in diesen Prozess einbringen, was dann aber voraussetzt, dass du dir deliver aus den Dovecot Source selber kompilierst. deliver ist bei der Syno Firmware afaik noch nicht mitdabei.
Wo hast du denn eine dovecot-info.log definiert?

 

[Heatseeker]

Tja, ich habe nur das gemacht was im Wiki unter "Automatisieren mit Cron" steht. Dort steht nach den Dateirechten gefummel: "Anschließend kann mit /opt/etc/init.d/S10cron der cron daemon neu gestartet werden. Damit sollten alle Arbeiten abgeschlossen sein und der Mail-Server laufen. Ob alles geklappt hat, kann man sehen, wenn in /var/log/dovecot-info.log Zeilen mit "deliver(Hans):" auftauchen."

Deshalb bin ich einfach mal blind davon ausgegangen. Die restlichen Sachen mit -x test,... klappen auch nicht wirklich. Vermutlich passt da im Wiki etwas nicht zusammen. Aber es funktioniert jetzt ja.

 

[jahlives]

Deshalb bin ich einfach mal blind davon ausgegangen. Die restlichen Sachen mit -x test,... klappen auch nicht wirklich. Vermutlich passt da im Wiki etwas nicht zusammen. Aber es funktioniert jetzt ja.

Wenn das mit -x test nicht klappt dann hast du entweder nicht den ipkg cron installiert oder du versuchst -x test während der cron noch läuft, was nicht geht.

 

[Heatseeker]

So, nachdem ich versucht habe die mails automatisch sortieren zu lassen und das doch etwas viel arbeit wird wollte ich nun wieder zurück zu meiner alten konfiguration. Nun klappt die leider auch nicht mehr!
meine rc-file sieht so aus:

[retriever]
type = SimpleIMAPSSLRetriever
server = imap.strato.de
port = 993
username = XXX
password = XXX
mailboxes = (XXX)

[destination]
type = Maildir
path = ~/.Maildir/
user = Henning
filemode = 0600

[options]
delete = false
read_all = false
message_log = ~/.getmail/log

[filter-spamassassin]
type = Filter_external
path = /opt/bin/spamc
allow_root_commands = true

.rc gehört dem gehört Henning:users
Wenn ich nun als root oder auch als Henning versuche mails abholen zu lassen mit:

/opt/bin/getmail -q -l --rcfile /volume1/homes/Henning/.getmail/mailsynoIMAP.rc

bekomme ich die Fehlermeldung:

Error: Default config/data dir "/root/.getmail/" does not exist - create or specify alternate directory with --getmaildir option

Kann wer was damit anfangen?
Grüße
Heatseeker

 

[asheiner]

Dann probier's doch mal so

/opt/bin/getmail -q -l --getmaildir /volume1/homes/Henning/.getmail/ --rcfile mailsynoIMAP.rc

 

[Heatseeker]

Moin,
dann bekomm ich dies hier:

Exception exceptions.AttributeError: "'logfile' object has no attribute 'file'" in <bound method logfile.__del__ of <getmailcore.utilities.logfile object at 0x4070b54c>> ignored
Configuration error: configuration file /volume1/homes/Henning/.getmail/mailsynoIMAP.rc incorrect (error opening message_log file ~/.getmail/log (No such file or directory, opening file "~/.getmail/log"))

Das .rc file müsste jedoch korrekt sein, das lief vorher auch.

 

[asheiner]

wenn du als root das rs File vom User Henning aufrufst würde ich im rc-File die Pfadangaben so machen, da ~ ja auf das Home des ausführendn Users zeigt.

[destination]
path = ~Henning/.Maildir/

[options]
message_log = ~Henning/.getmail/log

 

[Heatseeker]

Die Fehlermeldungen kommen auch wenn ich als Henning drin bin. Früher wurde das ja auch per cron aufgerufen und dann auch als User Henning

EDIT: Änderung hats aber auch nicht gebracht, sorry.

 

[xabano]

bekomme ich die Fehlermeldung:

Error: Default config/data dir "/root/.getmail/" does not exist - create or specify alternate directory with --getmaildir option

Kann wer was damit anfangen?

Gemäss dieser Fehlermeldung dürfte es sich um ein Berechtigungsproblem handeln. Wie meldest du dich denn als Henning an? Ich hatte bei mir schon festgestellt, dass ich genau diesen Fehler erhalte, wenn ich mich als User anmelde.
Wenn ich mich aber als root anmelde, anschliessend den Benutzer mit su ändere und das Skript aufrufe läuft es korrekt.

 

[Heatseeker]

Da ich auch schon solche Probleme hatte, versuch ich immer beides. Einmal als root und einmal als User. Der Fehler tritt bei beiden Accounts auf.

 

[xabano]

Im File /opt/bin/getmail ist das Default-getmail-Verzeichnis wie folgt konfiguriert:

defaults = {
    'getmaildir' : '~/.getmail/',

Die DS verhält sich mit dem ~ Zeichen nicht immer gleich.

Beispiel 1:

Über ssh als root anmelden
cd /
su user
whoami gibt 'user' zurück
cd ~
=> man befindet sich im Homeverzeichnis von user

Beispiel 2

über ssh als user anmelden
cd /
whoami gibt 'user' zurück
cd ~
=> man befindet sich im Homeverzeichnis von root

Ich weiss nicht ob das generell bei Linux so ist. Aber das erklärt das Verhalten von getmail.

 

[jahlives]

über ssh als user anmelden
cd /
whoami gibt 'user' zurück
cd ~
=> man befindet sich im Homeverzeichnis von root

Ich weiss nicht ob das generell bei Linux so ist. Aber das erklärt das Verhalten von getmail.

Das ist ein Bug auf der DS. Es wird jeder User mittels ~ nach /root gemappt und das sollte nicht so sein. Habe das an Synology gemeldet.
Zur Not einfach absolute Pfade in den rc Files verwenden und alles sollte klappen

path = ~Henning/.Maildir/

Dieser Pfad wird wohl kaum auf der DS gefunden auch auf einem Linux wohl kaum. Auf die DS bezogen würde dein Pfad so ausschauen

/root/Henning/.Maildir

und wenn dieser Pfad so existieren würde, dann hättest du ein ziemliches Problem. Denn in /root darf dein User keinesfalls Lese/Schreibrechte haben

 

[Trolli]

Ich würde die Nachrichten gerne in den anderen Konten stehen lassen. Wenn ich das richtig verstehe, sollte doch die Option

delete_dup_msgids = true

dafür sorgen, dass die bereits vorhandenen Mails nicht nochmal eingelesen werden. Getmail schreibt sich ja auch für jedes Konto eine eigene oldmail-Datei in sein Verzeichnis. Darüber soll ja wahrscheinlich dieser Abgleich stattfinden. Funktioniert aber nicht. Die Nachrichten werden jedes Mal neu eingelesen. Gibt es da einen Trick?

 

[asheiner]

Also bei mir funktioniert die ~ so wie ich das erwarte.

DS209> cd /
DS209> whoami
root
DS209> cd ~Andreas
DS209> pwd
/var/services/homes/Andreas
DS209> uname -a
Linux DS209 2.6.24 #1157 Mon Apr 19 21:32:42 CST 2010 armv5tejl unknown
DS209>

Als user Andreas ist zwar das Mapping anders aber das Ergebnis ist trotzdem das erwartete.

DS209> cd /
DS209> whoami
Andreas
DS209> cd ~
DS209> pwd
/volume1/homes/Andreas
DS209> ls -l /var/services/homes /volume1/homes
lrwxrwxrwx    1 root     root           14 Apr 22 17:35 /var/services/homes -> /volume1/homes

Also wird bei meiner DS209 (V2.3) ~ nicht nach /root gemapped.


@Trolli:
Die Funktionalität, die du haben willst erreicht du über diese Optionen:

[options]
delete = false
delete_after = 30
read_all = false