Re: [exim] Mail Implementation Design (Update)

Graeme Fowler wrote:
> Hi
>
> On Tue, 2006-08-29 at 07:29 +0800, W B Hacker wrote:
> <snip>
>
>>But even a very active ISP ordinarily has a 'rate of change' that is
>>insignificantly low compared to, for example, a Point-of-Sale / inventory
>>control system, theater ticket sales, or banking.
>
>
> I worked for a number of years for a recently acquisitive UK ISP (which
> in fact swallowed the hosting company I was part of). Granted, the ISP
> side of the business used a RDBMS exporting to file-based DBs; their
> rate of change was relatively low.
>
> <snip>
>
>>But I still do not recommend it for general smtp use.
>
>
> The hosting side had a massive rate of change, and the
> keep-in-db-and-export-via-cron approach had started to cause us
> problems, so we moved to a replicated SQL backend approach whereby
> changes were reflected all but instantaneously. It worked perfectly, for
> many hundreds of thousand addresses across many tens of thousands of
> domains.
>
> I think, at this point, I will accept the relative merits of both
> systems but agree to disagree with Bill :)
>
> Graeme
>
>

Not that we are required to agree, but don't think we actually disagree!

'Relative merits' is indeed the key.

You've cited - as a good example - the case of an entity with an unusually high
rate-of-change. Probably one in ten thousand, if not one in one-hundred
thousand MTA operators are that active w/r rate-of-change (not basic traffic).

Note also that even then, replication of the SQL DB was ultimately needed.
This is a non-trivial task for anyone not experienced with it.

For the more common case, just about anything is fast enough to keep up with
rate-of-change, so 'life cycle cost' - even for a personal server, needs to also
consider learning curve, maintenance and admin workload.

Admin'ing an RDBMS and its UI's is extra workload, and a different set of skills
that must be covered. SME's don't necessarily have those resources.

Having made the devel and testing investment (largely for MTA-unrelated reasons)
we can 'cheaply' use PostgreSQL even on very lightly loaded servers, and are
pleased to offer such advice as we can to others who go that route.

But neither our experience, approach, record structures, nor even SQL queries
are generally useful or even readily 'conveyable' to others. 'Overly'
customized, if you will.

So I still hold that simpler means and simpler DB's (BSD, GDB, CDB) are safer,
easier, less work for perhaps 95% + of the community - even for many
medium/large ISP's.

That's why I don't 'recommend' it.

Not because it doesn't work well.

But because it requires a great deal of work that is 'avoidable' and of
questionable value for the majority.

Best,


Bill