6. Client-Befehle (Client Commands)
RFC 3501 IMAPv4 March 2003
Beispielsweise sind die folgenden Nicht-Warte-Befehlsfolgen ungültig:
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
Die folgenden sind Beispiele für gültige Nicht-Warte-Befehlsfolgen:
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
UID SEARCH + UID SEARCH kann als Nicht-Warte-Befehlsfolge gültig
oder ungültig sein, je nachdem, ob das zweite UID SEARCH
Nachrichten-Sequenznummern enthält.
6. Client-Befehle (Client Commands)
IMAP4rev1-Befehle werden in diesem Abschnitt beschrieben. Befehle sind nach dem Zustand geordnet, in dem der Befehl zulässig ist. Befehle, die in mehreren Zuständen zulässig sind, werden im minimal zulässigen Zustand aufgeführt (beispielsweise sind Befehle, die im authentifizierten und im ausgewählten Zustand gültig sind, in den authentifizierten Zustandsbefehlen aufgeführt).
Befehlsargumente, die in den Befehlsbeschreibungen unten durch „Arguments:" gekennzeichnet sind, werden nach Funktion und nicht nach Syntax beschrieben. Die genaue Syntax der Befehlsargumente wird im Abschnitt „Formale Syntax" beschrieben.
Einige Befehle bewirken die Rückgabe bestimmter Serverantworten; diese werden in den Befehlsbeschreibungen unten durch „Responses:" gekennzeichnet. In den Antwortbeschreibungen im Abschnitt „Antworten" finden sich Informationen zu diesen Antworten, und im Abschnitt „Formale Syntax" die genaue Syntax dieser Antworten. Es ist möglich, dass Serverdaten als Ergebnis eines beliebigen Befehls übertragen werden. Daher geben Befehle, die keine spezifischen Serverdaten benötigen, „no specific responses for this command" (keine spezifischen Antworten für diesen Befehl) an, statt „none" (keine).
Das „Result:" in der Befehlsbeschreibung bezieht sich auf die möglichen getaggten Statusantworten auf einen Befehl und auf eine etwaige besondere Auslegung dieser Statusantworten.
Der Zustand einer Verbindung wird nur durch erfolgreiche Befehle geändert, die als zustandsändernd dokumentiert sind. Ein zurückgewiesener Befehl (BAD-Antwort) ändert niemals den Zustand der Verbindung oder der ausgewählten Mailbox. Ein fehlgeschlagener Befehl (NO-Antwort) ändert im Allgemeinen den Zustand der Verbindung oder der ausgewählten Mailbox nicht; die Ausnahme bilden die Befehle SELECT und EXAMINE.
RFC 3501 IMAPv4 March 2003
6.1. Client-Befehle - Beliebiger Zustand (Client Commands - Any State)
Die folgenden Befehle sind in einem beliebigen Zustand gültig: CAPABILITY, NOOP und LOGOUT.
6.1.1. CAPABILITY-Befehl (CAPABILITY Command)
Arguments: none (keine)
Responses: REQUIRED untagged response: CAPABILITY (ERFORDERLICHE nicht getaggte Antwort: CAPABILITY)
Result: OK - capability completed (Fähigkeiten abgeschlossen) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der CAPABILITY-Befehl fordert eine Auflistung der Fähigkeiten an, die
der Server unterstützt. Der Server MUSS eine einzelne nicht getaggte
CAPABILITY-Antwort mit „IMAP4rev1" als einer der aufgeführten
Fähigkeiten senden, bevor die (getaggte) OK-Antwort erfolgt.
Ein Fähigkeitsname, der mit „AUTH=" beginnt, zeigt an, dass der Server
jenen bestimmten Authentifizierungsmechanismus unterstützt. Alle
derartigen Namen sind definitionsgemäß Teil dieser Spezifikation.
Beispielsweise wäre die Autorisierungsfähigkeit für einen
experimentellen „blurdybloop"-Authentikator „AUTH=XBLURDYBLOOP" und
nicht „XAUTH=BLURDYBLOOP" oder „XAUTH=XBLURDYBLOOP".
Andere Fähigkeitsnamen beziehen sich auf Erweiterungen, Überarbeitungen
oder Änderungen dieser Spezifikation. In der Dokumentation der
CAPABILITY-Antwort finden sich weitere Informationen. Keine
Fähigkeiten über den in dieser Spezifikation definierten
Basis-IMAP4rev1-Satz hinaus werden ohne ausdrückliche Client-Aktion
zur Aufrufung der Fähigkeit aktiviert.
Client- und Server-Implementierungen MÜSSEN die Fähigkeiten STARTTLS,
LOGINDISABLED und AUTH=PLAIN (beschrieben in [IMAP-TLS])
implementieren. Im Abschnitt „Sicherheitsüberlegungen" finden sich
wichtige Informationen.
Im Abschnitt „Client-Befehle - Experimentell/Erweiterung" finden sich
Informationen über die Form standort- oder implementierungsspezifischer
Fähigkeiten.
RFC 3501 IMAPv4 March 2003
Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed
6.1.2. NOOP-Befehl (NOOP Command)
Arguments: none (keine)
Responses: no specific responses for this command (but see below) (keine spezifischen Antworten für diesen Befehl, siehe unten)
Result: OK - noop completed (noop abgeschlossen) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der NOOP-Befehl gelingt immer. Er tut nichts.
Da jeder Befehl eine Statusaktualisierung als nicht getaggte Daten
zurückgeben kann, kann der NOOP-Befehl als periodische Abfrage nach
neuen Nachrichten oder Nachrichtenstatusaktualisierungen während einer
Inaktivitätsperiode verwendet werden (dies ist die bevorzugte Methode
dafür). Der NOOP-Befehl kann ebenfalls verwendet werden, um einen
etwaigen Inaktivitäts-Autoabmeldetimer auf dem Server
zurückzusetzen.
Example: C: a002 NOOP S: a002 OK NOOP completed . . . C: a047 NOOP S: * 22 EXPUNGE S: * 23 EXISTS S: * 3 RECENT S: * 14 FETCH (FLAGS (\Seen \Deleted)) S: a047 OK NOOP completed
RFC 3501 IMAPv4 March 2003
6.1.3. LOGOUT-Befehl (LOGOUT Command)
Arguments: none (keine)
Responses: REQUIRED untagged response: BYE (ERFORDERLICHE nicht getaggte Antwort: BYE)
Result: OK - logout completed (logout abgeschlossen) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der LOGOUT-Befehl informiert den Server, dass der Client mit der
Verbindung fertig ist. Der Server MUSS eine BYE nicht getaggte Antwort
senden, bevor die (getaggte) OK-Antwort erfolgt, und dann die
Netzwerkverbindung schließen.
Example: C: A023 LOGOUT S: * BYE IMAP4rev1 Server logging out S: A023 OK LOGOUT completed (Server und Client schließen dann die Verbindung)
6.2. Client-Befehle - Nicht authentifizierter Zustand (Client Commands - Not Authenticated State)
Im nicht authentifizierten Zustand stellt der AUTHENTICATE- oder LOGIN- Befehl die Authentifizierung her und tritt in den authentifizierten Zustand ein. Der AUTHENTICATE-Befehl bietet einen allgemeinen Mechanismus für verschiedene Authentifizierungstechniken, Privatsphärenschutz und Integritätsprüfung; hingegen verwendet der LOGIN-Befehl ein traditionelles Benutzername- und Klartext-Passwort-Paar und hat keine Möglichkeit, Privatsphärenschutz oder Integritätsprüfung herzustellen.
Der STARTTLS-Befehl ist eine alternative Form der Herstellung von Sitzungs-Privatsphärenschutz und Integritätsprüfung, stellt jedoch keine Authentifizierung her und tritt nicht in den authentifizierten Zustand ein.
Server-Implementierungen DÜRFEN den Zugriff auf bestimmte Mailboxen ohne Herstellung einer Authentifizierung gestatten. Dies kann durch den ANONYMOUS-[SASL]-Authentikator geschehen, der in [ANONYMOUS] beschrieben ist. Eine ältere Konvention ist ein LOGIN-Befehl mit dem Benutzernamen „anonymous"; in diesem Fall ist ein Passwort erforderlich, obwohl der Server jedes Passwort akzeptieren kann. Die Beschränkungen, die für anonyme Benutzer gelten, sind implementierungsabhängig.
Einmal authentifiziert (einschließlich als anonym), ist es nicht möglich, in den nicht authentifizierten Zustand zurückzukehren.
RFC 3501 IMAPv4 March 2003
Zusätzlich zu den universellen Befehlen (CAPABILITY, NOOP und LOGOUT) sind die folgenden Befehle im nicht authentifizierten Zustand gültig: STARTTLS, AUTHENTICATE und LOGIN. Im Abschnitt „Sicherheitsüberlegungen" finden sich wichtige Informationen zu diesen Befehlen.
6.2.1. STARTTLS-Befehl (STARTTLS Command)
Arguments: none (keine)
Responses: no specific response for this command (keine spezifische Antwort für diesen Befehl)
Result: OK - starttls completed, begin TLS negotiation (starttls abgeschlossen, TLS-Aushandlung beginnen) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Eine [TLS]-Aushandlung beginnt unmittelbar nach dem CRLF am Ende der
getaggten OK-Antwort vom Server. Sobald ein Client einen STARTTLS-
Befehl ausgibt, DARF er keine weiteren Befehle ausgeben, bis eine
Serverantwort gesehen wurde und die [TLS]-Aushandlung abgeschlossen
ist.
Der Server verbleibt im nicht authentifizierten Zustand, selbst wenn
Client-Anmeldedaten während der [TLS]-Aushandlung bereitgestellt
werden. Dies schließt nicht aus, dass ein Authentifizierungsmechanismus
wie EXTERNAL (definiert in [SASL]) eine durch die [TLS]-Aushandlung
bestimmte Client-Identität verwendet.
Sobald [TLS] gestartet wurde, MUSS der Client zwischengespeicherte
Informationen über Server-Fähigkeiten verwerfen und SOLLTE den
CAPABILITY-Befehl erneut ausgeben. Dies ist notwendig, um
Man-in-the-Middle-Angriffe zu verhindern, die die Fähigkeitenliste vor
STARTTLS verändern. Der Server KANN nach STARTTLS andere Fähigkeiten
bekanntgeben.
Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
RFC 3501 IMAPv4 March 2003
6.2.2. AUTHENTICATE-Befehl (AUTHENTICATE Command)
Arguments: authentication mechanism name (Name des Authentifizierungsmechanismus)
Responses: continuation data can be requested (Fortsetzungsdaten können angefordert werden)
Result: OK - authenticate completed, now in authenticated state (authenticate abgeschlossen, nun im authentifizierten Zustand) NO - authenticate failure: unsupported authentication mechanism, credentials rejected (authenticate-Fehlschlag: nicht unterstützter Authentifizierungsmechanismus, Anmeldedaten zurückgewiesen) BAD - command unknown or arguments invalid, authentication exchange cancelled (Befehl unbekannt oder Argumente ungültig, Authentifizierungsaustausch abgebrochen)
Der AUTHENTICATE-Befehl zeigt einen [SASL]-Authentifizierungsmechanismus
dem Server an. Wenn der Server den angeforderten
Authentifizierungsmechanismus unterstützt, führt er einen
Authentifizierungsprotokoll-Austausch durch, um den Client zu
authentifizieren und zu identifizieren. Er KANN ebenfalls eine
OPTIONALE Sicherheitsebene für nachfolgende Protokollinteraktionen
aushandeln. Wenn der angeforderte Authentifizierungsmechanismus nicht
unterstützt wird, SOLLTE der Server den AUTHENTICATE-Befehl durch
Senden einer getaggten NO-Antwort zurückweisen.
Der AUTHENTICATE-Befehl unterstützt nicht die optionale
„initial response"-Funktion von [SASL]. Abschnitt 5.1 von [SASL]
beschreibt, wie ein Authentifizierungsmechanismus gehandhabt wird, der
eine anfängliche Antwort verwendet.
Der von diesem Protokollprofil von [SASL] angegebene Dienstname ist
„imap".
Der Authentifizierungsprotokoll-Austausch besteht aus einer Reihe von
Server-Herausforderungen (challenges) und Client-Antworten, die für den
Authentifizierungsmechanismus spezifisch sind. Eine Server-
Herausforderung besteht aus einer Antwort zur Befehlsfortsetzungs-
anforderung mit dem „+"-Token gefolgt von einer BASE64-kodierten
Zeichenkette. Die Client-Antwort besteht aus einer einzelnen Zeile, die
eine BASE64-kodierte Zeichenkette enthält. Wenn der Client einen
Authentifizierungsaustausch abbrechen möchte, gibt er eine Zeile aus,
die aus einem einzelnen „*" besteht. Wenn der Server eine derartige
Antwort erhält, MUSS er den AUTHENTICATE-Befehl durch Senden einer
getaggten BAD-Antwort zurückweisen.
Wenn durch den [SASL]-Authentifizierungsaustausch eine Sicherheitsebene
ausgehandelt wird, tritt diese unmittelbar nach dem CRLF in Kraft, das
den Authentifizierungsaustausch für den Client abschließt, und nach dem
CRLF der getaggten OK-Antwort für den Server.
Während Client- und Server-Implementierungen den AUTHENTICATE-Befehl
selbst implementieren MÜSSEN, ist es nicht erforderlich, andere
Authentifizierungsmechanismen als den in [IMAP-TLS] beschriebenen
PLAIN-Mechanismus zu implementieren. Ebenso ist ein
Authentifizierungsmechanismus nicht verpflichtet, Sicherheitsebenen zu
unterstützen.
RFC 3501 IMAPv4 March 2003
Hinweis: Eine Server-Implementierung MUSS eine Konfiguration
implementieren, in der sie KEINE Klartext-Passwort-Mechanismen
zulässt, es sei denn, entweder der STARTTLS-Befehl wurde
ausgehandelt oder es wurde ein anderer Mechanismus bereitgestellt,
der die Sitzung vor dem Mitlesen von Passwörtern schützt.
Server-Standorte SOLLTEN KEINE Konfiguration verwenden, die einen
Klartext-Passwort-Mechanismus ohne einen derartigen
Schutzmechanismus gegen das Mitlesen von Passwörtern zulässt.
Client- und Server-Implementierungen SOLLTEN zusätzliche [SASL]-
Mechanismen implementieren, die keine Klartext-Passwörter
verwenden, wie etwa den in [SASL] beschriebenen GSSAPI-Mechanismus
und/oder den [DIGEST-MD5]-Mechanismus.
Server und Clients können mehrere Authentifizierungsmechanismen
unterstützen. Der Server SOLLTE seine unterstützten
Authentifizierungsmechanismen in der Antwort auf den CAPABILITY-Befehl
aufführen, damit der Client weiß, welche Authentifizierungsmechanismen
er verwenden soll.
Ein Server KANN einen CAPABILITY-Antwortcode in die getaggte OK-
Antwort eines erfolgreichen AUTHENTICATE-Befehls einfügen, um
Fähigkeiten automatisch zu senden. Es ist für einen Client unnötig,
einen separaten CAPABILITY-Befehl zu senden, wenn er diese
automatischen Fähigkeiten erkennt. Dies SOLLTE nur geschehen, wenn
keine Sicherheitsebene durch den AUTHENTICATE-Befehl ausgehandelt
wurde, da die getaggte OK-Antwort als Teil eines AUTHENTICATE-Befehls
nicht durch Verschlüsselung/Integritätsprüfung geschützt ist. [SASL]
verlangt vom Client, in diesem Fall einen CAPABILITY-Befehl erneut
auszugeben.
Wenn ein AUTHENTICATE-Befehl mit einer NO-Antwort fehlschlägt, KANN der
Client einen anderen Authentifizierungsmechanismus ausprobieren, indem
er einen weiteren AUTHENTICATE-Befehl ausgibt. Er KANN ebenfalls
versuchen, sich durch Verwendung des LOGIN-Befehls zu authentifizieren
(siehe Abschnitt 6.2.3 für weitere Einzelheiten). Mit anderen Worten,
der Client KANN Authentifizierungstypen in absteigender
Präferenzreihenfolge anfordern, wobei der LOGIN-Befehl als letzter
Ausweg dient.
Die Autorisierungsidentität, die während des Authentifizierungs-
austauschs vom Client an den Server übergeben wird, wird vom Server als
der Benutzername interpretiert, dessen Berechtigungen der Client
anfordert.
RFC 3501 IMAPv4 March 2003
Example: S: * OK IMAP4rev1 Server C: A001 AUTHENTICATE GSSAPI S: + C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0 b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW Lud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg== S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0 uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg== C: S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe ceP2CWY0SR0fAQAgAAQEBAQ= C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP wkhbfa2QteAQAgAG1yYwE= S: A001 OK GSSAPI authentication successful
Hinweis: Die Zeilenumbrüche innerhalb der Server-Herausforderungen
und Client-Antworten dienen der Lesbarkeit und sind in echten
Authentikatoren nicht vorhanden.
6.2.3. LOGIN-Befehl (LOGIN Command)
Arguments: user name (Benutzername) password (Passwort)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - login completed, now in authenticated state (login abgeschlossen, nun im authentifizierten Zustand) NO - login failure: user name or password rejected (login-Fehlschlag: Benutzername oder Passwort zurückgewiesen) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der LOGIN-Befehl identifiziert den Client gegenüber dem Server und
überträgt das Klartext-Passwort, das diesen Benutzer authentifiziert.
RFC 3501 IMAPv4 March 2003
Ein Server KANN einen CAPABILITY-Antwortcode in die getaggte OK-Antwort
auf einen erfolgreichen LOGIN-Befehl einfügen, um Fähigkeiten
automatisch zu senden. Es ist für einen Client unnötig, einen separaten
CAPABILITY-Befehl zu senden, wenn er diese automatischen Fähigkeiten
erkennt.
Example: C: a001 LOGIN SMITH SESAME S: a001 OK LOGIN completed
Hinweis: Die Verwendung des LOGIN-Befehls über ein unsicheres
Netz (wie das Internet) ist ein Sicherheitsrisiko, da jeder, der den
Netzverkehr überwacht, Klartext-Passwörter erhalten kann. Der
LOGIN-Befehl SOLLTE nicht verwendet werden, außer als letzter
Ausweg, und es wird empfohlen, dass Client-Implementierungen eine
Möglichkeit haben, die automatische Verwendung des LOGIN-Befehls zu
deaktivieren.
Sofern nicht entweder der STARTTLS-Befehl ausgehandelt wurde oder
ein anderer Mechanismus bereitgestellt wurde, der die Sitzung vor
dem Mitlesen von Passwörtern schützt, MUSS eine Server-Implementierung
eine Konfiguration implementieren, in der sie die LOGINDISABLED-
Fähigkeit bekanntgibt und den LOGIN-Befehl nicht zulässt.
Server-Standorte SOLLTEN KEINE Konfiguration verwenden, die den
LOGIN-Befehl ohne einen derartigen Schutzmechanismus gegen das
Mitlesen von Passwörtern zulässt. Eine Client-Implementierung DARF
KEINEN LOGIN-Befehl senden, wenn die LOGINDISABLED-Fähigkeit
bekanntgegeben wird.
6.3. Client-Befehle - Authentifizierter Zustand (Client Commands - Authenticated State)
Im authentifizierten Zustand sind Befehle zulässig, die Mailboxen als atomare Einheiten bearbeiten. Von diesen Befehlen wählen die Befehle SELECT und EXAMINE eine Mailbox für den Zugriff aus und treten in den ausgewählten Zustand ein.
Zusätzlich zu den universellen Befehlen (CAPABILITY, NOOP und LOGOUT) sind die folgenden Befehle im authentifizierten Zustand gültig: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS und APPEND.
RFC 3501 IMAPv4 March 2003
6.3.1. SELECT-Befehl (SELECT Command)
Arguments: mailbox name (Mailbox-Name)
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT (ERFORDERLICHE nicht getaggte Antworten) REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY (ERFORDERLICHE OK nicht getaggte Antworten)
Result: OK - select completed, now in selected state (select abgeschlossen, nun im ausgewählten Zustand) NO - select failure, now in authenticated state: no such mailbox, can't access mailbox (select-Fehlschlag, nun im authentifizierten Zustand: keine solche Mailbox, auf Mailbox nicht zugreifbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der SELECT-Befehl wählt eine Mailbox aus, damit auf Nachrichten in der
Mailbox zugegriffen werden kann. Bevor der Server ein OK an den Client
zurückgibt, MUSS er die folgenden nicht getaggten Daten an den Client
senden. Beachten Sie, dass frühere Versionen dieses Protokolls nur die
nicht getaggten Daten FLAGS, EXISTS und RECENT verlangten; folglich
SOLLTEN Client-Implementierungen Standardverhalten für fehlende Daten
implementieren, wie bei dem jeweiligen Element erörtert.
FLAGS Definierte Flags in der Mailbox. Siehe die Beschreibung
der FLAGS-Antwort für weitere Einzelheiten.
`<n>` EXISTS Die Anzahl der Nachrichten in der Mailbox. Siehe die
Beschreibung der EXISTS-Antwort für weitere Einzelheiten.
`<n>` RECENT Die Anzahl der Nachrichten mit gesetztem \Recent-Flag.
Siehe die Beschreibung der RECENT-Antwort für weitere
Einzelheiten.
OK [UNSEEN `<n>`]
Die Nachrichten-Sequenznummer der ersten ungelesenen
Nachricht in der Mailbox. Fehlt diese, kann der Client
keine Annahmen über die erste ungelesene Nachricht in
der Mailbox treffen und muss einen SEARCH-Befehl
ausgeben, wenn er sie finden möchte.
OK [PERMANENTFLAGS (`<list of flags>`)]
Eine Liste der Nachrichten-Flags, die der Client dauerhaft
ändern kann. Fehlt diese, sollte der Client annehmen, dass
alle Flags dauerhaft geändert werden können.
OK [UIDNEXT `<n>`]
Der nächste Wert des eindeutigen Bezeichners. Siehe
Abschnitt 2.3.1.1 für weitere Informationen. Fehlt diese,
kann der Client keine Annahmen über den nächsten Wert des
eindeutigen Bezeichners treffen.
RFC 3501 IMAPv4 March 2003
OK [UIDVALIDITY `<n>`]
Der Gültigkeitswert des eindeutigen Bezeichners. Siehe
Abschnitt 2.3.1.1 für weitere Informationen. Fehlt diese,
unterstützt der Server keine eindeutigen Bezeichner.
In einer Verbindung kann jeweils nur eine Mailbox ausgewählt sein;
der gleichzeitige Zugriff auf mehrere Mailboxen erfordert mehrere
Verbindungen. Der SELECT-Befehl deselektiert automatisch jede
derzeit ausgewählte Mailbox, bevor der neue Auswahlversuch unternommen
wird. Folglich ist, wenn eine Mailbox ausgewählt ist und ein
fehlschlagender SELECT-Befehl versucht wird, keine Mailbox ausgewählt.
Wenn der Client die Mailbox ändern darf, SOLLTE der Server den Text der
getaggten OK-Antwort mit dem Antwortcode „[READ-WRITE]" versehen.
Wenn der Client die Mailbox nicht ändern darf, aber Lesezugriff
gestattet ist, wird die Mailbox als nur-lesend ausgewählt, und der
Server MUSS den Text der getaggten OK-Antwort auf SELECT mit dem
Antwortcode „[READ-ONLY]" versehen. Nur-lesender Zugriff über SELECT
unterscheidet sich vom EXAMINE-Befehl dadurch, dass bestimmte nur-
lesende Mailboxen die Änderung des dauerhaften Zustands auf
benutzerbezogener (statt globaler) Basis gestatten DÜRFEN. In einem
serverbasierten .newsrc-File markierte Netnews-Nachrichten sind ein
Beispiel für einen derartigen benutzerbezogenen dauerhaften Zustand,
der mit nur-lesenden Mailboxen geändert werden kann.
Example: C: A142 SELECT INBOX S: * 172 EXISTS S: * 1 RECENT S: * OK [UNSEEN 12] Message 12 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Deleted \Seen *)] Limited S: A142 OK [READ-WRITE] SELECT completed
RFC 3501 IMAPv4 March 2003
6.3.2. EXAMINE-Befehl (EXAMINE Command)
Arguments: mailbox name (Mailbox-Name)
Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT (ERFORDERLICHE nicht getaggte Antworten) REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY (ERFORDERLICHE OK nicht getaggte Antworten)
Result: OK - examine completed, now in selected state (examine abgeschlossen, nun im ausgewählten Zustand) NO - examine failure, now in authenticated state: no such mailbox, can't access mailbox (examine-Fehlschlag, nun im authentifizierten Zustand: keine solche Mailbox, auf Mailbox nicht zugreifbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der EXAMINE-Befehl ist identisch zu SELECT und liefert dieselbe
Ausgabe; jedoch wird die ausgewählte Mailbox als nur-lesend
gekennzeichnet. Keine Änderungen am dauerhaften Zustand der Mailbox,
einschließlich des benutzerbezogenen Zustands, sind gestattet;
insbesondere DARF EXAMINE NICHT bewirken, dass Nachrichten das
\Recent-Flag verlieren.
Der Text der getaggten OK-Antwort auf den EXAMINE-Befehl MUSS mit dem
Antwortcode „[READ-ONLY]" beginnen.
Example: C: A932 EXAMINE blurdybloop S: * 17 EXISTS S: * 2 RECENT S: * OK [UNSEEN 8] Message 8 is first unseen S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS ()] No permanent flags permitted S: A932 OK [READ-ONLY] EXAMINE completed
6.3.3. CREATE-Befehl (CREATE Command)
Arguments: mailbox name (Mailbox-Name)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - create completed (create abgeschlossen) NO - create failure: can't create mailbox with that name (create-Fehlschlag: Mailbox mit jenem Namen nicht anlegbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der CREATE-Befehl erstellt eine Mailbox mit dem angegebenen Namen. Eine
OK-Antwort wird nur zurückgegeben, wenn eine neue Mailbox mit jenem
Namen erstellt wurde. Es ist ein Fehler, zu versuchen, INBOX oder eine
Mailbox mit einem Namen zu erstellen, der sich auf eine vorhandene
Mailbox bezieht. Jeder Fehler bei der Erstellung gibt eine getaggte
NO-Antwort zurück.
RFC 3501 IMAPv4 March 2003
Wenn der Mailbox-Name mit dem Hierarchie-Trennzeichen des Servers (wie
vom Server durch einen LIST-Befehl zurückgegeben) endet, ist dies eine
Erklärung, dass der Client beabsichtigt, unter diesem Namen in der
Hierarchie Mailbox-Namen zu erstellen. Server-Implementierungen, die
diese Erklärung nicht benötigen, MÜSSEN sie ignorieren. In jedem Fall
wird der erstellte Name ohne das nachgestellte Hierarchie-Trennzeichen
erstellt.
Erscheint das Hierarchie-Trennzeichen des Servers an anderer Stelle im
Namen, SOLLTE der Server alle übergeordneten hierarchischen Namen
erstellen, die für das erfolgreiche Abschließen des CREATE-Befehls
benötigt werden. Mit anderen Worten, ein Versuch, „foo/bar/zap" auf
einem Server zu erstellen, bei dem „/" das Hierarchie-Trennzeichen ist,
SOLLTE foo/ und foo/bar/ erstellen, falls diese nicht bereits existieren.
Wenn eine neue Mailbox mit demselben Namen wie eine gelöschte Mailbox
erstellt wird, MÜSSEN ihre eindeutigen Bezeichner größer sein als alle
eindeutigen Bezeichner, die in der vorherigen Ausgabe der Mailbox
verwendet wurden, ES SEI DENN die neue Ausgabe hat einen anderen
Gültigkeitswert für den eindeutigen Bezeichner. Siehe die Beschreibung
des UID-Befehls für weitere Einzelheiten.
Example: C: A003 CREATE owatagusiam/ S: A003 OK CREATE completed C: A004 CREATE owatagusiam/blurdybloop S: A004 OK CREATE completed
Hinweis: Die Auslegung dieses Beispiels hängt davon ab, ob „/"
als Hierarchie-Trennzeichen von LIST zurückgegeben wurde. Ist „/"
das Hierarchie-Trennzeichen, wird eine neue Hierarchieebene namens
„owatagusiam" mit einem Mitglied namens „blurdybloop" erstellt.
Andernfalls werden zwei Mailboxen auf derselben Hierarchieebene
erstellt.
6.3.4. DELETE-Befehl (DELETE Command)
Arguments: mailbox name (Mailbox-Name)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - delete completed (delete abgeschlossen) NO - delete failure: can't delete mailbox with that name (delete-Fehlschlag: Mailbox mit jenem Namen nicht löschbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
RFC 3501 IMAPv4 March 2003
Der DELETE-Befehl entfernt die Mailbox mit dem angegebenen Namen dauerhaft.
Eine getaggte OK-Antwort wird nur zurückgegeben, wenn die Mailbox
gelöscht wurde. Es ist ein Fehler, zu versuchen, INBOX oder einen
nicht existierenden Mailbox-Namen zu löschen.
Der DELETE-Befehl DARF untergeordnete hierarchische Namen nicht
entfernen. Beispielsweise darf, wenn eine Mailbox „foo" eine
untergeordnete „foo.bar" hat (wobei „." das Hierarchie-Trennzeichen
ist), das Entfernen von „foo" NICHT „foo.bar" entfernen. Es ist ein
Fehler, zu versuchen, einen Namen zu löschen, der untergeordnete
hierarchische Namen hat und ebenfalls das \Noselect-Mailbox-Namensattribut
hat (siehe die Beschreibung der LIST-Antwort für weitere Einzelheiten).
Es ist gestattet, einen Namen zu löschen, der untergeordnete
hierarchische Namen hat und nicht das \Noselect-Mailbox-Namensattribut
hat. In diesem Fall werden alle Nachrichten in jener Mailbox entfernt,
und der Name erhält das \Noselect-Mailbox-Namensattribut.
Der Wert des höchstverwendeten eindeutigen Bezeichners der gelöschten
Mailbox MUSS beibehalten werden, damit eine neu erstellte Mailbox mit
demselben Namen die Bezeichner der früheren Ausgabe nicht wiederverwendet,
ES SEI DENN die neue Ausgabe hat einen anderen Gültigkeitswert für den
eindeutigen Bezeichner. Siehe die Beschreibung des UID-Befehls für
weitere Einzelheiten.
Examples: C: A682 LIST "" * S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo S: * LIST () "/" foo/bar S: A682 OK LIST completed C: A683 DELETE blurdybloop S: A683 OK DELETE completed C: A684 DELETE foo S: A684 NO Name "foo" has inferior hierarchical names C: A685 DELETE foo/bar S: A685 OK DELETE Completed C: A686 LIST "" * S: * LIST (\Noselect) "/" foo S: A686 OK LIST completed C: A687 DELETE foo S: A687 OK DELETE Completed
RFC 3501 IMAPv4 March 2003
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
6.3.5. RENAME-Befehl (RENAME Command)
Arguments: existing mailbox name (vorhandener Mailbox-Name) new mailbox name (neuer Mailbox-Name)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - rename completed (rename abgeschlossen) NO - rename failure: can't rename mailbox with that name, can't rename to mailbox with that name (rename-Fehlschlag: Mailbox mit jenem Namen nicht umbenennbar, in Mailbox mit jenem Namen nicht umbenennbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der RENAME-Befehl ändert den Namen einer Mailbox. Eine getaggte
OK-Antwort wird nur zurückgegeben, wenn die Mailbox umbenannt wurde. Es
ist ein Fehler, zu versuchen, von einem nicht existierenden Mailbox-Namen
oder in einen bereits existierenden Mailbox-Namen umzubenennen. Jeder
Fehler beim Umbenennen gibt eine getaggte NO-Antwort zurück.
Hat der Name untergeordnete hierarchische Namen, so MÜSSEN auch diese
untergeordneten hierarchischen Namen umbenannt werden. Beispielsweise
benennt ein Umbenennen von „foo" in „zap" „foo/bar" (wobei „/" das
Hierarchie-Trennzeichen ist) in „zap/bar" um.
Erscheint das Hierarchie-Trennzeichen des Servers im Namen, SOLLTE der
Server alle übergeordneten hierarchischen Namen erstellen, die für das
erfolgreiche Abschließen des RENAME-Befehls benötigt werden. Mit anderen
Worten, ein Versuch, „foo/bar/zap" in baz/rag/zowie auf einem Server
umzubenennen, bei dem „/" das Hierarchie-Trennzeichen ist, SOLLTE baz/
und baz/rag/ erstellen, falls diese nicht bereits existieren.
RFC 3501 IMAPv4 March 2003
Der Wert des höchstverwendeten eindeutigen Bezeichners des alten
Mailbox-Namens MUSS beibehalten werden, damit eine neu erstellte Mailbox
mit demselben Namen die Bezeichner der früheren Ausgabe nicht wiederverwendet,
ES SEI DENN die neue Ausgabe hat einen anderen Gültigkeitswert für den
eindeutigen Bezeichner. Siehe die Beschreibung des UID-Befehls für
weitere Einzelheiten.
Das Umbenennen von INBOX ist gestattet und hat ein besonderes Verhalten.
Es verschiebt alle Nachrichten in INBOX in eine neue Mailbox mit dem
angegebenen Namen und lässt INBOX leer. Unterstützt die Server-
Implementierung untergeordnete hierarchische Namen von INBOX, so bleiben
diese vom Umbenennen von INBOX unberührt.
Examples: C: A682 LIST "" * S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo S: * LIST () "/" foo/bar S: A682 OK LIST completed C: A683 RENAME blurdybloop sarasoop S: A683 OK RENAME completed C: A684 RENAME foo zowie S: A684 OK RENAME Completed C: A685 LIST "" * S: * LIST () "/" sarasoop S: * LIST (\Noselect) "/" zowie S: * LIST () "/" zowie/bar S: A685 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
RFC 3501 IMAPv4 March 2003
6.3.6. SUBSCRIBE-Befehl (SUBSCRIBE Command)
Arguments: mailbox (Mailbox)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - subscribe completed (subscribe abgeschlossen) NO - subscribe failure: can't subscribe to that name (subscribe-Fehlschlag: Abonnieren jenes Namens nicht möglich) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der SUBSCRIBE-Befehl fügt den angegebenen Mailbox-Namen der vom LSUB-
Befehl zurückgegebenen Menge der „aktiven" oder „abonnierten" Mailboxen
des Servers hinzu. Dieser Befehl gibt eine getaggte OK-Antwort nur
zurück, wenn das Abonnieren erfolgreich war.
Ein Server KANN das Mailbox-Argument von SUBSCRIBE validieren, um zu
prüfen, dass es existiert. Er DARF jedoch einen vorhandenen Mailbox-Namen
nicht einseitig aus der Abonnementliste entfernen, selbst wenn eine
Mailbox jenes Namens nicht mehr existiert.
Hinweis: Diese Anforderung besteht, weil ein Server-Standort
wählen kann, eine Mailbox mit einem bekannten Namen (z. B.
„system-alerts") routinemäßig zu entfernen, nachdem ihr Inhalt
abgelaufen ist, in der Absicht, sie neu zu erstellen, wenn neue
Inhalte passend sind.
Example: C: A002 SUBSCRIBE #news.comp.mail.mime S: A002 OK SUBSCRIBE completed
6.3.7. UNSUBSCRIBE-Befehl (UNSUBSCRIBE Command)
Arguments: mailbox name (Mailbox-Name)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - unsubscribe completed (unsubscribe abgeschlossen) NO - unsubscribe failure: can't unsubscribe that name (unsubscribe-Fehlschlag: Abonnement jenes Namens nicht kündbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der UNSUBSCRIBE-Befehl entfernt den angegebenen Mailbox-Namen aus der vom
LSUB-Befehl zurückgegebenen Menge der „aktiven" oder „abonnierten"
Mailboxen des Servers. Dieser Befehl gibt eine getaggte OK-Antwort nur
zurück, wenn die Kündigung des Abonnements erfolgreich war.
Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime S: A002 OK UNSUBSCRIBE completed
RFC 3501 IMAPv4 March 2003
6.3.8. LIST-Befehl (LIST Command)
Arguments: reference name (Referenzname) mailbox name with possible wildcards (Mailbox-Name mit möglichen Platzhaltern)
Responses: untagged responses: LIST (nicht getaggte Antworten)
Result: OK - list completed (list abgeschlossen) NO - list failure: can't list that reference or name (list-Fehlschlag: jene Referenz oder jenen Namen nicht auflistbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der LIST-Befehl gibt eine Teilmenge der Namen aus der vollständigen Menge
aller dem Client verfügbaren Namen zurück. Null oder mehr nicht getaggte
LIST-Antworten werden zurückgegeben, die das Namensattribut, das
Hierarchie-Trennzeichen und den Namen enthalten; siehe die Beschreibung
der LIST-Antwort für weitere Einzelheiten.
Der LIST-Befehl SOLLTE seine Daten schnell ohne ungebührliche Verzögerung
zurückgeben. Er SOLLTE beispielsweise nicht übermäßigen Aufwand
betreiben, um den \Marked- oder \Unmarked-Status zu berechnen oder andere
Verarbeitungen durchzuführen; erfordert jeder Name 1 Sekunde
Verarbeitung, dann würde eine Liste von 1200 Namen 20 Minuten dauern!
Ein leeres (""-Zeichenkette) Referenznamen-Argument zeigt an, dass der
Mailbox-Name so interpretiert wird wie durch SELECT. Die zurückgegebenen
Mailbox-Namen MÜSSEN dem angegebenen Mailbox-Namen-Muster entsprechen.
Ein nicht leeres Referenznamen-Argument ist der Name einer Mailbox oder
einer Ebene der Mailbox-Hierarchie und zeigt den Kontext an, in dem der
Mailbox-Name interpretiert wird.
Ein leeres (""-Zeichenkette) Mailbox-Namen-Argument ist eine besondere
Anforderung, das Hierarchie-Trennzeichen und den Wurzelnamen des im
Referenznamen angegebenen Namens zurückzugeben. Der als Wurzel
zurückgegebene Wert KANN die leere Zeichenkette sein, wenn die Referenz
wurzellos ist oder eine leere Zeichenkette ist. In allen Fällen wird ein
Hierarchie-Trennzeichen (oder NIL, falls keine Hierarchie existiert)
zurückgegeben. Dies erlaubt es einem Client, das Hierarchie-Trennzeichen
(oder herauszufinden, dass die Mailbox-Namen flach sind) zu erhalten,
selbst wenn derzeit keine Mailboxen jenes Namens existieren.
Die Referenz- und Mailbox-Namen-Argumente werden in eine kanonische Form
interpretiert, die eine eindeutige von links nach rechts verlaufende
Hierarchie darstellt. Die zurückgegebenen Mailbox-Namen liegen in der
interpretierten Form vor.
RFC 3501 IMAPv4 March 2003
Hinweis: Die Auslegung des Referenznamen-Arguments ist
implementierungsdefiniert. Sie hängt davon ab, ob die
Server-Implementierung ein Konzept des „aktuellen
Arbeitsverzeichnisses" und führender „Ausbruchzeichen" hat,
die das aktuelle Arbeitsverzeichnis außer Kraft setzen.
Beispielsweise enthält auf einem Server, der ein UNIX- oder
NT-Dateisystem exportiert, das Referenznamen-Argument das
aktuelle Arbeitsverzeichnis, und das Mailbox-Namen-Argument
enthielte den Namen, wie er im aktuellen Arbeitsverzeichnis
interpretiert wird.
Hat eine Server-Implementierung kein Konzept von Ausbruchzeichen,
ist die kanonische Form normalerweise der Referenzname, an den der
Mailbox-Name angehängt ist. Beachten Sie, dass, wenn der Server die
Namensraum-Konvention (Abschnitt 5.1.2) implementiert, „#" ein
Ausbruchzeichen ist und als solches behandelt werden muss.
Ist das Referenznamen-Argument keine Ebene der Mailbox-Hierarchie
(das heißt, es ist ein \NoInferiors-Name) und/oder endet das
Referenznamen-Argument nicht mit dem Hierarchie-Trennzeichen, so ist
implementierungsabhängig, wie dies interpretiert wird. Beispielsweise
könnten eine Referenz von „foo/bar" und ein Mailbox-Name von
„rag/baz" als „foo/bar/rag/baz", „foo/barrag/baz" oder
„foo/rag/baz" interpretiert werden. Ein Client SOLLTE ein derartiges
Referenznamen-Argument nicht verwenden, außer auf ausdrückliche
Anforderung des Benutzers. Ein hierarchischer Browser DARF KEINE
Annahmen über die Server-Interpretation der Referenz treffen, es sei
denn, die Referenz ist eine Ebene der Mailbox-Hierarchie UND endet
mit dem Hierarchie-Trennzeichen.
Jeder Teil des Referenznamen-Arguments, der in der interpretierten Form
enthalten ist, SOLLTE der interpretierten Form vorangestellt werden. Er
SOLLTE ebenfalls in derselben Form wie das Referenznamen-Argument vorliegen.
Diese Regel erlaubt es dem Client zu bestimmen, ob der zurückgegebene
Mailbox-Name im Kontext des Referenznamen-Arguments liegt oder ob etwas am
Mailbox-Argument das Referenznamen-Argument außer Kraft gesetzt hat. Ohne
diese Regel müsste der Client Kenntnis der Benennungssemantik des Servers
haben, einschließlich welche Zeichen „Ausbrüche" sind, die einen
Benennungskontext außer Kraft setzen.
RFC 3501 IMAPv4 March 2003
Beispielsweise hier einige Beispiele, wie Referenzen und Mailbox-
Namen auf einem UNIX-basierten Server interpretiert werden könnten:
Referenz Mailbox-Name Interpretation
------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/%
#news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/foo
archive/ ~fred/Mail/* ~fred/Mail/*
Die ersten drei Beispiele demonstrieren Interpretationen im Kontext
des Referenznamen-Arguments. Beachten Sie, dass „~smith/Mail" NICHT
in etwas wie „/u2/users/smith/Mail" umgewandelt werden SOLLTE, da es
sonst für den Client unmöglich wäre zu bestimmen, dass die
Interpretation im Kontext der Referenz lag.
Das Zeichen „*" ist ein Platzhalter und stimmt auf null oder mehr
Zeichen an dieser Stelle überein. Das Zeichen „%" ähnelt „*", stimmt
jedoch nicht auf ein Hierarchie-Trennzeichen überein. Ist der „%"-
Platzhalter das letzte Zeichen eines Mailbox-Namen-Arguments, werden
ebenfalls übereinstimmende Ebenen der Hierarchie zurückgegeben. Sind
diese Ebenen der Hierarchie keine auswählbaren Mailboxen, werden sie mit
dem \Noselect-Mailbox-Namensattribut zurückgegeben (siehe die Beschreibung
der LIST-Antwort für weitere Einzelheiten).
Server-Implementierungen ist gestattet, anderweitig zugreifbare Mailboxen
vor den Platzhalterzeichen zu „verbergen", indem sie verhindern, dass
bestimmte Zeichen oder Namen in bestimmten Situationen mit einem
Platzhalter übereinstimmen. Beispielsweise könnte ein UNIX-basierter
Server die Interpretation von „*" so einschränken, dass ein führendes
„/"-Zeichen nicht übereinstimmt.
Der besondere Name INBOX ist in der Ausgabe von LIST enthalten, wenn
INBOX von diesem Server für diesen Benutzer unterstützt wird und wenn die
Großbuchstaben-Zeichenkette „INBOX" mit den oben beschriebenen
interpretierten Referenz- und Mailbox-Namen-Argumenten mit Platzhaltern
übereinstimmt. Das Kriterium für das Weglassen von INBOX ist, ob SELECT
INBOX einen Fehlschlag zurückgibt; es ist nicht relevant, ob die echte
INBOX des Benutzers auf diesem oder einem anderen Server liegt.
RFC 3501 IMAPv4 March 2003
Example: C: A101 LIST "" "" S: * LIST (\Noselect) "/" "" S: A101 OK LIST Completed C: A102 LIST #news.comp.mail.misc "" S: * LIST (\Noselect) "." #news. S: A102 OK LIST Completed C: A103 LIST /usr/staff/jones "" S: * LIST (\Noselect) "/" / S: A103 OK LIST Completed C: A202 LIST ~/Mail/ % S: * LIST (\Noselect) "/" ~/Mail/foo S: * LIST () "/" ~/Mail/meetings S: A202 OK LIST completed
6.3.9. LSUB-Befehl (LSUB Command)
Arguments: reference name (Referenzname) mailbox name with possible wildcards (Mailbox-Name mit möglichen Platzhaltern)
Responses: untagged responses: LSUB (nicht getaggte Antworten)
Result: OK - lsub completed (lsub abgeschlossen) NO - lsub failure: can't list that reference or name (lsub-Fehlschlag: jene Referenz oder jenen Namen nicht auflistbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der LSUB-Befehl gibt eine Teilmenge der Namen aus der Menge der Namen
zurück, die der Benutzer als „aktiv" oder „abonniert" erklärt hat. Null
oder mehr nicht getaggte LSUB-Antworten werden zurückgegeben. Die
Argumente für LSUB liegen in derselben Form vor wie die für LIST.
Die zurückgegebene nicht getaggte LSUB-Antwort KANN andere Mailbox-Flags
als eine nicht getaggte LIST-Antwort enthalten. Sollte dies geschehen,
gelten die Flags in der nicht getaggten LIST-Antwort als
maßgeblicher.
Eine besondere Situation tritt bei Verwendung von LSUB mit dem „%"-
Platzhalter auf. Betrachten Sie, was geschieht, wenn „foo/bar" (mit einem
Hierarchie-Trennzeichen von „/") abonniert ist, aber „foo" nicht. Ein
„%"-Platzhalter für LSUB muss foo zurückgeben, nicht foo/bar, in der
LSUB-Antwort, und es MUSS mit dem \Noselect-Attribut gekennzeichnet sein.
Der Server DARF einen vorhandenen Mailbox-Namen nicht einseitig aus der
Abonnementliste entfernen, selbst wenn eine Mailbox jenes Namens nicht
mehr existiert.
RFC 3501 IMAPv4 March 2003
Example: C: A002 LSUB "#news." "comp.mail.*" S: * LSUB () "." #news.comp.mail.mime S: * LSUB () "." #news.comp.mail.misc S: A002 OK LSUB completed C: A003 LSUB "#news." "comp.%" S: * LSUB (\NoSelect) "." #news.comp.mail S: A003 OK LSUB completed
6.3.10. STATUS-Befehl (STATUS Command)
Arguments: mailbox name (Mailbox-Name) status data item names (Status-Datenelementnamen)
Responses: untagged responses: STATUS (nicht getaggte Antworten)
Result: OK - status completed (status abgeschlossen) NO - status failure: no status for that name (status-Fehlschlag: kein Status für jenen Namen) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der STATUS-Befehl fordert den Status der angegebenen Mailbox an. Er
ändert die derzeit ausgewählte Mailbox nicht und beeinflusst den Zustand
aller Nachrichten in der abgefragten Mailbox nicht (insbesondere DARF
STATUS NICHT bewirken, dass Nachrichten das \Recent-Flag verlieren).
Der STATUS-Befehl bietet eine Alternative zum Öffnen einer zweiten
IMAP4rev1-Verbindung und zum Ausführen eines EXAMINE-Befehls auf einer
Mailbox, um den Status jener Mailbox abzufragen, ohne die aktuelle
Mailbox in der ersten IMAP4rev1-Verbindung zu deselektieren.
Anders als der LIST-Befehl ist der STATUS-Befehl nicht garantiert
schnell in seiner Antwort. Unter bestimmten Umständen kann er recht
langsam sein. In einigen Implementierungen ist der Server verpflichtet,
die Mailbox intern nur-lesend zu öffnen, um bestimmte Statusinformationen
zu erhalten. Ebenfalls anders als der LIST-Befehl akzeptiert der
STATUS-Befehl keine Platzhalter.
Hinweis: Der STATUS-Befehl dient dazu, auf den Status von Mailboxen
zuzugreifen, die nicht die derzeit ausgewählte Mailbox sind. Da der
STATUS-Befehl bewirken kann, dass die Mailbox intern geöffnet wird,
und da diese Information auf der ausgewählten Mailbox auf andere
Weise verfügbar ist, SOLLTE der STATUS-Befehl NICHT auf der derzeit
ausgewählten Mailbox verwendet werden.
RFC 3501 IMAPv4 March 2003
Der STATUS-Befehl DARF NICHT als „Prüfung auf neue Nachrichten in der
ausgewählten Mailbox"-Operation verwendet werden (siehe Abschnitte 7,
7.3.1 und 7.3.2 für weitere Informationen zur ordnungsgemäßen Methode
der Neu-Nachrichten-Prüfung).
Da der STATUS-Befehl nicht garantiert schnell in seinen Ergebnissen
ist, SOLLTEN Clients nicht erwarten, dass sie viele aufeinander-
folgende STATUS-Befehle ausgeben und eine vernünftige Leistung
erhalten können.
Die derzeit definierten Status-Datenelemente, die angefordert werden
können, sind:
MESSAGES
Die Anzahl der Nachrichten in der Mailbox.
RECENT
Die Anzahl der Nachrichten mit gesetztem \Recent-Flag.
UIDNEXT
Der nächste Wert des eindeutigen Bezeichners der Mailbox. Siehe
Abschnitt 2.3.1.1 für weitere Informationen.
UIDVALIDITY
Der Gültigkeitswert des eindeutigen Bezeichners der Mailbox. Siehe
Abschnitt 2.3.1.1 für weitere Informationen.
UNSEEN
Die Anzahl der Nachrichten, die das \Seen-Flag nicht gesetzt haben.
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) S: A042 OK STATUS completed
6.3.11. APPEND-Befehl (APPEND Command)
Arguments: mailbox name (Mailbox-Name) OPTIONAL flag parenthesized list (OPTIONALE Flag-Klammerliste) OPTIONAL date/time string (OPTIONALE Datum/Zeit-Zeichenkette) message literal (Nachrichten-Literal)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - append completed (append abgeschlossen) NO - append error: can't append to that mailbox, error in flags or date/time or message text (append-Fehler: Anfügen an jene Mailbox nicht möglich, Fehler in Flags oder Datum/Zeit oder Nachrichtentext) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der APPEND-Befehl hängt das Literal-Argument als neue Nachricht an das
Ende der angegebenen Ziel-Mailbox an. Dieses Argument SOLLTE im Format
einer [RFC-2822]-Nachricht vorliegen. 8-Bit-Zeichen sind in der
Nachricht zulässig. Eine Server-Implementierung, die nicht in der Lage
ist, 8-Bit-Daten ordnungsgemäß zu bewahren, MUSS in der Lage sein, 8-Bit-
APPEND-Daten reversibel mit einer [MIME-IMB]-Content-Transfer-Encoding in
7-Bit zu konvertieren.
Hinweis: Es KÖNNEN Ausnahmen geben, z. B. Entwurfsnachrichten, bei
denen erforderliche [RFC-2822]-Headerzeilen im Nachrichten-Literal-
Argument für APPEND weggelassen werden. Die vollen Auswirkungen
dessen müssen verstanden und sorgfältig abgewogen werden.
Ist eine Flag-Klammerliste angegeben, SOLLTEN die Flags in der
resultierenden Nachricht gesetzt werden; andernfalls wird die Flag-Liste
der resultierenden Nachricht standardmäßig auf leer gesetzt. In beiden
Fällen wird ebenfalls das Recent-Flag gesetzt.
Ist ein Datum/Zeit angegeben, SOLLTE das interne Datum in der
resultierenden Nachricht gesetzt werden; andernfalls wird das interne
Datum der resultierenden Nachricht standardmäßig auf das aktuelle Datum
und die aktuelle Zeit gesetzt.
Ist das Anhängen aus irgendeinem Grund nicht erfolgreich, MUSS die Mailbox
in ihren Zustand vor dem APPEND-Versuch versetzt werden; kein teilweises
Anhängen ist gestattet.
Existiert die Ziel-Mailbox nicht, MUSS ein Server einen Fehler
zurückgeben und DARF die Mailbox nicht automatisch erstellen. Sofern er
nicht sicher ist, dass die Ziel-Mailbox nicht erstellt werden kann, MUSS
der Server den Antwortcode „[TRYCREATE]" als Präfix des Texts der
getaggten NO-Antwort senden. Dies gibt dem Client einen Hinweis, dass er
einen CREATE-Befehl versuchen und das APPEND wiederholen kann, falls der
CREATE erfolgreich war.
RFC 3501 IMAPv4 March 2003
Ist die Mailbox derzeit ausgewählt, SOLLTEN die normalen Aktionen für
neue Nachrichten erfolgen. Insbesondere SOLLTE der Server den Client
umgehend über eine nicht getaggte EXISTS-Antwort benachrichtigen. Tut der
Server dies nicht, KANN der Client einen NOOP-Befehl (oder falls das
nicht, einen CHECK-Befehl) nach einem oder mehreren APPEND-Befehlen
ausgeben.
Example: C: A003 APPEND saved-messages (\Seen) \{310\}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <[email protected]>
C: Subject: afternoon meeting
C: To: [email protected]
C: Message-Id: <[email protected]>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed
Hinweis: Der APPEND-Befehl wird nicht für die Nachrichtenzustellung
verwendet, da er keinen Mechanismus zum Übertragen von [SMTP]-
Umschlag-Informationen bietet.
6.4. Client-Befehle - Ausgewählter Zustand (Client Commands - Selected State)
Im ausgewählten Zustand sind Befehle zulässig, die Nachrichten in einer Mailbox bearbeiten.
Zusätzlich zu den universellen Befehlen (CAPABILITY, NOOP und LOGOUT) und den authentifizierten Zustandsbefehlen (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS und APPEND) sind die folgenden Befehle im ausgewählten Zustand gültig: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY und UID.
6.4.1. CHECK-Befehl (CHECK Command)
Arguments: none (keine)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - check completed (check abgeschlossen) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der CHECK-Befehl fordert einen Prüfpunkt (checkpoint) der derzeit
ausgewählten Mailbox an. Ein Prüfpunkt bezieht sich auf alle
implementierungsabhängigen hausmeisterlichen Aufgaben, die mit der
Mailbox verbunden sind (z. B. Abgleich des im Speicher befindlichen
Zustands des Servers der Mailbox mit dem Zustand auf dessen Festplatte),
die normalerweise nicht als Teil jedes Befehls ausgeführt werden. Ein
Prüfpunkt KANN eine nicht augenblickliche Zeitspanne für den
Abschluss benötigen. Hat eine Server-Implementierung keine derartigen
hausmeisterlichen Erwägungen, ist CHECK äquivalent zu NOOP.
Es gibt keine Garantie, dass eine EXISTS nicht getaggte Antwort als
Ergebnis von CHECK geschieht. NOOP, nicht CHECK, SOLLTE für die
Neu-Nachrichten-Abfrage verwendet werden.
Example: C: FXXZ CHECK S: FXXZ OK CHECK Completed
6.4.2. CLOSE-Befehl (CLOSE Command)
Arguments: none (keine)
Responses: no specific responses for this command (keine spezifischen Antworten für diesen Befehl)
Result: OK - close completed, now in authenticated state (close abgeschlossen, nun im authentifizierten Zustand) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der CLOSE-Befehl entfernt alle Nachrichten, die das \Deleted-Flag
gesetzt haben, dauerhaft aus der derzeit ausgewählten Mailbox und kehrt
vom ausgewählten Zustand in den authentifizierten Zustand zurück. Es
werden keine nicht getaggten EXPUNGE-Antworten gesendet.
Es werden keine Nachrichten entfernt und kein Fehler gegeben, wenn die
Mailbox durch einen EXAMINE-Befehl ausgewählt ist oder anderweitig nur-
lesend ausgewählt ist.
Selbst wenn eine Mailbox ausgewählt ist, KANN ein SELECT-, EXAMINE- oder
LOGOUT-Befehl ohne vorherige Ausgabe eines CLOSE-Befehls ausgegeben
werden. Die Befehle SELECT, EXAMINE und LOGOUT schließen die derzeit
ausgewählte Mailbox implizit ohne einen Expunge. Wenn jedoch viele
Nachrichten gelöscht werden, ist eine CLOSE-LOGOUT- oder CLOSE-SELECT-
Folge deutlich schneller als eine EXPUNGE-LOGOUT- oder EXPUNGE-SELECT-
Folge, da keine nicht getaggten EXPUNGE-Antworten (die der Client
wahrscheinlich ignorieren würde) gesendet werden.
Example: C: A341 CLOSE S: A341 OK CLOSE completed
RFC 3501 IMAPv4 March 2003
6.4.3. EXPUNGE-Befehl (EXPUNGE Command)
Arguments: none (keine)
Responses: untagged responses: EXPUNGE (nicht getaggte Antworten)
Result: OK - expunge completed (expunge abgeschlossen) NO - expunge failure: can't expunge (e.g., permission denied) (expunge-Fehlschlag: expunge nicht möglich, z. B. Berechtigung verweigert) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der EXPUNGE-Befehl entfernt alle Nachrichten, die das \Deleted-Flag
gesetzt haben, dauerhaft aus der derzeit ausgewählten Mailbox. Bevor der
Server ein OK an den Client zurückgibt, wird für jede entfernte Nachricht
eine nicht getaggte EXPUNGE-Antwort gesendet.
Example: C: A202 EXPUNGE S: * 3 EXPUNGE S: * 3 EXPUNGE S: * 5 EXPUNGE S: * 8 EXPUNGE S: A202 OK EXPUNGE completed
Hinweis: In diesem Beispiel hatten die Nachrichten 3, 4, 7 und 11 das
\Deleted-Flag gesetzt. Siehe die Beschreibung der EXPUNGE-Antwort für
weitere Erläuterung.
6.4.4. SEARCH-Befehl (SEARCH Command)
Arguments: OPTIONAL [CHARSET] specification (OPTIONALE [CHARSET]-Spezifikation) searching criteria (one or more) (Suchkriterien, eine oder mehr)
Responses: REQUIRED untagged response: SEARCH (ERFORDERLICHE nicht getaggte Antwort: SEARCH)
Result: OK - search completed (search abgeschlossen) NO - search error: can't search that [CHARSET] or criteria (search-Fehler: jenes [CHARSET] oder jene Kriterien nicht durchsuchbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der SEARCH-Befehl durchsucht die Mailbox nach Nachrichten, die den
angegebenen Suchkriterien entsprechen. Suchkriterien bestehen aus einem
oder mehreren Suchschlüsseln. Die nicht getaggte SEARCH-Antwort vom
Server enthält eine Auflistung von Nachrichten-Sequenznummern, die
jenen Nachrichten entsprechen, die den Suchkriterien entsprechen.
RFC 3501 IMAPv4 March 2003
Wenn mehrere Schlüssel angegeben sind, ist das Ergebnis die Schnittmenge
(UND-Funktion) aller Nachrichten, die mit jenen Schlüsseln übereinstimmen.
Beispielsweise bezieht sich das Kriterium DELETED FROM "SMITH" SINCE
1-Feb-1994 auf alle gelöschten Nachrichten von Smith, die seit dem 1.
Februar 1994 in die Mailbox gelegt wurden. Ein Suchschlüssel kann
ebenfalls eine in Klammern gesetzte Liste von einem oder mehr
Suchschlüsseln sein (z. B. für die Verwendung mit den Schlüsseln OR und
NOT).
Server-Implementierungen DÜRFEN [MIME-IMB]-Body-Teile mit terminalen
Content-Medientypen außer TEXT und MESSAGE von der Berücksichtigung beim
SEARCH-Abgleich ausschließen.
Die OPTIONALE [CHARSET]-Spezifikation besteht aus dem Wort „CHARSET"
gefolgt von einem registrierten [CHARSET]. Sie zeigt den [CHARSET] der
Zeichenketten an, die in den Suchkriterien erscheinen. [MIME-IMB]-Content-
Transfer-Encodings und [MIME-HDRS]-Zeichenketten in [RFC-2822]/[MIME-IMB]-
Headern MÜSSEN dekodiert werden, bevor Text in einem [CHARSET] außer
US-ASCII verglichen wird. US-ASCII MUSS unterstützt werden; andere
[CHARSET]s KÖNNEN unterstützt werden.
Unterstützt der Server den angegebenen [CHARSET] nicht, MUSS er eine
getaggte NO-Antwort (nicht BAD) zurückgeben. Diese Antwort SOLLTE den
BADCHARSET-Antwortcode enthalten, der die vom Server unterstützten
[CHARSET]s aufführen KANN.
In allen Suchschlüsseln, die Zeichenketten verwenden, stimmt eine
Nachricht mit dem Schlüssel überein, wenn die Zeichenkette eine
Teilzeichenkette des Felds ist. Der Abgleich ist groß-/kleinschreibungs-
insensitiv.
Die definierten Suchschlüssel sind wie folgt. Siehe den Abschnitt
„Formale Syntax" für die genauen syntaktischen Definitionen der
Argumente.
`<sequence set>`
Nachrichten mit Nachrichten-Sequenznummern, die der angegebenen
Nachrichten-Sequenznummern-Menge entsprechen.
ALL
Alle Nachrichten in der Mailbox; der Standard-Anfangsschlüssel für
die UND-Verknüpfung.
ANSWERED
Nachrichten mit gesetztem \Answered-Flag.
RFC 3501 IMAPv4 March 2003
BCC `<string>`
Nachrichten, die die angegebene Zeichenkette im BCC-Feld der
Umschlagstruktur enthalten.
BEFORE `<date>`
Nachrichten, deren internes Datum (Zeit und Zeitzone
außer Acht gelassen) früher als das angegebene Datum ist.
BODY `<string>`
Nachrichten, die die angegebene Zeichenkette im Body der Nachricht
enthalten.
CC `<string>`
Nachrichten, die die angegebene Zeichenkette im CC-Feld der
Umschlagstruktur enthalten.
DELETED
Nachrichten mit gesetztem \Deleted-Flag.
DRAFT
Nachrichten mit gesetztem \Draft-Flag.
FLAGGED
Nachrichten mit gesetztem \Flagged-Flag.
FROM `<string>`
Nachrichten, die die angegebene Zeichenkette im FROM-Feld der
Umschlagstruktur enthalten.
HEADER `<field-name>` `<string>`
Nachrichten, die einen Header mit dem angegebenen Feldnamen (wie in
[RFC-2822] definiert) haben und die die angegebene Zeichenkette im
Text des Headers (was nach dem Doppelpunkt kommt) enthalten. Ist die zu
suchende Zeichenkette der Länge null, stimmt dies mit allen
Nachrichten überein, die eine Headerzeile mit dem angegebenen
Feldnamen unabhängig vom Inhalt haben.
KEYWORD `<flag>`
Nachrichten mit gesetztem angegebenem Schlüsselwort-Flag.
LARGER `<n>`
Nachrichten mit einer [RFC-2822]-Größe größer als die angegebene
Anzahl von Oktetten.
NEW
Nachrichten, die das \Recent-Flag gesetzt haben, aber nicht das
\Seen-Flag. Dies ist funktional äquivalent zu „(RECENT UNSEEN)".
RFC 3501 IMAPv4 March 2003
NOT `<search-key>`
Nachrichten, die nicht mit dem angegebenen Suchschlüssel
übereinstimmen.
OLD
Nachrichten, die das \Recent-Flag nicht gesetzt haben. Dies ist
funktional äquivalent zu „NOT RECENT" (im Gegensatz zu „NOT NEW").
ON `<date>`
Nachrichten, deren internes Datum (Zeit und Zeitzone außer Acht
gelassen) innerhalb des angegebenen Datums liegt.
OR `<search-key1>` `<search-key2>`
Nachrichten, die mit einem der beiden Suchschlüssel übereinstimmen.
RECENT
Nachrichten mit gesetztem \Recent-Flag.
SEEN
Nachrichten mit gesetztem \Seen-Flag.
SENTBEFORE `<date>`
Nachrichten, deren [RFC-2822] Date:-Header (Zeit und Zeitzone außer
Acht gelassen) früher als das angegebene Datum ist.
SENTON `<date>`
Nachrichten, deren [RFC-2822] Date:-Header (Zeit und Zeitzone außer
Acht gelassen) innerhalb des angegebenen Datums liegt.
SENTSINCE `<date>`
Nachrichten, deren [RFC-2822] Date:-Header (Zeit und Zeitzone außer
Acht gelassen) innerhalb des oder später als das angegebene Datum
liegt.
SINCE `<date>`
Nachrichten, deren internes Datum (Zeit und Zeitzone außer Acht
gelassen) innerhalb des oder später als das angegebene Datum liegt.
SMALLER `<n>`
Nachrichten mit einer [RFC-2822]-Größe kleiner als die angegebene
Anzahl von Oktetten.
RFC 3501 IMAPv4 March 2003
SUBJECT `<string>`
Nachrichten, die die angegebene Zeichenkette im SUBJECT-Feld der
Umschlagstruktur enthalten.
TEXT `<string>`
Nachrichten, die die angegebene Zeichenkette im Header oder Body der
Nachricht enthalten.
TO `<string>`
Nachrichten, die die angegebene Zeichenkette im TO-Feld der
Umschlagstruktur enthalten.
UID `<sequence set>`
Nachrichten mit eindeutigen Bezeichnern, die der angegebenen Menge
eindeutiger Bezeichner entsprechen. Sequenzmengen-Bereiche sind
zulässig.
UNANSWERED
Nachrichten, die das \Answered-Flag nicht gesetzt haben.
UNDELETED
Nachrichten, die das \Deleted-Flag nicht gesetzt haben.
UNDRAFT
Nachrichten, die das \Draft-Flag nicht gesetzt haben.
UNFLAGGED
Nachrichten, die das \Flagged-Flag nicht gesetzt haben.
UNKEYWORD `<flag>`
Nachrichten, die das angegebene Schlüsselwort-Flag nicht gesetzt
haben.
UNSEEN
Nachrichten, die das \Seen-Flag nicht gesetzt haben.
RFC 3501 IMAPv4 March 2003
Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" S: * SEARCH 2 84 882 S: A282 OK SEARCH completed C: A283 SEARCH TEXT "string not in mailbox" S: * SEARCH S: A283 OK SEARCH completed C: A284 SEARCH CHARSET UTF-8 TEXT \{6\} C: XXXXXX S: * SEARCH 43 S: A284 OK SEARCH completed
Hinweis: Da dieses Dokument auf 7-Bit-ASCII-Text beschränkt ist,
ist es nicht möglich, tatsächliche UTF-8-Daten zu zeigen. Das
„XXXXXX" ist ein Platzhalter für das, was in einer echten Transaktion
6 Oktette an 8-Bit-Daten wären.
6.4.5. FETCH-Befehl (FETCH Command)
Arguments: sequence set (Sequenzmenge) message data item names or macro (Nachrichtendaten-Elementnamen oder Makro)
Responses: untagged responses: FETCH (nicht getaggte Antworten)
Result: OK - fetch completed (fetch abgeschlossen) NO - fetch error: can't fetch that data (fetch-Fehler: jene Daten nicht abrufbar) BAD - command unknown or arguments invalid (Befehl unbekannt oder Argumente ungültig)
Der FETCH-Befehl ruft Daten ab, die mit einer Nachricht in der Mailbox
verknüpft sind. Die abzurufenden Datenelemente können entweder ein
einzelnes Atom oder eine in Klammern gesetzte Liste sein.
Die meisten Datenelemente, die in der formalen Syntax unter der Regel
msg-att-static identifiziert sind, sind statisch und DÜRFEN sich für
eine bestimmte Nachricht nicht ändern. Andere Datenelemente, die in der
formalen Syntax unter der Regel msg-att-dynamic identifiziert sind,
KÖNNEN sich ändern, entweder als Ergebnis eines STORE-Befehls oder
aufgrund externer Ereignisse.
Beispielsweise kann ein Client, der eine ENVELOPE für eine
Nachricht erhält, wenn er den Umschlag bereits kennt, den neu
übertragenen Umschlag sicher ignorieren.
Es gibt drei Makros, die häufig verwendete Mengen von Datenelementen
angeben und anstelle von Datenelementen verwendet werden können. Ein
Makro muss für sich allein verwendet werden und nicht in Verbindung mit
anderen Makros oder Datenelementen.
RFC 3501 IMAPv4 March 2003
ALL
Makro äquivalent zu: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
FAST
Makro äquivalent zu: (FLAGS INTERNALDATE RFC822.SIZE)
FULL
Makro äquivalent zu: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
BODY)
Die derzeit definierten Datenelemente, die abgerufen werden können, sind:
BODY
Nicht erweiterbare Form von BODYSTRUCTURE.
BODY[`<section>`]`<\\<partial>`>
Der Text eines bestimmten Body-Abschnitts. Die Abschnittsspezifikation
ist eine Menge von null oder mehr durch Punkte begrenzten
Teilbezeichnern. Ein Teilbezeichner ist entweder eine Teilnummer oder
eines der folgenden: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME
und TEXT. Eine leere Abschnittsspezifikation bezieht sich auf die
gesamte Nachricht einschließlich des Headers.
Jede Nachricht hat mindestens eine Teilnummer. Nicht-[MIME-IMB]-
Nachrichten und nicht mehrteilige [MIME-IMB]-Nachrichten ohne
gekapselte Nachricht haben nur einen Teil 1.
Mehrteiligen Nachrichten werden aufeinanderfolgende Teilnummern
zugewiesen, wie sie in der Nachricht auftreten. Ist ein bestimmter
Teil vom Typ message oder multipart, MÜSSEN seine Teile durch einen
Punkt gefolgt von der Teilnummer innerhalb jenes verschachtelten
mehrteiligen Teils angezeigt werden.
Ein Teil vom Typ MESSAGE/RFC822 hat ebenfalls verschachtelte
Teilnummern, die sich auf Teile des Body des MESSAGE-Teils beziehen.
Die Teilbezeichner HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT und TEXT
können der alleinige Teilbezeichner sein oder können durch eine oder
mehr numerische Teilbezeichner vorangestellt sein, sofern der
numerische Teilbezeichner sich auf einen Teil vom Typ MESSAGE/RFC822
bezieht. Der MIME-Teilbezeichner MUSS durch eine oder mehr numerische
Teilbezeichner vorangestellt werden.
Die Teilbezeichner HEADER, HEADER.FIELDS und HEADER.FIELDS.NOT
beziehen sich auf den [RFC-2822]-Header der Nachricht oder einer
gekapselten [MIME-IMT] MESSAGE/RFC822-Nachricht. HEADER.FIELDS und
HEADER.FIELDS.NOT werden von einer Liste von Feldnamen (wie in
[RFC-2822] definiert) gefolgt und geben eine Teilmenge des Headers
zurück. Die von HEADER.FIELDS zurückgegebene Teilmenge enthält nur
jene Headerfelder mit einem übereinstimmenden Feldnamen; ähnlich
enthält die von HEADER.FIELDS.NOT zurückgegebene Teilmenge nur die
Headerfelder mit einem nicht übereinstimmenden Feldnamen. Der
Feldabgleich ist groß-/kleinschreibungsinsensitiv, aber ansonsten
exakt. Das Untersetzen schließt die [RFC-2822] begrenzende leere
Zeile zwischen Header und Body nicht aus; die leere Zeile ist in allen
Header-Abrufen enthalten, außer im Fall einer Nachricht, die keinen
Body und keine leere Zeile hat.
Der MIME-Teilbezeichner bezieht sich auf den [MIME-IMB]-Header für
diesen Teil.
Der TEXT-Teilbezeichner bezieht sich auf den Text-Body der Nachricht,
wobei der [RFC-2822]-Header weggelassen wird.
Hier ist ein Beispiel einer komplexen Nachricht mit einigen ihrer
Teilbezeichner (Beispiel oben in der Beschreibung):
HEADER ([RFC-2822]-Header der Nachricht)
TEXT ([RFC-2822]-Text-Body der Nachricht) MULTIPART/MIXED
1 TEXT/PLAIN
2 APPLICATION/OCTET-STREAM
3 MESSAGE/RFC822
3.HEADER ([RFC-2822]-Header der Nachricht)
3.TEXT ([RFC-2822]-Text-Body der Nachricht) MULTIPART/MIXED
3.1 TEXT/PLAIN
3.2 APPLICATION/OCTET-STREAM
4 MULTIPART/IXED
4.1 IMAGE/GIF
4.1.MIME ([MIME-IMB]-Header für das IMAGE/GIF)
4.2 MESSAGE/RFC822
4.2.HEADER ([RFC-2822]-Header der Nachricht)
4.2.TEXT ([RFC-2822]-Text-Body der Nachricht) MULTIPART/MIXED
4.2.1 TEXT/PLAIN
4.2.2 MULTIPART/ALTERNATIVE
4.2.2.1 TEXT/PLAIN
4.2.2.2 TEXT/RICHTEXT
Es ist möglich, eine Teilzeichenkette des bezeichneten Texts abzurufen.
Dies geschieht, indem ein öffnender Spitzwinkel („\<"), die Oktett-
Position des ersten gewünschten Oktetts, ein Punkt, die maximale
Anzahl der gewünschten Oktette und ein schließender Spitzwinkel („>")
an den Teilbezeichner angehängt werden. Befindet sich das beginnende
Oktett jenseits des Endes des Texts, wird eine leere Zeichenkette
zurückgegeben.
Jeder Teilabruf, der versucht, über das Ende des Texts hinaus zu lesen,
wird entsprechend abgeschnitten. Ein Teilabruf, der bei Oktett 0
beginnt, wird als Teilabruf zurückgegeben, selbst wenn dieser Abschnitt
stattfand.
Hinweis: Das bedeutet, dass BODY[]\<0.2048> einer 1500-Oktett-
Nachricht BODY[]\<0> mit einem Literal der Größe 1500 zurückgibt,
nicht BODY[].
Hinweis: Ein Teilzeichenketten-Abruf eines HEADER.FIELDS- oder
HEADER.FIELDS.NOT-Teilbezeichners wird nach dem Teilen des Headers
berechnet.
Das \Seen-Flag wird implizit gesetzt; führt dies zu einer Änderung der
Flags, SOLLTEN diese als Teil der FETCH-Antworten enthalten sein.
BODY.PEEK[\<section>]\<\<partial>>
Eine alternative Form von BODY[\<section>], die das \Seen-Flag nicht
implizit setzt.
BODYSTRUCTURE
Die [MIME-IMB]-Body-Struktur der Nachricht. Diese wird vom Server
berechnet, indem die [MIME-IMB]-Headerfelder im [RFC-2822]-Header und
die [MIME-IMB]-Header geparst werden.
ENVELOPE
Die Umschlagstruktur der Nachricht. Diese wird vom Server berechnet,
indem der [RFC-2822]-Header in die Komponententeile zerlegt wird, wobei
verschiedene Felder bei Bedarf vorbesetzt werden.
FLAGS
Die Flags, die für diese Nachricht gesetzt sind.
INTERNALDATE
Das interne Datum der Nachricht.
RFC822
Funktionell äquivalent zu BODY[], unterscheidet sich in der Syntax der
resultierenden nicht getaggten FETCH-Daten (RFC822 wird zurückgegeben).
RFC822.HEADER
Funktionell äquivalent zu BODY.PEEK[HEADER], unterscheidet sich in der
Syntax der resultierenden nicht getaggten FETCH-Daten
(RFC822.HEADER wird zurückgegeben).
RFC822.SIZE
Die [RFC-2822]-Größe der Nachricht.
RFC822.TEXT
Funktionell äquivalent zu BODY[TEXT], unterscheidet sich in der Syntax
der resultierenden nicht getaggten FETCH-Daten (RFC822.TEXT wird
zurückgegeben).
UID
Der eindeutige Bezeichner für die Nachricht.
Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) S: * 2 FETCH .... S: * 3 FETCH .... S: * 4 FETCH .... S: A654 OK FETCH completed