C: ADD FOLDER Folders "Sent Mail" ""
S: +OK Ok
C: ADD RCPTTO=tom@example.com RCPTTO=alice@example.com
S: +OK Ok
C: ADD MAILFROM=john@example.com FLAGS=SEEN,DRAFT
S: +OK Ok
C: ADD {.7618}
S: > Proceed, please.
C: From: <john@example.com>
C: To: distribution-list: ;
C: Subject: Meeting
C:
C: [ ... ]
C: .
S: * ADD UID=1043320248/3479
S: +OK Message added
The ADD command uploads a
message from the client to the server to a folder, and/or sends
the message to its designated recipients. In most cases the
client sends several ADD commands
that specify the attributes, and/or the properties of a given
message. The client may send everything in a single
ADD command provided that it is
not large enough to exceed the maximum line length limitation,
but most clients will find it easier just to use multiple
commands. Other SMAP commands cannot be intermixed with a batch
of ADD commands. Upon receiving
another command, the server quietly aborts the upload process
before handling the command, and the client will have to start
over at some later point in time. A single rejected
ADD does not abort the upload, the
client can retry or explicitly issue some other command (such
as the RSET command) to abort it.
The following attributes and/or keywords follow the
ADD command:
name ""This keyword specifies the folder where the message is
added to. A maximum of one FOLDER may be specified.
Whitespace-delimited words that name an existing folder
follow the FOLDER keyword,
followed by a single empty word. At least one
RCPTTO keyword is required
if FOLDER is not specified,
in which case the message is only mailed to the
designated recipients without saving a copy in any
folder. Both FOLDER and
RCPTTO keywords may be
specified; the message is both saved in the folder, and
sent to its designated recipients.
user@hostSpecifies the message's recipient. If this keyword is
present, the message will be mailed to the specified
address. Multiple occurences of RCPTTO specify multiple recipients.
user@hostSpecifies the message's return address. This is optional, if not specified, the server uses whatever it thinks the return address is. Clients should not rely on this, because the mechanism by which the server makes this determination is not specified, and will vary from server to server.
listSets delivery status notification options for the sent message, as described by RFC 1891. This is an optional keyword that may not be implemented by all servers. Servers that do not implement delivery status notifications should reject this keyword.
list is a
comma-separated list of the usual delivery confirmation
requests, such as “SUCCESS,FAIL”. The default
set of delivery status notifications (when this keyword
is not specified) is implementation-defined.
The FLAGS, KEYWORDS, and INTERNALDATE set their corresponding
attributes, when the message is to be saved in a folder.
See “Reading message
attributes” for more information. These
keywords are optional, and the server will use
implementation-defined defaults if they are not
specified.
nnnn} or {xxxx/yyyy}This keyword must appear in the last ADD command (when the client uses
multiple ADD commands to
list all attributes and properties). It indicates that
the client is ready to upload the contents of the message
to the server. The client uses the same multi-line or
binary format that's used for downloading message
contents from the server, with one difference. The client
does not proceed with sending the actual message
immediately. The client must wait for the server's reply.
The server replies with a single line of text whose first
whitespace-delimited word is a single > character. Note that the server may
reject the command (and the client will receive an
-ERR), otherwise, upon
receiving the “>”
the client should then proceed to send the contents of
the message, in accordance with the selected transmission
format, then wait for the server's final reply.
The server's final response may include an optional
* ADD single line reply. A
list of whitespace-delimited keywords follow. At this
time, only the following keyword is defined by this
specification:
uidSpecifies the message's unique identifier, if the message is succesfully saved in a folder.
This keyword is not sent when the message is
only mailed, without saving a copy in a folder.
Furthermore, the ADD
command is not limited to saving the message in
the currenly open folder. The message may be
saved in any folder. But if it is, the message
will not be immediately accessible. The clients
needs to issue a NOOP. Presumably the server will
indicate that new messages were added to the
folder, and additional FETCH commands will reveal that
one of the messages has the same unique
identifier that was specified in this reply.
Of course, it is always possible that someone
else deleted the new message before this client
had a chance to issue a NOOP, so the new message is
still not guaranteed to be there. Such is life in
a multiprocessing environment, I suppose...
C: RSET
S: +OK RSET completed
This command does absolutely nothing. Its main purpose is
the side effect of aborting the current upload of a new
message via the ADD command.