Jason wrote:
> "AK" <aktrader2@excite.com> wrote in message
> news:uOWdnQZzH4k0ICvZnZ2dnUVZ_sSdnZ2d@comcast.com. ..
>
>>Jason wrote:
>>
>>
>>>Hi. This post may digress on to a discussion that doesn't relate
>>>directly to qmail, so I'm just looking for quick pointers... Nothing
>>>to specific if the solution doesn't relate to Q-Mail... Does anybody
>>>have any ideas for implementing the following solution?
>>>
>>>I want to make a standalone system that functions as a pop3 proxying
>>>device for thousands of users, connected with hundreds of domains, that
>>>are hosted on 1-5 pop3 servers.
>>>
>>>The idea is that email users would connect to this pop3-proxy
>>>the pop3 proxy would send username/password queries to all of the 5 pop3
>>>servers; whichever auth succeeds for that username/password/realm is
>>>then used to complete the transaction.
>>>the pop3-proxy would then make a full-blown pop3 connection to that
>>>server, proxy the commands from the customer on to the respective pop3
>>>server, and proxy the responses back to the client, and terminates the
>>>connection when the client terminates/timeouts.
>>>
>>>The idea being that I will then modify my DNS records to point all client
>>>pop3 requests to point to this new server. I understand that this would
>>>cause a huge amount of overhead because up to 5 connections would be made
>>>for every pop3 connection, but thats a sacrifice in performance that has
>>>to be made for the completion of this project.
>>>
>>>We'd also have to do a similiar thing with SMTP, but because SMTP is a
>>>lot easier to manage because it is entirely based on relaying, I think i
>>>can cross that bridge when I get there.
>>>
>>>Does anybody have any ideas in this regard?
>>>
>>>Thanks in advance,
>>>
>>>-- Jason
>>
>>You are looking for something well beyond the capability of a proxy. Yo
>>
>>Are there other options available to you?
>>
>>have a look at the vpopmail or qmail ldap implementation.
>>
>>You should consider consolidating your infrustracture such that you have
>>redundancy as well as a "single" point of access to every thing.
>>
>>Instead of trying to access five different systems, you could as part of
>>the application setup a mechanism that will check based on the realm to
>>which server it needs to connect and proceed from there.
>>
>>AK
>
>
> Thanks for your suggestions, but I think this is the only way that can
> accomplish what I am going for.
>
> The idea here is that I am actually in the process of combining two
> different mail platforms over into 1 new one, and the conversion process
> would best be done gradually (instead of doing the conversion in a batch all
> at once, which if done incorrectly, could lead to screwing myself bigtime).
>
> As such, I need to be able to direct the traffic to whichever pop3 server
> holds the mailbox for the specific user. If I can't do that, then I'm
> looking at a big headache. :-/
>
> If I have to, then I might even end up coding this project myself... which
> I would probably release on sourceforge if I did... But I can see how a
> tool like this could be a huge help to mail administrators everywhere who
> are in a similiar situation... (ie... parent company combines with a
> different one, and managmenet wants to homoginize mail platforms across the
> enterprise).
>
> -- Jason
>
>

Actually,

You will get a bigger headache in this approach than you would if you
were to either decide to retire the old or setup a mapping from the old
to the new and have any email sent to the old forwarded to the new.
(alias maps)

You essentially will be writting the service that will be listening for
the incoming connection. Then doing the cursery POP3D negotiation to get
the username/password. Then While delaying the response to the
authentication, will have your process attempt to authenticate to the
various mail server whether one after the other or all at the same time
beleiving that only one will succeed. Once a connection is achieved a
response to the original is sent.
Effectively you are trying to get a man-in-the-middle type of process.

While it would be some headache to maintain the current setup while
planning the combined system, in the long run, this will need to be
tackled at some point and will provide future guides should your firm
continue to expand merge and require a similar process.

Once the combined setup is achieve it can be tested prior to making it live.

AK