On 2/1/2011 12:50 PM, Ignacio Garcia wrote:
You are not thinking very clearly yet. You must distinguish clearly
between:
- Submission, users submitting mail for outgoing delivery. This is
visible to users, since they set the server in question as their
MUAs "SMTP server". This needs its own design, and it is what I
thought you wanted help with.
- Inbound MX service. Just publish appropriate MX records, and add
front-end SMTP servers to each of the two environments as necessary.
In ISP-grade implementations the SMTP inbound servers are not also
IMAP servers, rather they forward mail to IMAP servers (via LMTP
or SMTP).
Which do you need help with? State clear requirements for either or
each problem, and work from there.
yes, you're right, sorry. Maybe if I tell you what I want to do I can
make myself clearer. We have both a submission service and inbound mx
service. we want to have a unified smtp.mycompany.com so all
"submissions" can be processed using this canonical domain name. i
believe that is not too dificult. We also want to run both servers so 1
is mx-backup of the other and viceversa. However, I forsee several
problems here:
- both servers need to check against both databases for valid
destinations
- each server must know if delivery is to be local or it has to be
relayed to the other server.
- one server virtual_transport=maildrop (to courier-imap), the other
=dovecot (we are going with dovecot for the future, the one with courier
is older, but plenty of users)
So, is there any hope?
Ignacio
Speaking not as a Postfix expert but as a DBA, and speaking more on
administrative strategy rather than technically, I would consider
merging the two databases. This is just a guess that the two servers are
running under the same organizational umbrella and that the DB's serve a
similar purpose for a single organization. Ugliness will grow and grow
around accommodating two databases that should be one.
The unified DB would have a "server_a_user_table" and a
"server_b_user_table" ([much] better yet, a unified table with a server
tag column so arbitrary servers can be added ultimately). Then you have
the flexibility to distinguish a local user lookup versus a relay lookup
on each server by configuring each of transport queries appropriately.
(Hint:
http://dev.mysql.com/doc/refman/5.0/en/control-flow-functions.html#function_if)
Do the painful merging steps now and grow a sensible architecture that
can last for years. All kinds of dust will get rooted out in the
process. Optimistically your business will only need to add servers. An
obvious initial benefit is the simplified backup and monitoring
requirements.
Then as others have mentioned, the MySQL architecture can be replicated,
tuned, and accessed remotely with appropriate security settings. It can
even be replicated while live by setting it to read-only during initial
replication.
I believe efficiency in a replicated setting will still be very high.
Mail is very heavily read-oriented for DB's: settings/user migration/new
users don't change that much but there are 10^n lookups a day.
-Daniel
