Joachim Merkel <[EMAIL PROTECTED]> wrote on 10.05.04:
> Michael Heydekamp ([EMAIL PROTECTED]) schrieb:
[...]
> deren Diese Bearbeitungsschritte sollten
> ersatzweise vom E-UUZ (mit Schalter -gate) vorgenommen werden.
[...]
Danke, hab's �berwiegend �bernommen, aber auch selbst nochmal eine
�nderungen, Erg�nzungen und Pr�zisierungen vorgenommen, aktueller Stand
siehe Textanhang.
Das hier ...
> Zudem wurde jeder Kopien-Empf�nger
> durch den ge�nderten To:-Eintrag zum Original-Empf�nger und
> somit der Eindruck vermittelt, er sei der eigentliche Adressat
> und alle anderen Kopienempf�nger.
... ist allerdings nicht Schuld von UKA_PPP, sondern eine Eigenheit des
UUZ bei UUCP-Mails. Sollte im Text jetzt klar werden.
MichaelMY:
- Hinweise f�r Benutzer von UKA_PPP:
Die bisherigen Erfahrungen mit dem Zusammenspiel von Enhanced UUZ und
UKA_PPP haben zu einigen Empfehlungen gef�hrt, die nachfolgend zusam-
mengefa�t sind und denen man folgen sollte:
----------------------------------------------------------------------
1. Wie schon in der Dokumentation zur ersten Fassung des Enhanced UUZ
erw�hnt, sollte der Aufruf des Programms X_SPOOL.EXE mit dem
Schalter "/xc" unmittelbar vor dem UUZ-Aufruf im Netcall-Script
(i.d.R. hei�t diese Datei "XPNEWS") entfernt bzw. auskommentiert
werden. Damit wird die bisher mitunter fehlerhafte Deklaration von
Zeichensatz und deren Codierung vermieden, da die Funktion von
X_SPOOL.EXE nun ersatzweise vom Enhanced UUZ (�ber den Schalter
"-gate", siehe auch Punkt 2. b)) �bernommen wird.
2. a) Der UUZ-Aufruf im Netcall-Script sollte dann wie folgt aussehen:
exec $homedir+"\uuz.exe -zu -client -gate outfile.z .\"
Damit garantiert der Enhanced UUZ, da� Headerzeilen mit 8bit-
Zeichen korrekt MIME-codiert werden (die fr�heren Schalter
"-MIME" und "-1522" sind Default und nicht mehr abschaltbar).
Bisher fehlte im Standardaufruf des UUZ im UKA_PPP-Script
schlicht der Schalter "-1522", so da� permanent Header mit
uncodierten 8bit-Zeichen erzeugt und versandt wurden. :-(
b) Der Schalter "-gate" (siehe auch Punkt 1.) stellt sicher, da�
der Body der Nachricht auf das Vorkommen von 8bit-Zeichen
untersucht und daher sowohl Zeichensatz als auch dessen
Codierung jetzt immer korrekt deklariert werden.
c) Zuguterletzt ist durch den Schalter "-client" gew�hrleistet, da�
Mails im SMTP-Format erstellt werden, die UKA_PPP unver�ndert
und korrekt versendet.
Zum Hintergrund:
Bei den bisher erstellten Mails im UUCP-Format hat UKA_PPP bei
der internen Umwandlung in das SMTP-Format im Falle von Mails
mit Kopienempf�ngern �nderungen an der Adressierung der Nach-
richten vornehmen m�ssen, um den Versand von Dupes zu vermeiden
(zudem wurde durch die etwas sonderbare, bei UUCP-Mails aber
notwendige Gestaltung der To:- und Cc:-Header seitens des UUZ
jedem der Cc:-Empf�nger der falsche Eindruck vermittelt, er
selbst sei To:- und die �brigen Adressaten die Cc:-Empf�nger).
Bei dieser Umwandlung hat UKA_PPP aber stellenweise nicht
ber�cksichtigt, da� Headerzeilen gefaltet sein k�nnen, was im
Zusammenhang mit dem Enhanced UUZ sogar zum Verlust von Kopien-
empf�ngern ("Cc:") und/oder zur K�rzung des Subjects f�hren
konnte.
Der Enhanced UUZ tr�gt insofern mit dazu bei, als da� er gem��
RFC2822 Kopienempf�nger 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, aber
von dem bisherigen Verhalten gehen die Routinen in UKA_PPP aus.
Diese m�glichen Probleme sind durch die direkte Erstellung von
SMTP-Mails �ber den Schalter "-client" automatisch behoben, da
UKA_PPP die Nachrichten nun nicht mehr umformatieren mu�, dies
daher auch nicht tut und die Nachrichten 1:1 versendet.
Voraussetzung ist allerdings, da� die letzte aktuelle UKA_PPP-
Version v1.7x2 vom 25.04.2000 verwendet wird, alle vorherigen
Versionen sind nicht f�r den direkten Versand vn SMTP-Mails
geeignet.
Diese Hinweise gelten nicht f�r das noch zu ver�ffentlichende Add-On
f�r den Betrieb von UKA_PPP in einer RFC/Client-Box, denn dort werden
sie schon von vorneherein ber�cksichtigt sein.------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
