eMail-Server - wie richte ich ein Postfach ein?

Hallo,
ich schreibe es mal allgemein. Trotz vielem Suchen und im Detail gefundener genauer Beschreibung für das Eine und Andere, bekomme ich irgendwie nicht richtig den Überblick zusammen. Vielleicht kann mir jemand helfen? Das ist mein erster eMail-Server und es soll sendmail sein.

Es läuft ein eMailserver der richtig konfigurriert werden muss. Dabei habe ich einige Verständnisprobleme. Die verwendeten services/daimons sind:
sendmail, SpamAssassin(spamd), (ggf. mit spamass_milter, clamav_clamd), procmail, dovecot
Eine globale Installation, also keine Useraccounts von Dritten auf der Maschine, mehrere virtuelle Domains mit diesbezüglichen User-eMailAdressen und natürlich "Postfächer+Maildirs(IMAP)" für die "User" sollen angelegt werden.

Folgendes ist mir klar:
sendmail ist der MTA er lauscht auf div Ports u.a. 25, nimmt eMail entgegen und leitet sie weiter (an andere Server oder an Postfächer). Zum Konfigurieren hierfür nehme ich die spezifische "server".mc datei und die konfigurationsdateien: (access, alias, mailertable, virtualusertable). Diverse Filter und andere Dinge können über die *.mc Datei in sendmail eingebaut werden, wie "blacklist_recipients" u. defines für SSL Zeug - cert.pem/key muss hierfür erstellt sein, Auth Stuff, zusätzliche Verbindunng TLS, usw.) Und diverse MAILER(xxx) über die eMail weitergeleitet wird werden hier angegeben.
procmail dient zum Filtern der zu liefernden eMail an die Postfächer (z.Bsp durch Einbindung von Spamassasin-Client, etc)
dovecot der LDA und MDA schiebt die eMails in die Postfächer die wohl eigentlich (virt.) "User" sind. Die User können sich über Ihren MUA (Outlook, Thunderbird etc.) anmelden und dann mittels IMAP oder POP3 was dovegot zu Verfügung einfach oder verschlüsselt Ihre eMails lesen/abholen.

Soweit so gut! Für alles gibt es jeweils verschiedenste teils ausführliche Beschreibungen. Ich habe aber keine gefunden die wirklich mal den Zusammenhang erklärt, der meiner eMail-Umgebung entspricht.

Fragen: wie kommt die eMail über sendmail in ein Postfach? Woher weis sendmail, dass er die eMail über procmail nach dovegot schicken soll?
Wie bestimmt sendmail das SpamAssassin, camav,etc wann nach eintreffen einer eMail durchlaufen wird (Reihenfolge der MAILER zB? oded Reihenfolge der FUTURE-Angaben?)?
Wo ist das Postfach für IMAP, bzw die Maildirs-Verzeichnisse (dovegot läuft aber in /var/mail/ od. /var/spool/mail/ tut sich nichts (auch nicht nach einer Testemail von der Konsole)?
Sind die Postfächer die "Virtuellen User Accounts (auf dem alten vServer mit mbox war das anscheinend so)"?
Wo richte ich die Postfächer ein (virtusertable, mit irgendeiner dovecot2 conf-Datei), wenn ich keine OS-Accounts dafür haben will?
Wie wird der LDA mit sendmail aktiviert?
Wenn ich mit MySQL und Dovecot Virtuelle UserAccounts einrichte (Tabelle anlegen + conf-Datei und Abfragen bearbeiten) muss dann sendmail auch darauf zugreifen?
Wenn Dovegot für SSL konfiguriert wird kommt sendmail mit SASL dann auch damit klar?
Wenn Nein, wo und wie stelle ich das Zusammenspiel dann ein?

Gibt es hier Hilfe für alle meine Fragen?
Grüsse Harald
 
Fragen: wie kommt die eMail über sendmail in ein Postfach? Woher weis sendmail, dass er die eMail über procmail nach dovegot schicken soll?
Sendmail weiß, daß die Mail an procmail weitergeleitet werden soll, nicht mehr und nicht weniger, und zwar durch
Code:
FEATURE(`local_procmail')dnl
…
(*nach* den Definitionen für MAILER(`local') und MAILER(`smtp')
MAILER(`procmail')dnl
Wie bestimmt sendmail das SpamAssassin, camav,etc wann nach eintreffen einer eMail durchlaufen wird (Reihenfolge der MAILER zB? oded Reihenfolge der FUTURE-Angaben?)?
Gar nicht. Das sagst du procmail durch entsprechende Regeln in /etc/procmailrc
Wo ist das Postfach für IMAP, bzw die Maildirs-Verzeichnisse (dovegot läuft aber in /var/mail/ od. /var/spool/mail/ tut sich nichts (auch nicht nach einer Testemail von der Konsole)?
Wie genau hast du sendmail, procmail und dovecot konfiguriert? Die Konfigurationsdateien (gegebenenfalls eben Domainnamen etc. anonymisieren).
Sind die Postfächer die "Virtuellen User Accounts (auf dem alten vServer mit mbox war das anscheinend so)"?
Wo richte ich die Postfächer ein (virtusertable, mit irgendeiner dovecot2 conf-Datei), wenn ich keine OS-Accounts dafür haben will?
Der virtusertable benutzt Sendmail, um Mailadressen und Domains auf echte Mailboxen zu mappen. Dovecot bekommt davon nichts mit. Was du suchst, ist wahrscheinlich sowas: http://wiki.dovecot.org/VirtualUsers
Wie wird der LDA mit sendmail aktiviert?
Du läßt procmail an Dovecot ausliefern.
Wenn ich mit MySQL und Dovecot Virtuelle UserAccounts einrichte (Tabelle anlegen + conf-Datei und Abfragen bearbeiten) muss dann sendmail auch darauf zugreifen?
Nein.
Wenn Dovegot für SSL konfiguriert wird kommt sendmail mit SASL dann auch damit klar?
Die lokale Kommunikation sendmail -> Dovecot hat nichts mit SSL oder SASL zu tun.
 
Hallo Harald,

ich bin jetzt auch kein Experte was Mailserver anbelangt ... versuche trotzdem kurz deine Gedanken zu ordnen.

Da ich eher ein Postfixjünger bin (nicht weil sendmail "schlechter" ist sondern einfach weil mir postfix mehr "liegt") kann ich dir nur aus Postfix-sicht schreiben. Das Prinzip sollte aber das gleiche sein. Alle Forenmitglieder sind herzlich eingeladen mich an jeder Stelle zu verbessern!

Frage: Wie kommt die E-Mail in das Postfach.
Einfache Antwort: Der versendende Server verbindet sich (durch DNS Lookup) mit deinem Server. Hier können schon die ersten Blacklists greifen (zB wenn dein Mailserver von einer dynamischen IP deines Providers sendet, keinen MX Record hat, SpamAssasin usw). Wenn dein Mailserver die Verbindung akzeptiert nimmt er die E-Mail entgegen und fängt an Sie zu verarbeiten. Nach evtl. Scan durch ClamAV uä. stellt er die Mail zu. Du kannst hier wählen wer die Mail zustellen soll: der Mailserver kann sie an Procmail weiterleiten (procmail schaut dann in nach einer .procmailrc im Benutzerverzeichnis und leitet sie entsprechende der procmail-regeln in das lokale Postfach des Users), dem Dovecot LDA geben (dieser macht ähnliches wie procmail - nimmt aber dafür sieve-skripte und hält den dovecot imap-index auf dem laufenden). Dort angekommen sind die Mails für deinen User sichtbar.

Damit wäre die Basis geschaffen, dass dein Mailserver E-Mails zustellen kann (das sollte man als erstes durch spielen).

Grundlegend müssen alle deine Server auf den gleichen Mailbestand zugreifen. Wie die einzelnen Prozesse darauf zugreifen ist Konfiguration der einzelnen Dienste. Dovecot und Postfix "unterhalten" sich nur sehr wenig miteinander - wenn dann eher zu Authentifizierungszwecken. Wie Procmail, Sendmail, Dovecot usw mit E-Mails umgehen ist Konfigurationssache der einzelnen Dienste. Wenn Dovecot die Authentifizierung mittels einer sqlite Datenbank vornehmen kann, muss dass sendmail nicht unbedingt auch beherrschen.

Mein (ziemlich wertloser) tipp: Setze dir mal eine Testumgebung auf und versuche Sie mit den Basisdiensten (ohne virtuelle accounts, spamassasin, virenscanner) zum arbeiten zu bewegen. PN an mich wenn du dabei Hilfe brauchst.


Gruß,

Marlboro
 
Hallo,
vielen dank.
@waki87 erst mal eine erste Rückfrage:
Sendmail weiß, daß die Mail an procmail weitergeleitet werden soll, nicht mehr und nicht weniger, und zwar durch

FEATURE(`local_procmail')dnl

Damit dovecot aufgerufen werden soll hatte ich folgendes gefunden und in die mc-Datei eingetragen:
Code:
FEATURE(`local_procmail', `/usr/local/libexec/dovecot/dovecot-lda', `/usr/local/libexec/dovecot/dovecot-lda -f $g -d $u')dnl

...und später

dnl MAILER(`cyrusv2')dnl
MAILER(dovecot)dnl	    for LDA/MDA (Pop3 + IMAP)
Was hältst Du davon? Ist das falsch?

------------
http://wiki.dovecot.org/VirtualUsers - den Eintrag kenne ich "There are many ways to configure Dovecot ..."
Soll ich nach einer Lösung suchen (oder erfinden) wie man über procmail in die Datenbank schreibt?
Und dort steht auch nichts davon wie dovcote mit den usern aus der DB die Maildir++ Verzeichnisse erzeugt...

Ah, ja und wenn procmail dafür zuständig ist mails nach dovegot zuliefern, wieso muss ich dann noch einen Eintrag
MAILER(dovecot)dnl in die mc-Datei setzten (die dovecot.mc Datei wurde wie bei dovecot beschreiben hinzugefügt)

==> siehe Beschreibung Dovecot LDA with Sendmail
http://wiki2.dovecot.org/LDA/Sendmail
das habe ich gemacht

Die lokale Kommunikation sendmail -> Dovecot hat nichts mit SSL oder SASL zu tun.
in http://wiki2.dovecot.org/Sasl steht geschreiben "Dovecot has its own SASL implementation which may at some point be separated from Dovecot itself to "compete" against Cyrus SASL library in server side." und .. http://wiki2.dovecot.org/SSL sowie Configuring Dovecot to use SSL certificates http://wiki2.dovecot.org/SSL/DovecotConfiguration

In meiner *.mc Datei habe ich aber bereits nach anderer Anleitung eingegeben:
Code:
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl # -> For this to work your OpenSSL certificates must be configured.
dnl #
DAEMON_OPTIONS(`Port=smtps, 	 Name=MTA-SSL,    Family=inet, M=s')dnl
Daher noch mal die Frage: Wenn Dovegot für SSL konfiguriert wird kommt sendmail mit SASL dann auch damit klar? Oder muss das Eine aus sendmail dann wieder raus.

--------------------------
Insgesamt habe ich den Eintruck von widersprüchlichen Aussagen: einaml heist heiß "nimm für alles procmail" dann wieder "Du kannst hier wählen wer die Mail zustellen soll: der Mailserver kann sie an Procmail weiterleiten ..., dem Dovecot LDA geben" wohl direkt in sendmail.mc konfiguriert.
Welche Lösung wäre die bessere und warum?

Gibt es irgendwo mal eine komplette Anleitung wie dovecot mit sendmail zu konfigurieren ist?
Ich finde immer nur dovecot mit postfix und exim.
 
Zuletzt bearbeitet:
Hallo,
vielen dank.
@waki87 erst mal eine erste Rückfrage:


Damit dovecot aufgerufen werden soll hatte ich folgendes gefunden und in die mc-Datei eingetragen:
Code:
FEATURE(`local_procmail', `/usr/local/libexec/dovecot/dovecot-lda', `/usr/local/libexec/dovecot/dovecot-lda -f $g -d $u')dnl

...und später

dnl MAILER(`cyrusv2')dnl
MAILER(dovecot)dnl	    for LDA/MDA (Pop3 + IMAP)
Was hältst Du davon? Ist das falsch?
Das finde ich ziemlich obskur. Damit sagst du sendmail quasi »Der Pfad zu procmail ist /usr/local/libexec/dovecot/dovecot-lda.«, was offensichtlich nicht stimmt. Damit das überhaupt funktioniert, müßtest du statt MAILER(dovecot) auch MAILER(procmail) unten eintragen.
*Oder* du erstellst die dovecot.m4-Datei wie in dem Wiki-Artikel beschrieben und benutzt dann MAILER(dovecot).
In beiden Fällen wird aber procmail nicht benutzt. Sendmail liefert dann direkt an Dovecot aus. Wenn du ganz unbedingt Virtual Users in Dovecot brauchst (s.u.), halte ich das zwar für die richtige Lösung, aber du verlierst damit die Flexibilität, die dir procmail bietet. Außerdem müßtest du dann Spam- und Antivirusfilter auch direkt in Sendmail einbinden.

------------
http://wiki.dovecot.org/VirtualUsers - den Eintrag kenne ich "There are many ways to configure Dovecot ..."
Soll ich nach einer Lösung suchen (oder erfinden) wie man über procmail in die Datenbank schreibt?
Und dort steht auch nichts davon wie dovcote mit den usern aus der DB die Maildir++ Verzeichnisse erzeugt....
Procmail in Verbindung mit Dovecot und Virtual Users richtig zu konfigurieren ist, soweit ich das sehe, leider wohl unmöglich (aber vielleicht kann mich hier jemand anderes aus dem Forum berichtigen). Procmail hat schlicht und ergreifend bei Virtual Users in einer SQL-Datenbank keine Möglichkeit herauszufinden, an welchen Benutzer eine Mail jetzt gehen soll. Aber vielleicht überlegst du dir die Sache nochmal – ist das erforderliche Setup so komplex, daß lokale Benutzer in Verbindung mit /etc/aliases nicht ausreichen?

Ah, ja und wenn procmail dafür zuständig ist mails nach dovegot zuliefern, wieso muss ich dann noch einen Eintrag
MAILER(dovecot)dnl in die mc-Datei setzten (die dovecot.mc Datei wurde wie bei dovecot beschreiben hinzugefügt)
Müßtest du nicht, wenn du procmail benutzen wolltest. Richtig wäre dann MAILER(procmail) (aber nur mit FEATURE(`local_procmail') ohne Pfadangabe zum Dovecot-LDA).

in http://wiki2.dovecot.org/Sasl steht geschreiben "Dovecot has its own SASL implementation which may at some point be separated from Dovecot itself to "compete" against Cyrus SASL library in server side." und .. http://wiki2.dovecot.org/SSL sowie Configuring Dovecot to use SSL certificates http://wiki2.dovecot.org/SSL/DovecotConfiguration

In meiner *.mc Datei habe ich aber bereits nach anderer Anleitung eingegeben:
Code:
dnl # The following causes sendmail to additionally listen to port 465, but
dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed
dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't
dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS
dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps
dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.
dnl # -> For this to work your OpenSSL certificates must be configured.
dnl #
DAEMON_OPTIONS(`Port=smtps, 	 Name=MTA-SSL,    Family=inet, M=s')dnl
Daher noch mal die Frage: Wenn Dovegot für SSL konfiguriert wird kommt sendmail mit SASL dann auch damit klar? Oder muss das Eine aus sendmail dann wieder raus.
Nochmal: SSL in Sendmail hat nichts mit SASL in Dovecot zu tun. Sendmail benutzt SSL/STARTTLS, um für verschlüsselte Kommunikation zu anderen Mailservern im großen bösen Internet zu sorgen. Die Auslieferung von Mails erfolgt dann lokal (und natürlich unverschlüsselt).
Dovecot hingegen verschlüsselt die Kommunikation zum IMAP/POP3-Client (also dem Endbenutzer), der von irgendwo seine Mails abrufen will. Sendmail ist das wurscht.

--------------------------
Insgesamt habe ich den Eintruck von widersprüchlichen Aussagen: einaml heist heiß "nimm für alles procmail" dann wieder "Du kannst hier wählen wer die Mail zustellen soll: der Mailserver kann sie an Procmail weiterleiten ..., dem Dovecot LDA geben" wohl direkt in sendmail.mc konfiguriert.
Welche Lösung wäre die bessere und warum?
Procmail wäre meiner Ansicht nach immer noch die beste Lösung. Du kannst Spam-, Antivirus- und andere Filter einfach um ein Vielfaches leichter einbinden. Nutzer können ihre eigenen Regeln erstellen, ohne den Administrator bemühen zu müssen (~/.procmailrc). Nachteil ist nunmal, daß procmail nicht mit Dovecot Virtual Users zusammenspielt. Aber wie gesagt, ich würde mir überlegen, ob du das wirklich brauchst (bei weniger als 65535 Benutzern würde ich sagen »nein.« :D ).

Gibt es irgendwo mal eine komplette Anleitung wie dovecot mit sendmail zu konfigurieren ist?
Ich finde immer nur dovecot mit postfix und exim.
Leider nicht daß ich wüßte. Aber immerhin bist du schonmal auf einem guten Weg. :)
 
Hallo waki87
vielen Dank, endlich mal einer der vernünftig antwortet (ich bekomme in Foren immer wieder mal so schwachsinnige Antworten, das einem kraut..;) )
Jetzt sind mir einige Dinge klarer. Bei FEATURE(`local_procmail'...) hatte ich den Gedanken das MAILER(procmail) und local_procmail nicht für das selbe stehen. Ich dachte "local processing mail" = "lokale Verarbeitung Mail" könnte auch allgemein sein und nur so ähnlich heißen.
Procmail in Verbindung mit Dovecot und Virtual Users richtig zu konfigurieren ist, soweit ich das sehe, leider wohl unmöglich ... Procmail hat schlicht und ergreifend bei Virtual Users in einer SQL-Datenbank keine Möglichkeit herauszufinden, an welchen Benutzer eine Mail jetzt gehen soll.
OK - das ist mal eine Aussage! Meine Idee war bei Virtuellen Usern diese elegant mit der MySQL Datenbank zu verwalten ohne das der Account auf dem Server wirklich exestiert (und dieser wohl so auch weniger angreifbar wäre) Außerdem erschien mir die Verwaltung mit INSERT, UPDATE, DELETE etc. einfacher, vorausgesetzt was ich noch nicht weis, dass dovecot dann von selber für die eingetragenen User die Maildir-Verzeichnisse anlegt und organisiert.

ist das erforderliche Setup so komplex, daß lokale Benutzer in Verbindung mit /etc/aliases nicht ausreichen?
Nein - es gibt allerdings keine "echten" lokalen Benutzer - ich würde diese Useraccounts nur anlegen damit diese eMail-Postfächer/und Maildirs haben können. Ich möchte beides machen können, mit POP und IMAP zugreifen können.
Procmail wäre meiner Ansicht nach immer noch die beste Lösung. Du kannst Spam-, Antivirus- und andere Filter einfach um ein Vielfaches leichter einbinden. Nutzer können ihre eigenen Regeln erstellen,
Wie gesagt Nutzer habe ich eigentlich keine. Aber für das Einbinden von Spam-, Antivirus- und anderen Filtern finde ich immer wieder Rezepte für die *.mc Datei nicht für procmail.
Wie funktioniert das genau - die eMail kommt an wird an procmail übergeben dieser leitet sie durch spamd durch filtert dann je nach Header die mails raus übergibt sie dann einem Antivrus program und ggf. weiteren Filtern - dann gibt procmail die mail zurück zu sendmail damit dieser diese dann local in das postfach ausliefern kann?
Wäre es nicht besser Spamfilterung voher zu machen bevor die mail lokal ausgeliefert wird.

Ich habe hierfür z.B sowas eingetragen:
Code:
FEATURE(blacklist_recipients)dnl
FEATURE(`dnsbl',`sbl-xbl.spamhaus.org',`"550 SPAM MAIL REJECTED from "$&{client_name}"! Please see http://www.spamhaus.org/sbl for details.'")dnl
dnl # Probs mit Domainzugriff relays.ordb.org
dnl #FEATURE(`dnsbl',`relays.ordb.org', `"550 E-Mail rejected due to sending server misconfiguration - see http://www.ordb.org/faq/\#why_rejected"')dnl
FEATURE(`dnsbl',`bl.spamcop.net', `"Spam blocked see: http://spamcop.net/bl.shtml?"$&{client_addr}', `t')dnl
FEATURE(`dnsbl',`dsn.rfc-ignorant.org',`550 You do not accept bounces - http://www.rfc-ignorant.org/')dnl

Ich wüsste jetzt nicht wie ich das mit procmail machen sollte. (?)

@Marlboro: danke Dir auch für die Aufklärung. die Idee "erst mal nur Basiskonfiguration" ohne Filter und weiteren Dingen wie IMAP ist gar nicht so eine schlechte Idee, das macht man ja sonst auch.

viele Grüße - Harald
 
Generell sollten Virenfilter oder auch der gute SA und viele andere unbedingt so frueh wie moeglich greifen, nicht erst _nach_ der Annahme der Email. Ich empfehle daher dringend die Nutzung der Milterschnittstelle von sendmail. Eigentlich braucht kein Mensch procmail, zumindest konnte mir noch nie jemand einen guten Grund nennen.
 
OK - das ist mal eine Aussage! Meine Idee war bei Virtuellen Usern diese elegant mit der MySQL Datenbank zu verwalten ohne das der Account auf dem Server wirklich exestiert (und dieser wohl so auch weniger angreifbar wäre) Außerdem erschien mir die Verwaltung mit INSERT, UPDATE, DELETE etc. einfacher, vorausgesetzt was ich noch nicht weis, dass dovecot dann von selber für die eingetragenen User die Maildir-Verzeichnisse anlegt und organisiert.
Virtuelle Nutzer sind keinesfalls »eleganter« oder einfacher als echte Unix-Benutzer. Im Gegenteil: Du fügst damit ein künstliches Element an Komplexität hinzu, das die Administration nur schwieriger macht. Die Sicherheit wird durch das bloße Vorhandensein von Benutzeraccounts auch nicht beeinträchtigt. Du mußt denen ja keine anderen Dienste als POP/IMAP anbieten.

Wie gesagt Nutzer habe ich eigentlich keine. Aber für das Einbinden von Spam-, Antivirus- und anderen Filtern finde ich immer wieder Rezepte für die *.mc Datei nicht für procmail.
Wie funktioniert das genau - die eMail kommt an wird an procmail übergeben dieser leitet sie durch spamd durch filtert dann je nach Header die mails raus übergibt sie dann einem Antivrus program und ggf. weiteren Filtern - dann gibt procmail die mail zurück zu sendmail damit dieser diese dann local in das postfach ausliefern kann?
Wäre es nicht besser Spamfilterung voher zu machen bevor die mail lokal ausgeliefert wird.
Nein. Procmail liefert die Mail dann mit dem deliver-Programm von Dovecot aus. Gäbe er sie zurück an sendmail, wären die Mails ja in einer endlosen Schleife gefangen.

Ich habe hierfür z.B sowas eingetragen:
Code:
FEATURE(blacklist_recipients)dnl
FEATURE(`dnsbl',`sbl-xbl.spamhaus.org',`"550 SPAM MAIL REJECTED from "$&{client_name}"! Please see http://www.spamhaus.org/sbl for details.'")dnl
dnl # Probs mit Domainzugriff relays.ordb.org
dnl #FEATURE(`dnsbl',`relays.ordb.org', `"550 E-Mail rejected due to sending server misconfiguration - see http://www.ordb.org/faq/\#why_rejected"')dnl
FEATURE(`dnsbl',`bl.spamcop.net', `"Spam blocked see: http://spamcop.net/bl.shtml?"$&{client_addr}', `t')dnl
FEATURE(`dnsbl',`dsn.rfc-ignorant.org',`550 You do not accept bounces - http://www.rfc-ignorant.org/')dnl

Ich wüsste jetzt nicht wie ich das mit procmail machen sollte. (?)
Das bewirkt etwas vollkommen anderes als Spamassassin. Eine DNS-Blacklist ist dazu da, Hosts herauszufiltern, von denen gar keine Mail akzeptiert wird. Spamassassin wird dahinter geschaltet und kümmert sich um die Spam-Mails, die trotzdem durchkommen.

@j_t: Warum? Spam-Mail sollte ja sowieso mit ausgeliefert werden, um sie nach False Positives durchsuchen zu können. Ob Spamassassin jetzt von sendmail oder procmail aufgerufen wird, ist wurscht. Natürlich kann man sendmail Spam auch über Milter filtern lassen, aber wozu die Mühe, wenn man hinterher sowieso procmail aufruft, um seine anderen Filter laufen zu lassen?
 
Offensichtlichen SPAM blockt man. Warum sollte man den Muell annehmen. Wozu habe ich dann denn einen Spamfilter? Oder kann procmail Emails ebenfalls bereits zu Beginn der Kommunikation blocken?
Deine Definition des SA ist uebrigens sehr seltsam.
 
Das mit dem »offensichtlichen Spam« ist nicht so einfach. SA ist ja nicht unfehlbar. Willst du etwa blind alle Mails wegschmeißen, die SA zu »Spam« deklariert? Natürlich sollte auch erkannter »Spam« zur manuellen Durchsicht ausgeliefert werden. So kann man Spamassassin dann ja auch an Ham *und* Spam lernen lassen.

Im Übrigen wird ja das allermeiste (erfahrungsgemäß) schon von der Blacklist gefangen.
 
OK. Ich klinke mich aus der Diskussion aus. Die Vorstellungen ueber sinnvolle Emailserver weichen zu sehr ab.
 
OK. Ich klinke mich aus der Diskussion aus. Die Vorstellungen ueber sinnvolle Emailserver weichen zu sehr ab.
Hi - du bauchst dich nicht ausklinken es geht hier nicht darum wie man SPAM filtert, sondern wie ich die Konfiguration hin bekomme.
Eigentlich braucht kein Mensch procmail, zumindest konnte mir noch nie jemand einen guten Grund nennen.
Ein Grund wäre wie es waki87 schreibt, dass es viel einfacher zu konfigurieren ist. Aber da müsste ich erst mal ein paar Beispiele sehen wie macht man es mit "sendmail".mc und Filtern und wie macht man es mit procmail, dann kann ich mich auch entscheiden was meine Meinung dazu ist.

Also wen ich es richtig verstanden habe gibt es bei z.B. der Spammfilterung jetzt 3 Wege?
1. mit Filtern in "sendmail".mc
2. mit procmail
3. mit dovecot und der, mir noch unbekannten, "sieve" Schnittstelle (sieve-skripte).
Und man macht nur eins von den Dreien - richtig?
Und wenn man sich für eine der 3 Methode entschieden hat, dann macht man das auch so für Antivirus - richtig?

Wie schiebt procmail die mail in die Postfächer? Ich habe hier mal ein Version von meinem alten vServer (Confixx - SWsoft)
Code:
LOGFILE=/var/log/procmail.log
#VERBOSE=on
VERBOSE=off


# Path zum SpamAssassin Clienten
SPAMASSASSIN=/usr/bin/spamc

# SpamAssassin Lockfile
LOCKFILESPAMC=/var/spool/procmail/.spamclock

# Procmail Lockfile
LOCKFILEPROCM=/var/spool/procmail/.proclock

# die Mailbox in die Spam gelangen soll
SPAMBOX=/var/spool/mail/spam


# Mails durch Spamassassin schleusen und X-Spam-Status Flag setzen
# fw der ersten Regel sorgt dafür, dass Procmail wartet, bis das Programm fertig ist.
# Das angefügte H der beiden folgenden Regeln sorgt dafür, dass nur die Header der E-Mail durchsucht werden
#HL-091117 nur mails kleiner als 1024 kb ueberpruefen
#
#:0fw: $LOCKFILESPAMC
:0fw
* < 1024000
| $SPAMASSASSIN

#HL-091711 Mails mit X-Spam-Status Flag in Spambox leiten
:0H: $LOCKFILEPROCM
* ^X-Spam-Flag: Yes
| $SPAMBOX

Ich finde da nichts wie die mail in die mailbox kommt :confused:

viele Grüße Harald
 
Hi - du bauchst dich nicht ausklinken es geht hier nicht darum wie man SPAM filtert, sondern wie ich die Konfiguration hin bekomme.
Ein Grund wäre wie es waki87 schreibt, dass es viel einfacher zu konfigurieren ist. Aber da müsste ich erst mal ein paar Beispiele sehen wie macht man es mit "sendmail".mc und Filtern und wie macht man es mit procmail, dann kann ich mich auch entscheiden was meine Meinung dazu ist.

Also wen ich es richtig verstanden habe gibt es bei z.B. der Spammfilterung jetzt 3 Wege?
1. mit Filtern in "sendmail".mc
2. mit procmail
3. mit dovecot und der, mir noch unbekannten, "sieve" Schnittstelle (sieve-skripte).
Und man macht nur eins von den Dreien - richtig?
Und wenn man sich für eine der 3 Methode entschieden hat, dann macht man das auch so für Antivirus - richtig?
Jap, genau. Wobei man bei Methode 1 natürlich noch beachten muß, daß Spam-Mail dann in einen eigenen Ordner und nicht die INBOX ausgeliefert werden soll. Das habe ich mit sendmail alleine bisher noch nicht hinbekommen, man bräuchte also doch wieder ein dahintergeschaltetes procmail oder Sieve-Skript.

Wie schiebt procmail die mail in die Postfächer? Ich habe hier mal ein Version von meinem alten vServer (Confixx - SWsoft)
Code:
LOGFILE=/var/log/procmail.log
#VERBOSE=on
VERBOSE=off


# Path zum SpamAssassin Clienten
SPAMASSASSIN=/usr/bin/spamc

# SpamAssassin Lockfile
LOCKFILESPAMC=/var/spool/procmail/.spamclock

# Procmail Lockfile
LOCKFILEPROCM=/var/spool/procmail/.proclock

# die Mailbox in die Spam gelangen soll
SPAMBOX=/var/spool/mail/spam


# Mails durch Spamassassin schleusen und X-Spam-Status Flag setzen
# fw der ersten Regel sorgt dafür, dass Procmail wartet, bis das Programm fertig ist.
# Das angefügte H der beiden folgenden Regeln sorgt dafür, dass nur die Header der E-Mail durchsucht werden
#HL-091117 nur mails kleiner als 1024 kb ueberpruefen
#
#:0fw: $LOCKFILESPAMC
:0fw
* < 1024000
| $SPAMASSASSIN

#HL-091711 Mails mit X-Spam-Status Flag in Spambox leiten
:0H: $LOCKFILEPROCM
* ^X-Spam-Flag: Yes
| $SPAMBOX

Ich finde da nichts wie die mail in die mailbox kommt :confused:

viele Grüße Harald

Bei der Verwendung von Dovecot schreibst du Mail nicht, wie hier, direkt in die Postfächer, sondern verwendest das »deliver«-Programm von dovecot (/usr/local/libexec/dovecot/deliver o.ä.; Dokumentation: http://wiki.dovecot.org/LDA). Außerdem brauchst du für jeden User dann eine ~/.procmailrc, in der erstmal nur drinsteht, daß Mails an dovecots »deliver« übergeben werden sollen. Die letzte Regel in deinem Beispiel wäre also richtigerweise:

Code:
:0H: $LOCKFILEPROCM
* ^X-Spam-Flag: Yes
|/usr/local/libexec/dovecot/deliver -d $LOGNAME -m Spam
(wobei die Mailbox Spam natürlich für jeden Benutzer auch existieren muß.)
 
Zurück
Oben