Thank you Simon for the response! I believe the ssl_no_cert_verify switch will solve my
issue when combined with DNS entries for each pod name.
-Todd
-----Original Message-----
From: Simon Horman [mailto:horms@verge.net.au]
Sent: Monday, July 15, 2013 12:09 AM
To: Todd Taylor
Cc: perdition-users(a)vergenet.net
Subject: Re: Perdition: Handling partial host name returned from pop map
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.