Michael Heydekamp ([EMAIL PROTECTED]) schrieb: > Es gibt eine Mail von HH, die ich mal als Puffer anh�nge (ich hoffe, da� > das als Textanhang auch bei den T-Onlinern ankommt). Dort wird ein > vors�tzlich schr�ges Szenario mit dem h�ndischen Anh�ngen von Mails an > einen Pollpuffer beschrieben, mit dem alle Folgeprobleme reproduziert > werden k�nnen sollen.
Daf�r brauche ich keinen externen Clienten... [...] > Na super, ums Pollpaket ging's nur nicht, daran hat ein Client nichts > herumzufummeln. Dennoch vermutlich ein wichtiger Hinweis.. > Das Thema war, ob XPNews die vier zu versendenden Mails ^^^^^^^^^^^^^ dem "irgendwie" keine Aufmerksamkeit geschenkt wurde und aus "irgendwelchen" Gr�nden wurde die Dikussion des Unversandt-Handlings auf den Fall mit externen Clienten bzw. beschr�nkt... > (also *.OUT im Spool) gel�scht hat. Diese Frage bleibt leider offen, > obwohl es so einfach festzustellen gewesen w�re. Denn wenn XPNews die > *.OUT nicht gel�scht hat, ist nat�rlich auch klar, da� die Mails wieder > im Pollpaket - und somit als unversandte Mails - auftauchen. Ich halte Helmuts Bericht durchaus f�r plausibel, wenn auch er der alleinige Verursacher zu sein scheint, ist da vielleicht XP - irgendwie - auch noch beteiligt und zu verbessern, und die Folgen mancher Anwenderfehler besser vermeiden zu helfen. [...] Ohne mich da rein knien zu wollen, aber bei den Basteleien mit EDA.EXE, das auch die Poll(.pp)-Puffer-Header manipuliert, ist mir aufgefallen, da� im Poll-Puffer Nachrichten liegen bleiben, die als unversandt markiert sind. Es handelte sich dabei nicht um bereits versandte Nachrichten, weil es um den Spezialfall ging, da� mit EDA ge�nderte Nachrichten nochmal mit XPBMIME nachbearbeitet wurden (man erinnere sich, da� Tool l�scht eine zum Versand bereitstehende Nachricht und h�ngt ein mu-MIME-Attachment ran, wonach die neue Nachricht als .ips-Puffer erneut zum Versand �ber das Autoexec-Verzeichnis bereitgestellt wird und im Poll-(.pp)-File liegt), wobei diese alten Nachrichten im Pollpaket drin blieben und nicht gel�scht wurden und doch und immer wieder (!) versandt wurden, weil die im .pp-File nie gel�scht werden. (Die genauen Ursachen sind nich weiter interessant: es ist einfach zu vermeiden, nach dem Aufruf von EDA.EXE-Nachrichten mit XPBMIME zu �ndern, sondern das Ausgangsposting ist eben erneut zum Versand bereitzustellen und dann kann mit XPBMIME Attachments ranh�ngt werden und zuletzt EDA.EXE aufgerufen werden, d.d. EDA ist am besten unmittelbar vor dem Versand aufrufen). XP bekommt somit u.U. einfach nicht mit, da� im .pp-File noch Nachrichten sind, die schon versandt wurden. ;) Ich habe das nicht n�her untersucht, weil in allen diesen F�llen die Ursachen nachtr�gliche �nderungen am .pp-File- Headern die Ursache waren. Man kann geteilter Meinung sein, da� XP diese F�lle abfangen sollte, die Regel sind solche Tools wie EDA jedenfalls nicht. Was keinesfalls XP-konform ist, ist das manuelle Anh�ngen von Nachrichten an .pp-Files. Wozu gibts denn das Autoexec, das .MSG- und IPS- und nicht zuletzt das .EPP-Format. Es sind also F�lle denkbar, wo sich sowas ereignen kann. Interessanterweise waren das normale ZConnect-Netcalls bei mir, also keine RFC/Client-Box und kein ext. Client im Spiel. Bei einem externen Clienten k�nnte man also durchaus auch den Eindruck gewinnnen, da� der Client Nachrichten wieder in den .pp-Puffer zur�ckkopiert. Eigentlich ist mir auch der Hinweis in Erinnerung, da� man in solchen F�llen das .pp-File von Hand l�schen mu�. just my 2 cents -- Salut _)oachim ------------------------------------------------------------------------ FreeXP Support-Mailingliste [EMAIL PROTECTED] http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
