On Oct 12, 2016, at 2:07 PM, Rick Romero <admin@vfemail.net> wrote:
Quoting KT Walrus <kevin@my.walr.us>:
I’m in the process of setting up a Dovecot IMAP proxy to handle a number of IMAP server domains. At the current time, I have my users divided into 70 different groups of users (call them G1 to G70). I want each group to configure their email client to access their mailboxes at a domain name based on the group they belong to (e.g., g1.example.com <http://g1.example.com/>, g2.example.com <http://g2.example.com/>, …, g70.example.com <http://g70.example.com/>). I will only support TLS encrypted IMAP connections to the Dovecot IMAP proxy (‘ssl=yes’ in the inet_listener). My SSL cert has alternate names for all 70 group domain names.
I want the group domain to only support users that have been assigned to the group the domain name represents. That is, a user assigned to G23 would only be allowed to configure their email client for the IMAP server named g23.example.com <http://g23.example.com/>.
My solution during testing has been to have the Dovecot IMAP proxy to listen on different ports: 9930-9999. I plan to purchase 70 IPs, one for each group, and redirect traffic on port 993 to the appropriate Dovecot IMAP proxy port based on the IP I assign to the group domain name in the site’s DNS. The SQL for handling the IMAP login uses the port number of the inet_listener
I think this could work in production, but it will cost me extra to rent the 70 IPs and might be a pain to manage. Eventually, I would like to have over 5,000 groups so requiring an IP per group is less than ideal. I also think having Dovecot IMAP proxy have 5,000 inet_listeners might not work so well or might create too many threads/processes/ports to fit on a small proxy server.
I would rather have 1 public IP for each Dovecot IMAP proxy and somehow communicate to the userdb which group domain name was configured in the email client so only the users assigned to this group can login with that username.
Anyone have any ideas?
Do you have a SQL userdb? Create a table or a 'host' field for the user.
user_query = SELECT CONCAT(pw_name, '@', pw_domain) AS user, "89" as uid, "89" as gid, host, 'Y' AS proxy_maybe, pw_dir as home, pw_dir as mail_home, CONCAT('maildir:', pw_dir , '/Maildir/' ) as mail_location FROM vpopmail WHERE pw_name = '%n' AND pw_domain = '%d'
(mine is based on qmail/vpopmail)
Then populate 'host' for each user if you don't have any other way of programatically determining the host..
This doesn’t solve my problem. Indeed, I am doing this already:
password_query = SELECT password, 'Y' as proxy, CONCAT_WS('@',username,domain) AS destuser, pms AS host, ’secretmaster' AS master, ’secretpass' AS pass FROM users WHERE username='%n' and domain='%d' and (group_id=%{lport}-9930 or %{lport}=143 or '%s'='lmtp') and mailbox_status='active’;
This is the password_query I am using on the Dovecot IMAP proxy. This proxy doesn’t use a user_query (only the real backend Dovecot servers do). I allow authorizations on port 143 only for Postfix. Port 143 isn’t exposed to the email clients (only 993 is used by email clients).
Anyway, checking the %{lport} allows only IMAP logins using the proper domain name (IP or port) to allow the log in of the user.
I’m looking to find out the IMAP server name that the user configured their email client with and make sure I only allow users to access their mailboxes using their assigned IMAP server name.
Note that the problem I am trying to solve is if the user configures their email client with the wrong IMAP server name (e.g. using g2.example.com <http://g2.example.com/> instead of g23.example.com <http://g23.example.com/>) and later I move G23 to another datacenter and leave G2 in the current datacenter, they will not be able to access their emails since the G2 datacenter doesn’t have their mailboxes any more and the mailboxes for G23 are only in the G23 datacenter. My users aren’t email experts and I don’t want them to have to discover that they made a typo in the original setup long after they have forgotten how they set up the client in the first place.
To start with, the mailboxes will all be in the same datacenter, but I want to be able to move some of the mailboxes to be geographically closer to the users of those mailboxes (like Western users using Western servers while Eastern users use a datacenter closer to the East coast).
Kevin