Hans-Juergen Taenzer <[EMAIL PROTECTED]> wrote on 09.10.04:
> Michael Heydekamp ([EMAIL PROTECTED]) wrote:
>>>> Was (geht) "bei ausgehenden Mails nicht"? Die MID l�schen?
>>>> Weil?
>>> Das ist doch evident: XPFilter filtert ZC-Puffer. Der UUZ soll
>>> die MsgId aber beim Wandeln ins RFC-Format einsetzen.
>> Nein! Da kommt doch der Fall einer fehlenden MID gar nicht vor,
>> weil die im ZC-Raum eh Pflicht ist (unterstellt, da� der UUZ
>> Puffer konvertiert, die von ZC-konformer Software erstellt
>> wurden).
> Du fragst mich, warum es nicht m�glich ist, bei ausgehenden
> Nachrichten (Richtung RFC) mittels XPFilter die MsgId zu l�schen.
Was ich BTW jetzt immer noch nicht wei�. Warum geht das denn nicht?
Und geht es wirklich nicht?
> Ich erkl�rs Dir, und Du kommst mit einem Szenarium, das gar nicht
> Thema war.
Wie - "ich komme mit einem Szenarium, das gar nicht Thema war"? Das
Szenario ZC=>RFC (das gar nicht Thema war) hast *Du* doch mit den Worten
"bei ausgehenden Mails nicht" und "beim Wandeln ins RFC-Format" ins
Gespr�ch gebracht -- ich bin lediglich darauf eingegangen.
Mir ging's doch von Anfang an -- und das habe ich inzwischen auch
mehrfach deutlich gesagt -- nur um eingehende Mails.
Bitte aufdr�seln, ich komme nicht mehr mit. Wird wohl Zeit, da� wir
hier QIs zur Pflicht machen. <g>
> Abgesehen davon, ich erzeuge ich hier sehr wohl ZC-Mails, die keine
> MID besitzen.
Aber sicher nicht mit XP und das sind dann auch keine g�ltigen ZConnect-
Mails.
> Ich m�chte nicht, da� diese Mails zuk�nftig beim Wandeln ins RFC-
> Format eine Zwangs-MsgId ala *invalid* bekommen.
Hallo?? ES GEHT NICHT UM AUSGEHENDE MAILS. Herrje...
>> Nur weil sie im RFC-Raum *nicht* Pflicht ist (und der Fall dort
>> daher auch ganz "legal" vorkommen kann), sprechen wir �ber das
>> Thema doch �berhaupt.
>>> Mit anderen Worten:
>>> XPFilter hat gar keine Chance mehr, die MsgId zu entfernen.
>> Du gehst schlicht von falschen Voraussetzungen aus.
> Du kennst schlicht nicht alle M�glichkeiten, f�r die der UUZ
> eingesetzt wird.
Erstens interessiert mich in erster Linie der Einsatzbereich, f�r den er
vorgesehen ist, und zweitens kann ich Deine "M�glichkeiten" nicht
kennen, solange Du sie nicht mal klar offenlegst.
Insofern machst Du es einem auch nicht leicht, Deine Bedenken zu
verstehen, sie ggf. zu ber�cksichtigen oder die daraus entstehenden
Probleme vielleicht sogar zu l�sen.
Z.B. k�nnte ich mir sogar vorstellen, MIDs nach dem entsprechenden
Muster bei ausgehenden Nachrichten wieder aus der Liste rauszuwerfen,
aber ich wei� im Moment gar nicht, ob Dir das helfen w�rde.
>>> Nein. Es gibt Filter, XPBMF zB.
>> Aha, daher weht der Wind, sag das doch gleich. ;) Und welche
>> noch?
> Wei� nicht, w�sste auch nicht, ob die Anzahl der Filter, die so etwas
> auswerten, eine Rolle spielt.
Selbstverst�ndlich. Ist die Zahl "0", kann man das Problem z.B.
vernachl�ssigen, weil es dann keines g�be. Ist die Zahl "1" und das
betreffende Programm wird noch entwickelt, besteht die Chance, es in
diesem Programm zu l�sen.
Ist die Zahl aber "10", und 9 dieser Programme werrden nicht mehr
entwickelt und es gibt auch keinen Code dazu, ist das ein Problem.
[Keine MID vs. "invalid"-MID]
>> [...] Wenn man also diese beiden F�lle gleichbehandeln will, dann
>> implementiert man das eben.
> Wenn Du die �nderung in den UUZ einbaust, zwingst Du mich, speziell
> f�r diesen Sonderfall eine Sonderprogrammierung vorzunehmen, unsch�n,
> aber nat�rlich machbar.
Na siehste, mein ich doch.
> Was aber von Deiner Seite aus fehlt, ist die Begr�ndung f�r den
> angedachten Zwangsheader.
Nein, die habe ich in <[EMAIL PROTECTED]> ganz am Anfang erw�hnt,
aber Du hast sie bisher ignoriert. Daf�r kann ich ja nix.
Da� er in ZConnect per definitionem Pflicht (aka ein "Zwangsheader")
ist, reicht doch eigentlich schon als Begr�ndung f�r die objektive
Notwendigkeit. Frag doch mal das ZConnect-Gate von Joachim, warum es
solche MIDs erzeugt.
Was macht XPBMF denn in *diesen* F�llen?
Viel wesentlicher aus meiner pers�nlichen Sicht sind aber die fehlende
Bezugsverkettung, au�erdem die sp�ter ins Gespr�ch gebrachten m�glichen
Probleme beim Dupecheck und wo �berall sonst MsgIDs eine Rolle spielen
in XP. Nebenbei verhindert man noch die Erzeugung einer kaputten MID
durch ZPR.
> Ich erkenn im Augenblick nur Nachteile, keine Vorteile.
Ja, f�r Dich. Sorry, aber wenn Du Szenarien baust, die nicht
ZC-konforme Nachrichten zur Voraussetzung haben, kannst Du nicht den UUZ
"blamen", wenn er pl�tzlich ZC-konforme erzeugt.
>> Definitiv wei� ich jedenfalls, da� mit XPFILTER so eine
>> Gleichbehandlung dieser beiden F�lle m�glich ist.
> Du w�rdest mich zwingen zwei Filterl�ufe zu machen. Im ersten
> Filterlauf durch XPFilter den Zwangsheader entfernen lassen, dann
> XPBMF den Spamtest vornehmen zu lassen, und anschlie�end wiederum dann
> XPFilter die gegebenenfalls von XPBMF erzeugten spam-kennzeichnenden
> Header auswerten zu lassen. Nicht sch�n.
Mag sein, aber es funktioniert. Au�erdem kannst Du ja wie gesagt auch
in XPBMF auf das MID-Muster filtern.
>> Au�erdem halte ich f�r ziemlich sinnlos und �berfl�ssig, selbst
>> geschriebene, ausgehende Nachrichten (das ist ja das Szenario, von
>> dem Du oben f�lschlicherweise ausgehst, da� es der UUZ behandeln
>> solle) von XPBMF auf Spam �berpr�fen zu lassen.
> Davon war nie die Rede.
Du hast oben ...
----------8<----------
>>> Das ist doch evident: XPFilter filtert ZC-Puffer. Der UUZ soll
>>> die MsgId aber beim Wandeln ins RFC-Format einsetzen.
----------8<----------
... das bem�ngelt (im flaschen Glauben, es ginge um ausgehende
Nachrichten) und unmittelbar im Anschlu� XPBMF angesprochen.
Wenn XPBMF bei ausgehenden Nachrichten gar nicht zum Einsatz kommen
soll, was genau w�re dann �berhaupt das Problem bei ausgehenden
Nachrichten (unterstellt, die MID solle dort ebenfalls erzeugt werden,
was ja gar nicht der Fall ist)?
> Von der Benutzung des ZPR kann ich nur abraten, die Gr�nde kennst Du
> auch.
IIRC war ich derjenige, dem das aufgefallen ist.
> F�r die Mitlesenden: es gibt Konstellationen, in der der ZPR gnadenlos
> Puffer schrottet.
Das ist richtig, aber kein Argument gegen die Erzeugung einer MID durch
den UUZ.
Fairerweise mu� man aber dazusagen, da� diese Konstellationen auch
extrem selten sind. Trotzdem ist das so nicht akzeptabel.
>> Nur wenn der ebenfalls k�me (bzw. in der Vergangenheit gekommen
>> w�re), w�re die Argumentation auch in sich schl�ssig.
> Komische Argumentation: ich h�tte fr�her einmal gegen den ZPR
> argumentieren m�ssen, um jetzt gegen den angedachten Zwangsheader des
> UUZ argumentieren zu d�rfen?
Zumindest w�re das dann eine stringente Position. Ich wei� nicht, seit
wann genau der ZPR MIDs erzeugt, aber IIRC mindestens, seit ich ihn
kenne (also 1991). Dagegen hat nie jemand was gesagt, zumindest wei�
ich nix davon.
Jetzt stellt man dieselbe Frage f�r den UUZ und es tauchen pl�tzlich
Bedenken auf, die man die ganzen 13 Jahre vorher nicht gehabt hat. Das
ist zumindest nicht ganz einfach zu verstehen.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
