Individuelle Mailserverkonfiguration ohne Procmail möglich?

    Hallo Leute,


    Ich beschäftige mich gerade mit der Mailserver-Konfiguration. Auf meinem Rootserver läuft Whezzy (minimal) und eine frische i-MSCP v1.1.0-rc1.4 Installation mit Postfix und Dovecot. Eine neue Domain wurde angelegt und darüber neue E-Mail-Accounts generiert. E--Mail-Empfang und -Senden läuft problemlos sowohl mit als auch ohne Verschlüsselung per POP3 und auch über IMAP. Lob an die Entwickler - reibungslose Funktion ohne großen Konfigurationsaufwand.


    Was ist aber nun, wenn ich den Mailserver etwas anders konfigurieren möchte. Beispielsweise in der Art, dass suspekte Mails gar nicht erst angenommen werden.
    Dazu wär Procmail dann nicht geeignet, da dieser Filter ja erst aktiv wird, wenn die Mails schon angenommen wurden. Ich würde nun gerne Procmail entfernen und statt dessen eine Filterung der Mails über Amavis mit Spamassassin und Clamav vor der Mailannahme durch Postfix implementieren.


    Nun die eigentlichen Fragen:
    1. Kann ich solche individuellen Konfigurationen in Postfix und Dovecot problemlos durchführen, oder gibt es da irgendwelche Abhängigkeiten mit i-MSCP, die ich dabei beachten muss?
    2. Kann ich Procmail einfach deinstallieren oder gibt es dann Probleme mit i-MSCP?
    3. Werden individuelle Konfigurationen in Postfix und Dovecot bei Upgrades von i-MSCP beibehalten? Und hat auch eine eventuelle Deinstallation von Procmail Bestand nach solch einem Upgrade oder wird es dabei einfach neu installiert?


    Gruß, Curio

    Edited once, last by Curio ().

    Früher mit Confixx habe ich Procmail auch mal eingesetzt - da waren allerdings die Mailuser nicht virtuell. Meine (subjektive!) Meinung ist, dass Procmail deprecated ist. Dovecot bietet zum Filtern eigene Mechanismen, die auf der Filtersprache sieve basieren. Das hat den Vorteil, dass es hierfür auch den in Dovecot integrierten Daemon managed-sieve gibt, über den Mailuser ihren Filter selbst konfigurieren können. So gibt es beispielsweise für Roundcube ein passendes Plugin. Setze ich auf meinem Server so ein - funktioniert auch für "nicht-Nerds" super. Auch für Squirrel gibts ein Plugin, wobei ich dieses für den Standarduser nicht so eingängig finde. Generell hat Dovecot eine ziemlich zentralle Rolle (in meinem System): Postfix nutzt den Auth-Mechanismus von Dovecot um User zu authentifizieren. Zudem wird nicht der MDA von Postfix, sondern (wie beschrieben) der von Dovecot benutzt (lda).


    Wenn du "verdächtige Mails" auf deinem Server abweisen willst, dann setze am besten Blacklisting ein. Das ist sehr ressourcenschonend, da Blacklisting methodisch lediglich auf einem DNS-Abruf basiert. An dieser Stelle ist es auch vorteilhaft non-fqdn-mail-from/to abzuweisen. Auf meinem System ist es so, dass über diese Filterung bereits rund 97% des Spams abgewiesen wird. Die restlichen drei landen dann in Amavis und über diesen in Spamassassin. Ich bin mir nicht sicher, ob es möglich ist, dies quasi als Policy in Postfix zu integrieren, so dass die Mail noch bei offener Verbindung nach dem Spamcheck abgewiesen wird. Nehmen wir an es geht - welchen Vorteil hast du dadurch? Rechenzeit wird eh verbraten und die Spambots scheren sich nicht drum ob sie abgewiesen werden - die probieren es weiterhin. Wenn du also sagst, dass der ganze Spam tatsächlich in /dev/null soll, dann definiere für sieve eine globale (default) Policy, in der steht, dass alle als Spam getaggten Mails, verworfen werden. Aber Achtung: besitzen Mailuser eine eigene Policy, so überschreibt diese die globale.


    Über mögliche Probleme bei Updates kann ich jetzt wenig sagen, da ich Gentoo einsetze und dort solche Sachen eh von Hand machen muss.

    Danke für Deine Ausführungen, biologist.
    Bei meine bisherigen Rootservern habe ich den Mailserver auch ziemlich genau so aufgebaut, wie Du es beschrieben hast. Auch mit dieser zentralen Rolle von Dovecot.
    Die Gründe der Filterung der Mails schon vor der Annahme durch Postfix hat keinen technischen, sondern eher einen rechtlichen Hintergrund. Damit vermeide ich jeden Konflikt mit dem Brief- und Postgeheimnis. Einmal angenommene Mails müssen dann nämlich auch zugestellt werden. Um dies zu realisieren nutze ich eben Amavis so zu sagen als Mail-Gateway.
    Sieve nutze ich bisher auch, allerdings als Filter für IMAP-Verzeichnisse.


    So weit so gut.
    Aber meine Frage betraf eher die Verknüpfung des Mailsystem mit i-MSCP. Kann ich meine individelle Konfiguration für Postfix und Dovecot und der Deinstallation von Procmail so beständig realisieren oder gibt es Probleme mit i-MSCP (z.B. Überschreiben bei i-MSCP-Updates/Upgrades)?


    Gruß, Curio

    Du kannst aber auch einfach die Pakete von Spamassassin, clamav und amavis installieren und in postfix einbinden. Einfach diesem tut folgen:
    http://colekcolek.com/2012/02/…is-ubuntu-debian-squeeze/


    WICHTIG:
    Einige Eigenschaften sind bereits in den configs vorhanden, müssen, wenn überhaupt, nur ausgeklammert werden.


    Beispiel /etc/postfix/main.cf:
    Folgende Zeile ist bereits vorhanden, nur ausgeklammert

    Code
    1. content_filter = smtp-amavis:[127.0.0.1]:10024


    [hr]
    Ach ja, vergessen auf deine letzte Frage einzugehen, bei nem Update oder Installation von imscp werden die alten config files überschrieben. Gilt übrigens auch bei apachefiles, wenn du an der Domain ne Kleinigkeit änderst.
    Die Templatefiles findest du aber unter /etc/imscp/
    Diese werden bei einer Neuinstallation aber auch immer gelöscht, bzw. aktualisiert. Sprich danach müsstest die wieder anpassen (mom).


    Mit dem Befehl erzeugst du die neuen Configfiles aus den Templatefiles in dem oben genannten Ordner:

    Code
    1. perl /var/www/imscp/engine/setup/imscp-setup

    Edited once, last by mafioso ().

    Ninos, Du bist echt fleißig - Respekt.


    Als Neuling erschließt sich mir Dein Post allerdings nicht so richtig.

    Quote

    bei nem Update oder Installation von imscp werden die alten config files überschrieben


    Ich nehme an, dass Du damit die Config-Files von Postfix, Dovecote, usw. meinst. Das wäre echt fatal. Ein Haufen Nacharbeit nach jedem Upgrade.
    Was ich nun aber mit den von Dir erwähnten "Template"-Files anfangen soll, habe ich nicht verstanden. Wie sollen die mir aus dem Dilemma helfen.


    Der Tenor aus deinem Post ist für mich:
    Nimm das System so wie's ist, ansonsten hast Du Probleme. Ist das tatsächlich so?
    Das bedeutet, das i-MSCP wie ein Korsett auf dem LAMP-System liegt und ich nicht mehr viele Freiheiten habe. Das war das Problem für mich bei Plesk.
    Das tolle an Admintools wie Froxlor oder jetzt i-MSCP sollte doch sein, dass man noch individuelle Konfigurationsmöglichkeiten für die Dienste hat. Habe ich da einen falschen Eindruck?


    Ich werde es einfach mal ausprobieren. Ich passe die Mailserverkonfiguration nach meinen Vorstellungen an und schau mal, was beim Update auf den nächsten RC passiert. Vorher werde ich allerdings sämtliche Config-Files sichern.


    Gruß, Curio

    Die Templatefiles definieren allgemeine Konfigurationsdateien mit Variablen, welche in den Files vorhanden sind, die dann beim generieren der configfiles zu den templatefiles die Variablen/Platzhalter befüllen mit gewissen Parametern.


    Also Beispiel, Apacheconfigfile:
    Willst du bei jeder Domain die Redirects entfernen, öffnest du die templatefiles in /etc/imscp/apache/parts/ ( oder so ähnlich :D ). Dort findest du allgemeine Templatefiles wie zum Beispiel domain-fcgi.tpl. Diese Templatedatei wird zum Beispiel verwendet, um die die Configfiles für Webseiten, welche mit fcgi laufen, zu erstellen.
    Der Inhalt der Datei lautet:

    Code
    1. <VirtualHost {DMN_IP}:80> <IfModule suexec_module> SuexecUserGroup {USER} {GROUP} </IfModule> ServerAdmin webmaster@{DMN_NAME} DocumentRoot {HOME_DIR}/htdocs ServerName {DMN_NAME} ServerAlias www.{DMN_NAME} {DMN_NAME} {ALIAS}.{BASE_SERVER_VHOST} Alias /errors {WWW_DIR}/{ROOT_DMN_NAME}/errors/ RedirectMatch permanent ^/ftp[\/]?$ {BASE_SERVER_VHOST_PREFIX}{BASE_SERVER_VHOST}/ftp/ RedirectMatch permanent ^/pma[\/]?$ {BASE_SERVER_VHOST_PREFIX}{BASE_SERVER_VHOST}/pma/ RedirectMatch permanent ^/webmail[\/]?$ {BASE_SERVER_VHOST_PREFIX}{BASE_SERVER_VHOST}/webmail/ RedirectMatch permanent ^/imscp[\/]?$ {BASE_SERVER_VHOST_PREFIX}{BASE_SERVER_VHOST}/ ErrorDocument 401 /errors/401.html ErrorDocument 403 /errors/403.html ErrorDocument 404 /errors/404.html ErrorDocument 500 /errors/500.html ErrorDocument 503 /errors/503.html....


    Möchtest du jetzt bei jeder Domain die Redirects entfernen, so entfernst du/klammerst du die RedirectMatch Einträge aus. Du kannst selbstverständlich auch weitere Änderungen individuell vornehmen^^
    Was ich mit Variablen meine, sind folgende Dinger hier:

    Code
    1. {HOME_DIR}{BASE_SERVER_VHOST_PREFIX}{BASE_SERVER_VHOST}{ALIAS}{USER} {GROUP}{DMN_IP}


    Diese Platzhalter werden bei der Erstellung der Configfiles individuell mit der z.B. {DMN_IP} -> Domain Ip, {USER} -> Benutzer... ersetzt.


    Über den Befehl

    Code
    1. perl /var/www/imscp/engine/setup/imscp-setup

    kannst du dann von den Templatefiles die neuen Configfiles erstellen. Du sparst dir bei vielen Domains etc. dadurch ne Menge Arbeit, weil du nicht jede Configdatei manuell editieren musst, sondern nur die Templatefiles editierst.


    Diese Templatefiles werden aber bei jedem imscp update überschrieben, das heißt, entweder musst du diese nach jedem Update neu editieren, oder du erstellst ein Plugin bzw. verwendest die von imscp gesetzten Hooks bei der Installation. Ich denke später wird man individuelle configfiles auch in einen separaten Ordner ablegen können (die Ordner sind bereits vorhanden).


    PS: solltest du Änderungen bei einer Domain vornehmen, wird die Configdatei von dem Templatefile neu erstellt. Das heißt, Änderungen würde ich direkt in die Templatefiles reinschreiben, sonst musst du später mal immer wieder selbst Hand anlegen, wenn du z.B. ner Domain ein Zertifikat hinzufügst und sich deswegen der Status der Domain im Adminbereich auf "In Bearbeitung" ändert.


    Hoffe das war alles einigermaßen verständlich erklärt^^

    Ja noch einmal herzlichen Dank, Ninos. Sehr verständliche Erklärung.:idea:


    Ich hatte mir die Template-Files schon angeschaut und das Konzept mit den Platzhaltern ist mir auch geläufig. Ich hatte darin nur keine Lösung für mein Problem mit einer individuellen Mailserverkonfiguration gefunden.
    Ich habe verstanden, dass ich mit Hilfe der Template-Files gleiche Parameter in multiplen Config-Files zentral beeinflussen könnte. Das Beispiel mit den verschiedenen vHosts macht das gut plausibel. Allerdings habe ich es im Mailserverbereich nur mit einzelnen sehr unterschiedlichen Config-Dateien zu tun. Da wird mir das nicht viel nützen.


    Das mit dem Überschreiben der Config-Dateien bei i-MSCP-Upgrades muss ich jetzt erst mal verdauen und überschlafen.
    Gutes Nächtle, Curio

    Soweit ich weiß, wird bei postfix doch eh nur die main.cf, master.cf und postfix.data von imscp überschrieben? Weil dann dürften nach nem Update deine individuellen configfiles bestehen bleiben.
    https://github.com/i-MSCP/imsc…ebian/postfix/install.xml


    Wo sind die denn abgelegt?


    Hehe, dann mal gn8 :D

    Edited once, last by mafioso ().

    Hello ;


    Well, I do not understand all the discussion here (barrier language) but still that I understand some words :D


    1. Procmail


    Procmail is installed for nothing and I'll surely make it optional in near future.
    See http://forum.i-mscp.net/Thread…estion?pid=11035#pid11035


    2. Persistent custom changes


    See http://forum.i-mscp.net/Thread…0-rc1-4-and-newer-version


    Note: All available hooks are not yet documented on the wiki but I bet you can easily pull them from the i-MSCP engine code.


    I would recommend to update to last Git Master. ;)


    Thank you for using i-MSCP.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

    SSH key for online support

    Edited once, last by Nuxwin ().

    @Ninos:
    Ja es geht mir im Moment vor allem um die Konfigurationsdateien des Mailservers mit Postfix und Dovecot. Die werden tatsächlich bei jedem Update überschrieben. Ich hab's heute mit der aktuellen Git Master getestet.


    Ich verstehe nicht wirklich, warum bei jedem Update die Configs der Programme überschrieben werden müssen. Warum kann es in der Installationsroutine von i-MSCP nicht so gelöst werden, das die individuellen Einstellungen der Configs bestehen bleiben und nur die speziellen i-MSCP betreffenden Einträge angepasst werden?
    Nach der Einlassung von Nuxwin scheint es so zu sein. dass die Entwickler einen anderen Weg gehen. Ich muss als Nutzer von i-MSCP meine individuellen Konfigurationseinträge "umständlich" über Hooks in die jeweilige Updateroutine einfließen lassen. Da können im Laufe der Zeit ne Menge Material zusammenkommen, was darüber hinaus noch ständig überwacht und an moderne Entwicklungen angepasst werden muss. Ist das eine wirklich gute Entwicklung?


    Bei meinem vorherigen Admintool "Froxlor" wurden bei Updates die main.cf, master.cf, und andere Konfigurationsdateien nicht angetaste. Drum bin ich so verwundert.


    Nuxwin
    Thanks for your help.
    to 1.: that's nice.
    to 2.: I have read your hook solution, and I will use that way. It is better than the way over the templates.
    But I really don't understand the development in this point. Would it not be much easier if the install script in the configuration files of Postfix, Dovecot, etc only changes the imscp-related parts and does not overwrite the whole files?


    Gruß, Curio

    Edited once, last by Nuxwin ().