[Dovecot] SASL auth and proxy

[Ed W]

  On 01/10/2010 18:33, mailing at securitylabs.it wrote:
>  Il 01/10/2010 18:55, Ed W ha scritto:
>>  On 01/10/2010 17:23, Timo Sirainen wrote:
>>
>> I'm quite possibly missing the point, but you might restructure your 
>> application to have:
>>
>> - one mysql db (replicated if necessary for robustness) with ALL 
>> customer data in it
>> - pool of postfix servers which auth to the remote db (they can be 
>> persuaded to cache auth results if you wish)
>>
>
> You are completely right, I simply don't like the idea to have one 
> single big db with user data and all troubles that can happen 
> (performance, replication configuration, data corruption...)

I think if you consider this for a bit longer you will see that you have 
near exactly the same issues in the way you have done things?  eg if a 
node fails then you have lost a chunk of your data, hence backups need 
to be done for each machine (raising complexity), performance is limited 
per machine, you have no way to fail over to another db (say when doing 
upgrades)

If instead you start with a single aggregated DB then you have a single 
master source to backup and protect.  Then you can distribute that 
master version as far and wide as you wish, eg if you want to you can 
simply backup and restore it onto each server every hour if you want.  
Or use one way replication to get it onto the slaves.. Or export it to 
some flat file format and have postfix turn that into a map or whatever...

However, my personal favourite would just be a single master DB and 
appropriate secondary for resiliance.  Lookups should likely be quite 
cheap compared with the load on your backend servers and a single DB 
server should likely handle a very large incoming mail load?

> I think - for now - I will try authentication with multiple database 
> with Dovecot, by now I only have 4 internal servers with MySQL, so 
> performance I hope will not be a problem considering that Dovecot 
> cache the results.

Whatever works, but it seems like you might want to take a step back and 
look at the complete system and check it's still sane?  Seems like you 
are adding a chunk of complexity in order to have what you believe is a 
simpler system elsewhere?  Why not draw out the complete system of 
interactions doing it with various permutations of master db, split 
master/slave, master with slave copy per server and master with exported 
maps, plus the current solution - see which one is really the simplest 
overall?  My guess would be something like single master/slave turns out 
to be the winner?

Good luck!

Ed W