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

Re: POP/IMAP before SMTP

> Hi all,
> 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.

	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.

	[Sonera Corp. Internet messaging services hat on]

	Questions/comments I have are related on:
	- We have disjoint SMTP and POP servers (multiple each)
	- Our Port 110 "POP"-servers are actually proxies which
	  just take user's login-id, and look up our backend database
	  for the real server to which they then connect (and feed
	  the user specified username to it.)  After the connect
	  that proxy just moves bytes between user's and server's
	  sockets without looking into possible meanings inside
	  the datastream.
	- The real POP-servers have NO idea, where from the connection
	  came.  The POP-Proxy does NOT know wether or not the POP-
	  login authentication has been successfull, thus it can neither
	  do the logging...  (Sure, we could add to the POP-protocol in
	  between proxy and the real server an info entry telling where
	  from the proxy got its connection -- but those real servers
	  are reachable from anywhere in the world too..  Ok, a TCP-
	  wrapper could help there.)

> Is anyone actual implementing such for avoid anonymous mail submission?

	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.

	I really would like to know what MS-Exchange 5.X means with
	EHLO response:

	It definitely does not mean same thing as current IETF draft
	about authenticated SMTP sessions.

	(But then, it means there exists client support for it..)

	Any approach we use must have changes of having client support
	available.  Preferrably something that can be gotten to work
	with simple instructions with software that people have had
	for ages in their Windows boxes. (I mean, like for past year..)

	Do remember that the average computer skills of people using
	email these days approach zero, nothing fancy should be needed.

	(Reports from our helpdesk seem to point towards an observation
	 that although we have gotten lots of new customers, the SUM
	 of skill level has not increased noticeably :-(  Although the
	 initial customer group had wizards among them, those are already
	 working in our offices..)

> Rgds,
> Lai Yiu Fai                       |  Tel.:       (852) 2358-6202
> Centre of Computing Services      |  Fax.:       (852) 2358-0967
>  & Telecommunications             |  E-mail:     ccyflai@ust.hk

/Matti Aarnio <mea@nic.funet.fi>