Ralf Mueller <[EMAIL PROTECTED]> wrote on 08.05.04:
> Michael Heydekamp <[EMAIL PROTECTED]> schrieb am 08.05.04
> zum Thema: Re: E-UUZ und -graberec tut's nicht mehr ...
>> Mich w�rde mal interessieren, wie Du konkret darauf kommst,
>> irgendwas w�rde nicht mehr laufen?
> Aus allgemeiner, pers�nlicher Erfahrung: never change a running
> system!
Wie bist Du dann blo� �ber v2.90 hianusgekommen... <g>
> Ich denke, das m�ssen wir nicht weiter diskutieren.
Ich m�chte mir noch einen Hinweis dazu erlauben. Was "running" ist und
was nicht, kann der XP-User speziell in RFC-Netzen nicht immer
beurteilen. Zum einen deshalb nicht, weil er i.d.R. nicht die
notwendigen RFC-Kenntnisse besitzt, zum anderen deshalb nicht, weil er
das vom UUZ produzierte Ergebnis - also das, was tats�chlich versandt
wird - nicht sieht. Bei ihm lokal im ZConnect-Format sieht ja immer
alles prima aus, und drau�en kommen dann Header mit uncodierten 8bit-
Zeichen und hinzugef�gten/entfernten Leerzeichen an u.�.
Und wenn er es sehen w�rde, auch meist nicht w��te, ob es OK ist.
Z.B. erzeugt Deine Version unter bestimmten Umst�nden einen Header
"X-Charset:" mit falschem Inhalt - woraufhin der UUZ auch ein falsches
Ergebnis produziert. Was man mit dem Enhanced UUZ verhindern k�nnte,
indem man ihn die Nachricht nochmal pr�fen lie�e (siehe auch Hinweis
weiter unten).
Es k�nnen Dir BTW auch schon mal die Filehandles ausgehen, weil XP im
Laufe der Zeit (und zwar schon bei der v3.20 von Peter) zwar immer mehr
Files gleichzeitig ge�ffnet hat, aber irgendwie niemand daran gedacht
hat, da� man auch mal daf�r sorgen m��te, da� a) auf dem System des
Users gen�gend freie Handles vorhanden sind und b) XP sich diese auch
krallt. Das f�hrt dann mitunter und ganz �berraschend zu den ber�hmten
Datenbank-Fehlermeldungen (die gar keine Datenbankfehler sind).
Wir hatten das konkret bei einem UUCP-Netcall-Szenario.
Ach, was red' ich... ;) Sorry, aber da bin ich halt �berzeugungst�ter,
weil ich wei�, welche immensen - aber nicht auf den ersten Blick
sichtbaren und sich in der Oberfl�che niederschlagenden - Verbesserungen
vorgenommen wurden.
> Ich nehme zur Kenntnis, da� es so einfach:
>> Dr�berb�geln, fertig. Wenn's wider Erwarten nicht genehm ist, alte
>> Version dr�berb�geln, fertig. Dauert jeweils keine 30 Sekunden.
> sein soll -
Wie - "soll"? So einfach war das schon immer bei XP. Wie hast Du denn
die letzte Version installiert, war das da anders?
Gerade weil es sich hier um einen Umstieg von einer Version zu einer
Folgeversion derselben Versionslinie (nur mit inzwischen anderem Namen)
handelt, sind ja noch viel weniger Probleme zu erwarten.
>> Du sprachst doch oben von irgendwas, was nicht so einfach gehen
>> w�rde. Was genau wird warum nicht so einfach gehen?
> Einfach nur die Batches aus Deinem Add-On irgendwohin kopieren und
> gut is', genau das wird so nicht funktionieren, glaube es mir.
Die Frage war doch, was konkret nicht funktioniert (also was Du da
geschraubt hast). Mich interessiert das mal, weil man ggf. Ma�nahmen
bei dem Add-On ergreifen k�nnte/m��te, um sowas zu vereinfachen.
>> An Deiner UKA_PPP-Installation �ndert sich ja gar nix. Wenn Du an
>> Deinem Netcall-Script herumgeschraubt hast, mu� man sich mal
>> ansehen, was das ist. Evtl. werden die �nderungen gar nicht mehr
>> ben�tigt oder man pa�t sie in die vorhandene Batch ein.
> Tut mir leid, die von Dir oben ins Spiel gebrachten 30sec sind
> vorbei.
Ja klar, wenn Du die Fragen nicht gleich beim ersten Mal beantwortest,
kann man das nat�rlich in die L�nge ziehen. ;)
Wobei sich ja die 30 Sekunden eh nur aufs Kopieren und Zur�ckkopieren
bezogen...
>> Was -graberec wert ist, hatte ich in meinem letzten Posting schon
>> erl�utert. Es f�hrt in Deinem Fall schlicht zu einem falschen
>> Ergebnis (unabh�ngig von dem Bug im E-UUZ) und ist ein manchmal,
>> aber eben nicht immer funktionierender Hack.
>> Multidrop kannst Du mit a) nicht erschlagen, richtig. Das geht nur
>> �ber die Auswertung entsprechender Envelope-Header. Da kommen wir
>> wieder auf dieses "Original-recipient:" zur�ck.
>> Das baue ich ja wie gesagt ein.
> Das wird helfen - Danke!
Die Mail mit der gefixten Version und entsprechenden Erl�uterungen ist
raus.
Ach so, wichtiger Hinweis: Wenn Du den Enhanced UUZ mit dem alten
UKA_PPP-Script verwendest, bitte bei ausgehenden Nachrichten *unbedingt*
den UUZ-Schalter "-gate" benutzen und den einen Aufruf von x_spool aus
dem Script rauswerfen. N�heres siehe UUZ_ENH.TXT, dort nach "x_spool"
suchen.
Die Doku ist m�chtig, das kann man schon mal �bersehen, und ich hatte in
der Mail vergessen, darauf hinzuweisen.
Au�erdem solltest Du ebenfalls unbedingt "-client" verwenden, weil damit
SMTP-Mails erzeugt werden, die UKA_PPP unver�ndert und korrekt
versendet. Bei den bisher erzeugten Mails im UUCP-Format fummelt
UKA_PPP nochmal an den Nachrichten herum, und dabei kann es zum K�rzen
und zum Verlust von Headern kommen (speziell "Cc:" und "Subject:"), weil
UKA_PPP nicht damit rechnet, da� die gefoldet sein k�nnen.
Bei "-client" ist "-MIME" und "-1522" Default, die kannst Du Dir dann
schenken.
> Aus einer vorigen Beitrag zum Thema von Dir:
>> Langfristig erscheint es mir aber sinnvoller, Du w�rdest die
>> envelope- f�hige L�sung f�r UKA_PPP verwenden, sobald sie existiert.
> Betrifft diese L�sung nun beide oben genannten Punkte a) und b), d.h.
> wird die komplette envelope-L�sung dann mit UKA_PPP m�glich sein?
Die L�sung f�r b) (also Multidrop) existiert ja indirekt bereits in der
RFC/Client-Box: Da gibt es den Schalter "Envelope-Header auswerten", der
ja nichts anderes bewirkt, als da� der UUZ mit -UseEnvTo aufgerufen
wird.
Mit der Dir vorliegenden UUZ-Version w�rde dann auch "Original-
Recipient:" ausgewertet werden, und wenn Du zus�tzlich noch "-graberec"
angibst, w�rde sogar auch der funktionieren, sofern keiner der
unterst�tzten Envelope-Header vorhanden sein sollte (das geht derzeit
nur extern, weil XP f�r "-graberec" keinen Schalter hat und wohl auch
keinen bekommen wird, dazu ist das zu unzuverl�ssig).
Ich habe -UseEnvTo ja seinerzeit extra wegen Multidrop und eben der
Clients wie UKA_PPP eingebaut, die kein eigenes Envelope-Handling
besitzen.
Die zus�tzliche L�sung f�r UKA_PPP, von der wir sprechen, betrifft nur
den Fall a) und soll dort das Verhalten nachbilden, das die anderen
Clients bei Nicht-Multidrop-Mailboxen auch haben.
> Was ja dann vermutlich bedeuten w�rde, da� UUZ den b) Part �bernehmen
> m�sste,
Genau, s.o.
> den sonst die Clients erledigen.
N�, auch die envelope-f�higen Clients k�nnen Part b) gar nicht
erledigen, jedenfalls ist mir davon nichts bekannt. Die gehen von einem
normalen POP3-Postfach aus, dem genau eine Adresse zugeordnet ist, und
werten daher den Eintrag im Feld "Envelope-Adresse" aus.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
