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

Re: POP/IMAP before SMTP



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

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

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

	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

	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