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).
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.
>> Aber egal, um ausgehende Mails geht's ja auch gar nicht. Da
>> braucht der UUZ ja in Sachen MID nix zu erzeugen. Es geht nur um
>> RFC=>ZC.
> Das ging aus Deinen Postings dazu nicht hervor.
Ich habe es nicht ausdr�cklich gesagt, richtig. Wohl, weil ich
unterstellt hatte, da� erg�be sich aus Zusammenhang und Logik.
Du z.B. wei�t offenbar, da� sie bei RFC keine Pflicht ist. Ich
unterstelle, da� Du des weiteren wei�t, da� sie bei ZConnect Pflicht
ist.
Bei genau zwei M�glichkeiten entscheidest Du Dich trotz dieser
Kenntnisse, gegen das von vorneherein unwahrscheinlichere (ZC-Mail
enth�lt keine MsgID) Szenario zu argumentieren, das wesentlich
wahrscheinlichere (RFC-Mail enth�lt keine MsgID) aber v�llig au�er acht
zu lassen.
Verstehe ich nicht.
>> Wenn das so ist, w�re dann eben zuk�nftig
>> [EMAIL PROTECTED] ein genauso eindeutiges und geeignetes
>> Merkmal.
> Nein. Es gibt Filter, XPBMF zB.
Aha, daher weht der Wind, sag das doch gleich. ;) Und welche noch?
> in einer experimentellen Version, f�r die es ein grunds�tzlicher
> Unterschied ist, ob ein bestimmter Header vorhanden ist oder nicht
> (und nicht wie dieser Header aussieht (zumindest bei
> Spezialpr�fungen)).
Ich spreche nur �ber prinzipielle M�glichkeiten, nicht �ber tats�chlich
vorhandene. Nat�rlich k�nnte auch XPBMF auf ein bestimmtes Muster
pr�fen und diesen mit einem anderen Fall (Header nicht existent oder
leer) gleichbehandeln. Ob und was XPBMF im Detail wirklich kann,
entzieht sich meiner Kenntnis, aber technisch m�glich ist so ein
Algorithmus zweifellos (simple "or"-Logik). Wenn man also diese beiden
F�lle gleichbehandeln will, dann implementiert man das eben.
Definitiv wei� ich jedenfalls, da� mit XPFILTER so eine Gleichbehandlung
dieser beiden F�lle m�glich ist. Also kann man, wenn man das unbedingt
will, XPFILTER den Header wieder entfernen lassen (was allerdings wieder
zu einer nicht ZC-konformen Nachricht f�hrt) und ihn dann XPBMF vorlegen
- oder so. Dann bek�me XPBMF die Nachricht im geschilderten Fall ohne
MsgID vorgelegt und alles ist in Butter.
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.
Und mir fehlt bei der ganzen Argumentation auch nach wie vor der Protest
gegen das Erzeugen von MIDs seitens ZPR und UKAW. Nur wenn der
ebenfalls k�me (bzw. in der Vergangenheit gekommen w�re), w�re die
Argumentation auch in sich schl�ssig.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list