Re: POP/IMAP before SMTP

[Eugene Crosser <crosser@online.ru>]

> > >      POP/IMAP sends registration info to this server S, and SMTP
> > >      queries the server for valid data.  The server can do data
> > >      invalidation all by itself.

>      Will you write the server, and changes for the smtpserver, plus
>      hook API for whatever application wants to report acceptable IP
>      address ?   (I am chronicly short of spare cycles, especially on
>      things that are not on my official high-priority task schedule..)

Oh, I am under pressure too :-(  Well, look at the document attached
and tell me what you think.  Actually, a prototype server (w/o ssl)
is a work for a day or two...  Maybe I'll manage to do it.

>      Now the problem is that user's IP address is not passed
>      down the chain, which means the last server can't do 
>      setting the permission on with successfull login :-(
>      Furthermore doing logging at the POP-Proxy or SSL-tunnel
>      program (well, I guess I will make SSLeay-POP-proxy ;-) )
>      can not do it, as it does not know that the login was
>      successfull.  If it does the logging, then ANY connection
>      to the proxy will work, at least if the "user" is known,
>      and yields connection to the real servers..

Probably there is no way if authentication is done on the other end
of the tunnel *and* original address information is lost while tunnelling.

Eugene

=======================
This is a draft propsal for the "Who's On" protocol.
Eugene G. Crosser <crosser@average.org>
28 Apr 1998

"Who's On" protocol is designed to provide Internet server programs with
a way to know if a particular IP address is currently allocated to a known
(trusted) user and (optionally) with the identity of the said user.

One possible application may be allowing a client to submit email over
SMTP from an IP address that was recently used to retreive email over
POP/IMAP, if valid credentials where presented.  Another use may be an
addition/replacemnt to ident (RFC931/1413) to identify users logged in
over dialup using RADIUS, TACACS or some such.

The design goal is to make the API simple and move things like TTL
housekeeping into a dedicated server process.  On the other hand, the
server process is not supposed to ever perform "slow" operations like
DNS lookups.

The server process shall listen for client connections on UNIX domain or
TCP sockets or both, accepting plain or SSL-encrypted sessions or both.
The server may choose to only accept connections from a listed set
of hosts.

Once connection to the server is established, the client sends request,
which is a single line consisting of printable ASCII characters and
terminated by <CR><LF>, and waits for responce from the server, which
is a lingle line consisting of printable ASCII characters and terminated
by <CR><LF>.

There are two classes of requests the client may send to the server:
update requests and query request.  Update requests tell the server
that a particlular IP address is in use by a trusted user, and that
the particlular IP address is no longer in use by a trusted user.
Query request asks the server which user, if any, currently uses the
particular IP address.

Update request format is:

	"LOGIN" <SP> <addr-spec> <SP> <user-identity> <CR> <LF>
	"LOGOUT" <SP> <addr-spec> <SP> <user-identity> <CR> <LF>

<user-identity> field with preceding whitespace may be omitted from
either request.

The server shall, having accepted "LOGIN" request, remember the relation
between the <addr-spec> and the <user-identity> and may expire this
relation without "LOGOUT" request when the TTL for the entry expires.

The server may choose to accept update requests from a listed set of
hosts, require that update requests be only sent using SSL, or impose
other restrictions.  Set of restrictions must be the same for "LOGIN"
and "LOGOUT" requests.

The server shall respond to the update request with a string starting
with either '+' (plus) or '-' (minus) character, meaning success or
failure respectively, and optionally containing a description string.

Query request format is:

	"QUERY" <SP> <addr-spec> <CR> <LF>

The server may choose to accept query requests from a listed set of
hosts, require that query requests be only sent using SSL, or impose
other restrictions.

The server shall respond to the query request with tier of two strings:

	"+" <user-identity> <CR> <LF>
or
	"-" <description-string> <CR> <LF>

<user-identity> and <description-string> may be omitted.  The server
may choose to omit <user-identity> in responces to some or all requestors.

<addr-spec> is an IP address of the host in dotted-quad notation.
<user-identity> is a string of printable ASCII characters not starting
with whitespace and used to identify the user on a particular system.
<description-string> is a string of printable ASCII characters that
may contain plain text explanation of the failure.
==============