Mail Server selber schreiben

[babuschka]

Hallo zusammen!

Ich möchte gerne einen eigenen e-Mail Server in JAVA realisieren (SMTP & POP. Vorerst kein IMAP).

Bevor jetzt die Rufe "Da gibt es doch genug Programme für!!" kommen, etwas zu meiner Motivation.

Der Grund dafür, dass ich den Server selber schreiben möchte ist, dass ich eine bzw. mehrere PGP Funktionen einbauen möchte.
Die Idee kam mir als ich vor einigen Tagen als ich Enigmail für Thunderbird installieren wollte.
Ich studiere zur Zeit (Medien-)informatik im 7. Semester an der Uni Ulm und mir ist bei der Installation und Konfiguration aufgefallen, dass beides nicht so ganz trivial war. Auch frage ich mich, wie denn Outlook-Nutzer und besonders Anwender exotischer Mailprogramme ihre Mails verschlüsseln.
Im Klartext heisst das, dass ich mit der Bedienbarkeit von Enigmail und der mangelnden Unterstützung für PGP bei alternativen Mailprogrammen unzufrieden war, denn wenn ich als Informatikstudent eine Weile brauche um Enigmail so zu konfigurieren, so dass es das macht, was ich will, wie soll das dann meine Oma hinbekommen?
Das Problem bei PGP ist ja, das es ein asymetrischen Schlüsselaustauschverfahren verwendet. Das heisst, nutzt der Empfänger meiner e-Mail kein PGP so hab ich logischerweise auch keinen öffentlichen Schlüssel von ihm und kam ihm keine verschlüsselte e-Mail schicken. Für mich persönlich wäre es wünschenswert, wenn die ganze Welt PGP nutzen würde, so wäre theoretisch jeglicher e-Mailverkehr in zukunft sicher verschlüsselt und signiert. - Utopisch, ich weiss, aber wenn nur 80% aller Mailschreiber PGP nutzen würden, wäre es bereits ein Erfolg.
Diesem Ziel steht aber die Komplexität von PGP samt der Idee des TrustedWeb gegenüber. Selbst wenn ein eMail-Programm oder Plugin eine einfache Bedienung garantieren würden, bringt dies relativ wenig, wenn der User keine Ahnung von PGP an sich hat (Und das wird wohl leider sehr häufig der Fall sein).
Ich würde also hingehen und den User so wenig davon mitkriegen lassen. Ich würde ihn einmal nach einem (sicheren) Passwort fragen und anschließend alles andere dem Programm überlasssen:

1) Schlüsselpaar generieren
2) Kontakte im Mailprogramm durchsuchen und mit einem Keyserver abgleichen und möglichst viele öffentliche Schlüssel herunterladen
3) Ausgehende e-Mails immer signieren und den eigenen öffentlichen Schlüssel noch "dran kleben"
4) Ausgehende e-Mails möglichst verschlüsseln sofern ein öffentlicher Schlüssel des Empfängers bekannt ist
5) Ankommende e-Mails gegebenfalls automatisch entschlüsseln und die Signatur prüfen

Der Anwender selber soll davon so wenig wie möglich mitbekommen. Alles was er weiss ist: "Meine eMails werden verschlüsselt" und mehr nicht.

Jetzt war meine erste Idee eine total einfach Version von Enigmail zu schreiben und dies als Plugin realiseren.
Dann habe ich aber das Problem, dass ich für jedes existierende Programm ein Plugin schreiben müsste und das möchte ich nicht. Einige wenige dieser tools können ja noch nicht mal Erweiterungen wie Plugins nutzen (Autluck Äckzpräss *hust*).

Die Idee vom Plugin scheidet also aus.

Anschließend habe ich mir überlegt einfach einen Daemon zu schreiben der den SMTP- und POP bzw. IMAP - Strom bzw. Port überwacht, diesen abfängt und die Operationen automatisch ausführt. - Irgendwie nicht so elegant und auch nicht sehr einfach glaube ich.

Dann kam mit die Idee mit dem Mailserver und sie funktioniet wie folgt:

Nehmen wir an, Alice möchte Bob eine eMail schreiben.
Alice installiert meinen tollen Mailserver (Nennen wir ihn mal ezPGP - Ja, ich habe schon einen Namen dafür ;-)) und lässt ihn im Hintergrund als Daemon laufen. Bei der Installation des Servers wird ein Wizard gestartet, der ein (sicheres) Passwort abfragt und die oben genannten Schritte 1) - 2) ausführt.

Nehmen wir nun an, Alice hätte einen eMail account bei GMX mit dem Loginnamen alice@gmx.de und dem Passwort "123".

Alice trägt nun diese Daten, den SMTP- und POP server von GMX ein.

Nun öffnet sie ihr standartmäßiges eMailprogramm und trägt dort als Mailserver nicht GMX sondern den lokalen Server auf ihrem Rechner ein.

Von nun an werden eMails nicht mehr direkt an GMX sondern an ihren lokalen Mailserver geschickt. Dieser Server verwaltet die gesamte PGP-Arbeit wie in den Schritten 3) - 5) beschrieben ohne dass Alice groß etwas davon mitbekommt.
Herinkommende eMails fängt ezPGP ab und speichert sie lokal. Alice kann diese eMails ganz normal mit zum Beispiel Thunderbird mit POP oder IMAP abrufen.

Das ist so die Idee.

Nun habe ich schon einige Erfahrungen mit JAVA aber ich konnte trotz fleissigem Googlen keinen Ansatz finden um einen Mailserver zu schreiben (Noch nie gemacht).
Wie gesagt, ich studiere im 7. Semester Informatik und habe auch einige grundlegende Kentnisse von SMTP und POP. Trotzdem will mir kein so richtier Ansatz einfallen. Ich denke das Problem ist nicht so ganz trivial?
JavaMail bringt mir hierbei ja herzlich wenig. Das ist ja nur für Clientsoftware.
Ich vermute ich muss als Mailserver ständig an einem bestimmten Port "lauschen" falls Mails reinkommen und auch einen Socket reservieren/wählen?

Für eine Idee zu einem Ansatz wäre ich sehr dankbar.
Auch ein paar Klassen, die ich dabei verwenden könnte würden helfen.

Gruß
Timo

Ps.: Sorry, für den langen Text

 

[meez]

Ansatz: Zuerst mal die Protokolle implemetieren...

 

[Hilefoks]

Dieses Projekt ist sicher nett, um etwas Netzwerkprogrammierung mit Java zu lernen. Zeitgleich ist dieses Projekt aber wohl auch schon etwas zu gross, um einfach nur zu lernen.

Einen wirklichen Einsatz für diesen Mail-Server (so wie du ihn Skizziert) wird es aber wohl eher nicht geben. Das grösste Problem dabei ist deine Benutzerfreundlichkeit mit der du jede Sicherheit des PGP aushebelst.

Nehmen wir an das du einen solchen Mailserver betreibst und mir eine Mail schreiben möchtest. Dein Mailserver wird nun völlig automatisch meinen PGP-Key ziehen, damit die Mail verschlüsseln und diese mir schicken. Problem Nr. 1 ist aber schon einmal das ich mehrere PGP-Keys für die gleiche Adresse nutze - woher weiß dein Mail-Server welche er nehmen soll.

Noch schlimmer ist das zweite Szenario: Ein böser Mensch hängt sich zwischen dir und meinem Mailserver. Anschließend erzeugt er einen neuen PGP-Key auf meinen Namen. Dein Mail-Server nutzt nun dieses PGP-Key (z.B. weil er neuer ist) um mir Mails zu schreiben. Der böse Mensch zwischen uns fängt nun diese Mail, entschlüsselt sie mit dem ihm bekannten Key, verschlüsselt sie mit meinem echten Key wieder und schickt sie weiter an mich. So kann der böse Mensch unsere Kommunikation mitlesen und wir merken nicht einmal was davon.

Daher muss man immer selber "Hand anlegen", - man muss sich den öffentlichen Schlüssel auf einem sicheren Weg authentifizieren lassen. Das ist das Wesen eines jeden Public-Key-Verfahren (pgp, ssl, u.U. ssh, etc.). Wenn dies automatisiert wird, zumindest so weitreichend das man selbst nichts mehr davon mit bekommt, ist das ganze PGP Verfahren nicht mehr sicher!

Erschwerend kommt bei deinem Mailserver hinzu, das du nicht mit dem Benutzer kommunizieren kannst.

Sicherlich gibt es aber dennoch einen grossen Raum für Verbesserungen, insbesondere an der Benutzerfreundlichkeit. Ich hoffe dir nicht komplett den Mut genommen zu haben, aber ich hoffe das du dein Projekt nochmals genauer überdenkst. Nichts ist ärgerlicher als ein Projekt, bei dem nach viel arbeit festgestellt werden muss, das die gesamte Entwicklung in die falsche Richtung erfolgte...

MfG,
Hilefoks

 

[babuschka]

Danke für die Kritik.
Ich hatte gehofft, die ein oder andere Diskussion hier zunächst zum Konzept starten zu können..

Nehmen wir an das du einen solchen Mailserver betreibst und mir eine Mail schreiben möchtest. Dein Mailserver wird nun völlig automatisch meinen PGP-Key ziehen, damit die Mail verschlüsseln und diese mir schicken. Problem Nr. 1 ist aber schon einmal das ich mehrere PGP-Keys für die gleiche Adresse nutze - woher weiß dein Mail-Server welche er nehmen soll.

Ich würde sagen, das ist egal solange du persönlich da keine Präferenz machst?

Noch schlimmer ist das zweite Szenario: Ein böser Mensch hängt sich zwischen dir und meinem Mailserver. Anschließend erzeugt er einen neuen PGP-Key auf meinen Namen. Dein Mail-Server nutzt nun dieses PGP-Key (z.B. weil er neuer ist) um mir Mails zu schreiben. Der böse Mensch zwischen uns fängt nun diese Mail, entschlüsselt sie mit dem ihm bekannten Key, verschlüsselt sie mit meinem echten Key wieder und schickt sie weiter an mich. So kann der böse Mensch unsere Kommunikation mitlesen und wir merken nicht einmal was davon.

Das kann nicht passieren:
1) Ich würde wahrscheinlich das Konzept des TrustedWeb nutzen, falls dir das was sagt. Der "Mailserver" wird also nur PGPKeys nutzen, die er aus vertrauenswürdigen Quellen hat, die zertifiziert sind oder die z.B. über einen Fingerprint verifiziert werden können.
2) Wie soll der "böse Mann" die eMails mit deinem geheimen Schlüssel verschlüsseln? Wo soll er den her haben?

Erschwerend kommt bei deinem Mailserver hinzu, das du nicht mit dem Benutzer kommunizieren kannst.

Warum nicht? Der Mailserver-Daemon läuft ja auf dem selben Rechner..

 

[hupfdule]

Um das ganze mal einzugrenzen: Was du versuchst, ist ein Mailserver, der ausschließlich für Privatanwender gedacht ist, immer auf dem selben Rechner läuft und quasi als Proxy zwischen dem Client und dem eigentlichen Mailserver fungiert.

In dieser Konstellation ist das schon machbar. Den Aufwand kannst du damit doch stark begrenzen. Denn einen vollständigen Mailserver zu schreiben, dauert schon seine Zeit.

Dennoch teile ich die Meinung von Hilefoks, dass du teilweise die Sicherheit von PGP aushebelst. Diese Schwachstelle könntest du beheben, indem du tatsächlich den Mailserver mit dem Benutzer kommunizieren lässt, du also bei Bedarf ein Fenster öffnest, in das der Benutzer etwas eingeben oder eine Auswahl treffen muss. Das Passwort muss der Benutzer ohnehin angeben. Von daher muss diese Möglichkeit sowieso gegeben sein.

1) Ich würde wahrscheinlich das Konzept des TrustedWeb nutzen, falls dir das was sagt. Der "Mailserver" wird also nur PGPKeys nutzen, die er aus vertrauenswürdigen Quellen hat, die zertifiziert sind oder die z.B. über einen Fingerprint verifiziert werden können.

Das Konzept des TrustedWeb funktioniert ja nur dadurch, dass die Benutzer bewusst einem Schlüssel vertrauen oder nicht.
Du musst ja auch den Fall abdecken, dass du von einem Benutzer keinen vertrauenswürdigen Schlüssel hast. Das muss auf jeden Fall der Benutzer selbst entscheiden, ob er diesen verwenden will.

2) Wie soll der "böse Mann" die eMails mit deinem geheimen Schlüssel verschlüsseln? Wo soll er den her haben?

Den geheimen brauch er nicht. Es reicht der öffentliche. Den hat er.


Zuerst war ich etwas skeptisch bei deiner Idee. Jedoch bei weiteren Überlegungen denke ich, dass das nach dem obigen, stark eingegrenzen Einsatzgebiet doch durchaus eine sinnvolle Anwendung sein kann. Insbesondere das Vermeiden von Plugins für die Email-Programme finde ich sehr gut. Genau genommen ist das der für mich wichtigste Punkt. Das "Verstecken" der Funktionalität des Verschlüsselns ist in meinen Augen eher schlecht. Der Benutzer muss wissen, wann seine Mails verschlüsselt werden. Denn es wird ja auch nicht für jede Adresse ein vertrauenswürdiger Schlüssel vorhanden sein. Von daher werden auch weiterhin Emails unverschlüsselt übers Netz gehen.

 

[babuschka]

Um das ganze mal einzugrenzen: Was du versuchst, ist ein Mailserver, der ausschließlich für Privatanwender gedacht ist, immer auf dem selben Rechner läuft und quasi als Proxy zwischen dem Client und dem eigentlichen Mailserver fungiert.

Genau!
Ein Proxy-PGP-Mailserver sozusagen

Das Konzept des TrustedWeb funktioniert ja nur dadurch, dass die Benutzer bewusst einem Schlüssel vertrauen oder nicht.
Du musst ja auch den Fall abdecken, dass du von einem Benutzer keinen vertrauenswürdigen Schlüssel hast. Das muss auf jeden Fall der Benutzer selbst entscheiden, ob er diesen verwenden will.

Stümmt. Lässt sich, wie du sagst, aber mit ein paar wenigen Meldung aus dem Server relativ einfach lösen.

2) Wie soll der "böse Mann" die eMails mit deinem geheimen Schlüssel verschlüsseln? Wo soll er den her haben?

Den geheimen brauch er nicht. Es reicht der öffentliche. Den hat er.

Öhm. Quote von Hilefoks:

(...) verschlüsselt sie mit meinem echten(<- !!) Key wieder (...)

Zuerst war ich etwas skeptisch bei deiner Idee. Jedoch bei weiteren Überlegungen denke ich, dass das nach dem obigen, stark eingegrenzen Einsatzgebiet doch durchaus eine sinnvolle Anwendung sein kann. Insbesondere das Vermeiden von Plugins für die Email-Programme finde ich sehr gut. Genau genommen ist das der für mich wichtigste Punkt. Das "Verstecken" der Funktionalität des Verschlüsselns ist in meinen Augen eher schlecht. Der Benutzer muss wissen, wann seine Mails verschlüsselt werden. Denn es wird ja auch nicht für jede Adresse ein vertrauenswürdiger Schlüssel vorhanden sein. Von daher werden auch weiterhin Emails unverschlüsselt übers Netz gehen.

Mir ist inzwischen auch schon eine noch andere Anwendung in den Sinn gekommen.
Was, wenn man das Tool in einem Netzwerk zum Beispiel in einer Firma einsetzen würde?
Man müsste es nur geringfügig modifizieren. Das würde dann so aussehen:
Ein Administrator konfiguriert einen lokalen Mailserver mit eben dieser PGP-Funktion.
Alle User innerhalb dieses Netzwerk müssen sich verpflichten einen Account bei diesem Mailserver einzurichten (Zum Beispiel über ein HTTP interface). Anschließend werden noch die "richtigen" Accountdaten von z.B. GMX beim Mailserver eingetragen und schon gehts los: Ab jetzt werden alle eMails, die aus dem Netzwerk raus oder rein gehen über den Mailproxy geleitet und möglichst gut verschlüsselt und/oder signiert. Der Administrator überwacht das ganze und übernimmt die Konfiguration des servers. Anwender können über HTTP ihren Account verwalten und zum Beispiel User einstellen, denen sie vertrauen bzw. nicht vertrauen.
Das wäre zum Beispiel ein ganz konkretes Anwendungsszenario um eMailverschlüsselung bzw. -signierung in Firmen netzwerken zu realisieren. Die "blöden Sekretärinnen" müssten also nur einen Account registrieren und in ihrem eMailprogramm den Proxy Server statt dem richtigen Mailserver eintragen..

 

[hupfdule]

2) Wie soll der "böse Mann" die eMails mit deinem geheimen Schlüssel verschlüsseln? Wo soll er den her haben?

Den geheimen brauch er nicht. Es reicht der öffentliche. Den hat er.

Öhm. Quote von Hilefoks:

(...) verschlüsselt sie mit meinem echten(<- !!) Key wieder (...)

Genau. Mit dem echten öffentlichen Schlüssel. So wie du den falschen öffentlichen Schlüssel des Angreifers verwendest, obwohl du meinst, es wäre der echte öffentliche Schlüssel.

Was, wenn man das Tool in einem Netzwerk zum Beispiel in einer Firma einsetzen würde?

Bei solchen Sachen bin ich eher skeptisch. Diese Versuche einer echten transparenten Verschlüsselung halte ich für eher fragwürdig. Es gibt bereits Ansätze in der Richtung. Mir war so, als wäre GeNUGate ein solcher Ansatz, sieht jetzt aber mehr nach reinen Firewall-Lösungen aus.

Alle User innerhalb dieses Netzwerk müssen sich verpflichten einen Account bei diesem Mailserver einzurichten

Das muss nicht sein. Das kann (und soll) der Administrator erledigen.

Anschließend werden noch die "richtigen" Accountdaten von z.B. GMX beim Mailserver eingetragen und schon gehts los

Ich würde das Passwort meines privaten Accounts bestimmt nicht auf einem Server ablegen.... Allerdings haben Firmen in der Regel ihre eigenen Mailserver, so dass man das nicht muss. Auch ist deine Idee nur für solche firmeninternen Mailserver brauchbar.

Anwender können über HTTP ihren Account verwalten und zum Beispiel User einstellen, denen sie vertrauen bzw. nicht vertrauen.

Und das ist schon ein gravierender Schwachpunkt. Du versuchst dein gerade noch klar umrissenes Einsatzszenario zu erweitern und machst deine Idee damit unbrauchbar. Der PGP-Proxy läuft damit nicht mehr auf dem Client-PC. Er kann daher auch nicht mit dem Benutzer interagieren. Damit tritt genau das ein, was
Hilefoks gesagt hat.

Meine Meinung: Das o.g. Einsatzszenario ist gut. Dafür ist das gut zu gebrauchen. Versuch nicht mehr draus zu machen. Gerade der zentrale, transparente Einsatz ist Unfug. Das funktioniert mit PGP, bzw. dem WebOfTrust nicht.

 

[babuschka]

Okay, dann jetzt konkret zur Umsetzung erstmal nur der Mailserver.
Wie könnte ich das denn jetzt mal angehen? (In JAVA)

Einer hat weiter oben mal gepostet, dass man als Ansatz die Protokolle implementieren könne.
Hilft mir ehrlich gesagt nicht sehr viel

 

[hupfdule]

Recht hat er aber. Zumindest, wenn es an die tatsächliche Implementierung geht. Vorher jedoch musst du deine Idee noch viel stärker festlegen. Sinnvoll ist, wenn du dir selbst ein Pflichtenheft schreibst.

Kläre zuerst noch mal detailliert, was dein Mailserver leisten soll. Also das Einsatzszenario aus Sicht des Benutzers (jedoch möglichst detailliert). Dann teile das Ganze in Funktionalitäten auf. Das wären z.B. Empfangen von Mails, Verschlüsseln von Mails, Senden von Mails, etc. Halt ein typisches Use-Case (sinnvoll wäre auch, wenn du ein UML-Tool einsetzt).

Dann erstell die Architektur deiner Anwendung (sinnvollerweise auch in UML). Erstelle die Bildschirmmasken, die für die Interaktion mit dem Benutzer nötig sind (auf Papier oder in einem Grafikprogramm, bei Bedarf auch gern mit einem GUI-Editor wie Matisse von Netbeans).

Erst wenn das alles steht (also eben das gesamte Pflichtenheft), macht es Sinn mit der Implementierung zu beginnen.

Wie gesagt, mir scheint das Projekt recht interessant und sinnvoll. Ich könnte mir vorstellen, dass ich auch daran mitarbeite.

 

[babuschka]

Uhm, ich weiss nicht, ob sowas wirklich nötig ist...
Das Programm wird ja nicht so groß, oder?

 

[hupfdule]

Uhm, ich weiss nicht, ob sowas wirklich nötig ist...
Das Programm wird ja nicht so groß, oder?

*lach* Kommt drauf an, was du erreichen willst. Wenn du es wirklich erst mal nur zum Lernen machen willst, dann brauchst du das Pflichtenheft nicht. Allerdings solltest du dir im Klaren sein, dass du das fertige Produkt dann mit Sicherheit nicht wirklich einsetzen wirst, weil du viel zu viele Konzeptschwächen dann drin hast. Wenn es dir darum geht, wirklich etwas auf die Beine zu stellen, was am Ende auch von Leuten außer dir selbst benutzt wird, dann solltest du die Planungsphase nicht überspringen. Sie ist im Grunde wichtiger als das eigentliche Programmieren.

 

[babuschka]

He, he. Ja, schon klar.
Soll ja kein kommerzielles Produkt werden

Also Open Source, weil ich wahrscheinlich auf etwas Source Code von anderen Leuten zurückgreifen muss (z.B. GnuPG für die PGP Funktionen).

Mir is schon klar dass für ein ordentliches Konzept Pflichtenheft dergleichen wichtig ist.

Allerdings will ich das Ding erstmal nur "runterschreiben" und sozusagen "on the fly" mir ein Konzept überlegen und während dem Entwickeln immer wieder Rat und Ideen einholen. Da is ein Konzept relativ schnell übern Haufen geworfen

Anschließend, falls sich das Programm bewöhrt und Anklang findet, könnte ich mir eine "richtige" Realisierung vorstellen.

Ich persönlich hab die Erfahrung gemacht, dass mit dieser Methode recht ordentliche Programme entstehen, weil man ja die Erfahrung des vorherigen Programs hat
In den Softwareprojekten in denen ich bisher mitgewirkt habe, habe ich immer festgestellt dass Konzepte meist nur den den 1. oder 2. Meilenstein überleben und am Ende kommt was ganz anderes bei raus, wie gedacht

Wenn man also genug Zeit hat finde ich es sehr lohnenswert, erstmal drauf loszuprogrammieren, wenn man, so wie ich jetzt, von der Technik an sich noch wenig Ahnung hat. Dann baut man später bei der tatsächlichen Realisierung weniger Fehler oder kann Fehler vermeiden, über die man vorher schon gestolpert ist. Das kommt einem sauberen Source Code auch oft zugute.

Ist mir schon klar, dass das in größeren Projekten nicht machbar ist, insbesondere wenn man einen kommerziellen Zweck verfolgt und für einen Kunden programmiert.

Aber wenn man genug Zeit hat, finde ich meine Methode eigentlich nicht schlecht.

My 2 Cents

 

[hupfdule]

Klar, kein Thema. Wenn du die Zeit und Lust hast, das noch mal zu beginnen, ist das eine Option. Auf jeden Fall viel Spaß dabei.
Und halt uns ruhig etwas auf dem Laufenden über das Projekt.

 

[Yzebär]

Für private Projekte, die man hauptsächlich zum Lernen benutzt, halte ich es auch für übertrieben, großartig Zeit in Konzepte und Design zu investieren. Hat man die Sache quick and dirty durchgezogen, hat man danach die nötige Erfahrung, sinnvoll zu planen und zu designen, um das Projekt noch einmal sauber aufzusetzen.

 

[babuschka]

Ich werd hier sicher öfters mal auftauchen, wenn beim Entwickeln java nicht das macht, was ich will

Danke für all den Rat und die Kritik übrigens

Hier aber schonmal meine erste Frage: Wie "implementier" ich denn die Protokolle?

 

[hupfdule]

Wie "implementier" ich denn die Protokolle?

Ähm, was genau meinst du denn damit? Womit hast du das Problem?

Als erstes musst du dich mal informieren, was diese Protokolle leisten müssen. Dazu gibts die RFCs (die sind aber nicht gerade kurz ;-)) [1][2]

Und für beide musst du einen ServerSocket aufmachen. Dieser lauscht auf eingehende Verbindungen und arbeitet diese ab (möglichst in einem eigenen Thread).

[1] http://tools.ietf.org/html/rfc2821
[2] http://tools.ietf.org/html/rfc1939

 

[babuschka]

Ah, ja. Genau letzteres macht mir etwas Kopfzerbrechen.
Da weiss ich nicht so genau wie ich das machen soll.
Gibts da irgendwelche Klassen dazu, die das machen?
Also irgendwas, was mir ein Event schmeisst, wenn an einem Socket was ankommt.

 

[hupfdule]

Lies dir mal ein Tutorial zu Sockets durch.
Der genannte ServerSocket ist genau dazu da. Er belegt einen Port auf dem Server und jedes mal, wenn eine neue Verbindung rein kommt, erstellt er für dich einen Socket, über den du dann die Kommunikation laufen lässt.

Wenn du das ganze sowieso hauptsächlich zum Lernen unternimmst, dann lohnt es sich für dich vlt. statt der "normalen" Socket in java.io das java.nio package anzuschauen. Da gab es irgendwo mal ein recht schönes Einsteiger-Tutorial zu. Kannst ja mal das Forum durchsuchen. Vlt. gibt es hier den Link darauff.

 

[babuschka]

alles klar
Danke nochma

 

[hupfdule]

Das hier war das Tutorial, was ich meinte:

http://javagamesfactory.org/views/article?title=NIO Networking for Games&page=1

 

[babuschka]

okay, ich schaus mir mal an

 

[wranger]

Moin,

das Projekt hört sich sicher interissant an, ich hatte jetzt auch nicht die Zeit alles zu lesen, möchte an dieser Stelle jedoch noch auf einen Punkt hinweisen. Wenn ich das richtig verstanden habe, so läuft dein Server lokal beim Anwender.

Als Spamschutz sperren viele Emailanbieter (gmx, yahoo, usw.) lokale IP-Adressen die z.B. der Telekom, 1&1, usw. gehören. Sollte von diesen eine Mail verschickt werden, so ist die Warscheinlichkeit, dass die Mail ankommt doch ehr gering.

Ein Hinweis, falls ichs richtig verstanden habe!

 

[hupfdule]

Wenn ich das richtig verstanden habe, so läuft dein Server lokal beim Anwender.

So weit richtig.

Ich weiss nicht ob ichs richtig verstanden habe, als Spamschutz sperren viele Emailanbieter (gmx, yahoo, usw.) lokale Ip-Adressen die z.B. der Telekom, 1&1, usw. gehören. Sollte von diesen eine Mail verschickt werden, so ist die Warscheinlichkeit, dass die Mail ankommt doch ehr gering.

So weit falsch. ;-)

Er will ja keinen vollständigen Mailserver daraus machen, sondern nur so etwas wie einen Proxy. Angenommen eine Person mit Adresse ich@1und1.de schickt eine Mail an du@gmx.de, dann läuft die Mail so:

 MUA ------> 1&1 ------> GMX ------> MUA
     SMTP        SMTP        POP

Mit Proxy würde das so aussehen:

 MUA ------> Proxy ------> 1&1 ------> GMX ------> MUA
     SMTP          SMTP        SMTP        POP

Der 1&1 Mailserver sieht keinen Unterschied zwischen dem MUA und dem Proxy. Dieser Proxy schickt die selben Authentifizierungsdaten mit, die auch der MUA schicken würde. Somit gibt es hier kein Problem.


BTW: MUA == Mail User Agent

 

[Guest]

Ja, das hast du richtig verstanden.
Das ist natürlich ein Problem..

Man könnte vielleicht einen eigenen eMailanbieter bauen, der diese eMail forwarded und eine kleine Gebühr damit kassieren

 

[hupfdule]

Ja, das hast du richtig verstanden.

Hat er nicht.

Das ist natürlich ein Problem..

Ist es nicht.

Man könnte vielleicht einen eigenen eMailanbieter bauen, der diese eMail forwarded und eine kleine Gebühr damit kassieren

Supper Idee. Genau das, was die Benutzer in Scharen anzieht.

 

[wranger]

Ja, das hast du richtig verstanden.

Hat er nicht.

Das ist natürlich ein Problem..

Ist es nicht.

Hätte es aber sein können!

Man könnte vielleicht einen eigenen eMailanbieter bauen, der diese eMail forwarded und eine kleine Gebühr damit kassieren

Supper Idee. Genau das, was die Benutzer in Scharen anzieht.

Ahh jetzt! :bae: :###

 

[HansZ]

Um zu deiner initialen Frage zurückzukommen, könnte das xSocket-Framework (http://sourceforge.net/projects/xsocket/) für dich interessant sein. Dieses Framework ist im Umfeld Mailing - als Basis für Serversoftware - entstanden.