Zusammenfassung
- Ein positives
DELEsperrte eine Nummer in der laufenden Transaktion, entfernte aber noch nichts;RSETkonnte sämtliche Markierungen aufheben. - Nur clientseitiges
QUITaus TRANSACTION führte in UPDATE. Verbindungsfehler und Inaktivitätsabmeldung durften keine Entfernung auslösen. - RFC 1939 gestand Teilergebnisse zu: Ressourcenmangel konnte einige markierte Nachrichten löschen und andere bestehen lassen.
Das Erfolgssignal war kleiner als sein Wortlaut
Schon RFC 1081 teilte POP3 in AUTHORIZATION, TRANSACTION und UPDATE. Nach erfolgreicher Anmeldung öffnete der Server den Maildrop, erwarb den nötigen exklusiven Zugriff und nummerierte die aktuelle Sicht.
DELE 4 markierte Position vier. Danach schlugen weitere Befehle gegen diese Nummer fehl, doch die Nachricht blieb gespeichert. Solange TRANSACTION lief, hob RSET alle Markierungen auf. Das erste +OK belegte somit eine angenommene Absicht innerhalb der Sitzung, nicht die irreversible Wirkung.
Die Sperre schützte die Bedeutung der Positionsnummern bis UPDATE. Sie machte daraus keine dauerhafte Identität und übertrug dem Client keine Hoheit über Aufbewahrung. RFC 1225 und RFC 1460 bewahrten die Reihenfolge aus Markieren, Rücksetzen, UPDATE durch QUIT, Entfernen, Entsperren, Antworten und Schließen.
Ein Abbruch war kein stellvertretender Abschied
RFC 1725 erklärte 1994 ausdrücklich: Endet die Sitzung anders als durch ein vom Client gesendetes QUIT, tritt sie nicht in UPDATE ein und darf keine Nachricht entfernen. Auch der Inaktivitätstimer schließt ohne Löschung.
Damit blieb die Serverkopie erhalten, wenn Netzwerkempfang und sichere lokale Speicherung auseinanderfielen. Der letzte Oktett kann angekommen sein, während ein Schreibvorgang noch scheitert. Würde der TCP-Abbruch als Zustimmung gelten, vernichtete gerade der ungeklärte Fehler die einzige wiederholbare Quelle.
QUIT in AUTHORIZATION beendet nur. Erst in TRANSACTION, mit geöffneter Sicht und möglichen Markierungen, besitzt der Befehl die Autorität, UPDATE zu öffnen.
UPDATE war keine atomare Zusage
RFC 1939 erlaubt, dass bei Ressourcenmangel einige oder keine markierten Nachrichten entfernt werden. -ERR some deleted messages not removed beschreibt dieses Teilergebnis. Unmarkierte Nachrichten bleiben verbotenes Terrain; danach werden Sperre und Verbindung unabhängig vom Erfolg freigegeben.
Geht die letzte Antwort verloren, kann der Client vollständigen, teilweisen und ausgebliebenen Vollzug nicht unterscheiden. Eine alte Nummer darf nach dem Neuöffnen nicht blind wiederverwendet werden. UIDL kann Überlebende zuordnen, erklärt aber nicht, ob ein anderer Client oder Standortpolitik die fehlende Nachricht entfernte.
RFC 2449 ließ EXPIRE 0 bei Eintritt in UPDATE implizite DELE-Marken für per RETR geladene Nachrichten erzeugen. Die Richtlinie erweiterte die Menge, verschob aber nicht den Zeitpunkt der Entfernung.
Die IANA-Diensteregistrierung führt pop3 auf Port 110. Sie ist kein Beleg für heutige Nutzung oder korrekte Implementierung.
POP3 hielt vier Aussagen auseinander: markiert, in UPDATE versucht, als Ergebnis beobachtet und später abgeglichen. Genau diese Trennung begrenzte die Macht eines bequem klingenden +OK.
Quellen
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
