mouss wrote:
rihad wrote:
rihad wrote:
What's going on? How is Postfix supposed to learn the whole
mydestination list if there's no such SQL template? I thought Postfix
would deduce a "select k from mydestination" query or similar on its
own. The manpage is ambiguous in this regard.
Answering to myself: OK, Postfix seems to wish to learn mydestination
"lazily", that is, it issues SQL queries only when receiving mail to
decide what to do with it.
of course! postfix will not load a mysql table in memory. if it were so,
then this would be useless: you could simply dump the sql tables before
into a file ;-p
Sure enough, but I'm speaking of a single snapshotted value through a
single request ("transaction"). Besides its being more efficient,
caching makes for more consistent results: you wouldn't want Postfix to
first consider a delivery local (mydestination), only to suddenly change
its opinion and consider it remote. I hope it wouldn't dump core in that
case :)
Lack of the way to choose to cache query results is pretty surprising.
Moreover, a simple telnet to SMTP port and then issuing RCPT TO:
[EMAIL PROTECTED] results in _4_ successive queries every time!
run
# postconf | egrep "(mydestination|parent_dom)"
you'll need to read about lookup order and about mysql table.
consider using proxymap (proxy:mysql:....)
Oh, now you see what I meant by caching. Thanks, I haven't read about
proxymap yet, and I will.
Anyway, it is generally not recommended to put domain lists
(mydestination, relay_domains, virtual_*_domains), transport and
relocated maps in a remote backend.
If MySQL is local it's just a matter of convenience. I agree that remote
MySQL brings in yet another point of failure.
