News Fufix soll Aufsetzen eines Mailservers vereinfachen

fethomm schrieb:
Lesen schadet natürlich nie, aber wir wissen ja wie es darum bestellt ist. Wenn man sich nach dem Script die Konfigs anschaut, wird der Anfänger automatisch zum Lesen kommen sofern er denn verstehen will was da passiert.

Stimmt, es ist aber auch interessant sich das Script mal als Fortgeschrittener-User anzuschauen.
Allein schon genpasswd() :)
 
Was ist daran schwer einen Exchangeserver aufzusetzen? Oo
 
Ich werde mir das Script mal anschauen....obwohl ich etwas skeptisch bin.

Ein Mailserver zu Hause funktioniert anders, als ein Mailserver im Netz. Also wie sollen das Laien denn dann ausprobieren? Postfixadmin beispielsweise richtet sich an das Einrichten in "freier Wildbahn". Oder abgeholt werden müssen die Mails zu Hause über sowas wie Getmail oder Fetchmail, was auch extra konfiguriert werden muss.

Im Endeffekt muss man doch in den Configs manuell schrauben, wobei ein Anfänger dann oft gar nicht wissen kann, was er da macht.

Wer einen Mailserver sicher betreiben möchte, kommt um das Verstehen dessen nicht herum. Für fortgeschrittene User trotzdem eine super Sache.



Und an die Leute, die Exchange ins Spiel bringen: Ein auf Linux basierender Mailserver ist eigentlich etwas anderes.
 
Zuletzt bearbeitet:
fethomm schrieb:
Da Mailserver diffizile und verletzliche Gebilde sind, sollten die ersten Gehversuche, wie bei anderen Servern auch, nicht in freier Wildbahn, sondern im lokalen Netz oder in einer virtuellen Umgebung stattfinden.
a) lokales Netz oder public hat irgendie gar nichts damit zu tun ob physikalischer Server oder vm, von daher ist ie Aussage schonmal murks.
b) Wie soll man nen Mailserver bitteschön in nem lokalen Netz sinnvoll testen? Es wird zumeist keine Mail rausgehen (zumindest bei den meisten Heim-Netzen mit NAT über den DSL-Provider), es wird keine Mail ankommen (von wenigen Setups mit fester IP und Port-Forwarding mal abgesehen).
 
Blutschlumpf schrieb:
a) lokales Netz oder public hat irgendie gar nichts damit zu tun ob physikalischer Server oder vm, von daher ist ie Aussage schonmal murks.
b) Wie soll man nen Mailserver bitteschön in nem lokalen Netz sinnvoll testen? Es wird zumeist keine Mail rausgehen (zumindest bei den meisten Heim-Netzen mit NAT über den DSL-Provider), es wird keine Mail ankommen (von wenigen Setups mit fester IP und Port-Forwarding mal abgesehen).

Das ist nicht richtig, da man zum Testen SMTP Relaying für das Verschicken und einem Mail Retrieval Agent zum Abholen arbeiten kann, was dieses Script zwar von Werk aus wohl nicht anbietet und auch nicht muss. Für Sicherheitstests, auf die es in erster Linie aber bei einem Mailserver ankommt, reicht eine lokal betriebene VM oder betriebener Server.

Ich denke trotzdem, dass sich Fufix an ISP- Admins richtet, die sich die Installation erleichtern möchten.
 
sini schrieb:
[...] muss man da wieder alles von Grund auf in irgendwelchen total überladenen Text-Konfigurationen rumrühren?!

Eine (Plain-)Textkonfiguration unter Linux ist die kompakteste Form der menschenlesbaren Konfigurationsdatei, die es gibt. In der Regel besteht sie aus Schlüssel-Werte-Paaren. Im Normalbetrieb stehen dort nur minimale Kommentare darin. Der Rest befindet sich in der zugehörigen Doku.

Überladen sind meistens GUIs, die versuchen, die Fülle nötiger Optionen in einer einzigen Oberfläche unterzubringen. Es ist dann nämlich alles andere als einfach, Usability-Anforderungen sauber umzusetzen. Viele Hersteller scheitern kläglich daran. Lesen können hingegen die meisten - und das oft sogar erheblich schneller als Klicken.

Anekdote am Rande:

Ein Haus mit einer vierstelligen Nutzeranzahl ist gerade auf Exchange umgestellt worden. Ich betreibe dort eine dreistellige Zahl Debian-Server. Auf denen läuft eine Kette MTAs gegen einen zentralen Postfix. Daneben steht ein Zimbra (u.a. ebenfalls Postfix) in Failover-Konfiguration.

Im Nachbarbüro höre ich täglich vier Kollegen lautstark fluchen. Mal über Exchange, mal über die Outlook-Clients, mal über beides. Und das sind Profis - kein Scherz! - die wissen, was sie tun. Die haben eine entsprechend hohe Schmerztoleranz.

Ich hingegen langweile mich auf der Mailebene. Total. Wenn man eine Bombe auf eine meiner Maschinen schmeißt, schickt die mir vorher noch eine Nachricht, dass das System explodiert ist, bevor es die Kiste zerbröselt.

Welcher Mailsystem "besser" ist, ist sicher stark fallabhängig. - Nun, ich gehe dann mal in aller Ruhe das Skript lesen. Danke dafür!

Nebenan fluchen schon wieder die Kollegen.
 
@moranaga

Die Leute verwechseln oft Groupware (Exchange) mit einem reinen Mailserver.

"Auf denen läuft eine Kette MTAs gegen einen zentralen Postfix"

Heißt das, dass du auf jedem Debianserver ein Postfix laufen läßt, welcher dann mit dem zentralen Postfix kommuniziert? Da geht es dann sicherlich lediglich um Status und Log's jeder einzelnen Maschine? Dazu reicht in meinen Augen auch der vorinstallierte EXIM.

Deine Konfig mit einem Exchange vergleichen, der eine vierstellige Nutzerzahl abfangen muß, kann man dann trotzdem nicht. Das kannst du erst, wenn sowas wie Zimbra oder Zarafa (ebenfalls Groupware) bei der Masse läuft. Dabei geht es dann um weit mehr, als das Verwalten der Mails und da können auch ganz andere Sachen klemen.
 
evox9 schrieb:
@moranaga

Die Leute verwechseln oft Groupware (Exchange) mit einem reinen Mailserver.
...
Dabei geht es dann um weit mehr, als das Verwalten der Mails und da können auch ganz andere Sachen klemen.

True ...
 
Juhu finde ich super!
Ich benutze gerade Zentyal auf meinen Privaten Server und Plesk auf allen Firmen Server und da ist schon E-Mail vor konfiguriert, aber wenn ich jetzt auf nen Kunden Server mal flott Mail installieren soll nimmt einem das Script viel Arbeit ab!
Ergänzung ()

Blutschlumpf schrieb:
a) lokales Netz oder public hat irgendie gar nichts damit zu tun ob physikalischer Server oder vm, von daher ist ie Aussage schonmal murks.
b) Wie soll man nen Mailserver bitteschön in nem lokalen Netz sinnvoll testen? Es wird zumeist keine Mail rausgehen (zumindest bei den meisten Heim-Netzen mit NAT über den DSL-Provider), es wird keine Mail ankommen (von wenigen Setups mit fester IP und Port-Forwarding mal abgesehen).

Was laberst du für kaba?
Klar kann ich im lokalen Netz Mails schreiben.
Computer 192.168.2.101 schickt ne Mail an Adresse test@192.168.2.199 (Server) welche dann von 192.168.2.102 (z.b. Tablet) abgeholt wird.
Und das mit der VM ist wie Virtualbox gedacht. Ich kann auch ein Debian Minimal in net VM auf meinen Windows 7 Rechner laufen lassen und mir Mails mit meinen Windows 8.1 Laptop austauschen lassen.

Ich habe einen Linux Server hinter meinem Speedport laufen (DeutschLAN Connect Fiber 200 braucht man nen Speedport) und kann dort mit meiner festen IP (sowohl auch meiner DynDNS) Mails schicken und empfangen.
Ergänzung ()

sini schrieb:
Naja ich weiß nicht ob es sinnvoll ist, solche Sachen extra kompliziert und unübersichtlich zu machen ... Die Motivation der meisten Leute sich damit auseinander zu setzen, sinkt damit ja erheblich und zugleich steigt die Wahrscheinlichkeit von Fehlkonfigurationen.



Ist das aber nicht genau der Effekt der durch übertrieben komplizierte Konfigurationen erreicht wird? Der 0815-Anwender freut sich, dass seine Kiste "irgendwie" läuft, egal wie ...

Es gibt auch noch diverse Panels wie Plesk, Froxlor und co für 08/15 Anwender.
Dieses Script ist ideal für ISPs die flott mal nen Mail aufsetzen wollen.
 
Zuletzt bearbeitet:
@RaphixxYT

Du hast eine feste IP und ein DynDns?

Eigentlich werden Mailserver hinter einer dynamischen IP geblacklistet, sofern sie das SMTP SELBST übernehmen, es sei denn, du relayst über einen Provider (gmx, freenet, 1und1.....usw.)

Und das Verschicken von Mails in einem Netzwerk hat auch nur bedingt etwas mit der Sicherheit im Allgemeinen, auf die es in erster Linie bei einem Mailserver ankommt, zu tun.
 
evox9 schrieb:
@RaphixxYT

Du hast eine feste IP und ein DynDns?

Eigentlich werden Mailserver hinter einer dynamischen IP geblacklistet, sofern sie das SMTP SELBST übernehmen, es sei denn, du relayst über einen Provider (gmx, freenet, 1und1.....usw.)

Und das Verschicken von Mails in einem Netzwerk hat auch nur bedingt etwas mit der Sicherheit im Allgemeinen, auf die es in erster Linie bei einem Mailserver ankommt, zu tun.
Ich habe eine feste IP, die ich für Testzwecke mal bei No-Ip angegeben habe.
Bei mir landen die Mails vom Dyndns im Spam Ordner bei GMail, weiß nicht wie es bei anderen Anbietern ist.
Von der festen IP kommt es auch darauf an von welcher Domain (.CF, .ml, .GA, .tk landen im Spam wo .de, .CC, .net im Posteingang landet) die Mail gesendet wurde bzw. von welchen Server (IP auf Blacklist oder irgendein Dubioser Standort.).
Da ich Server in (fast) der ganzen Welt habe (zu 98% Kundenserver die ich Manage) ist das auch immer ein extrem bloßes Thema. Vor allem E-Mails sind assig in dem Bezug.
 
RaphixxYT schrieb:
Klar kann ich im lokalen Netz Mails schreiben.
Computer 192.168.2.101 schickt ne Mail an Adresse test@192.168.2.199 (Server) welche dann von 192.168.2.102 (z.b. Tablet) abgeholt wird.
Und das ist deiner Meinung nach ein sinnvolles (das Wort steht da bewusst auch schon im ersten Post drin) Setup um den ersten Mailserver zu testen?
Ich weiß nicht wer hier "kaba" redet.

Interessant bei der Mailserver-Config ist nicht ob ne Mail an root@192.168.2.199 irgendwo auf der Kiste ankommt, sondern ob der Server in der realen Welt funktioniert (also auch ohne relay dahinter).

Interessant ist zuallererst also ob ich ne Mail an den Mailserver senden kann und der die an gängige Provider wie Google, GMX und co weiterreicht und die dort auch angenommen werden statt rejected zu werden oder in der Spam-Liste zu landen.
Interessant ist ob der Mailserver dabei nicht als Open relay fungiert.
Interessant ist, dass die Verbindung dabei auch verschlüsselt ist (TLS/SSL).
Interessant ist ob auch IMAP funktioniert.

Meine IP @ home (Telekom) ist zum Beispiel bei Spamhaus gelistet. -> Zack, schon liegt das Kartenhaus da.
Ich kann für die IP keinen PTR setzen -> erneuter Einsturz
Für das SSL-Zertifikat brauch ich ne IP, mit der dynamischen wird das ein kurzer Spaß -> wieder liegt das Kartenhaus.

-> Das in nem privaten Netz zu testen ist eher sinnfrei. Man kann nur die Hälfte testen, hat viel mehr Aufwand und muss das ganze dann nachher nochmal alles testen sobald man auf ne feste IP umstellt.
 
@RaphixxYT

"Ich habe eine feste IP, die ich für Testzwecke mal bei No-Ip angegeben habe."

Sorry, das blicke ich nicht.

@Blutschlumpf

"Das in nem privaten Netz zu testen ist eher sinnfrei. Man kann nur die Hälfte testen, hat viel mehr Aufwand und muss das ganze dann nachher nochmal alles testen sobald man auf ne feste IP umstellt. "


Man kann sehr wohl einen Mailserver hinter einer dynamischen Ip auf Sicherheit testen, sei es, ob er gegen Bruteforce, Open relaying, Verschlüsselungscrack/ das generelle Angreifen der Zertifizierung beständig ist. Nenbei kann ebenfalls Pop/Imap, Virenscan und Spamabwehr getestet werden.

Hälfte? Das Grundkonstrukt ist eigentlich gleich und läßt sich im "offenen Betrieb", bis auf kleine Änderungen der Adressierung und Zertifikaten, komplett übernehmen.


Erkläre mir bitte, in Anbetracht der Sicherheitrisiken, warum es sinnvoller ist, einen Mailserver im offenen Netz zu testen, denn die ersten Angriffe erfolgen oft innerhalb kurzer Zeit, da ein echter Mailserver erfahrungsgemäß die Begierden von Spamern wecken.
 
Das was du beschreibst ist aber nicht das was jemand beim ersten Mailserver-Aufbau testen wird.
As ob da jemand zuhause im privaten Netz erst versucht die Verschlüsselung des Systems zu knacken. :lol:

Die Paxis sieht so aus: postfix drauf, anhand von diversen guides und google die config zusammenschustern.
dovecot drauf, apache drauf, ein webmail-programm drauf.
PTR und ggf. SPF einstellen.
Testen ob man Mails erhält.
Von Konsole testen ob man Mails verschicken kann und die auch ankommen.
Testen ob man mit auth über den Server versenden kann und ohne auth nicht.
Testen ob das Webinterface funktioniert.

Wenn man Angst haben sollte, dass der in der Zeit missbraucht wird, dann nimmt man iptables um Port 25 solange für andere dicht zu machen und baut da kein Setup mit privater IP für.
Ich sehe auch deine Befürchtung nicht so ganz.
Wenn man es nicht explizit so konfigureiert, nimmt z.B. postfix keine Mails als offener Relay an.
Die Milliarden an Spam-Mails jeden Tag stammen in den seltensten Fällen von offenen Relays, da werden entweder Server für angemietet oder man nimmt gehackte Rechner (Bots oder Webserver mit veralteten CRMs).
 
evox9 schrieb:
Die Leute verwechseln oft Groupware (Exchange) mit einem reinen Mailserver.

Ich bin nicht die Leute.

Heißt das, dass du auf jedem Debianserver ein Postfix laufen läßt, welcher dann mit dem zentralen Postfix kommuniziert?

Ja. Grob vereinfacht. Der "zentrale Postfix" besteht natürlich nicht aus einer einzelnen Maschine.

Da geht es dann sicherlich lediglich um Status und Log's jeder einzelnen Maschine?

Nein. Darüber läuft sämtliche Kommunikation. U.a. Mailinglisten- und Newsletterversand mit Nutzerzahlen im fünf- bis sechsstelligen Bereich.

Dazu reicht in meinen Augen auch der vorinstallierte EXIM.

Dazu reicht $mta. Wenn die Admins wissen, was sie tun. Welcher, ist Geschmackssache. Ich würde qmail bevorzugen, man wünscht sich Postfix, also geht das. Exim ist das erste, was von jeder Debian-Installation fliegt, auf der ich Admin-Rechte habe. Wie gesagt, ist das Geschmackssache.

Deine Konfig mit einem Exchange vergleichen, der eine vierstellige Nutzerzahl abfangen muß, kann man dann trotzdem nicht. Das kannst du erst, wenn sowas wie Zimbra oder Zarafa (ebenfalls Groupware) bei der Masse läuft.

Eins der Stichworte findet sich oben im Text. Ich gehe mit und erhöhe um GroupWise.

Dabei geht es dann um weit mehr, als das Verwalten der Mails und da können auch ganz andere Sachen klemen.

Ach. </Loriot> (No offense meant.)
 
Zuletzt bearbeitet:
evox9 schrieb:
@RaphixxYT

"Ich habe eine feste IP, die ich für Testzwecke mal bei No-Ip angegeben habe."

Sorry, das blicke ich nicht.

@Blutschlumpf

"Das in nem privaten Netz zu testen ist eher sinnfrei. Man kann nur die Hälfte testen, hat viel mehr Aufwand und muss das ganze dann nachher nochmal alles testen sobald man auf ne feste IP umstellt. "


Man kann sehr wohl einen Mailserver hinter einer dynamischen Ip auf Sicherheit testen, sei es, ob er gegen Bruteforce, Open relaying, Verschlüsselungscrack/ das generelle Angreifen der Zertifizierung beständig ist. Nenbei kann ebenfalls Pop/Imap, Virenscan und Spamabwehr getestet werden.

Hälfte? Das Grundkonstrukt ist eigentlich gleich und läßt sich im "offenen Betrieb", bis auf kleine Änderungen der Adressierung und Zertifikaten, komplett übernehmen.


Erkläre mir bitte, in Anbetracht der Sicherheitrisiken, warum es sinnvoller ist, einen Mailserver im offenen Netz zu testen, denn die ersten Angriffe erfolgen oft innerhalb kurzer Zeit, da ein echter Mailserver erfahrungsgemäß die Begierden von Spamern wecken.

Man kann im bei No-Ip seine "hostnames" selber mit IPs füttern und somit die feste IP in einen DynDNS "hostname" einbinden.
Ich hab das wahrscheinlich bissle blöd ausgedrückt.
Ergänzung ()

Blutschlumpf schrieb:
Und das ist deiner Meinung nach ein sinnvolles (das Wort steht da bewusst auch schon im ersten Post drin) Setup um den ersten Mailserver zu testen?
Ich weiß nicht wer hier "kaba" redet.

Interessant bei der Mailserver-Config ist nicht ob ne Mail an root@192.168.2.199 irgendwo auf der Kiste ankommt, sondern ob der Server in der realen Welt funktioniert (also auch ohne relay dahinter).

Interessant ist zuallererst also ob ich ne Mail an den Mailserver senden kann und der die an gängige Provider wie Google, GMX und co weiterreicht und die dort auch angenommen werden statt rejected zu werden oder in der Spam-Liste zu landen.
Interessant ist ob der Mailserver dabei nicht als Open relay fungiert.
Interessant ist, dass die Verbindung dabei auch verschlüsselt ist (TLS/SSL).
Interessant ist ob auch IMAP funktioniert.

Meine IP @ home (Telekom) ist zum Beispiel bei Spamhaus gelistet. -> Zack, schon liegt das Kartenhaus da.
Ich kann für die IP keinen PTR setzen -> erneuter Einsturz
Für das SSL-Zertifikat brauch ich ne IP, mit der dynamischen wird das ein kurzer Spaß -> wieder liegt das Kartenhaus.

-> Das in nem privaten Netz zu testen ist eher sinnfrei. Man kann nur die Hälfte testen, hat viel mehr Aufwand und muss das ganze dann nachher nochmal alles testen sobald man auf ne feste IP umstellt.

Im privaten Netzt sollte man alles erstmal testen.
Denn da kann man (wenn etwas kaputt ist) nochmal ohne irgendwelche gefahren einiges richten.
Ich hatte mal das erlebt das ein Kunde den SSH von einem von uns gemanagten Server haben möchte und wir es ihm erlaubt haben, nach nen Monat kam ne Abmahnung wegen Filesharing auf dem Server.
Der Kunde hat natürlich gesagt das er kein torrent installiert hat und nur den SSH an einen bekannten weiter gegeben hat.
 
Blutschlumpf schrieb:
Das was du beschreibst ist aber nicht das was jemand beim ersten Mailserver-Aufbau testen wird.
As ob da jemand zuhause im privaten Netz erst versucht die Verschlüsselung des Systems zu knacken. :lol:

Das habe ich nicht beschrieben, sondern auf deine Behauptung hin geantwortet, dass es SINNFREI wäre, sowas im "privaten Netz" zu testen.

Du kannst hinter jeder dynamischen IP online einen Openrelay Test oder SSL Test( Beispiel Heartbleed) machen, dazu stehen genug Dienste bereit.

Und das Spams in den seltensten Fällen? von gekaperten Mailservern, die als Open Relays dienen, stammen entspricht ebenfalls nicht der Realität.


Ich muß dich enttäuschen, aber in der Realität werden tatsächlich Mailserver allzuoft in lokalen Netzen/VM's getestet. Werden diese später sogar "offen" in VM's betrieben, läßt sich das komplette Setup dann, mit kleinen Änderungen, hochladen.

@Moranaga

Euer Setup interessiert mich. Du beschreibst ja, eine dreistellige Anzahl mit Debianservern zu betreiben auf denen dann jeweils Postfix läuft. Zusätzlich habt ihr noch Exchange und Zimbra was lediglich als Failover dient.

Warum verteilt ihr die komplette Kommunikation über so viele verschiedene Installationen? Laut Erfahrung und eine schnelle Maschiene vorausgesetzt, ist es schon einem Postfix egal, ob da nun 2 oder 20000 Mails durchgehen.

Exim ist sicherlich Geschmackssache, doch auch nicht so schwer zu bedienen, wie manche vielleicht denken.
 
Hi,

ich habe mittlerweile so einiges an neuen Information ins GitHub getragen: https://github.com/andryyy/fufix
Natürlich sollte das Script keiner benutzen, der so gaaaar keine Ahnung von dem hat, was er da tut.
Offene Relays en masse wird es mit fufix nicht geben. Dafür muss der Benutzer (genau wie bei einer Standard-Installation Postfix' übrigens) gezielt in die Konfiguration eingreifen.

Die nächsten Tage folgt wohl eher mehr Dokumentation als Funktion.

Beste Grüße und ein dickes Danke an alle für das Feedback!
André
 
evox9 schrieb:
Euer Setup interessiert mich. Du beschreibst ja, eine dreistellige Anzahl mit Debianservern zu betreiben auf denen dann jeweils Postfix läuft. Zusätzlich habt ihr noch Exchange und Zimbra was lediglich als Failover dient.

Zimbra wird durch Exchange abgelöst. Es kann nicht als Fallback dienen; zumindest würde das nicht allzuviel Sinn ergeben.

Warum verteilt ihr die komplette Kommunikation über so viele verschiedene Installationen?

Oft erklärt sich das durch gewachsene Strukturen. Es kann der Ausfallsicherheit dienen, und trotz der Leistungsfähigkeit einer Software dennoch der Lastverteilung, Stichwort "Cloud". In diesem Fall handelt es sich aber um ein Multi-Tier-Environment mit segmentierten Sicherheitszonen.

Laut Erfahrung und eine schnelle Maschiene vorausgesetzt, ist es schon einem Postfix egal, ob da nun 2 oder 20000 Mails durchgehen.

Schon. Wenn eine Sicherheitsregel aber nicht gestattet, dass ein MTA mit einem danebenstehenden anderen redet, muss die Nachricht über zugelassene Kanäle geleitet werden - selbst wenn das weitere Hops und damit "Umwege" bedeutet.

Exim ist sicherlich Geschmackssache, doch auch nicht so schwer zu bedienen, wie manche vielleicht denken.

Nein; qmail oder Postfix allerdings auch nicht. Letztlich läßt sich der Transport mit den meisten aktuellen MTAs bewerkstelligen. Sogar solchen vom größten GUI-Betriebssystemhersteller der Welt. ;)
 
@Moranaga

In einem Post beschreibtst du ja, dass Zimbra als Failover läuft. Jetzt schreibst du, dass Zimbra wiederrum von Exchange abgelöst wird und nicht als Fallback dienen kann.

Du schreibst, dass aufgrund von Sicherheitregeln es nicht gestattet ist, dass ein MTA mit einem danebenstehenden anderen redet. Du schreibst aber auch, dass die dann alle gegen ein Postfix laufen. Dadurch wird in meinen Augen die Sicherheitsregel wieder aufgehoben.

Du schreibst, dass die Exchangeleute mit Exchange und Outlook Probleme haben und du mit Postfix auf der Mailebene keine Probleme hast. Doch Postfix ist weder MUA noch MDA.


Kann es sein, dass du hier ziemlich viel durcheinander wirbelst?
 

Ähnliche Themen

Zurück
Oben