> [snip - stuff about how it can be done with pop and how users are fools :-]
We are offering this service as a 'favour' to customers. We have to
offer it, but we are at least allowed to enforce things upon them.
> 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!)
No, that doesn't work as I described in a subsequent email. At least
not all the time.
> 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.
I don't know ipass.com... I am looking at their website, but even
off the 2Mb line it is crawlingly slow... not good...
Ok, they provide an authentication manager, which is quite cute, and
I may be interested in for entirely different reasons, but isn't
helpful for our unix/mac customers, since they only appear (on a slow
first perusal) to offer win95 software.
> 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.
Or you do it on the fly.. which is what a external database lookup would
be.. such as NIS..
> 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.
Err, well, so long as you run bind8+, but yes an equiv to RBL using DNS
would be acceptable
> 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.
>
It does have some advantages though when spread across multiple machines.
Ok, if I can convince Philip to implement it the same was as RBL then that
would do... or can I just do it with an RBL call? I've not investigated
RBL all that closely. Anyone? Can you _allow_ relaying as a result of
an RBL call?
Julian
Unix Admin, Internet Vision
--
*** Exim information can be found at
http://www.exim.org/ ***
