- Clients can be written that do not have any native message
sending capability.
ADD.MESSAGE - When this feature is enabled (default is disabled)
a new "ADD.MESSAGE" command becomes available to the client.
The ADD.MESSAGE command instructs the server to add the
specified message to the designated mailbox. This command
can be thought of as being like a COPY command except in
this case the message that is put in the designated mailbox
is specified as a string, rather than as a message number to
be copied from the currently selected mailbox. An example
use of this command might be as follows:
tag42 ADD.MESSAGE OUTGOING-MAIL RFC822 {2083}
From: James Rice <Rice@Sumex-Aim.Stanford.Edu>
To:.....
This will have the effect of adding the message to the mailbox
called OUTGOING-MAIL.
If the server is unable to parse the message being added then
it is required to issue a suitable NO notification to the client.
When the ADD.MESSAGE feature is enabled, the "add_message"
production in the grammar is added and as defined below.
The "add_message" request is added to the list of requests
in the request production also as shown below:
add_message ::= ADD.MESSAGE SP mailbox SP format SP string
message_format ::= RFC822
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search /
select_version / select_features /
supported_versions / bboard / find /
read_only / read_write / flags / set_flags /
add_message) CRLF
Justification: This feature is provided so that clients can
easily add mail to specific mailboxes. This allows clients
to implement such behavior as outgoing mail storage (BCC)
without the need to resort to mailing to special BCC mailboxes.
RENUMBER - When this feature is enabled (default is disabled)
the RENUMBER command becomes available to the client.
The RENUMBER command will reorder the assignment of message
numbers to the messages in the mailbox. If this results in a
change to the association of any message number with any
message then the server is required to send solicited RESET
responses to the client. The intent of this command is
to allow users to view mailboxes in user-meaningful order
efficiently. While the client could do the ordering,
it would be less efficient in general. Note that the
server may or may not change the actual storage of the
messages and the ordering may or may not remain in effect
after another mailbox is selected or the IMAP session is
terminated. Informally, the syntax for the RENUMBER
command is:
tag RENUMBER field_name ordering_type
this has the effect of changing the IMAP grammar to be
as follows:
ordering_type ::= DATE / NUMERIC / ALPHA
renumber ::= RENUMBER SP field_name SP ordering_type
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search /
select_version / select_features /
supported_versions / bboard / find /
read_only / read_write / flags / set_flags /
renumber) CRLF
For example:
tag42 RENUMBER FROM ALPHA
;;;RENUMBER alphabetically by the from field
tag42 RESET 10:20,49
;;;Messages 10 to 20 and 49 have changed
tag42 OK RENUMBER finished. Sequence has changed
tag43 FETCH ALL 10:20,49
;;;Client chooses to fetch the changed msgs.
To support this the RESET message is defined as follows:
*/tag RESET message_sequence
This solicited of unsolicited message from the server informs the
client that it should flush any information that it has
retained for the specified messages.
Justification: This feature is provided so that clients can
view mailboxes in an order that is convenient to the user.
This is particularly important in the context of mailboxes
that the user copies messages to from other mailboxes. This
user-controlled filing process often does not happen in any
well-defined order. Because messages in a mailbox are
implicitly ordered (usually by arrival date, though this is
not a required ordering predicate), the user can be confused
by the apparent order of messages in the mailbox. The
addition of the RENUMBER command makes it unnecessary
for the user to leave IMAP and use some other mail system to
sort mailboxes.
ENCODING - When this feature is enabled (default is disabled) a new
generic key named ENCODING is defined. The value associated
with the generic ENCODING key is a list of (tag encoding-type
options...) lists that represent the ordered, possibly encoded
body of the message. Each such list represents a segment of
the body of the message and the way in which it is encoded.
Any options that follow the encoding_type are further
qualifiers that describe the format of the segment. Each tag
is created by the server and is unique with respect to the
other tags allocated for the other elements in the ENCODING
list. The client may use the tags returned by the server as
concrete keys to access a field which is encoded using the
encoding type and options mentioned in the appropriate list.
Thus:
tag41 FETCH 196 ENCODING ; Client asks for encoding field of msg 196.
tag41 FETCH ENCODING NIL ; Server replies. This message is not encoded.
tag41 OK Fetch completed.
tag42 FETCH 197 ENCODING ; Client asks for encoding field of msg 197.
tag42 FETCH ENCODING ((G001 UUENCODE) (G002 HEX)) ; Server replies.
tag42 OK Fetch completed.
tag43 FETCH 197 G002 ; Client asks for field named G002
tag43 FETCH G002 "A0 00 FF 13 42......." ; Server sends value of field.
tag43 OK Fetch completed.
or
tag44 STORE 197 G002 "0A 00 FF 31 24......."
; Store back the segment with nibbles swapped
Note: As a side-effect of enabling this feature, the generic key
TEXT will be redefined so as to return only those body parts of a
message that are of type TEXT. The concrete key RFC822.TEXT, on
the other hand, would still return everything in the body of the
message, even if it was full of strange, binary character
sequences.
When the client STOREs to a field denoted by one of the above tags
the server will interpret the value being passed as being in the
same format as is currently specified in the ENCODING field. The
server is not required to be able to reformat the data associated
with the ENCODING tags if the client STOREs a new value for the
ENCODING field. The interpretability of a message in the context
of its ENCODING field is undefined if the client side-effects that
ENCODING field, unless the client also STOREs new, reformatted
values for the fields that have had their encoding changed.
If the client stores a new value for the ENCODING field then the
tags in the new value will be used to index the parts of the body.
All tags in a client-STOREd ENCODING that are the same as those
originally generated by the server in response to a FETCH ENCODING
command are said still to denote the fields that they originally
denoted, though possibly reordered. Any tags not originally
defined by the server will denote new message parts, in the
appropriate format, in the relative position specified. The
exclusion of any tags that the server originally defined in a
FETCH of the ENCODING field will indicate the deletion of that
part of the message. Newly created message parts are undefined by
default, so if the client fails to follow the STOREing of the
ENCODING field with suitable STORE commands for the values
associated with any newly created tags, these fields will contain
the null value NIL.
Justification: This feature is supplied so as to allow support
for emergent multi-part and multi-media mail standards.
INDEXABLE.FIELDS - When this feature is enabled (default is
disabled) the grammar of fetch commands is changed to allow the
client to select a specific subsequence from the field in
question. For example:
tag42 FETCH 197 BODY 2000:3999
would fetch the second two thousand bytes of the body of message
197. This feature allows resource limited clients to access
small parts of large messages. The formal syntax for this is:
fetch_att ::= "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
fetch_key / (fetch_key SP NUMBER ":" NUMBER)
fetch_key ::= "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" /
"RFC822.TEXT" / key
If the lower bound number (the number to the left of the colon)
exceeds the maximum size of the field then the empty string is
returned. If the upper bound exceeds the maximum size of the
field but the lower bound does not then the server will return the
remaining substring of the field after the lower bound. The
bounds specified are zero indexed into the fields and the bounds
index fields by 8-bit bytes.
Justification: This feature is provided so as to allow resource-
limited clients to read very large messages and also to allow
clients to improve interactive response for the reading of large
messages by fetching the first "screen full" of data to display
immediately and fetching the rest of the message in the
background.
SET.EOL - When enabled (default is disabled), this feature
allows the new command SET.EOL to be available, changing the
grammar as follows:
character ::= "CR" / "LF" / number
request ::= tag SP (noop / login / logout / select / check /
expunge / copy / fetch / store / search /
select_version / select_features /
supported_versions / bboard / find /
read_only / read_write / flags / set_flags /
set_eol) CRLF
set_eol ::= "SET.EOL" 1#character
This has the effect of changing the end of line character sequence
generated by the server for newlines within strings to the
sequence of characters specified. The characters in the sequence
can be either the specified symbolically named characters or a
numerical value, specifying the decimal value of the character to
use. Thus, if the client would like newlines in strings to be
indicated by a carriage return followed by a control-d, the client
would issue the following command:
tag42 SET.EOL CR 4
If the server is unable to support the combination of characters
requested by the client as its end-of-line pattern it will reply
with a NO response. This might be the case, for example, if a
server is only able to generate its own native line feed pattern
and the CRLF required by IMAP by default.
The server is required to change any length denoting values, such
as envelope byte counts for all future transactions to reflect the
new eol setting. This change in reported sizes should apply to
all generic size fetching keys, but not to concrete ones such as
RFC822.SIZE, which by their very nature require a size measurement
in RFC822 format, i.e., with CRLF as the end-of-line convention.
Justification: This feature is provided because frequently clients
and servers might have end-of-line conventions other than the CRLF
specified by RFC822. It is undesirable that the IMAP be linked
too closely to RFC822 and selecting a different convention might
allow substantial performance improvements in both clients and
servers by saving either client, server or both from having to
shuffle text around so as to add or remove non-local end-of-line
sequences.
Acknowledgements:
This text is based on RFC1064 by Mark Crispin.
The following have made major contributions to this proposed update
to the IMAP2 protocol:
James Rice <Rice@sumex-aim.stanford.edu>
Richard Acuff <acuff@sumex-aim.stanford.edu>
Bill Yeager <yeager@sumex-aim.stanford.edu>
Christopher Lane <lane@sumex-aim.stanford.edu>
Bjorn Victor <Bjorn.Victor@docs.uu.se>
Additional input was also received from:
Andrew Sweer <sweer@sumex-aim.stanford.edu>
Tom Gruber <Gruber@sumex-aim.stanford.edu>
Kevin Brock <Brock@Sumex-Aim.Stanford.Edu>
Mark Crispin <MRC@cac.washington.edu>
Security Considerations
Security issues are not discussed in this memo.
Author's Address
James Rice
Stanford University
Knowledge Systems Laboratory
701 Welch Road
Building C
Palo Alto, CA 94304
Phone: (415) 723-8405
EMail: RICE@SUMEX-AIM.STANFORD.EDU