📄 rfc1730.txt
字号:
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed
6.3.10. APPEND Command
Arguments: mailbox name
optional flag parenthesized list
optional date/time string
message literal
Data: no specific data for this command
Result: OK - append completed
NO - append error: can't append to that mailbox, error
in flags or date/time or message text
BAD - command unknown or arguments invalid
The APPEND command appends the literal argument as a new message
in the specified destination mailbox. This argument is in the
format of an [RFC-822] message. 8-bit characters are permitted in
the message. A server implementation that is unable to preserve
8-bit data properly MUST be able to reversibly convert 8-bit
APPEND data to 7-bit using [MIME-1] encoding.
If a flag parenthesized list or date_time are specified, that data
SHOULD be set in the resulting message; otherwise, the defaults of
empty flags and the current date/time are used.
Crispin [Page 22]
RFC 1730 IMAP4 December 1994
If the append is unsuccessful for any reason, the mailbox MUST be
restored to its state before the APPEND attempt; no partial
appending is permitted. If the mailbox is currently selected, the
normal new mail actions should occur.
If the destination mailbox does not exist, a server MUST return an
error, and MUST NOT automatically create the mailbox. Unless it
is certain that the destination mailbox can not be created, the
server MUST send the response code "[TRYCREATE]" as the prefix of
the text of the tagged NO response. This gives a hint to the
client that it can attempt a CREATE command and retry the APPEND
if the CREATE is successful.
Example: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
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
Note: the APPEND command is not used for message delivery,
because it does not provide a mechanism to transfer [SMTP]
envelope information.
6.4. Client Commands - Selected State
In selected state, commands that manipulate messages in a mailbox are
permitted.
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
and the authenticated state commands (SELECT, EXAMINE, CREATE,
DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND
ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands
are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH,
FETCH, PARTIAL, STORE, COPY, and UID.
Crispin [Page 23]
RFC 1730 IMAP4 December 1994
6.4.1. CHECK Command
Arguments: none
Data: no specific data for this command
Result: OK - check completed
BAD - command unknown or arguments invalid
The CHECK command requests a checkpoint of the currently selected
mailbox. A checkpoint refers to any implementation-dependent
housekeeping associated with the mailbox (e.g. resolving the
server's in-memory state of the mailbox with the state on its
disk) that is not normally executed as part of each command. A
checkpoint may take a non-instantaneous amount of real time to
complete. If a server implementation has no such housekeeping
considerations, CHECK is equivalent to NOOP.
There is no guarantee that an EXISTS untagged response will happen
as a result of CHECK. NOOP, not CHECK, should be used for new
mail polling.
Example: C: FXXZ CHECK
S: FXXZ OK CHECK Completed
6.4.2. CLOSE Command
Arguments: none
Data: no specific data for this command
Result: OK - close completed, now in authenticated state
NO - close failure: no mailbox selected
BAD - command unknown or arguments invalid
The CLOSE command permanently removes from the currently selected
mailbox all messages that have the \Deleted flag set, and returns
to authenticated state from selected state. No untagged EXPUNGE
responses are sent.
No messages are removed, and no error is given, if the mailbox is
selected by an EXAMINE command or is otherwise selected read-only.
Even when a mailbox is selected, it is not required to send a
CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The
SELECT, EXAMINE, and LOGOUT commands implicitly close the
currently selected mailbox without doing an expunge. However,
Crispin [Page 24]
RFC 1730 IMAP4 December 1994
when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
sequence is considerably faster than an EXPUNGE-LOGOUT or
EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
client would probably ignore) are sent.
Example: C: A341 CLOSE
S: A341 OK CLOSE completed
6.4.3. EXPUNGE Command
Arguments: none
Data: untagged responses: EXPUNGE
Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g. permission
denied)
BAD - command unknown or arguments invalid
The EXPUNGE command permanently removes from the currently
selected mailbox all messages that have the \Deleted flag set.
Before returning an OK to the client, an untagged EXPUNGE response
is sent for each message that is removed.
Example: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed
Note: in this example, messages 3, 4, 7, and 11 had the
\Deleted flag set. See the description of the EXPUNGE
response for further explanation.
Crispin [Page 25]
RFC 1730 IMAP4 December 1994
6.4.4. SEARCH Command
Arguments: optional character set specification
searching criteria (one or more)
Data: mandatory untagged response: SEARCH
Result: OK - search completed
NO - search error: can't search that character set or
criteria
BAD - command unknown or arguments invalid
The SEARCH command searches the mailbox for messages that match
the given searching criteria. Searching criteria consist of one
or more search keys. The untagged SEARCH response from the server
contains a listing of message sequence numbers corresponding to
those messages that match the searching criteria.
When multiple keys are specified, the result is the intersection
(AND function) of all the messages that match those keys. For
example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
to all deleted messages from Smith that were placed in the mailbox
since February 1, 1994. A search key may also be a parenthesized
list of one or more search keys (e.g. for use with the OR and NOT
keys).
Server implementations MAY exclude [MIME-1] body parts with
terminal content types other than TEXT and MESSAGE from
consideration in SEARCH matching.
The optional character set specification consists of the word
"CHARSET" followed by a registered MIME character set. It
indicates the character set of the strings that appear in the
search criteria. [MIME-2] strings that appear in RFC 822/MIME
message headers, and [MIME-1] content transfer encodings, MUST be
decoded before matching. Except for US-ASCII, it is not required
that any particular character set be supported. If the server
does not support the specified character set, it MUST return a
tagged NO response (not a BAD).
In all search keys that use strings, a message matches the key if
the string is a substring of the field. The matching is
case-insensitive.
Crispin [Page 26]
RFC 1730 IMAP4 December 1994
The defined search keys are as follows. Refer to the Formal
Syntax section for the precise syntactic definitions of the
arguments.
<message set> Messages with message sequence numbers
corresponding to the specified message sequence
number set
ALL All messages in the mailbox; the default initial
key for ANDing.
ANSWERED Messages with the \Answered flag set.
BCC <string> Messages that contain the specified string in the
envelope structure's BCC field.
BEFORE <date> Messages whose internal date is earlier than the
specified date.
BODY <string> Messages that contain the specified string in the
body of the message.
CC <string> Messages that contain the specified string in the
envelope structure's CC field.
DELETED Messages with the \Deleted flag set.
DRAFT Messages with the \Draft flag set.
FLAGGED Messages with the \Flagged flag set.
FROM <string> Messages that contain the specified string in the
envelope structure's FROM field.
HEADER <field-name> <string>
Messages that have a header with the specified
field-name (as defined in [RFC-822]) and that
contains the specified string in the [RFC-822]
field-body.
KEYWORD <flag> Messages with the specified keyword set.
LARGER <n> Messages with an RFC822.SIZE larger than the
specified number of octets.
NEW Messages that have the \Recent flag set but not the
\Seen flag. This is functionally equivalent to
"(RECENT UNSEEN)".
Crispin [Page 27]
RFC 1730 IMAP4 December 1994
NOT <search-key>
Messages that do not match the specified search
key.
OLD Messages that do not have the \Recent flag set.
This is functionally equivalent to "NOT RECENT" (as
opposed to "NOT NEW").
ON <date> Messages whose internal date is within the
specified date.
OR <search-key1> <search-key2>
Messages that match either search key.
RECENT Messages that have the \Recent flag set.
SEEN Messages that have the \Seen flag set.
SENTBEFORE <date>
Messages whose [RFC-822] Date: header is earlier
than the specified date.
SENTON <date> Messages whose [RFC-822] Date: header is within the
specified date.
SENTSINCE <date>
Messages whose [RFC-822] Date: header is within or
later than the specified date.
SINCE <date> Messages whose internal date is within or later
than the specified date.
SMALLER <n> Messages with an RFC822.SIZE smaller than the
specified number of octets.
SUBJECT <string>
Messages that contain the specified string in the
en⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -