[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: POP/IMAP before SMTP



On Tue, Apr 28, 1998 at 12:20:35AM +0300, mea@nic.funet.fi wrote:
> > This is an important question these days, let me comment on it.
> 
> 	Indeed, and my comment was related on problem of having
> 	need to support rather weird setup we have at my work.

Though the setup may be a bit weird and I absolutely agree it need a seperate
server or protocol for such control,  it has no perfect solution right now
(actually some draft proposal exists but need support for both MTA and MUA)
and is it possible implementing this for current Zmailer?  i.e. Will frequent
ONLINE update with smtp-policy db harm the operation or cause unexpected
behaviour of smtpserver?

> ......
> > >      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.

Possibly if you have only one SMTP server for your local mail submission,
you can use syslog to log all POP/IMAP login message to your destinated 
SMTP host.

> 
> 	Will you write the server, and changes for the smtpserver, plus
> 	hook API for whatever application wants to report acceptable IP
> 	address ?   (I am chronicly short of spare cycles, especially on
> 	things that are not on my official high-priority task schedule..)

Actually, I tend to use minimal effort to achieve something that can be useful
and remedy the problem in certain extent.  Writing new code and hook API in
smtpserver is really ideal way for doing this but may be a long way away.
Actually, this is not your first priority task ...

> 
> > >      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.

Yes, the information is advisory only but you can limit the scope of
investigation in case of UBE complaint.  Let take ours as an example,  we
provide open network access points for users to connect to our network and
right now we can't avoid anonymous mail submission from these network nodes.
And this POP/IMAP before SMTP may help a lot to identify who & where the
mail was submitted.  (Surely, it is a different story if user's passwd was
compromised)

And what Eugene said it may also help for those roaming user especially in 
University environment.   Our faculty need frequent travel and surely this
help to save their work to change their default smtp configuration for
different provider.

> > 
> > >      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).
> 
> 	Sure, but I am a bit worried about how can I support
> 	the system in the environment that I run.
> 
> 	Essentially the problem is that we have chains of:
> 
> 	User -- POP-Proxy -- POP3d
> 	User -- SSL-tunnel -- POP-Proxy -- POP3d

Surely, content-based POP3 proxy (it is available as I know) must be used
to capture the POP "USER" command and logged it if logon successfully.

> 
> 	Now the problem is that user's IP address is not passed
> 	down the chain, which means the last server can't do 
> 	setting the permission on with successfull login :-(
> 	Furthermore doing logging at the POP-Proxy or SSL-tunnel
> 	program (well, I guess I will make SSLeay-POP-proxy ;-) )
> 	can not do it, as it does not know that the login was
> 	successfull.  If it does the logging, then ANY connection
> 	to the proxy will work, at least if the "user" is known,
> 	and yields connection to the real servers..
> 
> 	Perhaps my POP-Proxy is a bit too simple-minded with its
> 	behaviour, as once it forms a connection, it will not
> 	look into the bytestreams flowing between the user, and
> 	the POP-server.  Definitely it is not a content based
> 	firewall (like those bloody Cisco PIXes..)
> 
> 
> 	(and I have not even looked into question about IMAP4*
> 	 proxying...)
> 
> > Eugene
> 
> /Matti Aarnio -- wishing you good night

Bests,
Ken Lai