Internet DRAFT - draft-sabarish-immp
draft-sabarish-immp
Network Working Group Sabarish Ramanathan
Internet Draft: Internet Message Mapping Protocol Sabari Illam
Document: internet-drafts/draft-sabarish-immp-01.txt May 2005
IMMP -- Internet Message Mapping Protocol
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
By submitting this Internet-Draft, I accept the provisions of
Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The protocol discussed in this document is experimental and subject
to change. Persons planning on either implementing or using this
protocol are STRONGLY URGED to get in touch with the author before
embarking on such a project.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Sabarish [Page 1] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
Abstract
The Internet Message Mapping Protocol (IMMP) is designed to support
the provision of mail in a medium to large scale operation. It is
intended to be used as a companion to the SMTP protocol and mail
receiving protocols (POP, IMAP, web mail also), providing services
which are outside the scope of mail access. The services that IMMP
provides are mapping mails into appropriate subinbox (inside the
inbox) when the messages are received through SMTP, Extended inbox
management and Spam guard management.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conventions Used in this Document . . . . . . . . . . . . 3
1.3 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4
2.1 Link Level . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 IMMP Model . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Client Server Model . . . . . . . . . . . . . . . . . 4
2.2.2 IMMP with SMTP model . . . . . . . . . . . . . . . . . 4
2.3 Commands and Responses. . . . . . . . . . . . . . . . . . 5
2.3.1 Client Protocol Sender and Server Protocol Receiver . 6
2.3.2 Server Protocol Sender and Client Protocol Receiver . 7
3 State and Flow Diagram . . . . . . . . . . . . . . . . . . . 7
3.1 Non-Authenticated State . . . . . . . . . . . . . . . . . 8
3.2 Authenticated State . . . . . . . . . . . . . . . . . . . 8
3.3 Logout State . . . . . . . .. . . . . . . . . . . . . . . 8
3.4 Anonymous State . . . . . . . . . . . . . . . . . . . . 8
4 Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Atom . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Number . . . . . . . .. . . . . . . . . . . . . . . . . . 8
4.3 String. . . . . . . .. . . .. . . . . . . . . . . . . . . 8
4.3.1 8-bit and Binary Strings. . . . . . . . . . . . . . . 9
5 Operational Considerations . . . . . . . . . . . . . . . . . 9
5.1 SubInbox Naming . . . . . . . . . . . . . . . . .. . . . 9
5.2 Untagged Status Updates . . . . . . . . . . . . . . . . . 10
5.3 Response when no Command in Progress . . . . . . . . . . 10
5.4 Autologout Timer . . . . . . . . . . . . . . . . . . . . 10
5.5 Multiple Commands in Progress . . . . . . . .. . . . . . 10
5.6 Mail Access Protocol Fallback . . . . . . . . . . . . 11
6 Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1 Client Commands - Any State . . . . . . . . . . .. . . . 11
6.1.1 CAPABILITY Command . . . . . . . . . . . . . . . . . . 11
6.1.2 NOOP Command . . . . .. . . . . . . . . . . . . . . . 12
6.1.3 LOGOUT Command . . . . . . . . . . . . . . . . . . . . 12
6.2 Client Commands - Non-Authenticated State. . . . .. . . . 12
6.2.1 AUTHENTICATE Command . . . . . . . . . . . . . . . . 13
6.2.2 LOGIN Command . . . . .. . . . . . . . . . . . . . . 14
Sabarish [Page 2] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
6.3 Client Commands - SubInbox management. . . . . . .. . . . 15
6.3.1 CREATE Command . . . . . . . . . . . . . . . . . . . .15
6.3.2 DELETE Command . . . . .. . . . . . . . . . . . . . . .16
6.3.3 RENAME Command . . . . . . . . . . . . . . . . . . . . 16
6.3.4 REPLACE Command . . . . . . . . . . . . . . . . . . . 17
6.3.5 MOVE Command . . . . .. . . . . . . . . . . . . . . . 17
6.3.6 LIST Command . . . . . . . . . . . . . . . . . . . . .18
6.4 Client Commands - Spam Guard Agent . . . . . . . . . . . 19
6.4.1 SEARCHSPAMENTRY Command . . . . . . . . . . . . . . .20
6.4.2 STORESPAMENTRY Command . . . . .. . . . . . . . . . . .20
6.4.3 DELETESPAMENTRY Command . . . . . . . . . . . .. . . . 21
6.4.4 SEARCHSPAMGUARDAGENT Command . . . . . . . . .. . . . 21
6.4.5 STORESPAMGUARDAGENT Command . . . . .. . . . .. . . . 22
6.4.6 DELETESPAMGUARDAGENT Command . . . . . . . . . . . . .22
6.5 Client Commands - Anonymous Query Commands . . .. . . . . 22
6.5.1 VERIFYINSPAMGUARDAGENT Command . . . . . . . . . . .23
6.5.2 VERIFYSUBINBOX Command . . . . .. . . . . . . . . . . .23
7 Security Considerations . . . . . . . . . . . . . . . . . . . 23
8 IANA consideration . . . . . . . . . . . . . . . . . . . . . . 24
9 Informative References . . . . . . . . . . . . . . . . . . . 24
10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property Statement . . . . . . . . . . . . . . . 25
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 25
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1 Introduction
1.1 Scope
This document describes how to map messages into subinboxes of an
inbox of a mail. It also describes how to block the spam mail
coming to store in the inbox or subinboxes. It also describes how
the clients are going to manage subinboxes and spam guard agent.
1.2 Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
1.3 Abbreviations
SMTP indicates Simple Mail Transfer Protocol throughout this
document.
IMMP indicates Internet Message Mapping Protocol throughout this
document.
Sabarish [Page 3] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
In examples, "RS:", "IS:" and "IC:" indicate lines sent by the
Receiver-SMTP, IMMP-Server and IMMP-Client respectively.
2 Protocol Overview
2.1 Link Level
The IMMP protocol assumes a reliable data stream such as provided by
TCP. When TCP is used, an IMMP-Server listens on port 323.
2.2 IMMP Model
2.2.1 Client Server Model
This model of IMMP describes how the clients are creating, renaming
or deleting SubInboxes inside an Inbox of a user through
IMMP-Server. This model also describes how the client is managing
the Spam guard agent inside the IMMP-Server. We are going to discuss
about this in details in coming chapters.
2.2.2 IMMP with SMTP model
The IMMP design is based on the following model of communication: as
the result of a destination Receiver-SMTP received the From-Mail
address and To-Mail address from the Sender-SMTP, then it checks
whether To-Mail address (after removing the SubInboxes information
from the mail address) is valid or not.
If the To-Mail address is valid then the Receiver-SMTP server
establishes a two way transmission channel to IMMP-Server and checks
whether that From-Mail address is blocked by the IMMP SPAM guard
agent of the To-Mail address. If the From-Mail address is not
blocked by the Spam guard agent in IMMP server, then it sends an
acceptance receipt OK reply to the Receiver-SMTP to accept the mail.
If From-Mail address is blocked then IMMP-Server sends denied
receipt NO reply to the Receiver-SMTP. IMMP commands are generated
by the Receiver-SMTP and sent to the IMMP-Server. IMMP replies are
sent from the IMMP-Server to the Receiver-SMTP in response to the
commands.
If Spam guard accepted to receive the mail from From-Address,
Receiver-SMTP sends OK reply to the Sender-SMTP to transfer the
remaining mail data. After receiving the end of mail indicator from
the Sender-SMTP, Receiver-SMTP checks whether the To-Mail address
is having the SubInboxes information. If there is no SubInboxes
information in the To-Address, then Receiver-SMTP maps (stores) the
Sabarish [Page 4] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
mail into the INBOX of the recipient. If the To-Mail address has
SubInboxes information then Receiver-SMTP establishes a two way
transmission channel to the IMMP server and checks the
availability of the SubInboxes for that Recipient and if it is
available then sends OK reply to Receiver-SMTP and Receiver-SMTP
server mapped (stored) the data into that SubInbox of the Recipient.
If Receiver-SMTP server gets the unavailability of the SubInbox as
NO reply from the IMAP-Server then Receiver-SMTP server stores the
data into the Inbox of the Recipient itself.
-------------------------------------------------------------
+----------+ +----------+
+------+ | | | | +------+
| User |<-->| | | |<-->| IMMP |
+------+ | Sender- | | Receiver-| +------+
+------+ | SMTP |<-->| SMTP | +------+
| File |<-->| | | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
IMMP with SMTP model
Figure 1
-------------------------------------------------------------
2.3 Commands and Responses
A Receiver-SMTP and IMMP-Server and session consist of the
establishment of a client/server connection, query for verifying
whether the From-Address is blocked by the spam guard of IMMP-Server
for the corresponding To-Address and also check the availability of
SubInboxes for that Recipient.
An IMMP client/server model session consists of the establishment of
a client/server connection, an initial greeting from the server, and
client/server interactions. These client/server interactions consist
of a client command, server data, and a server completion result
response.
Sabarish [Page 5] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
All interactions transmitted by client and server are in the form of
lines; that is, strings that end with a CRLF. The protocol receiver
of an IMMP-Client or Server is either reading a line, or is reading
a sequence of octets with a known count followed by a line.
2.3.1 Client Protocol Sender and Server Protocol Receiver
The client command begins an operation. Each client command is
prefixed with an identifier (typically a short alphanumeric string,
e.g. A0001, A0002, etc.) called a "tag". A different tag is
generated by the client for each command.
Requests send by SMTP server to check the availability of SubInboxes
and query against Spam Guard Agent in IMMP server needs not to have
a tag in the request and they need not to Authenticate.
There are two cases in which a line from the client does not
represent a complete command. In one case, a command argument is
quoted with an octet count (see the description of literal in
String under Data Formats); in the other case, the command
arguments require server feedback (see the AUTHENTICATE command).
In either case, the server sends a command continuation request
response if it is ready for the octets (if appropriate) and the
remainder of the command. This response is prefixed with the
token "+".
Note: If, instead, the server detected an error in the command,
it sends a BAD completion response with tag matching the command
(as described below) to reject the command and prevent the client
from sending any more of the command.
It is also possible for the server to send a completion response
for some other command (if multiple commands are in progress), or
untagged data. In either case, the command continuation request is
still pending; the client takes the appropriate action for the
response, and reads another response from the server.
The protocol receiver of an IMMP server reads a command line from
the client, parses the command and its arguments, and transmits
server data and a server command completion result response.
Sabarish [Page 6] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
2.3.2 Server Protocol Sender and Client Protocol Receiver
Data transmitted by the server to the client and status responses
that do not indicate command completion are prefixed with the token
"*", and are called untagged responses.
Server data may be sent as a result of a client command, or may be
sent unilaterally by the server. There is no syntactic difference
between server data that resulted from a specific command and server
data that were sent unilaterally.
The server completion result response indicates the success or
failure of the operation. It is tagged with the same tag as the
client command which began the operation. Thus, if more than one
command is in progress, the tag in a server completion response
identifies the command to which the response applies. There are
three possible server completion responses: OK (indicating success),
NO (indicating failure), or BAD (indicating protocol error such as
unrecognized command or command syntax error).
The protocol receiver of an IMMP client reads a response line from
the server. It then takes action on the response based upon the
first token of the response, which may be a tag, a "*", or a "+". As
described above.
A client MUST be prepared to accept any server response at all
times. This includes server data that it may not have requested.
Server data SHOULD be recorded, so that the client can reference
its recorded copy rather than sending a command to the server to
request the data.
3 State and Flow Diagram
An IMMP server is in one of four states. Most commands are valid in
only certain states. It is a protocol error for the client to
attempt a command while the command is in an inappropriate state.
In this case, a server will respond with a BAD or NO (depending
upon server implementation) command completion result.
Sabarish [Page 7] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
3.1 Non-Authenticated State
In non-authenticated state, the user must supply authentication
credentials before most commands will be permitted. This state is
entered when a connection starts unless the connection has been
pre-authenticated.
3.2 Authenticated State
In authenticated state, the user is authenticated and most commands
will be permitted. This state is entered when a pre-authenticated
connection starts or when acceptable authentication credentials have
been provided.
3.3 Logout State
In logout state, the session is being terminated, and the server
will close the connection. This state can be entered as a result
of a client request or by unilateral server decision.
3.4 Anonymous State
In anonymous state, the SMTP server sends the query to Spam guard
agent of IMMP server and also checks the availability of SubInboxes
in the Inbox.
4 Data Formats
IMMP uses textual commands and responses. Data in IMMP can be in one
of several forms: atom, number, string, parenthesized list, or NIL.
4.1 Atom
An atom consists of one or more non-special characters.
4.2 Number
A number consists of one or more digit characters, and represents a
numeric value.
4.3 String
A string is in one of two forms: literal and quoted string. The
literal form is the general form of string. The quoted string form
is an alternative that avoids the overhead of processing a literal
at the cost of restrictions of what may be in a quoted string.
Sabarish [Page 8] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
A literal is a sequence of zero or more octets (including CR and
LF), prefix-quoted with an octet count in the form of an open brace
("{"), the number of octets, close brace ("}"), and CRLF. In the
case of literals transmitted from server to client, the CRLF is
immediately followed by the octet data. In the case of literals
transmitted from client to server, the client must wait to receive a
command continuation request (described later in this document)
before sending the octet data (and the remainder of the command).
A quoted string is a sequence of zero or more 7-bit characters,
excluding CR and LF, with double quote (<">) characters at each end.
The empty string is represented as either "" (a quoted string with
zero characters between double quotes) or as {0} followed by CRLF
(a literal with an octet count of 0).
Note: Even if the octet count is 0, a client transmitting a literal
must wait to receive a command continuation request.
4.3.1 8-bit and Binary Strings
IMMP implementations MAY transmit 8-bit or multi-octet characters in
literals, but should do so only when the character set is
identified.
Unencoded binary strings are not permitted. A "binary string" is any
string with NUL characters. Implementations MUST encode binary data
into a textual form such as BASE64 before transmitting the data. A
string with an excessive amount of CTL characters may also be
considered to be binary, although this is not required.
5 Operational Considerations
5.1 SubInbox Naming
The interpretation of SubInbox names is implementation-dependent.
However, the mailbox name INBOX is a special name reserved to mean
"the primary mailbox for this user on this server". Using IMMP
protocol can create SubInboxes inside the Inbox in tree model where
the Inbox is the root. We can directly send mail into the SubInboxes
but we need to specify it in the To-Address of a mail so that the
destination Receiver-SMTP works together with IMMP and maps the mail
data into the corresponding SubInbox of Inbox.
Sabarish [Page 9] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
For Example:
1) Mail sends to sabarish@immp.pro store the mail data into INBOX of
Sabarish.
2) Mail sends to work/sabarish@immp.pro store the mail data into
SubInbox "Work" inside the INBOX of Sabarish.
3) Mail sends to office/work/sabarish@immp.pro store the mail data
into the SubInbox "office" inside the SubInbox "Work".
5.2 Untagged Status Updates
At any time, a server can send data that the client did not request.
5.3 Response when no Command in Progress
Server implementations are permitted to send an untagged response
while there is no command in progress. Server implementations that
send such responses MUST deal with flow control considerations.
Specifically, they must either (1) verify that the size of the data
does not exceed the underlying transport's available window size, or
(2) use non-blocking writes.
5.4 Autologout Timer
If a server has an inactivity autologout timer, that timer MUST be
of at least 30 minutes' duration. The receipt of ANY command from
the client during that interval should suffice to reset the
autologout timer.
5.5 Multiple Commands in Progress
The client is not required to wait for the completion result
response of a command before sending another command, subject to
flow control constraints on the underlying data stream. Similarly,
a server is not required to process a command to completion before
beginning processing of the next command, unless an ambiguity would
result because of a command that would affect the results of other
commands. If there is such an ambiguity, the server executes
commands to completion in the order given by the client.
Sabarish [Page 10] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
5.6 Mail Access Protocol Fallback
When a client is directed by a user or an initial configuration to
contact a SubInbox service on a given host, it should first attempt
to reach the IMMP service on that host. The client should then use
the IMMP SubInbox management commands instead of the Mail Access
protocol (IMAP4, etc) mailbox management commands. If the connection
to the IMMP server fails with a refused connection, the client
should fall back to using the Mail Access protocol.
6 Commands
6.1 Client Commands - Any State
The following commands are valid in any state: CAPABILITY, NOOP, and
LOGOUT.
6.1.1 CAPABILITY Command
Arguments: none
Data: mandatory untagged response: CAPABILITY
Result: OK - capability completed
BAD - command unknown or arguments invalid
The CAPABILITY command requests a listing of capabilities that the
server supports. This listing of capabilities is not dependent upon
connection state or user. It is therefore not necessary to issue a
CAPABILITY command more than once in a session.
Capability names refer to extensions, revisions, or amendments to
this specification. No capabilities are enabled without
explicit client action to invoke the capability.
Example: IC: A001 CAPABILITY
IS: * CAPABILITY
IS: A001 OK CAPABILITY completed
Sabarish [Page 11] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
6.1.2 NOOP Command
Arguments: none
Data: no specific data for this command (but see below)
Result: OK - noop completed
BAD - command unknown or arguments invalid
The NOOP command always succeeds. It does nothing.
Since any command can return a status update as untagged data, the
NOOP command can be used as a periodic poll for status updates
during a period of inactivity. The NOOP command can also be used to
reset any inactivity autologout timer on the server.
Example: IC: A002 NOOP
IS: A002 OK NOOP completed
6.1.3 LOGOUT Command
Arguments: none
Data: mandatory untagged response: BYE
Result: OK - logout completed
BAD - command unknown or arguments invalid
The LOGOUT command informs the server that the client is done
with the session. The server must send a BYE untagged response
before the (tagged) OK response, and then close the network
connection.
Example: IC: A003 LOGOUT
IS: * BYE IMMP Server logging out
IS: A003 OK LOGOUT completed
(Server and client then close the connection)
6.2 Client Commands - Non-Authenticated State
In non-authenticated state, the AUTHENTICATE or LOGIN command
establishes authentication and enter authenticated state. The
AUTHENTICATE command provides a general mechanism for a variety
of authentication techniques, whereas the LOGIN command uses the
traditional user name and plaintext password pair.
Sabarish [Page 12] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
Server implementations may allow non-authenticated access to certain
information. The convention is to use a LOGIN command with the
userid "anonymous". A password is required. It is implementation -
dependent what requirements, if any, are placed on the password and
what access restrictions are placed on anonymous users.
Once authenticated (including as anonymous), it is not possible to
re-enter non-authenticated state.
In addition to the universal commands (CAPABILITY, NOOP, and
LOGOUT), the following commands are valid in non-authenticated
state: AUTHENTICATE and LOGIN.
6.2.1 AUTHENTICATE Command
Arguments: authentication mechanism name
Data: continuation data may be requested
Result: OK - authenticate completed, now in authenticated state
NO - authenticate failure: unsupported authentication
mechanism, credentials rejected
BAD - command unknown or arguments invalid,
authentication exchange cancelled
The AUTHENTICATE command indicates an authentication mechanism,
such as described in [IMAP-AUTH], to the server. If the server
supports the requested authentication mechanism, it performs an
authentication protocol exchange to authenticate and identify the
user. Optionally, it also negotiates a protection mechanism for
subsequent protocol interactions. If the requested authentication
mechanism is not supported, the server should reject the
AUTHENTICATE command by sending a tagged NO response.
The authentication protocol exchange consists of a series of server
challenges and client answers that are specific to the
authentication mechanism. A server challenge consists of a command
continuation request response with the "+" token followed by a
BASE64 encoded string. The client answer consists of a line
consisting of a BASE64 encoded string. If the client wishes
to cancel an authentication exchange, it should issue a line with a
single "*". If the server receives such an answer, it must reject
the AUTHENTICATE command by sending a tagged BAD response.
Sabarish [Page 13] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
A protection mechanism provides integrity and privacy protection to
the protocol session. If a protection mechanism is negotiated, it is
applied to all subsequent data sent over the connection. The
protection mechanism takes effect immediately following the CRLF
that concludes the authentication exchange for the client, and the
CRLF of the tagged OK response for the server. Once the protection
mechanism is in effect, the stream of command and response octets is
processed into buffers of ciphertext. Each buffer is transferred
over the connection as a stream of octets prepended with a four
octet field in network byte order that represents the length of the
following data. The maximum ciphertext buffer length is defined by
the protection mechanism.
The server is not required to support any particular authentication
mechanism, nor are authentication mechanisms required to support
any protection mechanisms. If an AUTHENTICATE command fails with a
NO response, the client may try another authentication mechanism by
issuing another AUTHENTICATE command, or may attempt to authenticate
by using the LOGIN command. In other words, the client may request
authentication types in decreasing order of preference, with the
LOGIN command as a last resort.
Example: IS: * OK KerberosV4 IMMP Server
IC: A004 AUTHENTICATE KERBEROS_V4
IS: + AmFYig==
IC: BAcAQU5EUkVXLfhASHFRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
IS: + or//EoAADZI=
IC: DiAF5A4gA+oOIALuBkAAmw==
IS: A004 OK Kerberos V4 authentication successful
Note: the line breaks in the first client answer are for editorial
clarity and are not in real authenticators.
6.2.2 LOGIN Command
Arguments: user name
password
Data: no specific data for this command
Result: OK - login completed, now in authenticated state
NO - login failure: user name or password rejected
BAD - command unknown or arguments invalid
Sabarish [Page 14] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
The LOGIN command identifies the user to the server and carries the
plaintext password authenticating this user.
Example: IC: A005 LOGIN SABARISH RAMAN
IS: A005 OK LOGIN completed
6.3 Client Commands - SubInbox management
This section describes commands permitted in authenticated state for
manipulating SubInboxes as atomic entities.
6.3.1 CREATE Command
Arguments: subinbox name
Data: no specific data for this command
Result: OK - create completed
NO - create failure: can't create subinbox with that
name,can't create subinbox on that subinbox path
which specified along the name
BAD - command unknown or arguments invalid
The CREATE command creates a subinbox with the given name in INBOX.
An OK response is returned only if a new subinbox with that name has
been created. It is an error to attempt to create INBOX or a
subinbox with a name that refers to an existing subinbox inside the
same parent subinbox. Any error in creation will return a tagged NO
response.
If the subinbox name is suffixed with the server's hierarchy
separator character (as returned from the server by a LIST command),
this is a declaration that the client may, in the future, create
subinbox names under this name in the hierarchy. Server
implementations that do not require this declaration MUST ignore it
and return a tagged OK response.
Example: IC: A006 CREATE work/
IS: A006 OK CREATE completed
IC: A007 CREATE office/work
IS: A007 OK CREATE completed
Sabarish [Page 15] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
Note: the interpretation of the above commands in this example
depends on whether "/" was returned as the hierarchy separator from
LIST. If "/" is the hierarchy separator, then a new level of
hierarchy named "work" with a member called "office" is created.
Otherwise, two subinbox at the same hierarchy level are created.
6.3.2 DELETE Command
Arguments: subinbox name
Data: no specific data for this command
Result: OK - delete completed
NO - delete failure: can't delete subinbox with that name
BAD - command unknown or arguments invalid
The DELETE command permanently removes the subinbox with the given
name. An OK response is returned only if the subinbox has been
deleted. It is an error to attempt to delete INBOX or a subinbox
name that does not exist. Any error in deletion will return a tagged
NO response.
Example: IC: A008 DELETE work
IS: A008 OK DELETE completed
6.3.3 RENAME Command
Arguments: existing subinbox name
new subinbox name
Data: no specific data for this command
Result: OK - rename completed
NO - rename failure: can't rename subinbox with that name
can't rename to subinbox with that name
BAD - command unknown or arguments invalid
The RENAME command changes the name of a subinbox. An OK response is
returned only if the subinbox has been renamed. It is an error to
attempt to rename from a subinbox name that does not exist or to a
subinbox name that already exists in the parent subinbox. Any error
in renaming will return a tagged NO response.
Sabarish [Page 16] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
Renaming INBOX is permitted; a new, empty INBOX is created in its
place.
Example: IC: A009 RENAME worksabari offsabari
IS: A009 OK RENAME completed
6.3.4 REPLACE Command
Arguments: existing subinbox name
existing new subinbox name
Data: no specific data for this command
Result: OK - replace completed
NO - replace failure: can't delete subinbox with that
name, can't replace with subinbox with that name
BAD - command unknown or arguments invalid
The REPLACE command deletes a subinbox, automatically changing
subscriptions to a new subinbox. An OK response is returned only
if the subinbox has been removed. It is an error to attempt to
replace a subinbox name that does not exist or replace with a
subinbox name that does not exist. Any error in deletion will return
a NO response.
Replacing INBOX is not permitted.
Example: IC: A010 REPLACE worksabari offsabari
IS: A010 OK REPLACE completed
6.3.5 MOVE Command
Arguments: subinbox name
partition parenthesized list
Data: no specific data for this command
Result: OK - move completed
NO - move failure: can't move subinbox with that name
can't move subinbox to that server/partition
BAD - command unknown or arguments invalid
Sabarish [Page 17] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
The MOVE command moves a subinbox between subinboxes, moves a
subinbox between two subinboxes. The partition parenthesized list
specifies where the subinbox is to be moved to. The interpretation
of the partition parenthesized list is the same as for the CREATE
command.
Example: IC: A011 MOVE SABARISUBINBOX (oldpath, newpath )
IS: A011 OK MOVE completed
6.3.6 LIST Command
Arguments: reference name
subinbox name with possible wildcards
Data: untagged responses: LIST
Result: OK - list completed
NO - list failure: can't list that reference or name
BAD - command unknown or arguments invalid
The LIST command returns a subset of names from the complete set of
all subinboxes inside the inbox. Zero or more untagged LIST replies
are returned, containing the name hierarchy delimiter and name; see
the description of the LIST reply for more detail.
An empty ("" string) reference name argument indicates that the
subinbox name is interpreted as by SELECT. The returned subinbox
names MUST match the supplied subinbox name pattern. A non-empty
reference name argument is the name of a subinbox or a level of
subinbox hierarchy.
The reference and subinbox name arguments are interpreted, in an
implementation-dependent fashion, into a canonical form that
represents an unambiguous left-to-right hierarchy. The returned
subinbox names will be in the interpreted form.
Any part of the reference argument that is included in the
interpreted form SHOULD prefix the interpreted form. It should also
be in the same form as the reference name argument. This rule
permits the client to determine if the returned subinbox name is in
the context of the reference argument, or if something about the
subinbox argument overrode the reference argument. Without this
rule, the client would have to have knowledge of the server's naming
semantics including what characters are "breakouts" that override a
naming context.
Sabarish [Page 18] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
For example, here are some examples of how references and subinbox
names might be interpreted on a UNIX-based server:
Reference Subinbox Name Interpretation
------------ ------------ --------------
inbox/Mail/ foo.* inbox/Mail/foo.*
inbox/ % inbox/%
The character "*" is a wildcard, and matches zero or more characters
at this position. The character "%" is similar to "*", but it does
not match a hierarchy delimiter.
Example: IC: A012 LIST "inbox/Mail/" "%"
IS: * LIST (\Noselect) "/" inbox/Mail/foo
IS: * LIST () "/" inbox/Mail/meetings
IS: A012 OK LIST completed
6.4 Client Commands - Spam Guard Agent
This section describes commands permitted in authenticated state for
manipulating Spam Guard Agent. Spam Guard Agent provides a way for
users to store list of spam mail addresses and blocked the mail when
the SMTP server is getting mails from those spam mail addresses with
the help of IMMP.
Servers are expected to at least allow the client to manipulate the
spam guard agent with the same name as the "user" specified in the
LOGIN command.
Servers allow client to create any number of spam guard agents and
IMMP check the incoming mails with all the information in the spam
guard agents assigned to that user.
Each spam guard agent contains some number of spam mail addresses.
The standard field is:
EMAIL electronic mail address
Sabarish [Page 19] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
6.4.1 SEARCHSPAMENTRY Command
Arguments: spam guard agent name
lookup criteria
Data: untagged responses: SEARCHSPAMENTRY
Result: OK - searchspamentry completed
NO - searchspamentry failure: can't searchspamentry that
name
BAD - command unknown or arguments invalid
The SEARCHSPAMENTRY command searches the specified spam guard agent
for mail address that express the intersection (AND function) of all
of the specified criteria. The names matching the criteria are
returned in some set of untagged SEARCHSPAMENTRY replies. If no
criteria are specified, all mail addresses in the spam guard agent
are returned.
Wildcards are permitted in the pattern as in LIST, except that the
behavior of the "%" wildcard is undefined. The reserved field "mail"
specifies entries whose mail addresses matches the specified
pattern.
Example: IC: A013 SEARCHSPAMENTRY Sabarish Email "*Rubble"
IS: * SEARCHSPAMENTRY "*Rubble"
IS: A013 OK SEARCHSPAMENTRY completed
6.4.2 STORESPAMENTRY Command
Arguments: spam guard agent name
Email
Data: no specific data for this command
Result: OK - storespamentry completed
NO - storespamentry failure: can't storespamentry that
name
BAD - command unknown or arguments invalid
Store the spam entry in the specified spam guard agent. Here the
spam entry is a mailing address. For creating a new entry, directly
use this storespamentry. For editing the spam entry, delete the spam
entry and store the new one.
Sabarish [Page 20] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
Entry names are case-insensitive strings.
Example: IC: A014 STORESPAMENTRY SabariGuard "mail@immp.pro"
IS: A014 OK STORESPAMENTRY completed
6.4.3 DELETESPAMENTRY Command
Arguments: spam guard agent name
Email
Data: no specific data for this command
Result: OK - deletespamentry completed
NO - deletespamentry failure: can't deletespamentry that
name
BAD - command unknown or arguments invalid
Remove the spam entry in the specified spam guard agent for the
specified Email.
Example: IC: A015 DELETESPAMENTRY SabariGuard "mail@immp.pro"
IS: A015 OK DELETESPAMENTRY completed
6.4.4 SEARCHSPAMGUARDAGENT Command
Arguments: lookup criteria
Data: untagged responses: SEARCHSPAMGUARDAGENT
Result: OK - searchspamguardagent completed
NO - searchspamguardagent failure: can't
searchspamguardagent that name
BAD - command unknown or arguments invalid
The SEARCHSPAMGUARDAGENT command searches for the specified spam
guard assigned for the login user. The names matching the criteria
are returned in some set of untagged SEARCHSPAMGUARDAGENT replies.
If no criteria are specified, all spam guard agents are returned.
Wildcards are permitted in the pattern as in LIST, except that the
behavior of the "%" wildcard is undefined. The reserved field "mail"
specifies entries whose mail addresses matches the specified
pattern.
Example: IC: A016 SEARCHSPAMGUARDAGENT "*RubbleAgent"
IS: * SEARCHSPAMGUARDAGENT "*RubbleAgent"
IS: A016 OK SEARCHSPAMGUARDAGENT completed
Sabarish [Page 21] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
6.4.5 STORESPAMGUARDAGENT Command
Arguments: spam guard agent name
Data: no specific data for this command
Result: OK - storespamguardagent completed
NO - storespamguardagent failure: can't
storespamguardagent that name
BAD - command unknown or arguments invalid
Store the spam guard agent and assigned for the login user. For
creating a new guard, directly use this storespamguardagent. For
editing the spam guard agent, delete the spam guard agent and store
the new one.
Spam guard agent names are case-insensitive strings.
Example: IC: A017 STORESPAMGUARDAGENT SabariGuard
IS: A017 OK STORESPAMGUARDAGENT completed
6.4.6 DELETESPAMGUARDAGENT Command
Arguments: spam guard agent name
Data: no specific data for this command
Result: OK - deletespamguardagent completed
NO - deletespamguardagent failure: can't
deletespamguardagent that name
BAD - command unknown or arguments invalid
Remove the spam guard agent for the login user.
Example: IC: A018 DELETESPAMENTRY SabariGuard "mail@immp.pro"
IS: A018 OK DELETESPAMENTRY completed
6.5 Client Commands - Anonymous Query Commands
This section describes commands permitted in anonymous state for
querying IMMP server to check whether a particular subinbox is
available for that mail address and also check whether that incoming
mail address is blocked by the spam guard agent of the IMMP server.
Mostly mail posting protocols (SMTP, etc) use this commands.
Sabarish [Page 22] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
6.5.1 VERIFYINSPAMGUARDAGENT Command
Arguments: check-mail-address, in-mail-address
Data: no specific data for this command
Result: OK - not blocked by Spam guard agent.
NO - blocked by Spam guard agent
BAD - command unknown or arguments invalid
Check whether the check-mail-address is blocked by spam guard agents
of the user of in-mail-address.
Example:
RS: VERIFYINSPAMGUARDAGENT "spammail@immp.pro" "mymail@immp.pro"
IS: OK VERIFYINSPAMGUARDAGENT completed
6.5.2 VERIFYSUBINBOX Command
Arguments: sub-inbox, mail-address
Data: no specific data for this command
Result: OK - available inside the inbox
NO - unavailable inside the inbox
BAD - command unknown or arguments invalid
Check whether the sub-inbox is available inside the inbox of the
mail-address.
Example: RS: VERIFYSUBINBOX "office/work" "mymail@immp.pro"
IS: OK VERIFYSUBINBOX completed
7 Security Considerations
IMMP protocol transactions, including spam guard agent and option
data, are sent in the clear over the network unless the optional
privacy protection is negotiated in the AUTHENTICATE command.
A server error message for an AUTHENTICATE command which fails due
to invalid credentials should not detail why the credentials are
invalid.
Sabarish [Page 23] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
Use of the LOGIN command sends passwords in the clear. This can be
avoided by using the AUTHENTICATE command instead.
A server error message for a failing LOGIN command should not
specify that the user name, as opposed to the password, is invalid.
Additional security considerations are discussed in the section
discussing the AUTHENTICATE and LOGIN commands.
8 IANA consideration
IANA needs to reserve 323 port to this protocol.
9 Informative References
[SMTP] Jonathan B. Postel, "SIMPLE MAIL TRANSFER PROTOCOL", RFC 821
[POP3] R. Gellens, "POP3 Extension Mechanism", RFC 2449
[IMAP4] Crispin, Mark R., "Internet Message Access Protocol -
Version 4", RFC 1730.
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731
[MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822.
10 Author's Address
Sabarish Ramanathan
"Sabari Illam",
96 Gangadhara Iyer Street,
Karaikudi, Tamil Nadu 630 001
India
sabarish@computer.org
Sabarish [Page 24] Expires November 2005
Internet Draft IMMP -- Internet Message Mapping Protocol May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Disclaimer
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Sabarish [Page 25] Expires November 2005
