Re: POP/IMAP before SMTP

[Eugene Crosser <crosser@online.ru>]

This is an important question these days, let me comment on it.

> > Has anyone implemented POP/IMAP before IMAP with ZMailer smtpserver using
> > the policy filtering?  How it works:  everytime someone successfully
> > enters a  correct userid/passwd to POP/IMAP server,  the IP address of
> > remote client is logged in a .db file together with a timestamp.   The
> > database will then  serve as a list of IP addresses that are allowed to
> > perform an SMTP relay by the smtpserver.   A background process is used to
> > expire addresses from the database as their validity runs out, say 15mins.
> > 
> > Will it possible for smtpserver to reread smtp-policy database file
> > without any racing problem for frequent modification, say per 30 second?
> 
>      I think this needs ANOTHER server and protocol (an easy one, but
>      another anyway) for it.
> 
>      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.

This I absolutely agree!  Having a separate server for this purpose is a
right solution, and, among other things, allows for having POP and SMTP
on different machines.

>      In all cases that data is advisory only, you can't truly rely
>      on it to be of any real worth for authenticating the SMTP session.

>      To a degree it could diminish problems related to  anonymous
>      email submission.  Another approach COULD be use of SSL to
>      authenticate the session, and perhaps the user, but there
>      is no client support, as far as I know.

Matti, this is not the question of *real* authentication, this is a
question of travelling customers.  Imagine you have a strict anti-spam
smtp policy, that forbids submissions from other networks to arbitrary
destinations.  Now imagine you have a customer who took his laptop and
went to South Africa for a week.  There, he plugs the phone jack,
connects to a local provider (using, e.g. roaming), and tries to send
mail.  He has our smtp server in his configuration, and we will kick him
off.

Now, if we have the scheme described above, he does not need to do
*anything* special, and he may use *any* software, and we will accept
his mail.  Here, we do not need real authentication, we just need to
open anti-spam shields for a moment and for a particular IP address.
So, I don't feel that implementing of this feature should have any
relation to implementing authenticated or SSL SMTP (that clearly needs
cooperation with the client).

Eugene