MAILQ protocol version 2


Scheduler writes following to the interface socket:

	"version zmailer 2.0\n"
	"some magic random gunk used as challenge\n"

Then client writes there:

	"AUTH username HEXAUTHENTICATOR\n"

and scheduler replies:

	"- some message \n"
	"+ some message \n"

where "+" at line beginning is success (and anything else is failure).

That done, initial login phase has completed, and actual command interface
can commence.

The HEXAUTHENTICATOR is calculated by catenating the challenge line
(without its ending '\n'), and user password, and doing MD5 over them.
Then the resulting message digest is printed out bytewise with "%02x",
that is, lowercase hex characters.


	---------- ToBeWritten: commands ... -------------
	(and multiline replies, and state things, and ...)

	Multiline replies follow same rules as e.g. at POP3.

ETRN etrn_string
	- Single-line reply

SHOW QUEUE SHORT
	- Success/Failure indicating reply; "+ xxxx" = success, "- xxx" = fail
	- On success a multiline reply

SHOW QUEUE THREADS
	- Success/Failure indicating reply; "+ xxxx" = success, "- xxx" = fail
	- On success a multiline reply

SHOW SNMP
	- Success/Failure indicating reply; "+ xxxx" = success, "- xxx" = fail
	- On success a multiline reply

SHOW THREAD channel host
	- Multiline reply
	- Each line containing following TAB separated fields
		- Spoolfile name (1234-567 or X/1234-567 or X/Y/1234-567)
		- "<"source-envelope-address">"
		- Recipient entry offset within the file
		- expiry time_t
		- next wakeup time_t
		- last feed time_t
		- count of processing attempts
		- If wakeup in future, "retry in #d#h#m#s"
		  else reason for waiting: "channel"/"thread"/""
		- Diagnostic message from transport agent
	(Recipient addresses are not known to the scheduler, so it can't
	 report those)


KILL MSG spoolid           (expires the message -- all recipients)
	- Not yet implemented

KILL THREAD channel host   (expires the thread)
	- Not yet implemented

REQUEUE ROUTER spoolid     (?? - from a TODO item..)
	- Not yet implemented