Hi,
nachdem die Arbeiten am Code des neuen UUZ nahezu abgeschlossen sind,
bin ich gerade dabei, die Dokumentation dazu zu komplettieren.
Da es inzwischen einiges zum Betrieb von UKA_PPP zusammen mit dem
Enhanced UUZ zu sagen gibt, habe ich das mal zusammengefasst und bitte
um kurze Pruefung sowie ggf. Ergaenzung (speziell JM).
----------8<----------
- Hinweise fuer Benutzer von UKA_PPP:
Die bisherigen Erfahrungen mit dem Zusammenspiel von Enhanced UUZ und
UKA_PPP haben zu einigen Empfehlungen gefuehrt, die nachfolgend zusam-
mengefasst sind und denen man folgen sollte:
----------------------------------------------------------------------
1. Wie schon in der ersten Dokumentation des Enhanced UUZ erwaehnt,
sollte der Aufruf des Programms X_SPOOL.EXE mit dem Schalter "/xc"
unmittelbar vor dem UUZ-Aufruf im Netcall-Script (i.d.R. heisst die
Datei "XPNEWS") entfernt bzw. auskommentiert werden. Damit wird die
bisher mitunter fehlerhafte Deklaration von Zeichensatz und
Codierung vermieden.
2. Der UUZ-Aufruf im Netcall-Script sollte wie folgt aussehen:
exec $homedir+"\uuz.exe -zu -client -gate outfile.z .\"
Zum einen garantiert der Enhanced UUZ, dass Headerzeilen mit 8bit-
Zeichen korrekt MIME-codiert werden (die frueheren Schalter "-MIME"
und "-1522" sind Default und nicht mehr abschaltbar). Bisher fehlte
im Standardaufruf des UUZ im UKA_PPP-Script der Schalter "-1522"
schlicht, so dass permanent Header mit uncodierten 8bit-Zeichen
erzeugt und versandt wurden. :-(
Des weiteren stellt der Schalter "-gate" sicher, dass der Body der
Nachricht auf das Vorkommen von 8bit-Zeichen untersucht und sowohl
Zeichensatz als auch Codierung korrekt deklariert werden.
Zuguterletzt ist durch den Schalter "-client" gewaehrleistet, dass
Mails im SMTP-Format erstellt werden, die UKA_PPP unveraendert und
korrekt versendet. Bei den bisher erstellten Mails im UUCP-Format
hat UKA_PPP wegen der Behandlung von Kopienempfaengern Aenderungen an
den Nachrichten vornehmen muessen, dabei aber stellenweise nicht
beruecksichtigt, dass Headerzeilen gefaltet sein koennen, was zum
Verlust von Kopienempfaengern ("Cc:") und/oder zur Kuerzung des
Subjects fuehren konnte.
Hintergrund ist, dass der Enhanced UUZ gemaess RFC2822 Kopienempfaenger
kommasepariert in einen einzigen Cc:-Header schreibt (statt mehrere
einzelne Cc:-Header zu erzeugen) und sowohl diesen wie auch den
Subject:-Header bei Bedarf faltet. Beides war beim "alten" UUZ
nicht der Fall, und von diesem Verhalten gehen die Routinen in
UKA_PPP aus.
Diese Hinweise gelten nicht fuer das noch zu veroeffentlichende Add-On
fuer den Betrieb von UKA_PPP in einer RFC/Client-Box - dort sind sie
schon von vorneherein beruecksichtigt.
----------8<----------
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
