Michael Heydekamp ([EMAIL PROTECTED]) schrieb: > Bei RFC/Client schon. Bei ZConnect m��te das BTW auch gehen, wenn > man den Schalter "Absender [EMAIL PROTECTED]" aktiviert.
interessant. >> [...] Ich will nur zwei vd. Accounts mit vd. Usernamen bei >> demselben Anbieter verwalten, die unter vd. Boxnamen unter XP >> erscheinen m�ssen. > Prinzipiell geht das - von dem oben angesprochenen > "Multiserver-Netcall" mal abgesehen - nat�rlich mindestens mal mit > zwei Boxen und Netcall/ Spezial. Wobei man da wieder was f�r > UKA_PPP basteln m��te, um die Verbindung nach dem Poll der ersten > Box nicht zu trennen. Das w�re kein Problem, ich brauche es aber relativ selten, und aus Sicherheitsgr�nden will ich die Nachrichten trennen. Der eine ist rein beruflich und ich habe keine Lust, das da was schiefl�uft. [Multiserver-Netcall] > Da mu� man sich dann allerdings nochmal genau ansehen, wie man das > Unversandt-Handling sauber hinbek�me. Das wird nicht ganz trivial. F�r mich w�re es glatter overkill. Wobei man fast automatisch auf diese �berlegungen kommt, wenn man sich n�her damit befasst. Das Hauptproblem sehe ich eigentlich nur darin, da� die Abarbeitung nicht f�r jede Box separat von XP angesto�en wird, weil sonst die Pausen beim Einlesen st�ren und daher die Nachrichten immer noch unversandt erscheinen. [...] > Ach so, jetzt ist klar - wenn Du die MID per Filter patchst, wirst > Du diesbzgl. allerdings Probleme bekommen. Vermutlich wird das > Ergebnis sein, da� eine Nachricht mit gepatchter MID, die nicht > versandt werden konnte, von XP als versandt betrachtet werden wird. > Und zu der MID, die die unversandte Nachricht inzwischen tr�gt, wird > XP keine Nachricht in der Datenbank finden und mit einer > Fehlermeldung reagieren. Nichts da, es erscheint lediglich die Meldung da� nicht alle Nachrichten versandt werden konnten und dennoch sind die unversandten nicht mehr markiert und das <box>.pp-File ist gel�scht. Es kann nat�rlich sein, da� in der letzten snapshot-Version das anders ist und eine Fehlermeldung kommt, habe ich nicht �berpr�ft. > Stimmt, ist ein Szenario, mit dem man das Unversandt-Handling > sabotieren kann. Und sehr effektiv, ist aber der klassische Fall, da� mit Ausgangsfiltern nicht zu spa�en ist.. [...] > Sicher w�re es sch�ner, UKA_PPP w�rde direkt auf das XP-Spool > zugreifen, aber das k�me eben einem Umbau von UKA_PPP gleich. W�re auch schwer zu testen, und es wird auch nicht mehr kopiert, als bisher schon. [...] >> Ich dachte eher an ein XP angepa�tes, erweitertes >> Installationsskript f�r eine Standardinstallation. > UKA_PPP m��te sich aber die Daten bei jedem Netcall neu holen. Nur > bei der Installation reicht nicht (und auch da w��te UKA_PPP ja > erstmal nicht, wo die BFGs l�gen, es sei denn, man h�lt sich an die > Konvention von RFC/Client und sagt einfach "eine Verzeichnisebene > dar�ber"). Eigentlich ist ein Batch-File wegen des Unversandt-Handlings schon das richtige und ein weiterer Aufruf von X_Script.Exe erledigt die Einstellungen. So konfiguriere ich generell die Provider �ber einen call mit modify-Befehlen f�r die $Config.$cf und copy-Befehlen der $Config.$pp, meine Version des least-cost-routers. Da kann man auch die .bfg auswerten. Erst der zweite Aufruf von X_Script.Exe startet mit FXPNEWS. Alles in ein Skript zu packen w�rde vielleicht auch gehen, aber es m��ten alle ge�nderten Werte in die Variablen von X_Script.Exe �bernommen werden und das ge�nderte $Config.$cf nach WATTCP.CFG kopiert werden. Hier wird jedenfalls sonst der alte Provider angew�hlt - egal was in $Config.$cf und der WATTCP.CFG aus dem FXPNEWS heraus mit modify ge�ndert wurde. Da sind zwei Aufrufe bisher das einfachste -- solange es nicht einen expliziten Skript-Befehl daf�r gibt. Habe ich allerdings auch nicht nach gesucht. > Wobei mir gerade einf�llt, da� UKA_PPP mit einem $homedir arbeitet > (was wohl das XP-Verzeichnis ist), und ich grad nicht wei�, wo es > das immer �berhaupt hergehabt hat. Anscheinend wird es nirgendwo definiert (im Unterschied zu home, dem UKA_PPP-Verzeichnis) und es wird auf das XP-Stammverzeichnis als Verzeichnis aus dem XP_Script aufgerufen wird, sowieso immer als erstes zu durchsuchendes Verzeichnis genommen. >>> Eher hielte ich es noch f�r sinnvoll, sich mit dem Fixen von ein, >>> zwei alten Bugs in UKA_PPP zu besch�ftigen. >> Tja, sollte man vielleicht KHW wegen des Source mal anschreiben. > Ich denke nicht, da� er andere Sourcen hat als die, die wir auf dem > FTP- Server finden. Er hat mir mal geschrieben, da� er da dringend > mal aufr�umen m�sse, aber das ist schon ein paar Jahre her. ;) ;) [...] > Du sprichst eher von einer "richtigen" Anpassung an RFC/Client, aber > die hatte ich nicht im Blick. Ja, als Starter-Kit eben. >> Nur wenn wir reden �ber eine Standard-Installation aus Sicht von >> XP reden, ist die mit UKAD derzeit besser gel�st. > Das ist klar, weil UKAD den Boxtyp direkt unterst�tzt. Nur geht > z.B. Multibox auch damit nicht. Soweit bin ich nicht gekommen, mich damit zu befassen. Da halte ich dann auch keine automatische Konfiguration f�r UKA_PPP mit den Angaben aus dem <box>.bfg-File mehr f�r sinnvoll. -- Salut _)oachim ------------------------------------------------------------------------ FreeXP Support-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
