Emails von fetchmail direkt ins Maildir?

stagger

stagger

LogWing
Hi,

ich habe fetchmail so eingerichtet, dass Emails von bestimmten Konten abgerufen und ihren Usern zugewiesen werden, die landen dann in /var/mail/<user>. Aber wie bekomme ich die statt in /var/mail/<user> in /home/<user>/Maildir? Ich lese hier seit Stunden irgendwelche Seiten zu und man-pages von fetchmail, procmail sowie fetchmail und komme einfach nicht weiter ;'( So schwer kann das nicht sein, aber anscheinend bin ich zu doof. Deshalb eine ganz simple Frage: Wie sag ich fetchmail ganz, ganz einfach, dass jede Nachricht in das Maildir-Verzeichnis des Users, zu dem das Konto gehört, geschoben werden soll?
 
Du könntest ne systemweite procmailrc machen (/etc/procmailrc), mit dem Inhalt
Code: 
MAILDIR=$HOME/Maildir/
DEFAULT=$HOME/Maildir/
Jetz müsstest Du nur noch dafür Sorge tragen, dass Dein MTA auch procmail aufruft.
Welchen MTA (Mailserver) benutzt Du? Sendmail? Postfix? ...?
Postfix kann auch ohne Weiteres direkt ins Maildir liefern.
 
Ich hab im Moment gar keinen MTA, das ist es ja! Vielleicht klappt es ja auch deshalb nicht, denn die procmailrc, die du oben beschrieben hast, hatte ich so schon mal. Kann natürlich auch sein, dass er die nicht gefunden hat, weil er in /etc/ statt /usr/local/etc nachgesehen hat. Weißt du denn, wie die Sache mit maildrop aussähe?
Ich wollte im Moment nur die Emails zugestellt bekommen, damit ich sie auf dem IMAP-Server liegen habe. Versenden kann ich nach wie vor über den GMX bzw. T-Online SMTP, das ist kein Problem.
 
Fetchmails stellt doch aber an und für sich über einen MTA zu?! Wenn Du FreeBSD hast, dann ist das standardmäßig sendmail. Der arbeitet aber mit der standard-config meines Wissens nach nicht mit procmail zusammen. Schau mal nach, ob sendmail läuft! :D
 
stagger schrieb:
Ich hab im Moment gar keinen MTA, das ist es ja! Vielleicht klappt es ja auch deshalb nicht, denn die procmailrc, die du oben beschrieben hast, hatte ich so schon mal. Kann natürlich auch sein, dass er die nicht gefunden hat, weil er in /etc/ statt /usr/local/etc nachgesehen hat. Weißt du denn, wie die Sache mit maildrop aussähe?
Ich wollte im Moment nur die Emails zugestellt bekommen, damit ich sie auf dem IMAP-Server liegen habe. Versenden kann ich nach wie vor über den GMX bzw. T-Online SMTP, das ist kein Problem.
Zum Vergrößern anklicken....

Mein privater Mailserver holt die Mails per fetchmail ab, übergibt diese an procmail und dann werden diese widerrum an maildrop übergeben (ohne MTA; ist in diesem Fall auch überflüssig).

fetchmail:
sollte alles klar sein:
mda "/usr/bin/procmail -d %T"

procmail:

MAILDIR=/$HOME/Maildir/
DEFAULT=$MAILDIR
SENDMAIL=/usr/bin/maildrop
SENDMAILFLAGS=-d

maildrop:
DEFAULT=$HOME/Maildir

Sollte funktionieren für das Abholen von Mail.
 
Äh... zwei kleine Fragen noch:
1. Ist es nicht Quatsch, procmail und maildrop zu benutzen? Machen die nicht beide das gleiche? Wäre es nicht besser, sofort an maildrop zu übergeben? Wenn ja, wie? ;)
2. Wo liegen die Dateien? Ich befürchte nämlich, die schon wieder dahin zu tun, wo sie nicht gefunden werden. Und zig mal umsonst symlinken wär Unsinn.
 
stagger schrieb:
Äh... zwei kleine Fragen noch:
1. Ist es nicht Quatsch, procmail und maildrop zu benutzen? Machen die nicht beide das gleiche? Wäre es nicht besser, sofort an maildrop zu übergeben? Wenn ja, wie? ;)
2. Wo liegen die Dateien? Ich befürchte nämlich, die schon wieder dahin zu tun, wo sie nicht gefunden werden. Und zig mal umsonst symlinken wär Unsinn.
Zum Vergrößern anklicken....
Ich habe diese "Schiene" gewählt da ich per procmail Filterregeln definiert hatte und procmail "immer" sämtliche mailboxen zerstört hat (ist schon einige Zeit her;vielleicht bug ....).

Die meisten (fast alle :) )Programme suchen unter /etc.
dazu:
/etc/maildroprc
/etc/procmailrc (gobale config)
/etc/fetchmailrc (kannst du Dir aussuchen;man ..)

zu fetchmail:
versuche gleich maildrop zu benutzen mit
mda "/usr/bin/maildrop -d %T"

maildroprc bedarf keiner weiteren Beachtung außer auskommentieren der Zeile:
DEFAULT=$HOME/Maildir

falls du etwas suchst (procmail ....) which $programm sagt es dir wo es sich versteckt sofern im pfad; wenn nicht im Pfad vergiss den verschiedenen tools nicht die pfade zu "sagen".

[EDIT] Du mußt Dich nicht am meine Pfade halten :)
mda "$pfad/maildrop -d %T"

Chris
 
Zuletzt bearbeitet:
Es kommt folgender Fehler:
Code: 
/usr/local/bin/maildrop: Cannot set my user or group id.
Nachforschungen im Netz haben mich fast ausschließlich zu Seiten geführt, die das Ganze in Verbindung mit Postfix und MySQL beschreiben. Super. Als ich MySQL von der Suche ausgeschlossen hatte, bin ich drauf gestoßen, dass das Setzen des SetUID-Bits Abhilfe schaffen könnte. Tut es auch, und die Mails landen im Maildir. obsduser, du bist mein Held. Ich liebe dich :) Wenigstens läuft es erstmal. Allerdings empfinde ich das gesetzte Bit irgendwie als bedrohlich. Gehts nicht auch ohne? Fällt jemandem was ein?
 
stagger schrieb:
Allerdings empfinde ich das gesetzte Bit irgendwie als bedrohlich. Gehts nicht auch ohne? Fällt jemandem was ein?
Zum Vergrößern anklicken....
maildrop muss die Identität jedes Benutzers annehmen können um in den Verzeichnissen der jeweiligen Benutzer die Post ablegen zu können. Welcher Systembenutzer hat das Recht das zu tun?

Gruß Björn
 
Zuletzt bearbeitet:
Code: 
Welcher Systembenutzer hat das Recht das zu tun?
Wenn fetchmail als root aufgerufen wird, als was dann maildrop?
 
Wie Björn schon gesagt hat, maildrop muss die Post in sämtliche Mailboxen verschieben können.
Wenn Du die Mails an einen MTA übergeben würdest wird der MTA auch als "root" seine Dienste verrichten müssen.

Wenn fetchmail als "root" aufgerufen (od. als daemon läuft, dies meiner einer auch vorzieht :) ) wurde, wird der Aufruf von maildrop auch als root erfolgen = kein setuid bit erforderlich.

Chris
 
Wenn fetchmail als "root" aufgerufen (od. als daemon läuft, dies meiner einer auch vorzieht ) wurde, wird der Aufruf von maildrop auch als root erfolgen = kein setuid bit erforderlich.
Zum Vergrößern anklicken....
Ja anscheinend doch! Ohne gehts ja nicht. Sollte es wirklich zu schwer sein, das zu glauben, kann ich ja mal die Konsolenausgabe posten.
 
Zuletzt bearbeitet:
Was denn nu? procmail oder maildrop? Ich verwende fetchmail+procmail, ist eigentlich ganz einfach und wurde hier ja schon ein paar mal erzaehlt. Eine .fetchmailrc in $HOME (wichtig: Mode 0700!) mit mda '/usr/local/bin/procmail -d %T' und dann ein eigene .procmailrc oder eine globale in /usr/local/etc/procmailrc (ist aber nicht so toll, weil du dann nicht user-spezifisch sortieren lassen kannst, eine eigene .procmailrc hat aber Vorrang vor der globalen). Bei mir sieht die im Prinzip so aus:
MAILDIR=$HOME/Maildir
DEFAULT=./

Plus sonstige Filterregeln halt. Zum testen ob alles klappt emfpiehlt sich das setzen von LOGFILE und VERBOSE=on
 
Was gegen procmail spricht, sind die kryptischeren Konfigurationsdateien und seine Ressourcenfresserei. Wenn eine 10MB-Mail kommt, lädt procmail die (soweit ich weiß) erstmal komplett in den Speicher. Maildrop regelt das geschickter.
 
Klingt nach FUD. Procmail recipies lesen sich eigentlich sehr einfach und es gibt spezielle Optionen, ob Header oder Body geprueft werden. Warum sollte man also den ganzen Body parsen, wenn die Regel nur auf den Header angewandt werden kann?

Dass procmail die komplette Mail lesen und wieder schreiben muss, sollte wohl auch klar sein. Wenn maildrop das nicht macht, dann wuerde es niemand verwenden (wer will schon halbe Mails)
 
Was heißt FUD? Alles ist einfach, wenn mans kann. Außerdem sage ich ja gar nicht, dass Maildrop nicht die ganze Mail liest, allerdings verwendet es mit seinen temporären Dateien eine andere Methode, die nicht so speicherhungrig ist. Ich lasse mich da natürlich gern vom Gegenteil überzeugen, z.B. mit einem Link auf eine Seite.
 
Das mit den temporären Dateien ist ein roter Hering. Wenn die Datei kurzlebig ist, dann landet die garnicht auf der Festplatte, sondern geht nur durch den Buffer Cache ... und da belegt sie dann eben auch 10MB.

Und sollte der Webserver wirklich stark belastet sein (10 Mails / Sekunde, oder Mails mit 10-20MB, (wer kriegt solche Mails eigentlich?)), dann packe ich lieber noch ein GB RAM mehr rein, als dass die Kiste erstmal alle Mails auf Platte schreibt, von Platte liest und wieder woanders auf die Platte schreibt ...

Aber egal, es soll jeder das Verwenden, was er will. Ich sehe fuer mich persoenlich in maildrop jedoch keinerlei Vorteile (bzw. kenne sie einfach nicht).
 
Mal die lowlevel Lösung:

.fetchmailrc:


poll mein.server
protocol pop3
username Trallalla
password blablabla
is martin here
fetchall
mda "cat >> meinedatei"

CU

Martin
 
Zuletzt bearbeitet:
MrFixit schrieb:
Wenn die Datei kurzlebig ist, dann landet die garnicht auf der Festplatte, sondern geht nur durch den Buffer Cache ... und da belegt sie dann eben auch 10MB.
Zum Vergrößern anklicken....
Das stimmt natürlich. Allerdings hab ich ein besseres Gefühl, wenn sich das Betriebssystem um den Speicherbedarf kümmert und notfalls weniger cachet, als dass es der MDA macht. Ist aber nur ne persönliche Vorliebe...

MrFixit schrieb:
(wer kriegt solche Mails eigentlich?))
Zum Vergrößern anklicken....
Zwar gibt es nur ab und zu Experten, die mir solche Monster schicken, aber es kommt vor. Und wenn procmail dann länger braucht, wird auch fetchmail erst später fertig. Um zu erklären, warum das für mich schlecht ist, muss ich etwas weiter ausholen. Fetchmail läuft bei mir als Cronjob und ruft alle 5 Minuten die Mails ab. Bis jetzt war es immer so, dass fetchmail, wenn es noch nicht fertig war bevor die neue Instanz gestartet wurde, komplett abgebrochen hat und alle Mails daraufhin erneut heruntergeladen wurden. Hat eine schöne Endlosschleife ergeben, die mir die Leitung einmal für 24h komplett belegt hat bis ich es gemerkt hab. Wie man das umgeht, möchte ich mal gerne wissen, das nervt nämlich. Kann man fetchmail bei Systemstart nicht als Dämon starten, ohne ein eigenes Startskript zu schreiben?

Dazu noch eine ganz allgemeine Frage: Wird beim Start alles in den rc.d-Verzeichnissen aufgerufen und es wird den Skripten überlassen, ob sie rc.conf nach einer gesetzen Variable durchforsten, die kontrolliert, ob der Dienst überhaupt laufen soll?

MrFixit schrieb:
dann packe ich lieber noch ein GB RAM mehr rein, als dass die Kiste erstmal alle Mails auf Platte schreibt, von Platte liest und wieder woanders auf die Platte schreibt ...
Zum Vergrößern anklicken....
Mach das. Ich habe das Geld nicht.
 
Öhm, wenn ich Dich richtig verstanden hab, hat fetchmail-Prozess 1 grade Mails abgeholt, dann wollte cron fetchmail-Prozess 2 starten und fetchmail-Prozess 1 wurde abgeschossen, ja?
Ist es aber nicht normalerweise so, dass fetchmail, wenn noch ein anderer fetchmail-Prozess rennt, abbricht mit der Meldung "another foreground fetchmail running at [pid]"?
Bissel OT, aber nur sone Frage...
 
stagger schrieb:
Das stimmt natürlich. Allerdings hab ich ein besseres Gefühl, wenn sich das Betriebssystem um den Speicherbedarf kümmert und notfalls weniger cachet, als dass es der MDA macht.
Zum Vergrößern anklicken....
Der Speicherbedarf ist in beiden Faellen quasi gleich. Die RAM-only Variante ist halt ueblicherweise schneller. Auf einem gut frequentierten Mailserver ist jede temp. Datei eine Suende :)

Fetchmail läuft bei mir als Cronjob und ruft alle 5 Minuten die Mails ab. Bis jetzt war es immer so, dass fetchmail, wenn es noch nicht fertig war bevor die neue Instanz gestartet wurde, komplett abgebrochen hat und alle Mails daraufhin erneut heruntergeladen wurden. Hat eine schöne Endlosschleife ergeben, die mir die Leitung einmal für 24h komplett belegt hat bis ich es gemerkt hab. Wie man das umgeht, möchte ich mal gerne wissen, das nervt nämlich.
Zum Vergrößern anklicken....
Zwei separat gestartete fetchmail-Prozesse (foreground) verhalten sich hier so:
Erster laeuft, zweiter meckert: fetchmail: another foreground fetchmail is running at 59454. Aber es ging hier ja um maildrop/procmail, nicht fetchmail. Wenn deine Leitung duenn ist, dann dauern 10MB halt mal zwei Minuten, daran aendert auch procmail/maildrop nichts. Zumal selbst eine 10MB Mail innerhalb von 4-5s von procmail/maildrop bearbeitet sein sollte.
Kann man fetchmail bei Systemstart nicht als Dämon starten, ohne ein eigenes Startskript zu schreiben?
Zum Vergrößern anklicken....
Siehe fetchmail(1), crontab(5).
Dazu noch eine ganz allgemeine Frage: Wird beim Start alles in den rc.d-Verzeichnissen aufgerufen und es wird den Skripten überlassen, ob sie rc.conf nach einer gesetzen Variable durchforsten, die kontrolliert, ob der Dienst überhaupt laufen soll?
Zum Vergrößern anklicken....
Schau dir die Skripte doch einfach mal an :)
rcNG Skripte lesen rc.conf ein, alte Skripte ueberlicherweise nicht, die wurden durch gesetztes x-Bit aktiviert (oder auch nicht).

Mach das. Ich habe das Geld nicht.
Zum Vergrößern anklicken....
Gnaa! Entweder du machst das privat, kriegts 2 Mails/Stunde und die Bearbeitungszeit von procmail/maildrop ist vernachlaessigbar. Oder du brauchst bessere procmail/maildrop Performanz, weil du 100 Mails/Minute kriegst, dann ist auch Geld fuer mehr Hardware da.
 
Zuletzt bearbeitet:
Nachdem fetchmail jetzt läuft, bin ich auf getmail gestoßen - *GNARR*

Hätte auch früher passieren können! Das braucht überhaupt keinen MDA und kann auch direkt filtern mit ClamAV, SpamAssassin oder sonstigem.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben