Hi Todd,
On Thu, Jul 11, 2013 at 05:46:17PM +0000, Todd Taylor wrote:
Perdition folks,
I'm investigating implementing the latest version of Perdition Proxy for a client
where the popmap would be provided using LDAP. User/Domain routes are already stored in
LDAP, with limited information. Perdition will be servicing POP/POPS and IMAP/IMAPS.
They will have multiple load balanced proxies to multiple unique mail platforms. The users
are going through a migration, so their target will change and there is not a 1:1 mapping
between old to new targets. At the moment, each user is connecting with a target pod
specific FQDN.
The client is reluctant to add additional LDAP attributes unless absolutely necessary.
They currently have the partial hostname of the user's target mail platform stored in
LDAP, as 'pod1'. For all connections to work, I believe I'll need a full
hostname (ie,
pop.pod1.platformdomain.com and
imap.pod1.platformdomain.com) that matches
the cert on the target platform interface. I'm sure I could use DNS for to resolve
'pod1' to the target platform IP. However, I don't think it will help for SSL
connections, presenting perdition with an SSL challenge during connection to the target.
Given the above, I have a couple questions for those with any thoughts or experiences:
1) Can I configure Perdition to ignore the cert errors when connecting to the
target?
You can use ssl_no_cert_verify to tell perdition not to verify the
certificate it receives when connecting to the target IMAPS server.
2) If (1) can be done, can I simply using DNS to
deal with the partial hostname?
Assuming my answer to (1) resolves your the problem at hand, yes, I think so.
3) Assuming above doesn't work, is there a
nifty way to 'fix up' the hostname returned from the popmap? Is it possible to
prefix 'pop.' and append '.domain.com' to the value returned?
You should be able to use add_domain=remote_login. possibly in
conjunction with strip_domain=remote_login to append .domain.com, provided
that
something.domain.com is the reverse DNS lookup of the IP address that
end-users (clients) connect to.
There is currently no option to add a prefix.
If there is a desire for enhancements in this area than my current
thinking is that it would be nice to provide something similar to
the query_key option for remote_login and local_authentication.
4) Would you recommend:
a. One Perdition farm listening to all user connections and routing to any target
farm -or-
b. Perdition farms per Pod/FQDN, allowing for a default route while also providing a
means of routing to other pods.
I believe that one instance should be sufficient, especially if the
query_key option can be used to good effect.
But if that doesn't meet your needs I see no particular problem with
multiple instances.