On 2016-04-18 08:45, Thomas Porschberg wrote:
ich habe für den Sportverein, Schulklassen etc. diverse Mailinglisten bei googlegroups. Für mein Software-Projekt würde ich nicht unbedingt auf Google setzen wollen. Gibt es Alternativen?
Ich bin ja immer ein Freund von selbst Hosten, bzw. Hosten bei Leuten, die du persönlich kennst.
Zusatzfrage: Habe bei meinem Provider einen root-Server gemietet. Da könnte ich sicher auch mailman o.ä. aufsetzen, scheue aber aus der Kalten etwas den Verwaltungsaufwand (hab das auch noch nicht praktisch gemacht).
Nujah, ich betreibe einen eigenen Mailserver, mit Debian/Exim4/Dovecot. Das ist schon wesentlich schwieriger aufzusetzen, als ein Apache. Es gibt auch ein paar Dinge, die du beachten solltest, damit "die Großen" auch mit dir spielen wollen (stichwort SPF-Record und so). Die gute Nachricht ist: wenn das einmal steht musst du das fast nie wieder anfassen. Nach meiner Erfahrung würde ich übrigens die Nutzung von Postfix statt Exim nahe legen. Halte das Setup nahe an deinem Distributions-Default, plain text configuration, etc. Keep it Simple. Auf den IMAP/POP Server kannst du rein für Mailinglisten ja an sich auch verzichten - spart nochmal deutlich Arbeit. Ggf. kneifst du dir dann sogar das TLS.
Wie schätzt ihr einen solchen Aufwand ein?
Anders sieht das ggf. bei Mailman aus. Mailman macht wirklich exzellentes Mailhandling, es gibt da nichts besseres! Man tut aber gut daran das Interface vor "normalen" Menschen zu verstecken, sonst sind die schnell wieder bei Google Groups. Fehlkonfiguration von Listenadmins (sofern du Listen für Andere hostest), und manchmal auch die Updates können dir da schon mehr Wartungsaufwand abverlangen, als der Mailserver an sich. Im Vergleich zu ${geileNeueWebApp} ist es aber immernoch sehr wartungsarm.
Ich würde da noch auf quickml[1] hinweisen. Das ist total entspannt zu betreiben, hat aber z.B. kein Webinterface. Konfiguration, Listensetup, Archivierung nur per email, etc.
[1] http://0xcc.net/quickml/index.html.en
Hi nochmal.
ich habe für den Sportverein, Schulklassen etc. diverse Mailinglisten bei googlegroups. Für mein Software-Projekt würde ich nicht unbedingt auf Google setzen wollen. Gibt es Alternativen?
Ich bin ja immer ein Freund von selbst Hosten, bzw. Hosten bei Leuten, die du persönlich kennst.
Zusatzfrage: Habe bei meinem Provider einen root-Server gemietet. Da könnte ich sicher auch mailman o.ä. aufsetzen, scheue aber aus der Kalten etwas den Verwaltungsaufwand (hab das auch noch nicht praktisch gemacht).
Nujah, ich betreibe einen eigenen Mailserver, mit Debian/Exim4/Dovecot. Das ist schon wesentlich schwieriger aufzusetzen, als ein Apache. Es gibt auch ein paar Dinge, die du beachten solltest, damit "die Großen" auch mit dir spielen wollen (stichwort SPF-Record und so). Die gute Nachricht ist: wenn das einmal steht musst du das fast nie wieder anfassen. Nach meiner Erfahrung würde ich übrigens die Nutzung von Postfix statt Exim nahe legen. Halte das Setup nahe an deinem Distributions-Default, plain text configuration, etc. Keep it Simple. Auf den IMAP/POP Server kannst du rein für Mailinglisten ja an sich auch verzichten - spart nochmal deutlich Arbeit. Ggf. kneifst du dir dann sogar das TLS.
Wie schätzt ihr einen solchen Aufwand ein?
Anders sieht das ggf. bei Mailman aus. Mailman macht wirklich exzellentes Mailhandling, es gibt da nichts besseres! Man tut aber gut daran das Interface vor "normalen" Menschen zu verstecken, sonst sind die schnell wieder bei Google Groups. Fehlkonfiguration von Listenadmins (sofern du Listen für Andere hostest), und manchmal auch die Updates können dir da schon mehr Wartungsaufwand abverlangen, als der Mailserver an sich. Im Vergleich zu ${geileNeueWebApp} ist es aber immernoch sehr wartungsarm.
Ich würde da noch auf quickml[1] hinweisen. Das ist total entspannt zu betreiben, hat aber z.B. kein Webinterface. Konfiguration, Listensetup, Archivierung nur per email, etc.
Was ich auch noch gerne habe ist:
Das erleichtert das Setup des Mailservers ungemein und die Config die dort heraus kommt ist gut ;)
Viele Grüsse Marcus
On 04/18/2016 01:15 PM, Paul Hänsch wrote:
Nujah, ich betreibe einen eigenen Mailserver, mit Debian/Exim4/Dovecot.
Für Mailman braucht man kein Dovecot, wie du ja auch richtig schreibst. Und auch von mir klar die Empfehlung zu Postfix statt Exim. Der Rest ist meiner Meinung nach genauso aufwändig oder wenig aufwändig wie eine gute Webserver-Installation, wenn man HTTPS, korrekte Ciphersuite plus jeweilige Updates, FastCGI oder UWSGI, und allen sonstigen Kram zählt den man "üblicherweise" braucht.
Ggf. kneifst du dir dann sogar das TLS.
Bitte? Sowas sollte man nun wirklich niemandem raten.
On 2016-04-18 15:09, Moritz Bartl wrote:
Ggf. kneifst du dir dann sogar das TLS.
Bitte? Sowas sollte man nun wirklich niemandem raten.
Das ist das was *die* wollen, was du glaubst... ;-)
Ich dachte mir ja schon, dass irgendwer Anstoß daran nimmt. Ich halte aber daran fest, denn...
...allgemein: - SSL ist keine Email-Verschlüsselung! - Auch nicht ein ganz kleines bisschen - Auch nicht "besser als gar nichts", die Mailserver in der Kette sind die hauptsächlichen Angriffspunkte, und gerade diese werden nicht abgedeckt - Irgendwo in der Kette irgendwie was mit Verschlüsselung zu haben ist weit entfernt von sicherer Kommunikation
...spezifisch: - das diskutierte Setup soll nicht für Submission verwendet werden - Andere Mailserver stellen nicht authentifiziert zu und machen häufig auch keinen Gebrauch von einem angebotenen TLS Kanal. Tatsächlich wird dein Server sich sehr einsam fühlen, wenn du Mailzustellung ausschließlich via TLS zulässt - *Falls* du den Server zur Submission verwenden willst, gibt es dennoch Authentifizierungsverfahren die das Auslesen von Passwörtern auf Plaintext-Kanälen verhindern (z.B. CRAM)
Das gilt natürlich nicht wenn du z.B. auch IMAP anbietest, wo dann die Mailpostfächer abrufbar sind. Auch wenn du ohnehin schon ein SSL-Zertifikat für einen eventuellen Webserver hast, schmerzt es nicht weiter, das auch für den SMTP Server zu verwenden.
Um nochmal zum Anfang zurückzukommen: SSL wurde entworfen und ist geeignet um Kleinkriminelle davon abzuhalten, deine Kreditkartennummer von der Leitung zu sniffen. In dem Bereich ist es vollkommen richtig platziert. Spätestend mit den Five-Eyes-Leaks sollte sich unser Verständnis von Computersicherheit aber dahingehend gewandelt haben, dass wir eine andere Größenordnung von Gegener annehmen müssen. Ausgerechnet SSL stellt in diesem Fall keinen Gewinn da. "Die Kosten der Überwachung" deckst du dann beim Erwerb deines Zertifikates gleich mit ab. Was steigt sind vor allem deine eigenen Kosten.
SSL ist eine schlechte Ausrede um sich mit PGP nicht auseinandersetzen zu müssen. Admins jetzt dazu zu nötigen irgendwelche Profaninhalte hinter SSL-Seiten zu stellen ist Ressourcenverschwendung. Das trainiert Internetnutzer dazu Warnungen weg zu klicken und steigert obendrein noch die Einstiegshürde für den gefühlt professionellen Betrieb eigener Services. Die Energie lässt sich sinnvoller aufwenden um z.B. überhaupt erst mal dein Hosting selbst in die Hand zu nehmen. *Das* nämlich wäre ein Anfang.
Hallo.
Am 18.04.2016 um 19:07 schrieb Paul Hänsch:
- SSL ist keine Email-Verschlüsselung!
- Auch nicht ein ganz kleines bisschen
- Auch nicht "besser als gar nichts", die Mailserver in der Kette sind die hauptsächlichen Angriffspunkte, und gerade diese werden nicht abgedeckt
- Irgendwo in der Kette irgendwie was mit Verschlüsselung zu haben ist weit entfernt von sicherer Kommunikation
Transportverschlüsselung ist keine Content-Verschlüsselung, soweit klar.
Aber wenn du schon auf Überwachung durch übermächtige Dritte annimmst, dann mach dir klar wo diese Überwachung stattfindet. Wenn ich von meinem Server an dich auf dem FSFE-Server zustelle, dann geht diese Information, dass *ich* für *dich* eine Mail habe, nur unsere beiden Mailserver etwas an. Wer im DeCIX lauscht, der braucht das nicht zu erfahren. Da ist schon genug der Information, dass mein Server für deinen Server eine oder mehrere Mails hat.
Dass der übermächtige Gegner meinen Server kompromittiert ist nicht ganz wahrscheinlich und dass dieser den FSFE-Server kompromittiert ist auch eher unwahrscheinlich. Also hilft Transportverschlüsselung eben grade für diesen Fall wirklich, weil man die realistischen Angriffsvektoren ausschaltet. Nicht um besonders geheime Daten zu schützen sondern um Privatsphäre zu erzeugen. Klar dass ich meinem Admin vertrauen muss und auch klar, dass ich dem Admin des Gegenüber vertrauen muss. Deshalb versende ich auch so ungern an Gmx- und Gmail-User. Aber im "normalen" Umfeld der Kommunikation zwischen vergleichsweise kleineren Providern und self-hosted-Services, da ist TLS genau das was wir brauchen. Und es wird auch wirklich von anderen Mailservern benutzt, ganz ehrlich.
- *Falls* du den Server zur Submission verwenden willst, gibt es dennoch Authentifizierungsverfahren die das Auslesen von Passwörtern auf Plaintext-Kanälen verhindern (z.B. CRAM)
Wo da jetzt der Vorteil sein soll, erschließt sich mir ganz und gar nicht. Viele Implementierungen brauchen für CRAM das Passwort im Plaintext in der Datenbank. Das ist dann wirklich zu viel verlangt an Vertrauen in den Server-Admin.
Um nochmal zum Anfang zurückzukommen: SSL wurde entworfen und ist geeignet um Kleinkriminelle davon abzuhalten, deine Kreditkartennummer von der Leitung zu sniffen. In dem Bereich ist es vollkommen richtig platziert. Spätestend mit den Five-Eyes-Leaks sollte sich unser Verständnis von Computersicherheit aber dahingehend gewandelt haben, dass wir eine andere Größenordnung von Gegener annehmen müssen. Ausgerechnet SSL stellt in diesem Fall keinen Gewinn da. "Die Kosten der Überwachung" deckst du dann beim Erwerb deines Zertifikates gleich mit ab. Was steigt sind vor allem deine eigenen Kosten.
Ein TLS-Zertifikat kostet schon lange nichts mehr. Es war bisher noch mit jährlicher Überwindung für das Javascript-lastige StartSSL-Webinterface verbunden, seit Dezember 2015 ist das aber vorbei. Kosten für TLS sind für einfache Websites nicht mehr vorhanden.
SSL ist eine schlechte Ausrede um sich mit PGP nicht auseinandersetzen zu müssen.
PGP schützt sensible Inhalte aber nicht die Privatsphäre.
Admins jetzt dazu zu nötigen irgendwelche Profaninhalte hinter SSL-Seiten zu stellen ist Ressourcenverschwendung. Das trainiert Internetnutzer dazu Warnungen weg zu klicken
Welche Warnungen und welche Ressourcen? Kann es sein, dass du noch im TLS von vor 10 Jahren festhängst?
HTTP/2 ist TLS-only und mit Verschlüsselung immer noch effizienter als HTTP/1.1 plain.
Zitate passend zu deinem FUD:
| "On our production frontend machines, SSL/TLS accounts for less than | 1% of the CPU load, less than 10 KB of memory per connection and less | than 2% of network overhead. Many people believe that SSL/TLS takes a | lot of CPU time and we hope the preceding numbers will help to dispel | that." - Adam Langley, Google
| "We have deployed TLS at a large scale using both hardware and | software load balancers. We have found that modern software-based TLS | implementations running on commodity CPUs are fast enough to handle | heavy HTTPS traffic load without needing to resort to dedicated | cryptographic hardware." - Doug Beaver, Facebook
Zudem bewertet Google Seiten besser, wenn sie mit TLS ausgeliefert werden. (https://security.googleblog.com/2014/08/https-as-ranking-signal_6.html)
In ein paar Jahren werden fast alle Transportkanäle im Internet verschlüsselt ablaufen, Gründe dafür gibt es genug, dagegen mittlerweile keine mehr.
Gruß, Bernd
On 2016-04-18 19:58, Bernd Wurst wrote:
Zitate passend zu deinem FUD:
Nein Bernd, ich will deine Mail eigentlich als Gegenmeinung stehen lassen, aber das hier geht so nicht. Den FUD, den diese Zitate ansprechen habe ich weder ex- noch implizit erwähnt. Das finde ich vom Argumentationsstil jetzt wirklich nicht OK. Wir kommen hier ohne Blödsinn aus.
Das Wort Ressourcenverschwendung bezog sich auf menschliche Arbeit.
Hallo.
Am 18.04.2016 um 20:49 schrieb Paul Hänsch:
Das Wort Ressourcenverschwendung bezog sich auf menschliche Arbeit.
Okay, das hatte ich anders aufgefasst und als maschinelle Ressourcen verstanden. Der Teil meiner Mail war im neuen Kontext natürlich unangebracht. Blödsinn ist es aber trotzdem nicht.
Gruß, Bernd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hoi zümma,
Am 18.04.2016 um 13:15 schrieb Paul Hänsch:
On 2016-04-18 08:45, Thomas Porschberg wrote:
ich habe für den Sportverein, Schulklassen etc. diverse Mailinglisten bei googlegroups. Für mein Software-Projekt würde ich nicht unbedingt auf Google setzen wollen. Gibt es Alternativen?
https://media.ccc.de/v/eh15_-_15_-__-_saal_-_201504031700_-_serviette_se rver_-_sveng
Ahoj Michael
- -- Hacking for Freedom!