From: Eray Aslan on
On 12.02.2010 14:47, Richard Cooper wrote:
> On 12 Feb 2010, at 12:12, Eray Aslan wrote:
>> On 12.02.2010 13:25, Richard Cooper wrote:
>>> Feb 12 00:41:24 mail1 postfix/smtpd[24782]: NOQUEUE: reject: RCPT from unknown[]: 550 5.1.1 <recipient(a)>: Recipient address rejected: User unknown in virtual alias table; from=<sender(a)> to=< recipient(a) > proto=SMTP helo=<>
>>> This is a very intermittent and short lived error. Emails to recipient(a) were working before the error and start working again a few seconds after it.
> I'm not sure that apples to my case. That page says "If the update fails in the middle [because the disk is full or because something else happens] then you have no usable database, and Postfix will stop working". In my case the update completes without error, correctly writes virtual_aliases.db and postfix continues working. The only visible error is that during the update Postfix "forgets" some of the lookup table for a short period of time.

You might also want to try CDB. Its updates are atomic. Recommended
instead of Berkeley DB.


From: Victor Duchovni on
On Fri, Feb 12, 2010 at 11:25:05AM +0000, Richard Cooper wrote:

> Based on my debugging it seems that this error is related to me running postmap to rebuild the virtual_alias table This is despite the fact that the recipient(a) address is correctly configured in both the old and new virtual_aliases. Here a log of what was happening at the same time as the above error:

The original Berkeley DB (version 1.8x) which was available at the time
that "hash" and "btree" table support were added to Postfix was a simple
indexed file format and library. In that version of Berkeley DB there
were no memory mapped page pools, transaction logs, ...

If are using Berkeley DB on a BSD system with version 1.8x, then postmap
is race-free due to the Postfix locking protocol for Berkeley DB files.

Newer much more feature-full versions of Berkeley DB are no longer race-free
with the Postfix locking protocol, and you need to atomically create/rename
a newly built table.

I don't use Berkeley DB for multi-reader tables, I strongly recommend
CDB for that purpose. I only use Berkeley DB for single reader/writer
tables such as TLS session caches, address verification caches, ...


P.S. Morgan Stanley is looking for a New York City based, Senior Unix
system/email administrator to architect and sustain our perimeter email
environment. If you are interested, please drop me a note.