So, if you are doing synchronous multi-master you will also need to do explicit failover (in this case, not from server A to server B, but from server A/B to only server B): otherwise, a partition between the servers would be catastrophic to your data integrity (as there would be no way for the servers to know whether they should start accepting data that might be different from its buddy, as both think the other is offline).
Once you start thinking in terms of multiple servers (whether it be based on replication or partitioning) you have to start thinking about these kinds of complex corner case issues, as you have moved from working with "a server" to "a distributed system", with all of the associated theoretical limits (such as CAP).
You're right, although the MySQL binary log used for replication handles this fairly gracefully for reasonable outage periods. Collisions are still possible after a resync, but it tries pretty hard to resolve them using timestamps on the transactions.
I'm working on some software to automatically manage outages, deploying new server instances, re-syncing databases, etc., but that's quite a few steps away from where we're at right now. For near-term purposes, anything that could do as good of a job at multi-master replication as MySQL can would be just fine.
I can then only wish you luck in your attempt to take an off-the-shelf system (dbmail) that was designed to be used with an ACID database and plop it on top of what is now an only eventually consistent data store without first rewriting it to tolerate those semantics ;P.
Once you start thinking in terms of multiple servers (whether it be based on replication or partitioning) you have to start thinking about these kinds of complex corner case issues, as you have moved from working with "a server" to "a distributed system", with all of the associated theoretical limits (such as CAP).