.

Es scheint eine einfache Lösung zu werden, einen Linux basierten Mailserver unter Verzicht auf alle Altlasten völlig neu aufzusetzen. Jedenfalls scheint es so. Man nehme die neue opensuse 13.2, dazu postfix, Dovecot und Roundcube und noch ein paar Ingredenzien - und schwups ist alles fertig - so die graue Theorie. Doch man braucht auch den phpMyAdmin für die mariadb Datenbank (ehemals mysql). Und die diversen Admin-Zugänge sollen natürlich per ".htaccess" Dateien richtig abgesichert, also dicht gemacht werden.
.

Das bedeutet, das ganze System läuft von nun nur noch unter "https", also werden die Browser- Server-Verbindungen SSL verschlüsselt. Eigentlich ist das nur für den Austausch der Zugangs-Passwörter notwendig. Denn die unverschlüsselten Mails sind ja von den diversen "Diensten" sowieso bereits gesannt und durchgelesen. Zu diesen Sicherheitsgedanken gehört selbstverständlich eine saubere Konfiguration des Webservers und des/der virtuellen Hosts - natürlich mit den per ".htaccess" abgeblockten Zugängen zu den drei verschiedenen Administrations-Ebenen.

Wie bereits früher erläutert, sind Senden und Empfangen von Mails zwei getrennte paar "Schuhe" und die Adminstration der Server.Module ist der dritte "Schuh".
.

Eine virtuelle Maschine installiere ich mit dem VM-Manger aus meiner DOM0 heraus. Und diese neue VM bekommt den Namen mail3.ipw.net auf einer eigenen physikalischen 40 Giga Platte. Ich kann also aus einer opensuse 12.3 DOM0 Umgebung eine DOMU (Gast-VM) unter 13.2 aufsetzen. Dort wähle ich 1 GB RAM und 2 CPUs aus und selektiere gleich am Anfang die kleinst mögliche textbasierte Netzwerk-Installation mit 700 MB. Ich möchte nämlich ganz gezielt nur die Module nachinstallieren, die ich wirklich brauche. Der neue Roundcube 1.0 Mailserver soll von außen per Webinterface administriert werden, also brauche ich kein X11 (das wären 2 Gigabyte Download) oder bei KDE sogar noch mehr.
.

Nach der Version 12.3 wurde YAST (und auch das grafische YAST2) auf "neue Beine" gestellt. Laut der Doku wurden die alten Programme mit halbautomatischen Scripten convertiert und sehen optisch fast genauso aus wie früher. Doch die Ladezeiten haben sich mindestens verdreifacht, nach "Gefühl" verzehnfacht. Das hindert doch schon ein bischen am flüssigen Administrieren.
.

Seit über 20 !! Jahren hat der Apache Webserver bei uns exzellente Dienste geleistet und auch mit mysql (inzwischen heißt es mariadb) sind wir hier bei uns recht zufrieden. Dazu brauchen wir postfix als Mail-Transport Agent, Dovecot und Roundcube zum webbasierten SMTP Senden und POP3/IMAP Abrufen und natürlich den PhpMyAdmin für die Datenbank- Administration. Das klingt doch alles sehr gesund und das textbasierte YAST (also nicht die Grafikversion yast2) machts möglich. Dazu haben wir eine Menge laufender Webs zum Vergleich, von denen man immer abkupfern kann, was an Konfiguratioen gebaucht wird, also alles ganz easy ...... wenn da nicht jede Menge Fallstricke lauern ...... und jetzt kommts.
.

Zum Grundkonzept eines Webservers gehört bei uns die prinzipelle Einrichtung von virtuellen hosts, die sogenannten vhost Konfigurationen. Der Apache hat dazu ausgekügelte Schutzmechanismen, damit kein Fremder (meist aus Fernost) und auch kein Nachbar dem anderen schaden kann.

In den fünf (5) Konfigurationsverzeichnissen des Apache
.

1. /etc/apache2
2. /etc/sysconfig
3. /etc/apache2/sysconfig.d
4. /etc/apache2/vhosts.d/
5. /etc/apache2/conf.d

.
gibt es sogenannte xxx.conf Dateien, in denen genau festgelegt wird, ob überhaupt und wo irgendjemand irgendetwas darf.
.

Wir haben auf diesem Server fogende Revisionen :
.

• opensuse (xen) x86_64 Version 13.2
• Apache 2.4.10
• PHP Version 5.6.1
• mariadb Version: 10.0.15/16

.

In der /etc/apache2/httpd.conf steht schon mal drinnen, daß prizipiell "niemand gar nichts darf" und das sieht so aus.
.

• <Directory /> # das gilt für den gesamten Server in allen Ecken
      Options None
      AllowOverride None
      Require all denied # diese Option ist neu und ersetzt zwei alte Optionen
  </Directory>

.
Der Admin muß ganz gezielt erlauben, wo und unter welchem Namen jemand etwas darf.
.
Das macht der Admin auf zweierlei Art und Weise. In der vhost.conf Datei für einen der virtuellen hosts bestimmt er die Ausnahmen für ein ganz bestimmtes Verzeichnis auf dem Server und dessen gesamte Unterverzeichnisse.
.

• <VirtualHost _default_:443> # der vhost kann nur über SSL besucht werden
    ServerName mail3.ipw.net:443<Directory "/srv/www/htdocs"> # und es betrifft nur dieses Verzeichnis.

Eine weitere Option erlaubt Ausnahmen (sogenannte overrides = überschreiben) davon, wovon wir bei Typo3 zum Beispiel Gebrauch machen wollen bzw. müssen.

•    AllowOverride all (oder none)

und das betrifft die Zugangsdateien mit dem namen ".htaccess".
.

Grundsätzlich unterscheiden sich die beiden Konfigurations-Dateien/Skripte dieser Art von Zugangsberechtigungen in ihrer Behandlung durch den Apache:

1. Die "vhost" Konfiguration(en) wird einmalig beim Starten (oder Laden bzw. Aufrufen) des Apache auf Plausibilität geprüft und sofort ausgeführt.
2. Die jeweiligen ".htaccess" Dateien in den unterschiedlichsten Verzeichnissen werden zwar anfänglich auch einmal auf Plausibilität gepüft, aber ausgeführt (bzw. abgearbeitet) werden sie erst bei jedem Zugriff auf Inhalte aus diesem Verzeichnis und dann vor allem jedes !!! Mal aufs Neue.

.

Und jetzt stellt sich die Frage, ob man die Konfiguration gleich in der vhost Datei einbaut oder wie früher in die .htaccess Datei verlagert.

Laut Beschreibung auf der apache.org Seite sei es vom Code her nicht unterschiedlich, doch hat sich die letzten Tage herausgestellt, es ist doch (noch) unterschiedlich und das ist Mist, man sucht sich nämlich dämlich.
.

<VirtualHost _default_:443>
  ServerName mail3.ipw.net:443
  Serveralias 193.218.xxx.yyy

  SSLEngine on
  RewriteEngine on
  RewriteCond %{HTTPS} !=on
  DocumentRoot "/srv/www/htdocs"
        SSLCompression off
        SSLHonorCipherOrder     on
        SSLCipherSuite HIGH:MEDIUM:!ADH
        SSLProtocol all -SSLv3
        SSLCipherSuite AES256+EECDH:AES256+EDH
        SSLCertificateFile      /etc/xxxxx/mail3.ipw.crt
        SSLCertificateKeyFile   /etc/yyyyy/mail3.ipw.key

<Directory "/srv/www/htdocs">
   Options Indexes FollowSymLinks
   AllowOverride all
   Require all Granted
</Directory>
 ScriptAlias /cgi-bin/ "/srv/www/cgi-bin/"
<Directory "/srv/www/cgi-bin">
   AllowOverride None
   Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch -Includes
   Require all Granted
 </Directory>

 HostnameLookups Off
 UseCanonicalName Off
 ServerSignature Off
</VirtualHost>


Anmerkung : Dir Zugangsberchtigungen habe ich dann doch wieder in einzelne .htaccess Dateien ausgelagert. Der Inhalt steht hier unten drunter.
.

AuthType Basic
AuthName "<br>Dies ist der Zugang zu xxxyyyAdmin auf dem Mailserver mail3.ipw.net vom Feb. 2015"
AuthBasicProvider file
AuthUserFile /etc/xxx/yyy/.htpasswd
Require valid-user
.
Der "AuthName" wird je nach Funktion angepaßt, sodaß man sofort sieht, wo man gelandet ist.
.

Wenn Sie bislang nur Bahnhof vestanden hatten, können Sie hier getrost abbrechen. Auch ich habe mich mit den nachfolgenden Problemen recht schwer getan. Es ist überhaupt nicht trivial und Sie müssen bei jedem Schritt gehörig vordenken und nachdenken.
.

So ist der Webzugang zum phpMyAdmin, Dovecot-Admin und Roundcube-Admin mit einem zusätzlichen SSL User und einem Password abgesichert.

Das ersetzt natürlich immer noch nicht eine funktionierende Firewall, die sämtliche andern Ports schließt und die von opensuse wird mit YAST konfiguriert.

Es gibt immer noch eine paar Argumente, warum auch in 2015 "MyISAM" in bestimmten "mysql/mariadb" Umgebungen Sinn macht. Die "Innodb" Dateien werden schlagartig riesengroß und auf einmal hat man 300 MB für 5 Datensätze. Das ist bei Problemen und Fehlern sehr hinderlich, mit solchen Brocken umgehen zu müssen. Das kann aber zum Glück jeder selbst entscheiden. Wir haben so gut wie keinen massenhaften Schreib-Zugriff und brauchen auch darum nie zurückzurollen oder einen Chrash abzufangen.
.
Bei opensuse 13.2 ist die mariadb Version: 10.0.13 mit Innodb als default dabei. Ich habe aber mariadb Version von 10.0.13 - (am 8. Feb. 2015) auf jetzt 10.0.16 hochgefahren, weil dort die Volltext-Suche verbessert sein soll. Und die Datenbankengine sei jetzt ARIA ?. Also mal sehen. Im Moment brauche ich das Ganze nur für das Roundcube Mailsystem. Später kommen irgendwann die großen Museenseiten dran.

Bei der mariadb wird fortlaufend ergänzt, repariert und verbessert. Das sollte man durch die jeweils aktuelle Version nutzen. Es gibt bei opensuse ein spezielles Repository, in dem die ganz aktuellen "builds" der stabilen Datenbank-Server verfügbar sind. Hier der Link :

download.opensuse.org/repositories/server:/database/openSUSE_13.2/

Und das Updaten auf ganz aktuelle Versionen geht dann mit "zypper dup" recht komfortabel.
.

Datenbank-Namen - ein anscheinend schwieriges Thema mit viel Unsinn im Internet.

Ein gefundener Vorschlag eines "Profis": Legen Sie eine Datenbank mit Namen "postfix" an und dann den user "postfix" - aber das ist solch ein Unsinn. Sie suchen später Fehler und werden dusselig vor lauter "postfix"es.

Datenbanknamen immer mit einen "_db" hinten dran anlegen, also "postfix_db" oder "roundcube_db" und den ersten (admin-) user immer als "postfix_adm" benennen. Das ist dann später sehr sehr hilfreich. Bei postfix und postfixadmin und dovecat und roundcube haben sie über 20 .conf Dateien, deren Inhalte und  gegenseitige Verknüpfungen Sie irgendwann nicht mehr überblicken.
.

Zuerst brauche ich eine bash script Datei, mit der ich die Funktion des "postfix" MTA überpfüfen kann. Dazu installiere ich mir mit yast ein kleines e-mail- Clientprogramm mit Namen "mailx" und einen bash shell-Script, der die Testmail rausschickt.

Die wesentliche Zeile in dem bash script ist :
.

• echo "`date` - Das ist die Testmail mit nur einem String" | mail -s "Der mailtest-Script auf $RDESERVER ist gelaufen -siehe Logfile-" "$EMAILADR1"

.
Das muß in einer Zeile stehen. Und die Variablen müssen vorher gefüllt sein.

Sehr hilfreich ist es, wenn möglich - auf dem Empfangs-Mailserver das mail-warn Logbuch mit "tail - f mail-warn" mitlaufen zu lassen. Kommt dort keine e-mail an, sendet postfix (noch) nichts. Stimmt die Konfiguration des sendenden "postfix" noch nicht ganz, kommt dort zwar eine e-mail an, doch die wird abgewiesen und erzeugt einen Logbuch-Eintrag. Aus dem kann man den genauen Fehler ablesen.
.

Auch hier muß man lesen, lesen und nochmals lesen - jedenfalls, wenn man weiß, was man überhaupt sucht und wo:
.
http://wiki2.dovecot.org/SSL/DovecotConfiguration
.
Da wir den gesamten Zugang zu diesem Server nur noch über SSL und https handhaben wollen, muß SSL auch in Dovecot global aktiviert sein. Sonst hilft es nichts, in der Firewall die Ports 993 und 995 freizugeben.

Die Konfiguraton ist überhaupt nicht trivial und man muß öfter mit dem "angryIP" Scanner die Ports 993 und 995 prüfen, ob die auch nach draußen offen sind.
.
Details kommen noch. und das dauert, es ist viel ....
.