Verstaendnisfrage sendmail fetchmail procmail
Moin Moin! Ich versuche gerade zum ersten Mal ein Linuxsystem zu installieren, mit dem ich so alles machen kann, das ich bis jetzt unter Windows getan habe. Jetzt habe ich noch so einige Fragen zum Thema eMail: Ich bin mir noch nicht so sicher, was für einen eMail-Client ich nehmen soll. Ich werde wohl einige ausprobieren. Jetzt kann man bei einem Client wie kmail ja pop3s abrufen wie mit einem Win-eMial-Client auch. Ich kann das Abholen, Verschicken, in Ordner sortieren aber auch von send-, fetch-., und procmail machen lassen. Dann könnte ich verschiedene Clients testen/verwenden, die alle auf den gleichen Datenbestand zugreifen, oder? Oder gilt das nur für neue eMails, die dann unter /var/spool/main oder so liegen und jeder client hat dann so sein eigenes Archiv? Oder kommen hier diese mboxes in Spiel, von denen man immer mal wieder in anderen Threads was liest? Also Ihr seht sicher schon, mir ist klar, was die einzelnen Programme machen, aber wie paßt das Zusammenspiel. Sendmail soll so ein Konfigurationshorror sein. Da gibt es sicher auch Alternativen. Oder sind die dann nix? Kann ich mit sendmail denn auch mit verschiedenen Absenderadressen/smtp-Servern umgehen? Oder brauch ich dann mehrere User? Es wäre toll, wenn mir jemand etwas Klarheit verschaffen könnte! Gruß & Danke Thilo
Am Die, 19 Mär 2002 schrieb Thilo A. Coblenzer:
Moin Moin! Ich versuche gerade zum ersten Mal ein Linuxsystem zu installieren, mit dem ich so alles machen kann, das ich bis jetzt unter Windows getan habe. Jetzt habe ich noch so einige Fragen zum Thema eMail:
Ich bin mir noch nicht so sicher, was für einen eMail-Client ich nehmen soll. Ich werde wohl einige ausprobieren. Jetzt kann man bei einem Client wie kmail ja pop3s abrufen wie mit einem Win-eMial-Client auch. Ich kann das Abholen, Verschicken, in Ordner sortieren aber auch von send-, fetch-., und procmail machen lassen. Dann könnte ich verschiedene Clients testen/verwenden, die alle auf den gleichen Datenbestand zugreifen, oder?
Geht im Prinzip mit kmail auch, kmail speichert Deine Mais in mbox-Dateien unter ~/Mail. da können andere MUAs dann auch draufzugreifen. Der Vorteil bei einem Programm wie fetchmail ist erstens, daß es keine eierlegende Wollmilchsau ist wie kmail, sondern genau auf das Mailabrufen spezialisiert ist, das kann es dann sehr gut, andererseits bist Du vom verwendeten MUA absolut unabhängig, d.h. Du konfigurierst fetchmail/procmail und brauchst Dich um das Mailabrufen nicht zu kümmern, egal welchen MUA Du verwendest. Außerdem ist procmail im Bereich Mailfilterung ungleich mächtiger als die in einem MUA wie kmail eingebauten Filterfunktionen.
Oder gilt das nur für neue eMails, die dann unter /var/spool/main oder so liegen und jeder client hat dann so sein eigenes Archiv?
Nein, die meisten benutzen ~/Mail und mbox als Format, es gibt allerdings auch andere Formate (MH wird z.B. AFAIK von Sylpheed benutzt, mutt kann alle gängigen)
Oder kommen hier diese mboxes in Spiel, von denen man immer mal wieder in anderen Threads was liest?
s.o.
Also Ihr seht sicher schon, mir ist klar, was die einzelnen Programme machen, aber wie paßt das Zusammenspiel.
Ich würde fetchmail/procmail/sendmail vorziehen aber Du machst Dir nichts kaputt, wenn Du Deine Mails erst mal mit dem in Kmail eingebauten POP3 abrufst.
Sendmail soll so ein Konfigurationshorror sein. Da gibt es sicher auch Alternativen. Oder sind die dann nix? Kann ich mit sendmail denn auch mit verschiedenen Absenderadressen/smtp-Servern umgehen? Oder brauch ich dann mehrere User?
Ich finde eine Standardsendmailkonfiguration ohne riesige Tricks eigentlich überhaupt nicht schwierig, kannst Du sogar mit yast machen. Außerdem mal die sendmail.iga im Netz suchen und durchlesen. Aber es gibt natürlich jede Menge Alternativen, psotfix z.B. oder qmail. Für Deinen Anwendungszweck (mehrere Absenderadressen/SMTPs) würde ich Dir zu masqmail raten, das darauf spezialisiert ist. Mit sendmail ist das doch eher ein Krampf (es sei denn, Du findest ein Relay, der nach Authentifizierung beliebige Absenderadressen zulässt, wie smtprelay.t-online.de für T-Online-Kunden). Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin, From: "Christoph Maurer" Tuesday, March 19, 2002 11:01 AM
Am Die, 19 Mär 2002 schrieb Thilo A. Coblenzer: [...] Für Deinen Anwendungszweck (mehrere Absenderadressen/SMTPs) würde ich Dir zu masqmail raten, das darauf spezialisiert ist. Mit sendmail ist das doch eher ein Krampf (es sei denn, Du findest ein Relay, der nach Authentifizierung beliebige Absenderadressen zulässt, wie smtprelay.t-online.de für T-Online-Kunden). vielen Dank für die schnelle Erklärung. Ist masqmail dann ein sendmail-Ersatz? Oder eine Ergänzung?
An das Relay habe ich auch schon gedacht. Ich wäre aber lieber Providerunabhängig, da ich mich mit meinem Notebook ja nicht immer über T-Online einwähle. Gruß & Danke Thilo
Moin,
* Thilo A. Coblenzer
vielen Dank für die schnelle Erklärung. Ist masqmail dann ein sendmail-Ersatz? Oder eine Ergänzung? Ein Ersatz, der als besondere Fähigkeit gut mit meherern Smart Hosts umgehen kann. (Sagt man so, ich kenne ihn nicht.)
An das Relay habe ich auch schon gedacht. Ich wäre aber lieber Providerunabhängig, da ich mich mit meinem Notebook ja nicht immer über T-Online einwähle. An dem Smart Host von T-Online kannst Du Dich wohl auch aus anderen Netzen anmelden. Irgendeinen Smart Host solltest Du jedenfalls haben, bei Dialup-Verbindungen ist sonst die Gefahr zu groß, daß Deine Mails nicht transportiert werden (Spamschutz).
Thorsten -- Whenever there is a conflict between human rights and property rights, human rights must prevail. - Abraham Lincoln
Moin, From: "Thorsten Haude" Tuesday, March 19, 2002 11:50 AM
* Thilo A. Coblenzer
[02-03-19 11:10]: vielen Dank für die schnelle Erklärung. Ist masqmail dann ein sendmail-Ersatz? Oder eine Ergänzung? Ein Ersatz, der als besondere Fähigkeit gut mit meherern Smart Hosts umgehen kann. (Sagt man so, ich kenne ihn nicht.)
Ich denke, es ist and der Zeit, zu sagen, was ich genau brauche/machen will: Also das ganze soll auf einem Notebook installiert werden. D.h. ich wechsele ab und an mal das Netz: zu Hause und an der Uni bin ich über meine WLAN-Karte online. Sonst verwende ich (hoffentlich in Zukunft) das interne Modem. D.h. wenn ich offline bin sollen keine Mails gesendet/empfangen werde. Wenn das Modem sich einwählt, sollen ersteinmal gesendet/empfangen werden. Und imWLAN soll dies in einem gewissen Intervall geschehen. Da sehe ich allerdings nicht so das Problem. Man könnte die Config-Dateien ja per Skript ändern - falls das überhaupt nötig ist. Wie reagiert denn z.B. fetch-/sendmail wenn ich offline bin?. Sonst sollen pro User (da gibt es ja fast nur mich) mehrere POP3-Fächer abgeholt werden und dann etwas in Ordner sortiert werden. Dann wären noch ein paar einfache Filterregeln zum Spamschutz gut. Ich benötige aber auch verschiedene Absenderadressen, zu denen es natürlich jeweils einen SMTP-Server gib. Und das soll natürlich alles aus allen Netzen gehen. Wie gesagt, ein Relay fände ich nicht so gut. Welches Programm eignet sich denn jetzt dafür am besten und ist vielleicht auch noch einfach zu konfigurieren? Gruß & Danke Thilo
Hallo, at Tue, 19 Mar 2002 12:01:06 +0100 Thilo A. Coblenzer wrote:
Welches Programm eignet sich denn jetzt dafür am besten und ist vielleicht auch noch einfach zu konfigurieren?
Wenn es nur um eMail geht würde ich Sylpheed installieren. Denn das hat alles was Du brauchst. Ich würde die claws Version empfehlen, da dort die Filterfunktionen am besten sind. Zu beziehen unter http://sylpheed-claws.sourceforge.net/. Gruß Michael -- Homepage http://macbyte.info/ | Registered Linux User #228306 Phone/Fax +49 7000 MACBYTE | http://counter.li.org GNU GPG-Key ID 22C51B8D0140F88B | ICQ #151172379 ++ Webdesign + Don't send HTML-Mails + PHP Development ++
at Tue, 19 Mar 2002 12:01:06 +0100 Thilo A. Coblenzer wrote:
Welches Programm eignet sich denn jetzt dafür am besten und ist vielleicht auch noch einfach zu konfigurieren?
Wenn es nur um eMail geht würde ich Sylpheed installieren. Denn das hat alles was Du brauchst. Ich würde die claws Version empfehlen, da dort die Filterfunktionen am besten sind. Zu beziehen unter http://sylpheed-claws.sourceforge.net/. danke für die Antwort. Das habe ich vielleicht vergessen auch nocht zu quoten. Ich habe mich inzwischen für Demönen (also so was wie sendmail,
Moin, From: "Michael Raab" Tuesday, March 19, 2002 12:15 PM potfix, fetchmail ...) entschieden, da ich dann immer mal den Mailclient wechselen kann. Bzw. einige parallel verwenden kann. Gruß & Danke Thilo
Am Die, 19 Mär 2002 schrieb Thilo A. Coblenzer:
Moin, From: "Thorsten Haude" Tuesday, March 19, 2002 11:50 AM
* Thilo A. Coblenzer
[02-03-19 11:10]: vielen Dank für die schnelle Erklärung. Ist masqmail dann ein sendmail-Ersatz? Oder eine Ergänzung? Ein Ersatz, der als besondere Fähigkeit gut mit meherern Smart Hosts umgehen kann. (Sagt man so, ich kenne ihn nicht.)
Ich denke, es ist and der Zeit, zu sagen, was ich genau brauche/machen will: Also das ganze soll auf einem Notebook installiert werden. D.h. ich wechsele ab und an mal das Netz: zu Hause und an der Uni bin ich über meine WLAN-Karte online. Sonst verwende ich (hoffentlich in Zukunft) das interne Modem. D.h. wenn ich offline bin sollen keine Mails gesendet/empfangen werde. Wenn
Per Definitionem erfüllt.
das Modem sich einwählt, sollen ersteinmal gesendet/empfangen werden. Und
zu realisieren in /etc/ppp/ip-up.local
imWLAN soll dies in einem gewissen Intervall geschehen.
cron-Aufruf von fetchmail, bzw. sendmail -q
Da sehe ich allerdings nicht so das Problem. Man könnte die Config-Dateien ja per Skript ändern - falls das überhaupt nötig ist. Wie reagiert denn
Geht sicher.
z.B. fetch-/sendmail wenn ich offline bin?.
Sendmail kannst Du so einstellen, daß er die Mails erstmal in ne Warteschlange steckt, und auf Anforderung versendet. fetchmail wird eine Fehlermeldung generieren, die Du dann aber vernachlässigen kannst.
Sonst sollen pro User (da gibt es ja fast nur mich) mehrere POP3-Fächer abgeholt werden und dann etwas in Ordner sortiert werden. Dann wären noch ein paar einfache Filterregeln zum Spamschutz gut.
Ich verwende SPAMBLOCK mit Procmail: http://www.belwue.de/wwwservices/hilfestellungen/spamblock.html
Ich benötige aber auch verschiedene Absenderadressen, zu denen es natürlich jeweils einen SMTP-Server gib. Und das soll natürlich alles aus allen Netzen gehen. Wie gesagt, ein Relay fände ich nicht so gut.
Deshalb Masqmail.
Welches Programm eignet sich denn jetzt dafür am besten und ist vielleicht auch noch einfach zu konfigurieren?
Masqmail ist AFAIK einfach zu konfigurieren (habe mir irgendwann mal die Konfig-Dateien angeschaut, sah nicht besonders kompliziert aus), procmail ist nach Lektüre der entsprechenden Manpages auch nicht weiter schwierig, fetchmail ist fast trivial, solange es um einfache pop3-Aufrufe geht, außerdem gibt es dafür auch ein spezielles Konfigprogramm, das ich allerdings noch nie genutzt habe. Und MUA wählst Du nach Gefallen... Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin,
* Christoph Maurer
Am Die, 19 Mär 2002 schrieb Thilo A. Coblenzer:
imWLAN soll dies in einem gewissen Intervall geschehen. cron-Aufruf von fetchmail, bzw. sendmail -q Huh? 'fetchmail --daemon' würde ich sagen, besser noch eine Konfigurationsdatei.
z.B. fetch-/sendmail wenn ich offline bin?. Sendmail kannst Du so einstellen, daß er die Mails erstmal in ne Warteschlange steckt, und auf Anforderung versendet. fetchmail wird eine Fehlermeldung generieren, die Du dann aber vernachlässigen kannst. Tja, aber warum auf Fehler warten, wenn man die doch mit den Skripten wie oben besprochen vermeiden kann?
procmail ist nach Lektüre der entsprechenden Manpages auch nicht weiter schwierig Ich verstehe nicht, warum so viele Leute die Frage nach einem LDA reflexartig mit Procmail beantworten. Die Konfiguration von Procmail ist *grauenhaft*, allenfalls die sendmail.cf kann da noch mithalten.
Klar kann man das lernen, man kann auch Befunge oder INTERCAL lernen. Die Frage ist nur, ob der Aufwand in irgendeinem Verhältnis zum Nutzen steht. Die Konfigurationsdatei von Maildrop schreibt sich fast von alleine, und Procmails Leistungsfähigkeit ist ein Bruchteil von der von Mail::Audit. (Hehe, da paßt die Sig ja ganz gut.) Thorsten -- Im übrigen gilt ja hier derjenige, der auf den Schmutz hinweist, für viel gefährlicher als der, der den Schmutz macht. - Kurt Tucholsky
Am Die, 19 Mär 2002 schrieb Thorsten Haude:
* Christoph Maurer
[02-03-19 12:45]: Am Die, 19 Mär 2002 schrieb Thilo A. Coblenzer:
imWLAN soll dies in einem gewissen Intervall geschehen. cron-Aufruf von fetchmail, bzw. sendmail -q Huh? 'fetchmail --daemon' würde ich sagen, besser noch eine Konfigurationsdatei.
Kommt drauf an, verwende zwar auch fetchmail -d, hat aber auch seine Nachteile, wenn z.B. der Strato-Server mal wieder für ne Stunde Ärger macht, sagt fetchmail im Daemon-Mode "too many timeouts" und ruft nicht mehr von diesem POP ab, bis man fetchmail neu aufruft, deswegen kann ein cron-Aufruf durchaus sinnvoller sein.
z.B. fetch-/sendmail wenn ich offline bin?. Sendmail kannst Du so einstellen, daß er die Mails erstmal in ne Warteschlange steckt, und auf Anforderung versendet. fetchmail wird eine Fehlermeldung generieren, die Du dann aber vernachlässigen kannst. Tja, aber warum auf Fehler warten, wenn man die doch mit den Skripten wie oben besprochen vermeiden kann?
Wenn's geht, ist ja gut, wenn nicht, auch nicht tragisch.
procmail ist nach Lektüre der entsprechenden Manpages auch nicht weiter schwierig Ich verstehe nicht, warum so viele Leute die Frage nach einem LDA reflexartig mit Procmail beantworten. Die Konfiguration von Procmail ist *grauenhaft*, allenfalls die sendmail.cf kann da noch mithalten.
Du scheinst mir eine Procmail-Phobie zu haben, was ist an Procmail grauenhaft? Wer Regular-Expressions kann und die Manpage gelesen hat, kann Procmail im Nu bedienen.
Klar kann man das lernen, man kann auch Befunge oder INTERCAL lernen.
Was ist das?
Die Frage ist nur, ob der Aufwand in irgendeinem Verhältnis zum Nutzen steht. Die Konfigurationsdatei von Maildrop schreibt sich fast von alleine, und Procmails Leistungsfähigkeit ist ein Bruchteil von der von Mail::Audit.
Hat Maildrop dann auch ein Sprachinterface, ich erzähle im kurz worum es geht, und er generiert automatisch eine Konfigurationsdatei? :) Im Ernst, jede Konfigurationsdatei will geschrieben werden, und wer die Procmail-Syntax einmal verstanden hat (was schnell passiert ist, auch wenn Du Dich dagegen sperrst), der ist auch schnell mit der Konfiguration fertig. Zu Mail::Audit Dafür ist Procmail schneller, es erfüllt die Anforderungen, die ich an einen MDA habe, geradezu perfekt. Wollte noch nie etwas mit Procmail machen, was nicht ging.
(Hehe, da paßt die Sig ja ganz gut.) Die ich deshalb zitiere: Im übrigen gilt ja hier derjenige, der auf den Schmutz hinweist, für viel gefährlicher als der, der den Schmutz macht.
Ich wehre mich entschieden dagegen, daß Procmail Schmutz ist, bzw. daß ich gefährlich bin, weil ich auf Procmail hinweise. Maildrop ist sicher nicht schlecht, Mail::Audit hat seine Vorzüge, aber auch Procmail: Warum wehrst Du Dich so vehement dagegen, warum dieser missionarische Eifer? Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin, * Christoph Maurer[02-03-19 13:32]: >Am Die, 19 Mär 2002 schrieb Thorsten Haude: >> * Christoph Maurer [02-03-19 12:45]: >> >Am Die, 19 Mär 2002 schrieb Thilo A. Coblenzer: >> >> imWLAN soll dies in einem gewissen Intervall geschehen. >> >cron-Aufruf von fetchmail, bzw. sendmail -q >> Huh? 'fetchmail --daemon' würde ich sagen, besser noch eine >> Konfigurationsdatei. >Kommt drauf an, verwende zwar auch fetchmail -d, hat aber auch seine >Nachteile, wenn z.B. der Strato-Server mal wieder für ne Stunde >Ärger macht, sagt fetchmail im Daemon-Mode "too many timeouts" und >ruft nicht mehr von diesem POP ab, bis man fetchmail neu aufruft, >deswegen kann ein cron-Aufruf durchaus sinnvoller sein. Stimmt, das habe ich ab und an bei einem bestimmten Server auch mal. >> >procmail ist nach Lektüre der entsprechenden Manpages auch nicht >> >weiter schwierig >> Ich verstehe nicht, warum so viele Leute die Frage nach einem LDA >> reflexartig mit Procmail beantworten. Die Konfiguration von Procmail >> ist *grauenhaft*, allenfalls die sendmail.cf kann da noch mithalten. >Du scheinst mir eine Procmail-Phobie zu haben, was ist an Procmail >grauenhaft? Wer Regular-Expressions kann und die Manpage gelesen >hat, kann Procmail im Nu bedienen. Du solltest nicht von Dir auf andere schließen. Ich bin sicher, daß die meisten Menschen diese äh.. nennen wir es mal 'Syntax', nicht ansatzweise verstehen können. >> Klar kann man das lernen, man kann auch Befunge oder INTERCAL lernen. >Was ist das? Programmiersprachen. Hier mal ein Quine in Befunge: - - - Schnipp - - - :0g,:34*`#@_1+ - - - Schnapp - - - Zumindest der Anfang erinnert stark an Procmail. >> Die Frage ist nur, ob der Aufwand in irgendeinem Verhältnis zum Nutzen >> steht. Die Konfigurationsdatei von Maildrop schreibt sich fast von >> alleine, und Procmails Leistungsfähigkeit ist ein Bruchteil von der >> von Mail::Audit. >Im Ernst, jede Konfigurationsdatei will geschrieben werden, und wer >die Procmail-Syntax einmal verstanden hat (was schnell passiert ist, >auch wenn Du Dich dagegen sperrst), der ist auch schnell mit der >Konfiguration fertig. Ich sperre mich nicht dagegen, ich habe Procmail jahrelang benutzt. Ich weiß also, wovon ich spreche. >Zu Mail::Audit >Dafür ist Procmail schneller, es erfüllt die Anforderungen, die ich an >einen MDA habe, geradezu perfekt. Wollte noch nie etwas mit Procmail >machen, was nicht ging. Gehen tut alles, klar. Was aber geht mit Maildrop nicht? >> (Hehe, da paßt die Sig ja ganz gut.) >Die ich deshalb zitiere: >> Im übrigen gilt ja hier derjenige, der auf den Schmutz hinweist, >> für viel gefährlicher als der, der den Schmutz macht. >Ich wehre mich entschieden dagegen, daß Procmail Schmutz ist, >bzw. daß ich gefährlich bin, weil ich auf Procmail hinweise. Ist ja gut, so ernst war das nun auch nicht gemeint. (Oha, diesmal weise ich lieber nicht auf die Sig hin.) >Maildrop ist sicher nicht schlecht, Mail::Audit hat seine Vorzüge, >aber auch Procmail: Warum wehrst Du Dich so vehement dagegen, warum >dieser missionarische Eifer? Mich stört nur, daß jedem Neuling gleich Procmail empfohlen wird, ohne daß man darüber nachdenkt, durch wieviele Reifen man gedanklich springen muß, um Procmail etwas klarzumachen. Siehe andere Mail für Beispiele. Thorsten -- Unterschätze nie die Macht dummer Leute, die einer Meinung sind. - Kurt Tucholsky
* Thorsten Haude schrieb am 19.Mär.2002:
* Christoph Maurer
[02-03-19 13:32]: Am Die, 19 Mär 2002 schrieb Thorsten Haude:
Ich verstehe nicht, warum so viele Leute die Frage nach einem LDA reflexartig mit Procmail beantworten. Die Konfiguration von Procmail ist *grauenhaft*, allenfalls die sendmail.cf kann da noch mithalten.
Du scheinst mir eine Procmail-Phobie zu haben, was ist an Procmail grauenhaft? Wer Regular-Expressions kann und die Manpage gelesen hat, kann Procmail im Nu bedienen.
Du solltest nicht von Dir auf andere schließen. Ich bin sicher, daß die meisten Menschen diese äh.. nennen wir es mal 'Syntax', nicht ansatzweise verstehen können.
Hä? Wo ist das Problem? Ich sehe keins. Ganz im Gegensatz zu sendmail.cf Bernd
Moin,
* Thilo A. Coblenzer
Ich denke, es ist and der Zeit, zu sagen, was ich genau brauche/machen will: Ne, das ist entschieden zu spät.
Also das ganze soll auf einem Notebook installiert werden. D.h. ich wechsele ab und an mal das Netz: zu Hause und an der Uni bin ich über meine WLAN-Karte online. Sonst verwende ich (hoffentlich in Zukunft) das interne Modem. Ist die WLAN-Karte immer aktiv oder gibt es für (De-)Aktivierung ein Skript oder etwas Ähnliches?
D.h. wenn ich offline bin sollen keine Mails gesendet/empfangen werde. Wenn das Modem sich einwählt, sollen ersteinmal gesendet/empfangen werden. Und imWLAN soll dies in einem gewissen Intervall geschehen. Wenn es so ein Skript gibt, ist das kein Problem.
Wie reagiert denn z.B. fetch-/sendmail wenn ich offline bin?. Darauf würde ich es nicht ankommen lassen.
Sonst sollen pro User (da gibt es ja fast nur mich) mehrere POP3-Fächer abgeholt werden und dann etwas in Ordner sortiert werden. Dann wären noch ein paar einfache Filterregeln zum Spamschutz gut. Fetchmail und Maildrop.
Ich benötige aber auch verschiedene Absenderadressen, zu denen es natürlich jeweils einen SMTP-Server gib. Und das soll natürlich alles aus allen Netzen gehen. Wie gesagt, ein Relay fände ich nicht so gut. Wird sich nicht vermeiden lassen, wenn Du sichergehen willst, daß Deine Mails ankommen.
Welches Programm eignet sich denn jetzt dafür am besten und ist vielleicht auch noch einfach zu konfigurieren? Ein Programm, das alles kann, gibt es nicht. Ansonsten hast Du schon Empfehlungen gehört.
Thorsten -- When a thing has been said and said well, have no scruple. Take it and copy it. - Anatole France
Am Die, 19 Mär 2002 schrieb Thorsten Haude:
* Thilo A. Coblenzer
[02-03-19 11:10]: An das Relay habe ich auch schon gedacht. Ich wäre aber lieber Providerunabhängig, da ich mich mit meinem Notebook ja nicht immer über T-Online einwähle. An dem Smart Host von T-Online kannst Du Dich wohl auch aus anderen Netzen anmelden. Irgendeinen Smart Host solltest Du jedenfalls haben, bei Dialup-Verbindungen ist sonst die Gefahr zu groß, daß Deine Mails nicht transportiert werden (Spamschutz).
Am smtprelay nicht, und das ist der einzige, der beliebige Absenderadressen zulässt. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Am Die, 19 Mär 2002 schrieb Thilo A. Coblenzer:
Moin, From: "Christoph Maurer" Tuesday, March 19, 2002 11:01 AM
Am Die, 19 Mär 2002 schrieb Thilo A. Coblenzer: [...] Für Deinen Anwendungszweck (mehrere Absenderadressen/SMTPs) würde ich Dir zu masqmail raten, das darauf spezialisiert ist. Mit sendmail ist das doch eher ein Krampf (es sei denn, Du findest ein Relay, der nach Authentifizierung beliebige Absenderadressen zulässt, wie smtprelay.t-online.de für T-Online-Kunden). vielen Dank für die schnelle Erklärung. Ist masqmail dann ein sendmail-Ersatz? Oder eine Ergänzung?
Ein Ersatz, habe ihn selbst noch nicht eingesetzt, soll aber für solche Fälle wie Deinen :) genau das richtige sein.
An das Relay habe ich auch schon gedacht. Ich wäre aber lieber Providerunabhängig, da ich mich mit meinem Notebook ja nicht immer über T-Online einwähle.
Dann ist sicher masqmail die bessere Lösung. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin,
* Thilo A. Coblenzer
Ich bin mir noch nicht so sicher, was für einen eMail-Client ich nehmen soll. Ich werde wohl einige ausprobieren. Jetzt kann man bei einem Client wie kmail ja pop3s abrufen wie mit einem Win-eMial-Client auch. Ich kann das Abholen, Verschicken, in Ordner sortieren aber auch von send-, fetch-., und procmail machen lassen. Dann könnte ich verschiedene Clients testen/verwenden, die alle auf den gleichen Datenbestand zugreifen, oder? Richtig, es gibt höchstens kleine Schönheitsfehler, weil einige der Programme Indexdateien anlegen, das kann man aber auch wegbekommen. Der Vorteil ist eben der, den Du nennst, Du kannst Dein Programm frei wählen oder auch parallel benutzen.
Oder kommen hier diese mboxes in Spiel, von denen man immer mal wieder in anderen Threads was liest? Das ist halt das Format, in dem die Mails gespeichert werden, nicht viel mehr als eine Textdatei, in der alle Mails hintereinander drinstehen. Das versteht praktisch jeder MUA, außerdem gibt andere nützliche Tools, allen voran grepmail.
Sendmail soll so ein Konfigurationshorror sein. Da gibt es sicher auch Alternativen. Oder sind die dann nix? Kann ich mit sendmail denn auch mit verschiedenen Absenderadressen/smtp-Servern umgehen? Oder brauch ich dann mehrere User? Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random, ebenso wie die Konfigurationsdatei von Procmail. Ich empfehle Dir, Postfix bzw. Maildrop einzusetzen, die sind deutlich einfacher zu meistern. (Wenn Du Perl kannst oder einen Grund haben willst, es schnell zu lernen, empfehle ich Mail::Audit.)
Es wäre toll, wenn mir jemand etwas Klarheit verschaffen könnte! Ich habe mal versucht, den Ablauf darzustellen, ich würde mich freuen, wenn Du Verbesserungsvorschläge hättest. (http://www.vranx.de/mail/) Länger und besser ist das im aktuellen Linuxmagazin beschreiben.
Thorsten -- Die Zensur ist das lebendige Geständnis der Großen, daß sie nur verdummte Sklaven aber keine freien Völker regieren können. - Johann Nepomuk Nestroy
Am Die, 19 Mär 2002 schrieb Thorsten Haude:
* Thilo A. Coblenzer
[02-03-19 10:47]: Sendmail soll so ein Konfigurationshorror sein. Da gibt es sicher auch Alternativen. Oder sind die dann nix? Kann ich mit sendmail denn auch mit verschiedenen Absenderadressen/smtp-Servern umgehen? Oder brauch ich dann mehrere User? Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random,
Einspruch: D.Haller hat vor kurzem mal genauer beschrieben, was darin steht, so unverständlich ist das gar nicht. Allerdings soll ja auch niemand (oder fast niemand) sendmail.cf direkt editieren, m4 ist schon erfunden...
ebenso wie die Konfigurationsdatei von Procmail. Ich empfehle Dir, Postfix bzw. Maildrop einzusetzen, die sind deutlich einfacher zu meistern.
Was an Procmail unverständlich ist (wenn man einmal die Syntax begriffen und man procmailex gelesen hat), bleibt mir schleierhaft, aber die Diskussion hatten wir schonmal IIRC :)
(Wenn Du Perl kannst oder einen Grund haben willst, es schnell zu lernen, empfehle ich Mail::Audit.)
Ist aber dann mehr ein Selbstzweck. -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin, * Christoph Maurer[02-03-19 12:37]: >Am Die, 19 Mär 2002 schrieb Thorsten Haude: >> * Thilo A. Coblenzer [02-03-19 10:47]: >> >Sendmail soll so ein Konfigurationshorror sein. Da gibt es sicher auch >> >Alternativen. Oder sind die dann nix? Kann ich mit sendmail denn auch mit >> >verschiedenen Absenderadressen/smtp-Servern umgehen? Oder brauch ich dann >> >mehrere User? >> Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random, >Einspruch: D.Haller hat vor kurzem mal genauer beschrieben, was >darin steht, so unverständlich ist das gar nicht. In /dev/random? >Allerdings soll ja auch niemand (oder fast niemand) sendmail.cf >direkt editieren, m4 ist schon erfunden... Verstehe, die sendmail.cf ist also doch so verständlich, daß man sie besser überhaupt nicht ansieht. In Postfix' main.cf kann ich lesen wie in einem Buch. >> ebenso wie die Konfigurationsdatei von Procmail. Ich empfehle Dir, >> Postfix bzw. Maildrop einzusetzen, die sind deutlich einfacher zu >> meistern. >Was an Procmail unverständlich ist (wenn man einmal die Syntax >begriffen und man procmailex gelesen hat), bleibt mir schleierhaft, >aber die Diskussion hatten wir schonmal IIRC :) Klar, wenn man einmal die Syntax begriffen hat, ist es kinderleicht. Maildrop Procmail file lock flock n/a dotlock dotlock : if if * Zielbox to AND && cc cc c Externer Filter xfilter f Ich könnte noch eine Weile so weiter machen. >> (Wenn Du Perl kannst oder einen Grund haben willst, es schnell zu >> lernen, empfehle ich Mail::Audit.) >Ist aber dann mehr ein Selbstzweck. Huh? Ich kann meine Filter so kompliziert schreiben, wie ich nur will, in einer Sprache, die eigens für die Manipulation von Texten erschaffen worden ist. Das sehe ich als Vorteil. Dabei sind die Filter durch die Kontrollstrukturen oft einfacher als bei Procmail (Maildrop hat ebenfalls Kontrollstrukturen), meine Filter für Mailinglisten besteht zB. aus einem Hash und - - - Schnipp - - - foreach(list) foreach(address) if (address in list) accept(maildir/ML/list) - - - Schnapp - - - (In address befinden sich alle Empfänger der Mail.) Der einzige Nachteil ist die Geschwindigkeit. Thorsten -- Nobody will ever need more than 640 kB RAM. -- Bill Gates, 1983 Windows XP requires 64 MB RAM. -- Bill Gates, 2001 Nobody will ever need Windows XP. -- logical conclusion
Moin,
* Thorsten Haude
Am Die, 19 Mär 2002 schrieb Thorsten Haude:
* Thorsten Haude
[02-03-19 13:56]: [Kaputte Tabelle] Mit Crosspoint wär' das nicht passiert
Okay, ist ein Problem des Editors, meinem vim wäre das auch nicht passiert, da ich set expandtab in meiner .vimrc stehen habe. Geht sicher auch mit nedit. Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Moin,
* Christoph Maurer
* Thorsten Haude
[02-03-19 13:56]: [Kaputte Tabelle] Mit Crosspoint wär' das nicht passiert Okay, ist ein Problem des Editors, meinem vim wäre das auch nicht Am Die, 19 Mär 2002 schrieb Thorsten Haude: passiert, da ich set expandtab in meiner .vimrc stehen habe.
Geht sicher auch mit nedit. Klar geht das, aber da muß ich es eben erst entsprechend umstellen.
Thorsten -- The fact that windows is one of the most popular ways to operate a computer means that evolution has made a general fuckup and our race is doomed.
Hallo, On Tue, 19 Mar 2002, Thorsten Haude wrote:
* Christoph Maurer
[02-03-19 12:37]: Am Die, 19 Mär 2002 schrieb Thorsten Haude:
Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random, Einspruch: D.Haller hat vor kurzem mal genauer beschrieben, was darin steht, so unverständlich ist das gar nicht. In /dev/random?
Thorsten, bitte mach keine solche Vergleiche, wenn du meine Mails damals nicht gelesen hast und offenbar weder Ahnung von der sendmail.cf, noch der Konfigurationsmoeglichkeit ueber die m4-Makros, noch bereit bist darueber was zu lesen oder gar zu lernen.
Allerdings soll ja auch niemand (oder fast niemand) sendmail.cf direkt editieren, m4 ist schon erfunden... Verstehe, die sendmail.cf ist also doch so verständlich, daß man sie besser überhaupt nicht ansieht.
Tja. Ich editiere die .cf direkt, allerdings weil ich die m4- Makrodatei verschlampt habe. Und ich habe keine Probleme damit.
In Postfix' main.cf kann ich lesen wie in einem Buch.
Dito in der makro-Datei (meist /etc/mail/linux.mc) und auch die .cf ist gut lesbar, wenn man die Bedeutung von ein paar Buchstaben am Zeilenanfang kennt (O = Option, D = define variable etc.). D{mydomain} foo.tld definiert schlicht die Variable $mydomain auf den Wert foo.tld. Sendmail mag aber kurze Variablen, daher wird in der .cf die Variable M verwendet. (DMfoo.tld). Was daran schwieriger als ein mydomain = foo.tld in postfix' main.cf ist, musst du mir mal erklaeren (Mach dir aber erst die Bedeutung des '=' klar... Und dann die Bedeutung des 'D' bei sendmail).
Was an Procmail unverständlich ist (wenn man einmal die Syntax begriffen und man procmailex gelesen hat), bleibt mir schleierhaft, aber die Diskussion hatten wir schonmal IIRC :) Klar, wenn man einmal die Syntax begriffen hat, ist es kinderleicht.
Und die Syntax ist ebenfalls kinderleicht.
:0 [flags] [ : [locallockfile] ]
Maildrop Procmail file lock flock n/a dotlock dotlock :
Procmail kann dotlock. S.o. die Syntax.
if if * Zielbox to <nil>
Aktionline:= Name der Zielbox z.B: :0 * foo Zielbox
AND && <nil>
Weitere Zeile mit *
cc cc c Externer Filter xfilter f
Ich könnte noch eine Weile so weiter machen.
Und noch weiter zeigen, dass du procmail nicht kennst?
Huh? Ich kann meine Filter so kompliziert schreiben, wie ich nur will, in einer Sprache, die eigens für die Manipulation von Texten erschaffen worden ist. Das sehe ich als Vorteil.
Das kannst du auch mit procmail. Und zur Not kannst du ja in ein perlscript pipen.
Dabei sind die Filter durch die Kontrollstrukturen oft einfacher als bei Procmail (Maildrop hat ebenfalls Kontrollstrukturen), meine Filter für Mailinglisten besteht zB. aus einem Hash und - - - Schnipp - - - foreach(list) foreach(address) if (address in list) accept(maildir/ML/list) - - - Schnapp - - - (In address befinden sich alle Empfänger der Mail.)
Ok, das ist bequem ;) Hm. Sowas aehnliches muesste mit procmail auch gehen.
Der einzige Nachteil ist die Geschwindigkeit.
Und der ist bei vielen Mails doch deutlich. -dnh -- Und das tut doch jeder Editor: Cursor oben. Dann gehe ich das Posting von oben nach unten durch, lösche, antworte. Ist doch normal, oder? Nur: WARUM BEGREIFEN DAS MANCHE NICHT UND SCHREIBEN IHREN MÜLL GLEICH AN DEN ANFANG? *keuch* *lufthol* *keuch* [Thomas Klix in dag°]
Moin,
* David Haller
On Tue, 19 Mar 2002, Thorsten Haude wrote:
* Christoph Maurer
[02-03-19 12:37]: Am Die, 19 Mär 2002 schrieb Thorsten Haude:
Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random, Einspruch: D.Haller hat vor kurzem mal genauer beschrieben, was darin steht, so unverständlich ist das gar nicht. In /dev/random? Thorsten, bitte mach keine solche Vergleiche, wenn du meine Mails damals nicht gelesen hast und offenbar weder Ahnung von der sendmail.cf, noch der Konfigurationsmoeglichkeit ueber die m4-Makros, noch bereit bist darueber was zu lesen oder gar zu lernen. David, bitte treffe keine solchen Urteile, wenn Du alles ernst nimmst, was auf Deinem Monitor erscheint. Glaubst Du wirklich, daß ich annehme, Du hättest den Inhalt von /dev/random beschrieben?
Allerdings habe ich wirklich keine Ahnung von der sendmail.cf, zum Glück ist das mit Postfix nicht nötig. Wenn ich etwas Schwieriges machen will, programmiere ich C.
Allerdings soll ja auch niemand (oder fast niemand) sendmail.cf direkt editieren, m4 ist schon erfunden... Verstehe, die sendmail.cf ist also doch so verständlich, daß man sie besser überhaupt nicht ansieht. Tja. Ich editiere die .cf direkt, allerdings weil ich die m4- Makrodatei verschlampt habe. Und ich habe keine Probleme damit. Ja, Du bist auch sicherlich einer der Erfahrensten hier.
(O = Option, D = define variable etc.). Das meine ich. Bei postfix muß nichts erklärt werden.
mydomain = foo.tld
in postfix' main.cf ist, musst du mir mal erklaeren (Mach dir aber erst die Bedeutung des '=' klar... Und dann die Bedeutung des 'D' bei sendmail). Man kann an $mydomain sofort sehen, wofür es gut ist. Ich nehme mal an, daß Du schonmal programmiert hast, hast Du dabei möglichst kurze oder möglichst aussagekräftige Namen für die Variablen benutzt?
Was an Procmail unverständlich ist (wenn man einmal die Syntax begriffen und man procmailex gelesen hat), bleibt mir schleierhaft, aber die Diskussion hatten wir schonmal IIRC :) Klar, wenn man einmal die Syntax begriffen hat, ist es kinderleicht. Und die Syntax ist ebenfalls kinderleicht. Warum mußt Du sie dann erklären? Habe ich schon Maildropsyntax erklärt? (Wobei klar ist, daß man die Manpage lesen muß, um etwa das Pendent zu Procmails ^TO_ zu finden.)
Mehere Bedingungen sind UND verknuepft. Bei Maildrop sind sie UND-verknüpft, wenn da && steht. Macht irgendwie mehr Sinn, als ein Nullmorphem, oder?
Und? ist das soo viel schwerer als (und das noch ohne flags!) Allerdings. Nicht weil es unmöglich ist, es zu verstehen, sondern weil man sich bei Maildrop nicht mit sinnlosen Kürzeln wie ':0' herumschlagen muß. Wichtiger noch: Die Struktur einer Regel ist unmittelbar erkennbar und nicht von der Plazierung abhängig.
Und dabei fehlt z.B. die Moeglichkeit Bequem via einem Flag das Match auf den Header (H = default), den Body (B) einzuschraenken, oder eine Kopie (c) zu erzeugen.... Jetzt bin ich mal dran: Unfug. Das ist bei Maildrop sogar besser gelöst, weil ich das pro Bedingung mache: if (/imHeader/h || (/auchImHeader/h && /imBody/b)) { <Aktion> } Wie sieht das bei Procmail aus?
Eine Kopie macht man wie gesagt mit 'cc'.
Maildrop Procmail file lock flock n/a dotlock dotlock :
Procmail kann dotlock. S.o. die Syntax. Wie, verstehst Du das etwa nicht? Ich habe doch geschreiben, wie Procmail ein dotlock erstellt!
if if * Zielbox to <nil> Aktionline:= Name der Zielbox Genau das meine ich. Durch das zusätzliche Schlüsselwort wird es deutlicher als durch die Positionierung.
AND && <nil> Weitere Zeile mit * Also weitere 'if's? Oder bedeutet '*' garnicht 'if'? Was ist dann ein 'if'? Was bedeutet '*'?
cc cc c Externer Filter xfilter f
Ich könnte noch eine Weile so weiter machen. Und noch weiter zeigen, dass du procmail nicht kennst? Ich habe es jahrelang benutzt.
Huh? Ich kann meine Filter so kompliziert schreiben, wie ich nur will, in einer Sprache, die eigens für die Manipulation von Texten erschaffen worden ist. Das sehe ich als Vorteil. Das kannst du auch mit procmail. Was, komplizierte Filter schreiben? Ist mir nicht neu. OK, ich verstehe schon, was Du meinst. Nochmal: Ich habe nie behauptet, daß Procmail zu leistungsschwach ist.
Und zur Not kannst du ja in ein perlscript pipen. Fettes Argument. Ich kann übrigens auch aus meinem Mail::Audit Skript heraus Procmail aufrufen. (Nicht, daß ich jemals den Wunsch dazu verspürt hätte.)
Dabei sind die Filter durch die Kontrollstrukturen oft einfacher als bei Procmail (Maildrop hat ebenfalls Kontrollstrukturen), meine Filter für Mailinglisten besteht zB. aus einem Hash und - - - Schnipp - - - foreach(list) foreach(address) if (address in list) accept(maildir/ML/list) - - - Schnapp - - - (In address befinden sich alle Empfänger der Mail.) Ok, das ist bequem ;) Hm. Sowas aehnliches muesste mit procmail auch gehen. Der Witz ist: Falls das Procmail wirklich kann, wäre das das beste Argument *gegen* Procmail.
Der einzige Nachteil ist die Geschwindigkeit. Und der ist bei vielen Mails doch deutlich. Klar, den Luxus gönne ich mir eben. Als Default empfehle ich darum auch Maildrop. (Man kann Fetchmail ersetzen und das auch in Perl erledigen, dann dürfte der Unterschied gering sein. Mir ist aber lieber, die Mails schon im MTA zu haben, falls etwas schiefgeht.)
Ich habe nicht behauptet, daß Procmail unbeherrschbar ist, sondern daß Procmailisch *unnötig* schwierig ist. Maildrop kann AFAIK alles, was Procmail kann (und mehr) und ist wesentlich deutlicher. (Maildrop ist auch sicherlich einfacher als Perl, beim Einsatz von Perl habe ich aber auch deutlich mehr Möglichkeiten.) Thorsten -- Politik kann man in diesem Lande definieren als die Durchsetzung wirtschaftlicher Zwecke mit Hilfe der Gesetzgebung. - Kurt Tucholsky
Hallo, On Wed, 20 Mar 2002, Thorsten Haude wrote:
* David Haller
[02-03-19 22:52]: On Tue, 19 Mar 2002, Thorsten Haude wrote:
* Christoph Maurer
[02-03-19 12:37]: Am Die, 19 Mär 2002 schrieb Thorsten Haude:
Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random, Einspruch: D.Haller hat vor kurzem mal genauer beschrieben, was darin steht, so unverständlich ist das gar nicht. In /dev/random? Thorsten, bitte mach keine solche Vergleiche, wenn du meine Mails damals nicht gelesen hast und offenbar weder Ahnung von der sendmail.cf, noch der Konfigurationsmoeglichkeit ueber die m4-Makros, noch bereit bist darueber was zu lesen oder gar zu lernen. David, bitte treffe keine solchen Urteile, wenn Du alles ernst nimmst, was auf Deinem Monitor erscheint.
Das sowieso nicht :)
Glaubst Du wirklich, daß ich annehme, Du hättest den Inhalt von /dev/random beschrieben?
Es klang doch ziemlich danach, zumindest danach, dass du die .cf so lesbar wie /dev/random haeltst.
Allerdings habe ich wirklich keine Ahnung von der sendmail.cf, zum Glück ist das mit Postfix nicht nötig.
Stimmt.
Tja. Ich editiere die .cf direkt, allerdings weil ich die m4- Makrodatei verschlampt habe. Und ich habe keine Probleme damit. Ja, Du bist auch sicherlich einer der Erfahrensten hier.
Neneee, sicher nicht. Ich hab mich nur neulich mal hingesetzt und endlich mal die Doku zur .cf gelesen... Schwierig war das nicht, simpel aber (wg. der Komplexitiaet der Rewriting Rules) aber auch nicht. Die Konfiguration aber, an der man normalerweise schraubt, ist bis auf die kuerze der "Schluesselwoerter" und Variablen eigentlich simpel. Und so kenne ich z.B. noch nichtmal das Batbook.
(O = Option, D = define variable etc.). Das meine ich. Bei postfix muß nichts erklärt werden.
Ach? Nur weil das 'foo = bar' ne ueblichere Syntax als 'D{foo} bar' ist? Und es gibt gute Gruende fuer die "Kuerze" der .cf. Und gute Gruende, dass es das System der m4 Makros zur Konfiguration gibt.
mydomain = foo.tld
in postfix' main.cf ist, musst du mir mal erklaeren (Mach dir aber erst die Bedeutung des '=' klar... Und dann die Bedeutung des 'D' bei sendmail). Man kann an $mydomain sofort sehen, wofür es gut ist. Ich nehme mal an, daß Du schonmal programmiert hast, hast Du dabei möglichst kurze oder möglichst aussagekräftige Namen für die Variablen benutzt?
Ja. Natuerlich. Fuer die Aussagekraeftigen Namen sind aber die m4 Makros zustaendig, das steht dann z.B. define(`confDOMAIN_NAME',`foo.tld')dnl Ist das "aussagekraeftig" genug? Ja? Gut. Und diese zweistufige System _hat_ Vorteile, die sendmail.cf ist naemlich, bei aller Komplexitaet einfach zu parsen. [procmail]
Und die Syntax ist ebenfalls kinderleicht. Warum mußt Du sie dann erklären? Habe ich schon Maildropsyntax erklärt? (Wobei klar ist, daß man die Manpage lesen muß, um etwa das Pendent zu Procmails ^TO_ zu finden.)
Nein, hast du nicht, aber _mir_ musst du beide nicht erklaeren. Ich musste genauso mal lernen, was ein if ist, und wie man Muster in perl definiert, aber da ich inzwischen perl ein wenig kann, musst du mir's nicht erklaeren. Und zu procmail hab ich 'man procmailrc' einmal kurz ueberflogen. Und das hat auch schon gereicht.
Mehere Bedingungen sind UND verknuepft. Bei Maildrop sind sie UND-verknüpft, wenn da && steht. Macht irgendwie mehr Sinn, als ein Nullmorphem, oder?
Nur ne Frage der Syntaxdefinition. In Perl (und maildrop) ist die Definition eben '&&', in der procmailrc schlicht eine weitere Zeile mit '*'...
Und? ist das soo viel schwerer als (und das noch ohne flags!) Allerdings. Nicht weil es unmöglich ist, es zu verstehen, sondern weil man sich bei Maildrop nicht mit sinnlosen Kürzeln wie ':0' herumschlagen muß.
Wieso sinnloses Kuerzel? Hae? Dann ist aber 'sub' in perl genauso sinnlos. (ja, ich mag perl! ;) Und was sollen eigentlich die // bei ner Bedingung? (Wo ist der Unterschied?)
Wichtiger noch: Die Struktur einer Regel ist unmittelbar erkennbar und nicht von der Plazierung abhängig.
Hae? Die Plazierung ist in maildrop genauso wichtig. Oder funktioniert: { if } <Aktion> /foo/ Nein. Eben. Nur sind die Regeln _fuer_ die Platzierung ein wenig anders.
Und dabei fehlt z.B. die Moeglichkeit Bequem via einem Flag das Match auf den Header (H = default), den Body (B) einzuschraenken, oder eine Kopie (c) zu erzeugen.... Jetzt bin ich mal dran: Unfug. Das ist bei Maildrop sogar besser gelöst, weil ich das pro Bedingung mache: if (/imHeader/h || (/auchImHeader/h && /imBody/b)) { <Aktion> }
Ok, sorry, das kannte ich nicht. Da hast du Recht. ISR.
Wie sieht das bei Procmail aus?
Schwieriger. Wenn man es denn so verschachtelt. Kann aber gut sein, dass es auch geht... Aber das lohnt nicht. Denn: :0 H * imHeader <Aktion> :0 H * auchImHeader :0 AB * im Body <Aktion> Ja, ich weiss das ist nicht genau aequivalent, das ist aequivalent zu: if(/imHeader/h) { <Aktion> } if(/auchImHeader/h && /imBody/ ) { <Aktion> } Aber AFAIK koennte man auch irgendwas aequivalentes hinbekommen, das lohnt aber IMO nicht ;)
Eine Kopie macht man wie gesagt mit 'cc'.
Ok.
Maildrop Procmail file lock flock n/a dotlock dotlock :
Procmail kann dotlock. S.o. die Syntax. Wie, verstehst Du das etwa nicht? Ich habe doch geschreiben, wie Procmail ein dotlock erstellt!
Ah, da hab ich deinen Tabelleneintrag falsch gelesen ;)
if if * Zielbox to <nil> Aktionline:= Name der Zielbox Genau das meine ich. Durch das zusätzliche Schlüsselwort wird es deutlicher als durch die Positionierung.
Findest du? Naja, Geschmack... ;)
AND && <nil> Weitere Zeile mit * Also weitere 'if's? Oder bedeutet '*' garnicht 'if'? Was ist dann ein 'if'? Was bedeutet '*'?
Dass der Rest der Zeile ein Egrep-Ausdruck ist, nach dem (per default nur der Header) die Mail gescannt werden soll. Damit eine Regel zutrifft, muessen eben _alle_ per * angegebenen Ausdruecke "matchen". Analog ist wohl: if( ... ) { if ( ... ) { [..] } } Oder wenn du willst, eben auch per && verknuepft... Ja, ich sehe die Eleganz der Ausdruecke usw. von maildrop, das ist ja die von perl, und die mag ich ;) Nur halte ich das i.A. fuer Overkill zum Filtern von Mails. Bei mir sieht quasi die gesamte procmailrc so aus: :0 * ^X-Mailing-List:.*foo@bar.tld mailing-liste-foo Fuer solche Regeln ist perl/maildrop schlicht overkill. Eigentlich hab ich nur eine Regel, wo etwas komplexeres gemacht wird, aber das komplexe macht ein perlscript, das die mail per Pipe bekommt (nach ner ebenso simplen Regel wie oben), und das dann eines von 3 attach- ments extrahiert, parst und die Daten dann per DBI in ne DB stopft. Das perlscript ist aber wiederum so lang, dass wuerdest auch du kaum in deine maildrop-Regeln einbauen.
Ich könnte noch eine Weile so weiter machen. Und noch weiter zeigen, dass du procmail nicht kennst? Ich habe es jahrelang benutzt. [..] Huh? Ich kann meine Filter so kompliziert schreiben, wie ich nur will, in einer Sprache, die eigens für die Manipulation von Texten erschaffen worden ist. Das sehe ich als Vorteil. Das kannst du auch mit procmail. Was, komplizierte Filter schreiben? Ist mir nicht neu. OK, ich verstehe schon, was Du meinst. Nochmal: Ich habe nie behauptet, daß Procmail zu leistungsschwach ist.
Hm. Wuerd's dir was ausmachen, mir mal deine Regeln fuer maildrop mailen? Wuerde mich echt mal interessieren, was du da so alles machst :) [..]
Der einzige Nachteil ist die Geschwindigkeit. Und der ist bei vielen Mails doch deutlich. Klar, den Luxus gönne ich mir eben. Als Default empfehle ich darum auch Maildrop.
Mach ich andersrum ;)
(Man kann Fetchmail ersetzen und das auch in Perl erledigen, dann dürfte der Unterschied gering sein. Mir ist aber lieber, die Mails schon im MTA zu haben, falls etwas schiefgeht.)
Jup, und dann s.o. bzgl. overkill...
Ich habe nicht behauptet, daß Procmail unbeherrschbar ist, sondern daß Procmailisch *unnötig* schwierig ist.
s.o. ich halte procmail fuer nicht schwierig. maildrop (bzw. dessen perl-syntax) ist eher schwieriger, besonders, wenn man nicht perl kann...
Maildrop kann AFAIK alles, was Procmail kann (und mehr) und ist wesentlich deutlicher.
NACK. Ich halte beide fuer gleich "deutlich".
(Maildrop ist auch sicherlich einfacher als Perl, beim Einsatz von Perl habe ich aber auch deutlich mehr Möglichkeiten.)
Ack. -dnh PS: Nix fuer ungut ;) -- 98: Emacs emacs makes any computer slow
Moin,
* David Haller
(O = Option, D = define variable etc.). Das meine ich. Bei postfix muß nichts erklärt werden. Ach? Nur weil das 'foo = bar' ne ueblichere Syntax als 'D{foo} bar' ist? Ja.
Ja. Natuerlich. Fuer die Aussagekraeftigen Namen sind aber die m4 Makros zustaendig, das steht dann z.B.
define(`confDOMAIN_NAME',`foo.tld')dnl
Ist das "aussagekraeftig" genug? Ja? Gut. Wozu ist das 'dnl' gut? (Ne, ich will's nicht wirklich wissen.)
Und diese zweistufige System _hat_ Vorteile, die sendmail.cf ist naemlich, bei aller Komplexitaet einfach zu parsen. Wieviel Taktzyklen spart man denn damit pro Bootvorgang?
[procmail]
Und die Syntax ist ebenfalls kinderleicht. Warum mußt Du sie dann erklären? Habe ich schon Maildropsyntax erklärt? (Wobei klar ist, daß man die Manpage lesen muß, um etwa das Pendent zu Procmails ^TO_ zu finden.) Nein, hast du nicht, aber _mir_ musst du beide nicht erklaeren. Schon klar, darum geht's auch nicht.
Ich musste genauso mal lernen, was ein if ist, und wie man Muster in perl definiert, aber da ich inzwischen perl ein wenig kann, musst du mir's nicht erklaeren. Und zu procmail hab ich 'man procmailrc' einmal kurz ueberflogen. Und das hat auch schon gereicht. Ja, man kann es verstehen. Nein, Du bist kein typischer User.
Mehere Bedingungen sind UND verknuepft. Bei Maildrop sind sie UND-verknüpft, wenn da && steht. Macht irgendwie mehr Sinn, als ein Nullmorphem, oder? Nur ne Frage der Syntaxdefinition. In Perl (und maildrop) ist die Definition eben '&&', in der procmailrc schlicht eine weitere Zeile mit '*'... Die Syntax kann einfach oder umständlich definiert sein.
Und? ist das soo viel schwerer als (und das noch ohne flags!) Allerdings. Nicht weil es unmöglich ist, es zu verstehen, sondern weil man sich bei Maildrop nicht mit sinnlosen Kürzeln wie ':0' herumschlagen muß. Wieso sinnloses Kuerzel? Hae? Dann ist aber 'sub' in perl genauso sinnlos. (ja, ich mag perl! ;) 'subroutine', das dürfte klar sein.
Und was sollen eigentlich die // bei ner Bedingung? (Wo ist der Unterschied?) So markiert man Regexen.
Wichtiger noch: Die Struktur einer Regel ist unmittelbar erkennbar und nicht von der Plazierung abhängig. Die Plazierung ist in maildrop genauso wichtig. Oder funktioniert:
{ if } <Aktion> /foo/
Nein. Eben. Nur sind die Regeln _fuer_ die Platzierung ein wenig anders. Was ich meine: Bei Procmail funktioniert :0 * ^TO_whatever mail/whatever nicht, bei Maildrop funktioniert if (/whatever/) {to mail/whatever} sehr gut.
:0 H * auchImHeader :0 AB * im Body <Aktion> Das ist also ein UND, weil es keine Aktion gibt und die nächste Bedingung ein 'A' enthält. Klar, genauso leicht verständlich wie '&&'.
Aber AFAIK koennte man auch irgendwas aequivalentes hinbekommen, das lohnt aber IMO nicht ;) Es geht nicht darum, ob es sich lohnt.
Maildrop Procmail file lock flock n/a dotlock dotlock :
Procmail kann dotlock. S.o. die Syntax. Wie, verstehst Du das etwa nicht? Ich habe doch geschreiben, wie Procmail ein dotlock erstellt! Ah, da hab ich deinen Tabelleneintrag falsch gelesen ;) Klar, schieb's mal auf NEdit.
if( ... ) { if ( ... ) { [..] } }
Oder wenn du willst, eben auch per && verknuepft... Allerdings will ich das, davon rede ich ja die ganze Zeit.
:0 * ^X-Mailing-List:.*foo@bar.tld mailing-liste-foo
Fuer solche Regeln ist perl/maildrop schlicht overkill. Ist ja voll der Overkill: if (/^X-Mailing-List:.*foo@bar.tld/) { to mailing-liste-foo }
Hm. Wuerd's dir was ausmachen, mir mal deine Regeln fuer maildrop mailen? Wuerde mich echt mal interessieren, was du da so alles machst :) Ich benutze Mail::Audit. Und das unterfordere ich gnadenlos, interessant ist das also nicht.
Der einzige Nachteil ist die Geschwindigkeit. Und der ist bei vielen Mails doch deutlich. Klar, den Luxus gönne ich mir eben. Als Default empfehle ich darum auch Maildrop. Mach ich andersrum ;) Als Default Mail::Audit, für die schwierigen Sachen Maildrop? Na also, geht doch!
maildrop (bzw. dessen perl-syntax) ist eher schwieriger, besonders, wenn man nicht perl kann... Für mich ist das nicht Perlsyntax, sondern C-C++-Perl-Java-Ruby-Was- weiß-ich-noch-alles-Syntax.
Thorsten -- Try not to be a man of success but rather of value. - Albert Einstein
Gudnnaaamd, On Fri, 22 Mar 2002, Thorsten Haude wrote:
* David Haller
[02-03-21 03:20]: (O = Option, D = define variable etc.). Das meine ich. Bei postfix muß nichts erklärt werden. Ach? Nur weil das 'foo = bar' ne ueblichere Syntax als 'D{foo} bar' ist? Ja.
Wenn du meinst.[tm]
Ja. Natuerlich. Fuer die Aussagekraeftigen Namen sind aber die m4 Makros zustaendig, das steht dann z.B.
define(`confDOMAIN_NAME',`foo.tld')dnl
Ist das "aussagekraeftig" genug? Ja? Gut. Wozu ist das 'dnl' gut? (Ne, ich will's nicht wirklich wissen.)
Das erklaert sich von selbst, wenn man mal in so ne m4-Datei mal reinschaut: ==== dnl Definiere den Smarthost entweder hier, oder in /etc/mail/mailertable dnl ein Smarthost ist der Empfaenger-Host fuer alle EMails, die nach dnl draussen gehen dnl define(`SMART_HOST', `smtprelay.t-online.de')dnl ==== Siehe auch 'man m4'.
Und diese zweistufige System _hat_ Vorteile, die sendmail.cf ist naemlich, bei aller Komplexitaet einfach zu parsen. Wieviel Taktzyklen spart man denn damit pro Bootvorgang?
Keine Ahnung. Aber je simpler ein Parser (oder ein anderes Programm) ist, um so leichter ist es keine Fehler zu machen.
[procmail] Ich musste genauso mal lernen, was ein if ist, und wie man Muster in perl definiert, [..]. Und zu procmail hab ich 'man procmailrc' einmal kurz ueberflogen. Und das hat auch schon gereicht. Ja, man kann es verstehen. Nein, Du bist kein typischer User.
Ach? Bin ich nicht?
Bei Maildrop sind sie UND-verknüpft, wenn da && steht. Macht irgendwie mehr Sinn, als ein Nullmorphem, oder? Nur ne Frage der Syntaxdefinition. In Perl (und maildrop) ist die Definition eben '&&', in der procmailrc schlicht eine weitere Zeile mit '*'... Die Syntax kann einfach oder umständlich definiert sein.
Was ist an '&&' einfacher als an '*'? Wieso eigentlich nicht '&' oder '+'? Ist alles g'hupft wie gesprungen, IMO! [..]
man sich bei Maildrop nicht mit sinnlosen Kürzeln wie ':0' herumschlagen muß. Wieso sinnloses Kuerzel? Hae? Dann ist aber 'sub' in perl genauso sinnlos. (ja, ich mag perl! ;) 'subroutine', das dürfte klar sein.
Aber wozu?
Und was sollen eigentlich die // bei ner Bedingung? (Wo ist der Unterschied?) So markiert man Regexen.
Warum muss ich Regexen denn markieren? Warum kann ich nicht 'if(foo)' schreiben? Was soll das? (vgl. mit dem '*'! Das markiert eben bei procmail ne Bedingung (und zwar als extended regex a la egrep).
Wichtiger noch: Die Struktur einer Regel ist unmittelbar erkennbar und nicht von der Plazierung abhängig. Die Plazierung ist in maildrop genauso wichtig. Oder funktioniert:
{ if } <Aktion> /foo/
Nein. Eben. Nur sind die Regeln _fuer_ die Platzierung ein wenig anders. Was ich meine: Bei Procmail funktioniert :0 * ^TO_whatever mail/whatever nicht, bei Maildrop funktioniert if (/whatever/) {to mail/whatever} sehr gut.
Achso. Naja, du kennst python? Und naja, wenn du wg. sowas procmail nicht magst, dann bist du bei perl (maildrop/Mail::Audit) wohl genau richtig ;) Perl kann man ja wirklich schoen 'obfuscated' schreiben...
:0 H * auchImHeader :0 AB * im Body <Aktion> Das ist also ein UND, weil es keine Aktion gibt und die nächste Bedingung ein 'A' enthält. Klar, genauso leicht verständlich wie '&&'.
Moment, das mit dem flag 'A' ist was anderes als ein simples UND. :0 Hc * ^X-Mailing-List:.*suse-linux$ suse-linux :0 A * ^From:.*@thorstenhau.de | flame_haude.sh *g* Geht sicher auch mit maildrop, aber intuitiv?
Ah, da hab ich deinen Tabelleneintrag falsch gelesen ;) Klar, schieb's mal auf NEdit.
Noe. Ich hab schlicht das ':' flasch interpretiert ;)
Fuer solche Regeln ist perl/maildrop schlicht overkill. Ist ja voll der Overkill: if (/^X-Mailing-List:.*foo@bar.tld/) { to mailing-liste-foo }
Mit overkill meinte ich nicht die Regeln (oder deren Syntax), sondern maildrop/Mail::Audit... Wie du selbst sagtes, procmail ist (deutlich) schneller.
Hm. Wuerd's dir was ausmachen, mir mal deine Regeln fuer maildrop mailen? Wuerde mich echt mal interessieren, was du da so alles machst :) Ich benutze Mail::Audit. Und das unterfordere ich gnadenlos, interessant ist das also nicht.
Aha. Hm. Wenn du willst, mail mir's trotzdem, mal schauen, wie das dann als .procmailrc aussaehe ;) Dann kannst du ja mal "benchmarken" ;)
Der einzige Nachteil ist die Geschwindigkeit. Und der ist bei vielen Mails doch deutlich. Klar, den Luxus gönne ich mir eben. Als Default empfehle ich darum auch Maildrop. Mach ich andersrum ;) Als Default Mail::Audit, für die schwierigen Sachen Maildrop? Na also, geht doch!
Nope. Procmail als default, perl (via pipe aus procmail) fuer die schwierigen Sachen.
maildrop (bzw. dessen perl-syntax) ist eher schwieriger, besonders, wenn man nicht perl kann... Für mich ist das nicht Perlsyntax, sondern C-C++-Perl-Java-Ruby-Was- weiß-ich-noch-alles-Syntax.
Setzt aber voraus, dass man mind. eine davon kann. Und fuer mich _ist_ das perl-Syntax, ich sach nur: if(/REGEX/). Das kann C/C++/Java nicht (Ruby kenn ich nur vom Namen her). -dnh -- Die Tastatur finden Sie, indem Sie das Kabel verfolgen, ds mit einem 5poligen DIN-Stecker an der Rückseite Ihres Rechners angebracht ist. [CrossPoint-Hilfe]
Moin,
* David Haller
Keine Ahnung. Aber je simpler ein Parser (oder ein anderes Programm) ist, um so leichter ist es keine Fehler zu machen. Je komplizierter die zu parsende Sprache (oder der Weg dahin) ist, desto leichter ist es, einen Fehler zu machen. Sonst würden wir alle nur Assembler benutzen.
Was ist an '&&' einfacher als an '*'? Wieso eigentlich nicht '&' oder '+'? Ist alles g'hupft wie gesprungen, IMO! OK, ich habe jetzt keine Lust mehr, mit Dir über solche Details zu diskutieren. Wenn Dir nicht klar ist, warum '&&' ein besseres Symbol für UND ist als '*', dann tut es mir leid. Ich verdiene meine Brötchen mit dem Programmieren, habe aber keine Lust, mich mit Sprachen 'rumzuquälen, die man kaum unverständlicher schreiben könnte, wenn man es versuchte.
:0 Hc * ^X-Mailing-List:.*suse-linux$ suse-linux
:0 A * ^From:.*@thorstenhau.de | flame_haude.sh
*g*
Geht sicher auch mit maildrop, aber intuitiv? Keine Ahnung, ich weiß nämlich nicht, was das bedeuten soll.
Mit overkill meinte ich nicht die Regeln (oder deren Syntax), sondern maildrop/Mail::Audit... Wie du selbst sagtes, procmail ist (deutlich) schneller. Von Maildrop habe ich das nicht gesagt. Ich bin sicher, daß man den Unterschied allenfalls messen könnte.
Thorsten -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw
Thorsten Haude
Und diese zweistufige System _hat_ Vorteile, die sendmail.cf ist naemlich, bei aller Komplexitaet einfach zu parsen. Wieviel Taktzyklen spart man denn damit pro Bootvorgang?
Darum geht's nicht. sendmail hat den unbestechlichen Charme, daß ich Mail direkt via /usr/bin/sendmail verschicken kann, ohne einen smtp-Daemon laufen zu haben. Geht das mit Postfix auch? -- In the begining was the word, and the word was: Content-Type: text/plain; charset=us-ascii
Moin,
* Martin Schmitz
Thorsten Haude
writes: Und diese zweistufige System _hat_ Vorteile, die sendmail.cf ist naemlich, bei aller Komplexitaet einfach zu parsen. Wieviel Taktzyklen spart man denn damit pro Bootvorgang? Darum geht's nicht. sendmail hat den unbestechlichen Charme, daß ich Mail direkt via /usr/bin/sendmail verschicken kann, ohne einen smtp-Daemon laufen zu haben. Geht das mit Postfix auch? Sorry, für solche Kriterien habe ich mich noch nie interessiert.
Thorsten -- Death to all fanatics!
David Haller
[procmail]
Und die Syntax ist ebenfalls kinderleicht. Warum mußt Du sie dann erklären? Habe ich schon Maildropsyntax erklärt? (Wobei klar ist, daß man die Manpage lesen muß, um etwa das Pendent zu Procmails ^TO_ zu finden.)
Nein, hast du nicht, aber _mir_ musst du beide nicht erklaeren. Ich musste genauso mal lernen, was ein if ist, und wie man Muster in perl definiert, aber da ich inzwischen perl ein wenig kann, musst du mir's nicht erklaeren. Und zu procmail hab ich 'man procmailrc' einmal kurz ueberflogen. Und das hat auch schon gereicht.
Hm, wenn die procmail-Syntax so einfach ist, dann erklär' mich doch mal kurz und knapp, wie ich es hinbekomme, alle Absender auszufiltern, die in einer extra Datei zeilenweise aufgeführt sind (als egrep-fähige RegExp). Ich verzweifel gerade daran und im Netz hab' ich auch nichts wirklich brauchbares gefunden. -- In the begining was the word, and the word was: Content-Type: text/plain; charset=us-ascii
Am Fre, 22 Mär 2002 schrieb Martin Schmitz:
David Haller
writes: [procmail]
Und die Syntax ist ebenfalls kinderleicht. Warum mußt Du sie dann erklären? Habe ich schon Maildropsyntax erklärt? (Wobei klar ist, daß man die Manpage lesen muß, um etwa das Pendent zu Procmails ^TO_ zu finden.)
Nein, hast du nicht, aber _mir_ musst du beide nicht erklaeren. Ich musste genauso mal lernen, was ein if ist, und wie man Muster in perl definiert, aber da ich inzwischen perl ein wenig kann, musst du mir's nicht erklaeren. Und zu procmail hab ich 'man procmailrc' einmal kurz ueberflogen. Und das hat auch schon gereicht.
Hm, wenn die procmail-Syntax so einfach ist, dann erklär' mich doch mal kurz und knapp, wie ich es hinbekomme, alle Absender auszufiltern, die in einer extra Datei zeilenweise aufgeführt sind (als egrep-fähige RegExp). Ich verzweifel gerade daran und im Netz hab' ich auch nichts wirklich brauchbares gefunden.
Meinst Du so was? (\ Maskiert nur den Zeilenumbruch, Zeile zu einer zusammenbauen und \ entfernen) :0 * ? $FORMAIL -x"From" -x"From:" -x"Sender:" -x"Reply-To:" -x"Return-Path:"|\ /usr/bin/grep -is -f $HOME/.procmail/plonk.lst PLONK Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Christoph Maurer
Am Fre, 22 Mär 2002 schrieb Martin Schmitz:
Hm, wenn die procmail-Syntax so einfach ist, dann erklär' mich doch mal kurz und knapp, wie ich es hinbekomme, alle Absender auszufiltern, die in einer extra Datei zeilenweise aufgeführt sind (als egrep-fähige RegExp). Ich verzweifel gerade daran und im Netz hab' ich auch nichts wirklich brauchbares gefunden.
Meinst Du so was?
:0 * ? $FORMAIL -x"From" -x"From:" -x"Sender:" -x"Reply-To:" -x"Return-Path:"|\ /usr/bin/grep -is -f $HOME/.procmail/plonk.lst PLONK
Scheint prima zu funktionieren. Danke. Ich hatte mal aus 'ner Zeitschrift sowas hier, was mir auch ganz plausibel erschien, aber das ging so gar nicht: :0 Wi | (formail -x from: -x sender: -x to: | grep -iq -f \ $HOME/.procmail/plonk.lst) PLONK Siehst Du auf Anhieb, wo da der Fehler steckt? Gruß, Martin -- In the begining was the word, and the word was: Content-Type: text/plain; charset=us-ascii
Am Fre, 22 Mär 2002 schrieb Martin Schmitz:
Christoph Maurer
writes: Am Fre, 22 Mär 2002 schrieb Martin Schmitz:
Hm, wenn die procmail-Syntax so einfach ist, dann erklär' mich doch mal kurz und knapp, wie ich es hinbekomme, alle Absender auszufiltern, die in einer extra Datei zeilenweise aufgeführt sind (als egrep-fähige RegExp). Ich verzweifel gerade daran und im Netz hab' ich auch nichts wirklich brauchbares gefunden.
Meinst Du so was?
:0 * ? $FORMAIL -x"From" -x"From:" -x"Sender:" -x"Reply-To:" -x"Return-Path:"|\ /usr/bin/grep -is -f $HOME/.procmail/plonk.lst PLONK
Scheint prima zu funktionieren. Danke. Ich hatte mal aus 'ner Zeitschrift sowas hier, was mir auch ganz plausibel erschien, aber das ging so gar nicht:
:0 Wi | (formail -x from: -x sender: -x to: | grep -iq -f \ $HOME/.procmail/plonk.lst) PLONK
Siehst Du auf Anhieb, wo da der Fehler steckt?
Du hast zwei Action-Lines (| startet eine Action) das geht in Procmail nicht direkt. In meinem Vorschlag dagegen wird der Exitcode eines externen Programms als Filter aufgegriffen (?). Gruß Christoph -- Christoph Maurer - 52072 Aachen - Tux#194235 mailto:christoph-maurer@gmx.de - http://www.christophmaurer.de Auf der Homepage u.a.: Installation von SuSE 7.0 auf Notebook Acer Travelmate 508 T, Elektrotechnik an der RWTH Aachen
Hallo, On Fri, 22 Mar 2002, Martin Schmitz wrote:
David Haller
writes: [procmail]
Und die Syntax ist ebenfalls kinderleicht. Warum mußt Du sie dann erklären? Habe ich schon Maildropsyntax erklärt? (Wobei klar ist, daß man die Manpage lesen muß, um etwa das Pendent zu Procmails ^TO_ zu finden.)
Nein, hast du nicht, aber _mir_ musst du beide nicht erklaeren. Ich musste genauso mal lernen, was ein if ist, und wie man Muster in perl definiert, aber da ich inzwischen perl ein wenig kann, musst du mir's nicht erklaeren. Und zu procmail hab ich 'man procmailrc' einmal kurz ueberflogen. Und das hat auch schon gereicht.
Hm, wenn die procmail-Syntax so einfach ist, dann erklär' mich doch mal kurz und knapp, wie ich es hinbekomme, alle Absender auszufiltern, die in einer extra Datei zeilenweise aufgeführt sind (als egrep-fähige RegExp). Ich verzweifel gerade daran und im Netz hab' ich auch nichts wirklich brauchbares gefunden.
Extra Datei? Das geht _so_ AFAIK nicht, aber du kannst folgendes
verwenden:
In deiner ~/.procmailrc an der Stelle, wo du die Regel habe wolltest:
====
INCLUDERC=$PMDIR/spezielle.rc
====
(wobei du $PMDIR gesetzt haben musst, ansonsten nimm z.B. einfach
direkt das Verzeichnis, z.B. ~/.procmail)
Und in $PMDIR/spezielle.rc schreibst du dann z.B.:
====
:0
* ^FROM_(adr|adr2|...)
wohin_die_mails_sollen
====
Falls du unbedingt eine Zeilenweise definition haben willst, musst
du AFAIK die eigentliche regex dann generieren, aber das ist simpel,
da liessen sich dann z.B. wrapper-scripte bzw. aliase definieren um
eine Addy in das file mit den Adressen aufzunehmen... Ich nehm jetzt
einfach mal an, dass es ein spam-filter waere (du hast dir schon
www.rbl.org (?) angeschaut?)
==== ~/.procmail/spam_adrs.lst ====
foo@bar.tld
we_spam@foobar.com
# [..]
====
alias add_spam_adr='echo $@ >> ~/.procmail/spam_adrs.lst \
&& update_spam_filter.sh'
==== update_spam_filter.sh ====
#!/bin/sh
(
echo -e ':0\n* ^FROM_('
for a in `cat ~/.procmail/spam_adrs.lst`; do
echo "$a|"
done
echo -e ')\n/dev/null'
) | sed 's/|)/)/' > ~/.procmail/kill_spam.rc
====
==== ~/.procmailrc ====
[..]
INCLUDERC="~/.procmail/kill_spam.rc"
[..]
====
Um/statt das/dem alias 'add_spam_adr' koennte man sicher auch ein
script schreiben, dass sich z.B. aus mutt per shortcut aufrufen
liesse...
Ahja, ich wette, Thorsten kommt jetzt mit ner eleganteren Loesung
fuer maildrop/Mail::Audit daher (da man dort die
~/.procmail/spam_adrs.lst wohl per
my $spam_adrs = '(';
open(SPAM_ADRS, "<~/.procmail/spam_adrs.lst");
while(
Hallo, On Tue, 19 Mar 2002, Thorsten Haude wrote:
Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random,
Unfug. Die ist nur sehr knapp gefasst und eben recht komplex. Aber dafuer gibt's die m4 Macros.
ebenso wie die Konfigurationsdatei von Procmail.
Unfug. Die procmailrc ist simpelst. -dnh -- Paranoid schizophrenics outnumber their enemies at least two to one. -- from the fortune file
Moin,
* David Haller
On Tue, 19 Mar 2002, Thorsten Haude wrote:
Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random, ebenso wie die Konfigurationsdatei von Procmail. Unfug. Die procmailrc ist simpelst. Klar, simpelst. Erklär doch mal bitte die einzelnen Punkte der Liste weg, die ich in einer anderen Mail hatte.
Thorsten -- The fact that windows is one of the most popular ways to operate a computer means that evolution has made a general fuckup and our race is doomed.
Hallo, On Wed, 20 Mar 2002, Thorsten Haude wrote:
* David Haller
[02-03-19 22:27]: On Tue, 19 Mar 2002, Thorsten Haude wrote:
Die sendmail.cf hat allerdings große Ähnlichkeit mit /dev/random, ebenso wie die Konfigurationsdatei von Procmail. Unfug. Die procmailrc ist simpelst. Klar, simpelst. Erklär doch mal bitte die einzelnen Punkte der Liste weg, die ich in einer anderen Mail hatte.
Welche andere? -dnh -- "I have a very firm grasp on reality! I can reach out and strangle it any time!" -- from the BSD fortune file
participants (7)
-
B.Brodesser@t-online.de
-
Christoph Maurer
-
David Haller
-
Martin Schmitz
-
Michael Raab
-
Thilo A. Coblenzer
-
Thorsten Haude