Knowledgebase » Linux » lokaler IMAP Server + fetchmail + procmail für POP3-Sammlung
| lokaler IMAP Server + fetchmail + procmail für POP3-Sammlung |
| |
| Autor : |
zander |
erstellt : |
02.06.2007, 01:38 Uhr |
| Kommentare : |
9 Kommentare lesen ( Kommentar abgeben ) |
letztes Update : |
05.06.2007, 13:36 Uhr |
| Bewertung : |
ein User bewertete diesen Beitrag mit 1 ( bewerten ) |
Views : |
4335 |
| Seiten: - [1] - |
[edit 04.06.2007: fetchmailrc und procmailrc erweitert]
[edit 05.06.2007: konfigurationshinweis für thunderbird]
Folgende Problemstellung:
ein email-account, der nur über pop3 zur verfügung gestellt wird. ich arbeite mit diesen emails jedoch zumindest von zwei geräten aus, was dazu führt, dass mails oft nicht an beiden geräten verfügbar sind, gesendete mails nur lokal gespeichert sind etc. --> nicht brauchbar zur arbeit.
lösungsansatz: im internen netzwerk wird ein imap-server installiert, der die mailordner den clients zur verfügung stellt. die mails werden via pop3 vom provider abgeholt und dem imap server zur verfügung gestellt.
verwendete software:
imap-server: dovecot, wiki-eintrag dazu
programm, welches mails vom pop3 holt: fetchmail, wiki-eintrag dazu
zwischen fetchmail und dovecot steht: procmail, wiki-eintrag dazu
nun möchte ich festhalten, dass ich eher mehr einen schnellen hack realisiert habe, der anscheinend funktioniert, aber sicher nicht ausgereift ist. im netz gibt es diverse quellen, ich habe mich da bedient. man könnte viel mehr mit dieser konfiguration anfangen (serverseitiges filtern,...). ich sehe xapient gerade milde lächeln.
1) einen user für den zweck der ganzen aktion angelegt
2) dovecot (oder anderen imap-server) installieren mit den distri-tools. ich muss zugeben, mein dovecot lief nach der installation gleich problemlos (mittels etc/init.d/dovecot start gestartet) und ich habe an den configs nicht geändert. spätestens jetzt runzelt xapient leicht besorgt die stirn.
3) fetchmail und procmail ebenfalls installieren
4) fetchmail-config schreiben. ich habe im home-verzeichnis des unter 1) angelegten users eine config-datei abgelegt: .fetchmailrc
1:
2:
3:
4:
5:
6:
| server mail.domain.tld
proto pop3
user username
password 1234
mda 'procmail -f-'
mda "/usr/bin/procmail -d %s" |
|
dieses stückchen soll also die mails mittels pop3 vom server holen und reicht sie dann zur weiterverarbeitung an procmail weiter. vielleicht sollte ich erwähnen, dass das die mails auch vom pop3 runterlöscht. man müsste irgendwo keep oder so dazuschreiben, damit sie bleiben.
edit: im dazugehörigen thread wurde gefragt, ob auch mehrere konten abgefragt werden können: natürlich ist das möglich. die aktuelle konfiguration frägt nun ein weiteres konto ab und übergibt diese so erhaltenen mails ebenfalls an procmail. der code oben wird einfach nur wiederholt, bloß die userdaten sind andere.
5) procmail-config. habe ich ebenfalls im home des users abgelegt: .procmailrc
1:
2:
3:
4:
5:
| LOGFILE=$HOME/procmail.log
VERBOSE=on
:0
var/spool/mail/username |
|
spätestens jetzt lacht xapient schallend. nun, mir scheint, dies ist die allerkleinste und allersinnloseste procmail-config. aber sie soll nur alle mails, die von fetchmail kommen, in das mailverzeichnis des users weiterleiten. wenn man googelt sieht man, was das ding eigentlich könnte. hier könnte ich mails filtern (gemäß to, subject, ...) und an unterschiedliche mailboxen leiten, in unterschiedliche ordner stecken, hier würde ein spamassasin (o.ä.) eingehängt etc etc. ... nichts von alle dem passiert hier. ich leite nur stupide weiter und noch dazu hab ich das mailverzeichnis hardgecodet. xapient ist soeben vom stuhl gefallen.
inzwischen gibt es eine leicht erweiterte konfiguration:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
| LOGFILE=$HOME/procmail.log
VERBOSE=on
:0 w
* ^Subject: Anmeldung$
/mailordner/DieserOrdner
:0 w
* ^X-Spam-Level: \*\*\*\*\*\*
/mailordner/Junk
:0
var/spool/mail/username |
|
zwei regeln sind vor der schon vorhandenen "lege alles in die inbox des users"-regel dazugekommen (procmail verwendet reguläre ausdrücke für die regelerstellung):
eine regel prüft auf ein bestimmtes subject ("Anmeldung" im beispiel oben) und legt mails mit diesem subject im mail-ordner "DieserOrdner" ab. in der dargestellten fassung werden nur mails erkannt, deren subject genau "Anmeldung" lautet. wenn man das dollar-sign hinten weglässt würde auch "Anmeldung verloren" erkannt werden, würde man zwischen "Subject:" und "Anmeldung" .* setzen, wäre auch "Wo ist meine Anmeldung" von der regel erfasst. aber dazu findet sich in diversen regex tutorials mehr.
die zweite regel soll junk aussortieren. da ja in der vorliegenden konfiguration die mails von einem pop3-server eines providers geholt werden und dieser provider die mails bereits mit spamassasin prüft, kann man auf eine lokale prüfung verzichten. der spamassasin des providers fügt in die mails eine header-zeile "X-Spam-Level" ein, gefolgt von einer anzahl von sternchen, welche die spam-wahrscheinlichkeit der mail angeben. in der obigen konfiguration werden mails mit sechs sternchen und mehr in den mailordner "Junk" gelegt.
eine weitere interessante regel ist "TO":
1:
| * ^TO.*ich@meinedomain\.com |
|
hier werden emails erfasst, die an die angegebene email adressiert sind. im gegensatz zur verwendung des headers "To: ich@..." prüft aber TO auch auf cc etc., wie aus dem procmaillog ersichtlich wird:
1:
| procmail: Match on "(^((Original-)?(Resent-)?(To|Cc|Bcc)|(X-Envelope|Apparently(-Resent)?)-To):(.*[^a-zA-Z])?).*ich@meinedomain\.com" |
|
Hinweis zur Terminologie: hier spreche ich von "ordnern", in denen die mails abgelegt werden. nachdem (s.o.) hier das mbox-format verwendet wird, sind diese "ordner" am server eigentlich files. nur in einem imap-client (thunderbird, webmail,...) werden diese files als ordner dargestellt. würde man maildir verwenden, wären es tatsächlich ordner am server mit den mails als einzelnen files darunter. dann müsste man in der procmailrc einen slash am ende der zielangabe setzen, damit es als maildir erkannt wird, bspw.:
/mailordner/Junk/
6) so, den mist kann man jetzt testen:
1:
| /usr/bin/fetchmail -f /pfad/.fetchmailrc -v |
|
-f damit er diese angegebene config verwendet, -v (verbose) damit man auch was sieht.
7) wenn das funktioniert, und wenn die mails auch tatsächlich dort landen wo sie sollten (im mailverzeichnis des users nämlich), dann ist gut. bei mir hat sich das system entschieden (xapient bekommt hysterischen anfall), das mbox-format zu verwenden, also ist wohl die inbox in einer riesigen file. der dovecot hat alle weiteren imap-ordner (sent, trash, und was man sonst noch erstellen will) dann an einem anderen ort abgelegt, warum auch immer, funktioniert aber. xapient überlegt sich zu erschießen. nun, was wollte ich sagen...ach, ja ob das denn auch funktioniert? also erstens, wenn der fetchmail command oben keine fehler ausspuckt, zweitens könnte man in das mbox-file schauen ob neue heruntergeladene mails angehängt wurden. oder natürlich man hat schon seit schritt 2 einen mua wie thunderbird laufen und ist mit dem eigenen imap-server verbunden. was nämlich sehr cool funktioniert hat. und das erfolgserlebnis wenn diese systembenachrichtigung "neue mail" kommt ist gleich viel schöner als so ne schnöde textfile. egal. xapient, durchhalten!!!
8. jetzt möchte man noch dass der fetchmail-procmail vorgang automatisch ablauft, also könnte man cron verwenden.
der neue user hat, wie crontab -l feststellt, wahrscheinlich noch keine eigene, also mit crontab /etc/crontab eine neue kopie der system-crontab erstellen und deren ende dann mit crontab -e zB so umschreiben:
1:
| */2 * * * * /usr/bin/fetchmail -s -f /pfad/.fetchmailrc |
|
in dieser konfiguration wird das alle 2 minuten aufgerufen (*/2) und zwar mit dem von oben leicht modifizierten befehl für fetchmail. das -v ist jetzt natürlich weg, dafür dazu ein -s für silent.
so und interessanterweise funktioniert das alles anscheinend. der holt sich alle zwei minuten brav die mails und haut sie in meine inbox, der imap-server bietet diese inbox wunderbar an, man kann am imap-server natürlich noch weitere ordner erstellen. und alle mails sind auf allen computern gleich vorhanden. ich bin sehr zufrieden. xapient wischt sich den schweiß von der stirn.
Konfigurationshinweis für Thunderbird:
In der vorliegenden konfiguration werden ja manche mails bereits direkt am server in verschiedene ordner geschickt. wenn man mozilla thunderbird als email-client (mua) verwendet, kann es passieren, dass thunderbird nur die "INBOX" des imap-servers auf neue nachrichten prüft und man somit von thunderbird nicht auf neue nachrichten in anderen ordnern des imap-servers hingewiesen wird. problemlösung:
Extras > Einstellungen > Erweitert > Allgemein > Konfiguration bearbeiten (about:config)
hier nach dem einstellungsnamen:
"mail.check_all_imap_folders_for_n ew" suchen und den zugehörigen wert auf "true" ändern.
ja, mir ist klar, dass man ein how-to nicht so schreibt. weder von der qualität noch vom stil her. nur...ja, egal.
vielleicht kann man mehr aus dieser basis-konfiguration machen. also sicher kann man; will man auch???
nein, im ernst, ich würd mich über kritik, hinweise, kommentare oder erweiterungen sehr freuen!
so nochn paar links für die, die sich wirklich dafür interessieren:
steveyoung.wordpress.com
www.linuxforen.de
www.debian-administration.org
www.schiessle.org
www.linux-club.de
blog.enkelmann.net
:-) |
| Seiten: - [1] - |
| |
|
|
|
