Sieve und Getmail

cokotech

Member
Hallo Ihr!

Ich habe ein kleines Problem (ISPConfig3, dovecot).
Ich möchte das der Autoresponder auch für per fetchmail (getmail) geholte Mails gilt. Das geht aber nicht, weil sieve anscheinend den return-path auswertet, welcher aber durch getmail belegt wird.
Kann ich getmail dazu bringen als return-path den Absender einzusetzen oder aber dovecot/sieve dazu, das er "from" statt "return" auswertet?


Code:
 dovecot: deliver([EMAIL="test@meinedomain.de"]test@meinedomain.de[/EMAIL]): sieve: msgid=<[EMAIL="014a01cd4c88$20bf8ce0$623ea6a0$@dieanderedomain.de"]014a01cd4c88$20bf8ce0$623ea6a0$@dieanderedomain.de[/EMAIL]>: discarded duplicate vacation response to <[EMAIL="getmail@hoberg-reiche.de"]getmail@[COLOR=#0066cc]meinedomain.de[/COLOR][/EMAIL]>

Die zweite Frage wäre, ob es in dieser Kombination (ISPConfig3, Dovecot) möglich ist Sieve über einen Port zu erreichen, um es z.B. mittels Thunderbird plugin zu konfigurieren.


Vielen Dank im Vorraus und viele Grüße

Sven
 

cokotech

Member
Hmmmm ich antworte mir mal selbst:


Ich habe jetzt die Konfigdatei von getmail und anschliessend dann die (um es für die Zukunft zu übernehmen) /usr/local/ispconfig/server/conf/getmail.conf.master wie folgt geändert:

Code:
[options]
# message_log = /var/log/getmail.log
message_log_syslog = 1
delete = {DELETE}
read_all = {READ_ALL}
[retriever]
type = {TYPE}
server = {SERVER}
username = {USERNAME}
password = {PASSWORD}
[destination]
type = MDA_external
path = /usr/sbin/sendmail
arguments = ("-f", "%(sender)", "-i", "-bm", "[EMAIL="test@meinedomain.de"]test@meinedomain.de[/EMAIL]")
unixfrom = true

So funktioniert es anscheinend.
Spricht da etwas dagegen?


Viele Grüße Sven
 

cokotech

Member
Falls sich jemand dafür interessiert, es muss wohl

arguments = ("-f", "%(sender)", "-i", "-bm", "{DESTINATION}")

heissen. Also in der Master... sonst geht jede Mail an die eine Adresse ;-)




Viele Grüße Sven
 

tafkaz

Member
Vielen Dank!
Du hast mir den Tag gerettet!
Hatte genau das gleiche Problem...Keine Lösung wiet und breit...nur hier!

Danke
Sascha
 

asmodii

New Member
Nach vielen Stunden Quälerei habe ich "aufgegeben" das mit Getmail hinzubekommen. Die oben aufgezeigte Lösung funktioniert nicht. Das Problem ist, dass Getmail seine Absendeadresse in "return-path" schreibt. Fetchmail macht das nicht. Hat aber den Nachteil, dass man es händisch einrichten muss.

Falls jemand die Lösung zu Getmail kennt, dann bitte ich um die (Er)lösung. :)
 

Strontium

Member
Nach einem
ispconfig_update.sh --force
sind die Änderungen in der getmail.conf.master wieder weg.

Ich verwende die Getmail-Funktion nicht mehr weil die Passwörter im Klartext gespeichert sind.
 
Zuletzt bearbeitet:

Till

Administrator
Sie müssen im Klartext gespeichert sein da getmail sie sonst nicht verwenden könnte. Du musst getmail das Passwort im Klartext übergeben, damit es sich an einem anderen server anmelden kann. Gehashte Passworte kann man da nicht verwenden.
 

Till

Administrator
Also ich rede hier von one way hashes, denn alles andere ist ja auch weiterhin ein Klartext Passwort. Also Passworte wie bei z.B. SSH Usern oder IMAP Konten in ISPConfig die mittels crpyt und Salt verschlüsselt sind. Zeig mir bitte mal wie Du einen one way hash in Getmail verwendest, also ich lege das Passwort mit crypt verschlüsselt und Salt in der DB ab, wie soll Getmail das nutzen können und wie soll sich Getmail ohne Klartext Passwort an einem anderen IMAP oder POP3 Server anmelden? Für jedes Emailprogramm (und Getmail ist ein Emailprogramm) das sich als Client an einem anderen system anmeldet muss das Klartext Passwort vorliegen.
 

Till

Administrator
Und verstehe mich bitte nicht falsch, ich verstehe schon was Du meinst dass man das Passwort mit 2-Wege Verschlüsselung verschlüsseln könnte und das werden wir sicher auch mal in Zukunft machen. Nur ändert das an der Sicherheit sehr wenig, denn derzeit haben Zugriff auf das Klartext Passwort die User root, ispconfig und getmail. Wenn man es 2-Wege verschlüsselt haben weiterhin Zugriff auf das Klartext Passwort die User root, ispconfig und getmail, es ändert sich also nichts. Das einzige Szenario in dem ein 2-Wege verschlüsseltes Passwort hilfreich wäre ist wenn der Systemadministrator manuell ein Backup der DB zieht und dieses Backup nicht sicher verwahrt. Nur würde das selbe Problem auch bei veschlüsseltem Passwort auftreten, wenn er das DB Backup zusammen mit einem System Backup aufbewahrt oder aber das Systembackup selbst nicht sicher verwahrt, denn dort stehen in /etc/getmail/ ja auch die Klartext Passworte Andererseits werden sich mit 2-Wege verschlüsselten Passworten einige User bei Umzügen wundern warum nichts mehr geht wenn sie die Schüssel nicht sorgfältig umgezogen haben und dadurch Ihr Backup unbrauchbar wird. Hat also alles seine Vor- und Nachteile. Aber wie gesagt steht 2-Wege Verschlüsselung auf der ToDo Liste, nur für die Sicherheit des laufenden Servers bringt es nur marginal etwas da prinzipbedingt Klartext-Passworte notwendig sind.
 

Strontium

Member
denn dort stehen in /etc/getmail/ ja auch die Klartext Passworte
Nicht wenn man den Python Keyring verwendet.

Code:
zgrep -1 "Python keyring" /usr/share/doc/getmail6/configuration.txt.gz

To store your POP/IMAP account password into the Python keyring, ensure the password is not provided in the getmailrc file, and run getmail with the special option --store-password-in-keyring
 

Till

Administrator
Das ändert aber nichts an der Verfügbarkeit des Passwortes im Klartext und der Notwendigkeit dafür. Auch der Keyring erlaubt jederzeit den Zugriff auf das Klartext Passwort durch den Nutzer getmail und root. Du speicherst das Passwort dann halt in einem anderen File, reversibel verschlüsselt und nicht per one-way hash. Und das Passwort müsste trotzdem in der ISPConfig DB stehen damit es vom master zum slave sever transportiert wedren kann und auch bei einem serverumzug nicht verloren geht.
 

Werbung

Top