mouss wrote: > Matt Shields wrote: >> I'm trying to set up a large scale email system that supports 100,000+ >> IMAP accounts. We have an existing frontend web interface that does a >> lookup on a mysql db to figure out which IMAP server to connect to for >> each user. For the email infrastructure we have decided on Postfix >> and Cyrus. We have configured both to use mysql to get the virtual >> user information. >> >> Because of the way that the infrastructure is (biz reasons) we are not >> doing shared storage, we have numerous IMAP servers that we distribute >> accounts across. As we add more users, we image up a new IMAP server. >> For our business's scaling purposes this was the best plan. >> >> What I am having a problem is how do I get postfix to transfer the >> email to the particular IMAP server that the user account is on. I >> know that I need to use lmtp and transport, but all the examples I >> have seen show forwarding all email to 1 IMAP server. I would like >> Postfix to do a lookup for each mailbox and determine which IMAP >> server to deliver it to. > > There are primarily two ways: > > [virtual aliase] > you can use virtual_alias_maps to redirect foo at example.com to > foo at hostN.example.com, provided the final server accepts such addresses. > > If the final server doesn't accept these, and you use smtp to relay to, > then you can write the addresses back, using smtp_generic_maps. > > [transport] > an laternative is to use use (per-user) transport_maps. something like > > foo at example.com relay:[hostN.example.com] > > > In bothe approaches, the mappings can be generated using sql statements > (mostly CONCAT). something like > ... > query = SELECT concat('relay:[', host, '.example.com]') > FROM User > where '%u' = user and '%d' = domain > > you get the idea I hope. > > just to add that the virtual aliases way is to be preferred. transport_maps is a "latency sensitive" map, so it is better not to use an rdbms for that.