this version: D1 [2001-12-10 12:51]

Greetings:

I feel like we've gotten too quiet, and the noise we do have is not on the
track that I thought was leading in a good direction.  So, here I am, making
a joyful noise.

IMTP, the Internet Message Transfer Protocol, is used by the sender's MUA
to transfer a message to their IM2000 server for outbound notification and
future retrieval.  It should be a relatively simple protocol, and should:
	1) accept connections on a well-known port
	2) authenticate users
	3) accept messages
	4) report any errors in these processes
	5) close gracefully

I had also suggested IMMP, Internet Message Management Protocol, which would
allow users to manage their existing, queued messages.  This functionality
MAY be rolled into IMTP, but I am not yet convinced that it should be.  I will
not include sample verbs for IMMP here, anyway.

1. Establishing a connection

IMTP will live on a well-known tcp port, 'imtp', and accept connections.
Since users may wish to send mail from roaming locations, IMTP servers will
probably accept connections on public interfaces.

1.1. Verbs

Communication on a connection takes place by use of verbs, which are generally
in a "VERB parameters" form, terminated by CRLF.

1.2. Messages

Long-form data (like message bodies) are transferred by chunked netstrings, 
terminated by a 0-length netstring.

1.3. Replies

Server replies should begin with a status code, followed by an brief
explanation. 

2. Authenticating for use

IMTP must not allow open relaying due to poor configuration.  While an
anonymous IM2000 server might not be out of the question, its implementation
should be possibly only through an act of will. 

No HELO-type verb is needed, as host identifiation can be passed in a USER verb.

2.1. The greeting

The server should greet an incoming connection with an acknowledgement that
it is an IMTP server, its protocol version, and any incidentals.

Example:
	100 imtp:1.0 welcome_to_neotokyo


2.1. The USER verb

The user should begin authenticating by informing the server of his username
with the USER verb.  Usernames should include the relevant host to minimize
the confusion of virtual and multiple hosts.

The server should be able to respond:
	a. unknown user.
	b. disabled user.
	c. known user.
	d. abivalent response.

Responses a and b will preclude further authentication as that user, while
c and d will allow it.  The distinction between c and d is that a system may
be configured to always reply 'd' and simply deny any authentication attempt
for unknown users at a later phase -- this method makes it impossible to
troll for actual accounts.

Example:
	USER kali@neotokyo.jp
	401 unknown_user
	USER tetsuo@neotokyo.jp
	201 known_user proceed

2.2. The AUTH verb

The AUTH verb chooses an authentication method, and may be ommitted if
default IM2000 authentication is used.  (I leave this method out for the
sake of avoiding discussion of it for the time being.)

Example:
	AUTH calgary_suite_341
	411 authentication_unsupported
	AUTH kobayashi
	211 proceed {012091-21-2012-1231-1231-2}

2.3. The PASS verb

While the PASS verb suggests a password, multiple authentication methods
may be available.  This verb will reply either with a password or with a
response to the challenged issued by the server's authentication proceed
method.

This verb (along with AUTH) will require careful consideration, as we
want to make sure authentication is modular beyond the most basic IMTP
authentication.  After successful authentication, the IMTP server begins
waiting for messages.

Example:
	PASS cosmicreberth
	421 rejected
	PASS cosmicrebirth
	221 user_authenticated ready_to_receive

3. Accepting messages

3.1. The TO verb

The TO verb specifies the recipient of the current message.

Example:
	TO jp.mil.olympics!colonel
	435 scheme_unknown
	TO colonel@olympics.mil.jp
	231 proceed

3.1. The HEAD verb

The HEAD verb marks the beginning of a message transaction, and is followed 
by a message (chunked netstring) containing message headers.  The server
may reject the message preemptively if it finds fault with any header values.

Example:
	HEAD (#,"Priority: High\n\rSensitivity: High")(0,)
	441 high_sensitivity_messages_must_be_hand_delivered
	HEAD (#,"Priority: High\n\rSensitivity: Medium")(0,)
	241 proceed

3.1. The BODY verb

The BODY verb marks the beginning of a message transaction, and is followed
by a chunked netstring containing the message body. 

Example:
	BODY (#,<message body>)(0,)
	251 13124_bytes_accepted

5. Closing the connection

5.1. The QUIT verb

This verb marks the end of an IMTP session.  The server should reply before 
closing the tcp socket, to acknowledge that the session was terminated by
the QUIT, and not a coincidence.

Example:
	QUIT
	299 sayonara

------

Thoughts?

--
rjbs