Re: [EXIM] Request for a new feature

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Greg A. Woods
Fecha:  
A: exim-users
Asunto: Re: [EXIM] Request for a new feature
[ On Tue, May 26, 1998 at 12:44:44 (+0100), Julian wrote: ]
> Subject: [EXIM] Request for a new feature
>
> This is a blatant request for a new feature, the reason for posting it
> to the list is in case anyone else has a need for something similar.
>
> I am in the unfortunate position of needing to allow connections
> from abritrary IP addresses and arbritrary from/to addresses running
> arbritrary email software. However, naturally I want to limit this to
> people who have a right to use our services. Ah the joys of having to
> deal with people using dialup to random ISPs.
>
> In order to deal with 'authentication' we have come up with a scheme
> whereby the users run an authentication daemon, I won't go into the
> details right here, although I am more than happy to explain the
> idea if anyone cares.
>
> What I need is a hook into exim such that I can get authentication
> from an external program, it wouldn't be appropriate to have this
> built into exim (unless of course you all think that my authentication
> scheme is the best thing since sliced bread)


I've seen two "generic" solutions to this problem, and one not so
generic solution that may apply. Both solutions involve the same kind
of programming to interface into a mailer.

The first "generic" solution is exactly as you describe -- the user is
provided with a small "authentication" client which does some kind of
(hopefully cryptographically secure) authentication and provides the
client's current IP address to the mail server host. Unfortunately it's
often hard/difficult/impossible to get users to use such a system, and
as with any security technology, putting such tools in the hands of the
user implies a certain amount of trust in the user -- you essentially
limit your knowledge to knowing that the user possesses something. On
the other hand there are very significant advantages to using such a
custom authentication tool, such as using this same authentication for
POP/IMAP authorization.

The most generic solution is to keep track of the client's IP address
from valid POP/IMAP/etc. authentications. In this case you also have to
have some sort of "expiry" mechanism to clear out aged IP addresses.
(Unfortunately POP authentication may not be all that secure!)

The not-so-generic solution assumes you're providing some kind of
internet "roaming" service, such as iPass.com's. In this case you
should be receiving the client's IP address as part of the
authentication request or accounting start transaction. The end
accounting transaction can be used to invalidate the client's IP
address. Depending on the reliability of the end transaction you may
also want to have a timeout expiry on IP addresses.

In all of these cases you need to make the table of valid client IP
addresses available to the mailer. This can be done either through a
database lookup, or perhaps a shared memory table, etc.

I've seen various permutations of these schemes implemented very
successfully in real life situations scaling from the very smallest
corporate mail server right through to very large ISPs.

> I'd like kind of the reverse to the RBL, only I can't
> sensibly use DNS...


Actually you can, so long as you're willing to build a unique private
zone similar and parallel to the in-addr.arpa zone. With dynamic
updates to the primary server, such a scheme is very easy to build and
manage.

I've seen this done quite successfully in real life too (even before
dynamic updates were possible in BIND). The DNS is a very suitable
distributed database for this kind of appliation. In fact using the DNS
for this purpose is probably the most scalable approach.

-- 
                            Greg A. Woods


+1 416 443-1734      VE3TCP      <gwoods@???>      <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>


--
*** Exim information can be found at http://www.exim.org/ ***