I've done something very similar; there seem to be a couple of different approaches.
First off, you could use
recipient_bcc_maps to generate an additional address for incoming mail to that domain. This could be, for example, a table to say if the email has a recipient
firstname.lastname@example.org it should be bcc'd to
archive, which is then aliased to a file/maildir.
Alternatively, the way I've done it locally is by having entries like this in my "virtual" (
email@example.com firstname.lastname@example.org, offline-comms
and then in my "vmailbox" (
I then have
virtual_mailbox_base set up to be the base directory of my mail archives. The entry in the "virtual" table splits the incoming email to
email@example.com into a delivery to
offline-comms (which feeds the email to the application servers) and also to itself, so it gets looked up in "vmailbox" as well. The "vmailbox" entry tells the
virtual(8) delivery agent to save the email into a Maildir called "supply" under
Granted, this means having to update two files to add a new recipient. But if you were generating these files from a database, or using a database lookup, then that wouldn't really be a problem.
Note that I've aliased mail to
offline-comms to get it piped to the application server. This might not work for you, depending on how you've integrated DBMail. Another way to do it is to alias incoming email into a special domain that is for archiving:
firstname.lastname@example.org email@example.com, firstname.lastname@example.org
Then have the virtual domain
emails.example.com fed to your dbmail transport (e.g. using the
transports map to simply map
dbmail-lmtp:), and the
archive.example.com domain delivered using the
virtual transport to get saved to local mail.
Hope that helps!