From: Noel Jones on
On 5/19/2010 3:10 PM, Phil Howard wrote:
>
> But it sounds like what I need is something to rewrite envelope
> recipient address at SMTPD RCPT TO time. Like maybe (this does not
> exist) smtpd_recipient_map and (also does not exist)
> smtpd_recipient_domain_map ?? What I would envision this doing is
> applying this rewrite before checking to see if the user really exists,
> then using that rewritten address in all further checks that get done
> during the SMTPD session, all while the remote SMTP client waits for a
> response (it's already waiting for all those restriction checks).


Sounds as if you need to generate static files with a script.
Don't worry about the number of entries; hash: tables scale
well to hundreds of thousand entries, or use cdb: files for
fast performance up to millions of entries. (cdb: works great
for smaller files too.)

-- Noel Jones

From: Phil Howard on
On Wed, May 19, 2010 at 17:46, Noel Jones <njones(a)megan.vbhcs.org> wrote:

> Sounds as if you need to generate static files with a script. Don't worry
> about the number of entries; hash: tables scale well to hundreds of thousand
> entries, or use cdb: files for fast performance up to millions of entries.
> (cdb: works great for smaller files too.)
>

Sure does.

Over on the Dovecot side of things, I have the passdb/userdb files split out
by domain name. This allows me to manage restricted access. That means I
can permit a less-technical administrator to access only certain domains.
If they cause a problem, or some other problem happens when they are
updating, there is less exposure to failure (and less work the update
regression tests I could add to that have to do).

So it looks like I'll need to regenerate the virtual_alias_map file every
time even users are updated (much more frequent then how often domains are
updated), and run the mail system tests more often. I can, of course,
generate them from those Dovecot passdb files.