Michael Heydekamp <[EMAIL PROTECTED]> wrote on 13.03.04:
> Joachim Merkel <[EMAIL PROTECTED]> wrote on 13.03.04:
[...]
>> und jemand $cc_ignore lediglich in *.cfg auskommentiert hat, mu� man
>> eben $cc_ignore sicherheitshalber in XPNEWS nochmal initialisieren.
> Das wird da nicht initialisiert, sondern bewu�t auf "1" gesetzt. Ich
> habe inzwischen eine Vermutung, warum das so ist und in welchen
> F�llen das relevant ist. Wenn diese Vermutung stimmt, ist auch klar,
> warum das bei Netcalls mit einer RFC/PPP- oder RFC/Client-Box
> vollkommen irrelevant ist.
> Aber diese Vermutung mu� ich erst noch verifizieren.
Das habe ich nun getan - die Vermutung war richtig und damit ist die
Sache mit $cc_ignore wie folgt gekl�rt:
1) "$cc_ignore=1" in WATTCP.CFG ist ein beim Betrieb in einer ZConnect-
Box mit dem Originalscript XPNEWS notwendiger Hack, um den Versand
von Dupes bei Mails mit Kopienempf�ngern zu verhindern.
2) Beim Betrieb in einer RFC/PPP- oder RFC/Client-Box ist er schlicht
�berfl�ssig und auch unwirksam. Er kann daher auch in allen Scripts
f�r diese Boxtapen ersatzlos gestrichen werden. Das wollte ich
wissen, und zwar sicher, weil ich nicht Routinen entfernen wollte,
deren Funktion mir nicht 100%ig klar ist.
Das folgende nur f�r die, die an den Details interessiert sind:
---------------------------------------------------------------
Beim Betrieb in einer ZConnect-Box mit dem Originalscript XPNEWS von
UKA_PPP wird die UUZ-Konvertierung nicht von XP, sondern vom Script
vorgenommen. Dort ist per Default folgender UUZ-Aufruf eingetragen:
exec $homedir+"\uuz.exe -zu -MIME outfile.z .\ in out"
Es "fehlt" quasi der Parameter "-smtp". Daher erstellt der UUZ nicht
SMTP-Mails, sondern UUCP-Mails, die beim Versand von UKA_PPP zu SMTP-
Mails umgewandelt werden (ohne da� der User das mitbekommen k�nnte).
Bei Nachrichten mit Kopienempf�ngern erstellt der UUZ nun soviele
physikalische Nachrichten, wie die Mail Empf�nger hat. Dabei bedient er
sich selbst eines Hacks, indem er Header "f�lscht" - bei einer Mail an
<[EMAIL PROTECTED]> mit Kopie an <[EMAIL PROTECTED]> und <[EMAIL PROTECTED]> werden
drei physikalische Mails mit jeweils *unterschiedlichen* To:- und Cc:-
Headern erstellt:
Mail #1: To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Mail #2: To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Mail #3: To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
W�rde UKA_PPP nun bei *allen* drei Mails *alle* Empf�nger in die SMTP-
Header "RCPT TO" eintragen, w�rde jeder Empf�nger die Mail dreimal
erhalten - mit jeweils unterschiedlichen To:- und Cc:-Headern.
"$cc_ignore=1" dient nun dazu, genau das zu verhindern: UKA_PPP tr�gt
bei jeder Mail jeweils nur den ersten Empf�nger im To:-Header als "RCPT
TO" ein. Jeder Empf�nger erh�lt daher die Mail tats�chlich nur einmal -
aber jeder Empf�nger erh�lt jeweils auch andere To:- und Cc:-Header. :-(
So glaubt <[EMAIL PROTECTED]>, er sei der To:-Empf�nger und die anderen die
Kopienempf�nger - was ja auch stimmt. <[EMAIL PROTECTED]> und
<[EMAIL PROTECTED]>, die nur Kopienempf�nger sind, glauben aufgrund der
anderen Header aber ebenfalls, sie seien jeweils selbst der
To:-Empf�nger und die anderen beiden die Kopienempf�nger - was aber
*nicht* stimmt.
Beim Betrieb von UKA_PPP unter den Boxtypen RFC/PPP (XP2) und RFC/Client
(FreeXP) verh�lt es sich komplett anders: Dort wird nur *eine*
physikalische Mail im SMTP-Format erstellt (verantwortlich daf�r ist der
Schalter "-client", der quasi "-smtp" beinhaltet), deren Header in
diesem Fall so aussieht:
----------8<----------
HELO freexp.de
MAIL FROM:<[EMAIL PROTECTED]>
RCPT TO:<[EMAIL PROTECTED]>
RCPT TO:<[EMAIL PROTECTED]>
RCPT TO:<[EMAIL PROTECTED]>
DATA
[...]
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
[...]
----------8<----------
UKA_PPP erkennt offenbar, da� die Mail bereits im SMTP-Format vorliegt
und versendet sie daher unver�ndert, ohne noch daran rumzufummeln.
Daher ist der Eintrag "$cc_ignore=" hier auch irrelevant, weil nicht
mehr UKA_PPP die SMTP-Header erstellt.
Da nur eine physikalische Mail existiert und nur die Empf�nger in
den "RCPT TO"-Headern f�r den Versand von Belang sind, erh�lt jeder
Empf�nger die Mail auch nur einmal - im Unterschied zu vorher aber
erhalten alle Empf�nger sie jetzt mit *identischen* To:- und Cc:-
Headern. :-)
Alle hier beschriebenen Szenarien und Ergebnisse sind getestet und
verifiziert.
Meine urspr�ngliche Frage zu diesem Thema entsprang der Vermutung,
jemand k�nne die Funktion von "$cc_ignore=" in WATTCP.CFG bereits wissen
und darlegen - ist ja immerhin nicht ausgeschlossen.
Wenn das nicht so ist, ist das kein Problem, dann findet man es halt
heraus. Sollte sich jemand durch meine Frage bel�stigt gef�hlt haben,
dann war das bestimmt nicht meine Absicht.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
