This document describes a new scheme for client authentication and authorization in GNU Anubis 4.x.
So far the only authentication method used by Anubis was based on the
AUTH protocol (RFC 1413),
and thus required client party to use a popular daemon
identd, which listens on TCP port 113 for authentication requests. As
its primary advantage, this method allows to quickly identify whom the server
had to deal with, i.e. to obtain user name or his UID. Actually, the
authentication process finishes before the client sends over his first
byte. Besides, this method allows to process the entire SMTP envelope.
It has, however, several drawbacks, first of them being the
requirement to run identd on the client machine, which is
not always possible (e.g. on mobile devices), and may be considered
harmful for the system security (due to sending user ID over
the wire).
Proposed are two operation modes:
A short description of each mode follows:
Users are authenticated using ESMTP AUTH protocol. Early processing of SMTP envelope is not possible in this mode , instead it becomes possible only after the authentication is finished successfully. This mode also delays connecting to the MTA, since Anubis first has to perform ESMTP AUTH, and only after finishing authentication, does it read and process the user’s configuration file and connects to the selected MTA. Of course, the client is not able to begin sending messages until he is authenticated and accepted by Anubis.
There is a great difference between the two modes. To begin with, ‘Pixie’ mode provides a tunnel (or proxy), in the sense that Anubis connects user’s MUA to the remote MTA without requiring any special actions from the user.
Let’s consider a simple interaction between ‘Machine-A’, which runs Anubis 4, and ‘Machine-B’, where MUA is run.
A: 220 Machine-A (GNU Anubis vX.X [Dixie]) ESMTP time; send your identity! B: EHLO Machine-B A: 250-Machine-A Hello ID 250-STARTTLS 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN 250-XDATABASE 250 HELP B: STARTTLS A: 220 2.0.0 Ready to start TLS <TLS> B: AUTH <METHOD> [method-specific authentication interchange follows]
Now, the Anubis server has authenticated the client using data from Anubis database! I’d like this database to contain, beside the user name and password, the name and password of this user on Machine-A.
Confusing? Let’s suppose that the database contains following record:
JohnSmith encrypted-pass-1 John
The user has authenticated himself as ‘JohnSmith’ with password ‘encrypted-pass-1’, using ESMTP AUTH, and the given credentials matched those from the Anubis database. Now, Anubis, which has been running with super-user privileges, switches to UID of the user ‘John’.
Such solution will allow for a very flexible database, that would ease the administration tasks, since users will be able to update their corresponding records (of course, if the system administrator grants them such privileges). For instance, ODBC, SQL?
Let’s return to our sample session. After successful authentication and switching to the user’s privileges, Anubis parses file ‘~/.anubisrc’. Then, based on user’s configuration settings, it connects to the MTA and from then on operates as SMTP tunnel and mail processor :-). It sends the following response to ‘Machine-B’:
A: 220 OK, Welcome. Continue sending your mail!
The above description shows that it is impossible to use both ‘Pixie’ and ‘Dixie’ simultaneously. It is the responsibility of the system administrator to decide which operation mode to use. We could probably provide for a smooth switching between the two modes, without requiring to restart the daemon... However, it is not critical. Restarting the daemon in order to switch to another operation mode is also a feasible solution.
Now, let me describe for what kind of users each mode is intended.
The traditional (‘Pixie’) mode is intended for those users who use
Anubis on a single machine or within a local network that allows
to use identd. In short, ‘Pixie’ is useful when the use of
identd is possible and safe.
In contrast, the new mode ‘Dixie’ is intended for more complex
setups, where a single machine running GNU Anubis serves a number
of clients connecting from different machines and networks. It
is supposed that no client machine is running identd.
The only recommendation for this mode is that each user have a system
account on the machine running Anubis. But then, even this is
not required!
That’s a feature I haven’t described yet :^) As described above, Anubis
database must contain second login name in order for Anubis to be able to
switch to the user’s privileges and parse his ‘~/.anubisrc’ file.
Now, I supposed that the database is able to keep user configuration files
as well. So, each database record must contain an additional
flag informing Anubis whether it should read the local file
‘~/.anubisrc’, or read the configuration file stored in the
database. Sure enough, GNU Anubis still will have to switch
to the user’s privileges, for security reasons, but this
can be done using usual user-notprivileged configuration
(see section user-notprivileged).
Surely you have noticed that in its response to EHLO command
Dixie returned 250-XDATABASE capability. Yes, this is exactly
that command that I’d like to be used for remote management of
the database records (after having successfully passed ESMTP AUTH).
Available operations are: ADD, MODIFY, REMOVE, meaning
addition, modification and removal of a user record, and
UPLOAD, providing a way to upload the user’s configuration
file ‘~/.anubisrc’.
This solution will free the users from the obligation to have ‘~/.anubisrc’ on the server machine, so they, for the first time since early Anubis versions, will be able to have their own configuration files. Current versions((7) require that the user configuration file be stored on the server machine before the user is able to use the service. This approach requires a certain attention from the system administrator. Should the user wish to change something in his configuration file, he would have to install the modified file on ‘Machine-A’ (that’s how it works now, and that’s how it will continue to work for ‘Pixie’ mode). The new ‘Dixie’ mode solves this and frees the user from necessity to contact the system administrator of ‘Machine-A’. The Anubis database engine is supposed to check the correctness of the uploaded configuration file and inform the client about the result. It also should compute MD5 hash of the file and compare it to the one sent by the user... What for?
Well, we’re almost finished. The user will have a small program,
config-sender, written in whatever language (C, Java, C#),
whose main purpose is to send user’s configuration file to the
database. Such a program could even be installed on a mobile device!
Notice also, that this program is optional, the user is not required
to use it. I envision a situation where:
config-sender program. This
program, in turn, computes MD5 sum of the local ‘~/.anubisrc’
file and sends it to Anubis. There it will be compared to the sum
kept in the Anubis database, and if the two sums differ, the
config-sender will upload the contents of
‘~/.anubisrc’... (8)
config-sender program will, of course, connect to the Anubis
database using ESMTP (TLS/AUTH) and XDATABASE.
Such a program will be an additional advantage, since
no existing MUA is, of course, able to use XDATABASE command to
manage Anubis database. Notice however, that
GNU Hydrant will probably
support XDATABASE in the future...
Thus, the user will simply use his MUA, no identd, no hassle :)
Actually, the only requirement for the MUA is that it support ESMTP AUTH. Unfortunately, some MUA, even on UNIX-like systems, are still not able to use ESMTP AUTH. But in this case, the user can install Anubis on his machine and use it to perform authentication ;-)))
And the last detail: what to do if the remote MTA also requires ESMTP AUTH? The answer is quite simple: GNU Anubis is already able to handle this (see section esmtp-auth).
identd!
These can be stored in a special directory as usual files, then each database record will have an additional field with the name of the configuration file for the given user.
— THE END —
This document was generated on January 6, 2024 using texi2html 5.0.