Michael Heydekamp ([EMAIL PROTECTED]) schrieb: >> Jetzt kann ich keine zwei gmx-Boxen einrichten,
> Warum nicht? >> sondern mu� eine anders nennen, > Wie der Boxname hei�t, ist doch (bei RFC/Client) v�llig egal. Jedenfalls gings unter ZConnect nicht und ich habe es daher beibehalten, vd. Namen zu verwenden, die dann einen Teil der Adresse bilden. Wenn ich also zwei Accounts habe: [EMAIL PROTECTED] und [EMAIL PROTECTED], dann kann ich kaum zwei Boxen mit gmx einrichten. >> setze den Absender und den Namen in der MID auf gmx.de durch einen >> Ausgangsfilter um. > Verstehe ich nicht. Warum? s.o. >> Besser w�re aber einen FDQN zu setzen, damit bei nicht versandten >> Nachrichten auch die MID: mit der im <box>.PP �bereinstimmt. > Im Moment komme ich nicht ganz mit. Ok. > Falls es Dir darum gehen sollte, die Nachrichten mehrerer Boxen mit > einem Anruf versenden zu k�nnen: Probiere doch mal, unter > "Zus�tzliche Server" die Boxen, deren Nachrichten mitversendet > werden sollen, einzutragen. Das war ein Szenario, das ich ohnehin > nochmal testen wollte. Das ist mir jetzt noch v�llig fremd, aber liest sich erstmal gut. Ich will nur zwei vd. Accounts mit vd. Usernamen bei demselben Anbieter verwalten, die unter vd. Boxnamen unter XP erscheinen m�ssen. > Hmm, wird aber wohl daran scheitern, da� die Batch derzeit nur das > Spool der pollenden Box beachtet. Sie m��te im Grunde diesen > Eintrag in der BFG auswerten und die Nachrichten aller dort > eingetragenen Boxen ins UKA_PPP-Spool kopieren. Aha. > K�nnte man sich mal ansehen, wenn ich das Envelope-Handling einbaue, > da mu� ich ohnehin auf BFG-Eintr�ge zugreifen. > Aber zum einen ging der Versand der Nachrichten mehrerer Boxen > gleichzeitig unter ZConnect bisher auch nicht, und zum anderen hat > das immer noch nichts mit den angesprochenen (und nicht von XP > herbeigef�hrten) Unversandt-Problemen zu tun. Mir gehts eigentlich nur um unversandte Nachrichten und wie deren Abgleich nach dem R�ckkopieren ins boxspezifische Verzeichnis mit dem <boX>.pp-File �ber die MID erfolgt. Lediglich darum. Mit dem Bermuda-Dreieck des Helmut Hullen habe ich mich noch nie befa�t und w��te auch nicht, wann es in Erscheinung tritt. Nach meinen Erfahrungen verschwinden Nachrichten dann, wenn sie nach dem R�ckkopieren nicht mehr als unversandt identifiziert werden, was bei mir an dem ge�nderten Domain-Tail der MID: lag. Ich bin dar�berhinaus nicht gerade ein Fan dieser Rumkopiererei, wobei das Thema vd. Spoolfiles f�r ein sicheres Unversandt- Handling mir durchaus gew�rtig ist. >> Oder ein anderer Fall f�r die Doku: Wenn ich den 3. Parameter f�r >> die Aufruf-Batch UKA_FXP.BAT setze, um eine abweichende <box>.$cf >> aufzurufen, also mal als Beispiel, wenn statt gmx wie der 2. >> Parameter $CONFIG �bergeben k�nnte, nunmehr als 3. Parameter gmx1 >> steht, also gmx1.$cf erwartet w�rde, dann sollte auch eine >> gmx1.$do und eine gmx1.$pp vorhanden sein, > Auf GMX1.$DO bzw. �berhaupt die Vollst�ndigkeit und Plausibilit�t > einer Konfiguration zu pr�fen, ist wie bisher Aufgabe von UKA_PPP > selbst. Es ist ja �berhaupt nicht gesagt, da� eine GMX1.$CF auch > eine GMX1.$DO verwendet, denn man kann AFAIK in der .$CF ja auch > einen ganz anderen Config-Namen eintragen (und so mehrere Configs > die immer gleiche .$DO verwenden lassen). Stimmt schon. > Oder vertue ich mich da jetzt? Nein, die �bergabe einer ge�nderten, neuen $Config-Variablen wird akzeptiert, was dann ebenso auf das .$PP-File durchschl�gt. Wenn man also vd. .$cf f�r vd. Provider benutzt, ist der .$pp- Eintrag nicht derselbe, wie bei der ersten .$cf. Das kann man dann im WATTCP.LOG sehen. Ob das �berhaupt eine weitergehende Bedeutung hat, entzieht sich meiner Kenntnis. >> denn der Aufruf .\%1X_SCRIPT.EXE FXPNEWS %UKA_CFG% �bergibt als >> $Config ja den Wert aus der Umgebungsvariablen UKA_CFG die mit dem >> 3. Parameter geladen wurde. > Ja, so ist es gedacht und funktioniert es auch. >> BTW ist sonst das Batchfile nach meinem Eindruck stimmig. Ich habe >> mir das mal installiert, und es lief eigentlich alles problemlos. >> Ich habe nur fast einen Tag lang meine Filter angepasst > Bzw. sie einfach unter den Filtern eingetragen, oder? Ja, bis auf den Eintrag, wo ich den X-RFC..Eintrag des UUZ aus dem Spool-Files l�sche, der erfolgt noch immer aus der FXPNEWS. >> und alles ausgetestet, um denselben Zustand wie vorher zu haben >> (mit ein paar netten Features zugegeben) und bin immer noch der >> Meinung, passender f�r eine Standard-Installation w�re vermutlich, >> das mal in ein UKA_PPP-Skript umzuschreiben sich damit auch >> komplett die Box- Daten aus der .bfg zu holen. > Genau das geht aber nicht, weil UKA_PPP - jedenfalls im derzeitigen > Zustand - Parameter wie den Boxnamen gar nicht auswertet und keine > Ahnung hat, wo die Spoolverzeichnisse von XP liegen. > Das w�re ein Totalumbau von UKA_PPP, den ich eigentlich nicht > vorhatte. Ich dachte eher an ein XP angepa�tes, erweitertes Installationsskript f�r eine Standardinstallation. > Es ging erstmal nur um eine L�sung, die der von XP2 in einer > RFC/PPP-Box in nichts nachsteht und dar�ber hinaus noch einen Tick > besser und sicherer ist. > 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. >> Ob man sich mit dem Batch und der Dokumentation wirklich >> neue und bleibende Verbesserungen schafft, wei� ich nicht. >> Ist vielleicht besser als vorher, aber unter einer Standard- >> Installation verstehe ich noch was anderes, als hinterher in >> .$cf und .$do herumzukramen. > Braucht man doch auch gar nicht. Gerade die User, die eine > Standard-Installation von UKA_PPP betreiben, brauchen �berhaupt gar > nix "herumzukramen". Das ist ja gerade das Sch�ne. Du mu�t doch den Kram erstmal einrichten. Im Prinzip sollte das Vorgehenen doch so sein, da� UKA_PPP ausgepackt wird und RFC/Client unter XP eingerichtet wird. Zus�tzlich w�re ein Konfigurationsskript erforderlich, da� diese Angaben f�r UKA - automatisch - �bernimmt. Vermutlich ist das mit einem Skript f�r X_Skript zu umst�ndlich, aber im Prinzip verstehe ich nur darunter eine Standard-Installation. Die f�hrt nicht unbedingt weiter zu der von Dir ausgew�hlten Batch-Anbindung. Insofern w�re vielleicht der Unterschied wichtig, was eine Standard-Installation aus XP und was eine aus UKA_PPP-Sicht w�re. [...] >> IMHO w�re der Hinweis angebracht, da� man mit dem Batch in der >> Lage ist, eine bereits vorhandene, eingerichtete >> Standard-Installation von UKA_PPP durch XP aufzurufen > Auch eine noch nicht bereits vorhandene, neu eingerichtete > Installation kann man damit aufrufen. >> und nicht mehr. > Doch, das "mehr" steht ja bereits in der Doku, wobei noch ein, zwei > Sachen erg�nzt werden m��ten. Hm. Ich wollte da auch nicht soviel Energie reinstecken und zwei Varianten pflegen wollen. >> Alles in allem erscheint es mir dann sinnvoller auf UKAD zu >> wechseln, da� diese einfachen Anspr�che in jeder Hinsicht bedient. > Man mu� zur Kenntnis nehmen, da� es offenbar User gibt, die UKA_PPP > verwenden. Vor dem Hintergrund, da� man dort an die Sourcen > rankommt und es ggf. bis zum Gehtnichtmehr aufbohren und an seine > Bed�rfnisse anpassen kann, macht das u.U. sogar einen gewissen Sinn. Kein Problem, die Batch-Variante ist ok. Nur wenn wir reden �ber eine Standard-Installation aus Sicht von XP reden, ist die mit UKAD derzeit besser gel�st. -- Salut _)oachim ------------------------------------------------------------------------ FreeXP Support-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
