Joachim Merkel <[EMAIL PROTECTED]> wrote on 08.04.04:
> ich schrieb:
>> liegt), wobei diese alten Nachrichten im Pollpaket drin blieben
>> und nicht gel�scht wurden und doch und immer wieder (!)
> sorry! ^m�glicherweise
>> versandt wurden, weil die im .pp-File nie gel�scht werden.
> [...]
>> XP bekommt somit u.U. einfach nicht mit, da� im .pp-File noch
>> Nachrichten sind, die schon versandt wurden. ;)
> Das sie immer wieder versandt werden, habe ich nicht selbst
> festgestellt, sondern es sollte eigentlich eine Vermutung zu einer
> m�glichen Fehlerursache sein, da� .pp auch nach dem Versand nicht
> komplett gel�scht wurde.
Wie Du ja inzwischen selbst angemerkt hast, wird das *.PP neu erzeugt.
> Als letztes w�re dann nat�rlich auch noch zu kl�ren, ob sich das
> vielleicht von Boxtyp zu Boxtyp unterscheidet.
Das ist der Fall.
Der wesentliche Unterschied im Unversandt-Handling besteht einfach
darin, da� man - vereinfacht dargestellt - bei allen Netztypen au�er
RFC/Client dem Mailer eine einzige Datei hinwirft, und entweder nimmt
das angerufene System (die Box) sie an (dann gelten alle Nachrichten im
Puffer erstmal als versandt) oder nicht (dann gelten alle Nachrichten im
Puffer als unversandt). Sowas kann man �ber einen simplen Errorlevel
regeln.
Etwaige Rejects, weil z.B. der SMTP-Server sp�ter die eine oder andere
Nachricht vielleicht nicht angenommen hat, wird man dann z.B. bei
RFC/UUCP erst beim n�chsten Poll gewahr, weil die UUCP-Box das File als
Ganzes erstmal angenommen hat.
RFC/Client arbeitet v�llig anders und mu� v�llig anders arbeiten: Dort
spricht der Client direkt mit dem SMTP- bzw. NNTP-Server, und es kann
passieren, da� die erste Nachricht abgewiesen wird, die zweite nicht,
die dritte auch nicht, die vierte doch wieder usw.
Jetzt reicht es nicht mehr, XP mitzuteilen "Konnte Puffer nicht
loswerden", sondern XP mu� wissen, *welche* Nachrichten nicht versandt
werden konnten. Das wird dann eben �ber die Existenz der *.OUT
geregelt, weil ein Errorlevel o.�. hier nicht hilft.
Deshalb auch die Erfindung des Schalters "-client" bzw. "-ppp", der
daf�r sorgt, da� f�r jede ausgehende SMTP-Mail eine eigene Datei erzeugt
wird (bei UUCP w�rde man alle SMTP-Mails in eine einzige Datei
schreiben).
Nach dem Netcall liest XP die Message-IDs aus allen *.OUT aus,
extrahiert diese Nachrichten aus der Messagebase und stellt sie in einen
neuen Pollpuffer ein.
Man sollte vielleicht auch noch wissen, da� unversandte Nachrichten
nicht das Unversandt-Flag neu erhalten, sondern es bei versandten
Nachrichten nach dem Netcall entfernt wird.
Den einzigen Handlungsbedarf, den ich schon seit langem sehe (aber das
hat mit Dupes oder Datenverlusten nix zu tun), ist, da� man die
Nachrichten nicht aus der Messagebase, sondern aus dem urspr�nglichen
Pollpuffer extrhieren sollte. Bei Bin�rnachrichten (nicht bei MIME-
Attachments!) kann es sonst passieren, da� man die Nachricht neu
erstellen mu�, wenn sie nicht versandt werden konnte - XP weist den User
aber dann darauf hin.
Das hat mit dem Schalter "max. Speichergr��e f�r Bin�rnachrichten" unter
C/O/N zu tun, denn wenn da ein Limit eingestellt ist, enth�lt die aus
der Messagebase extrahierte Nachricht den Bin�ranteil m�glicherweise
nicht.
Da� man eine unversandte Nachricht aus der Messagebase und nicht aus dem
urspr�nglichen Pollpuffer extrahiert, hat vermutlich den einzigen Grund,
da� es weniger Arbeit war - denn daf�r gibt's seit jeher eine fertige
Routine. ;)
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
