J. Thomsen:
[ Charset ISO-8859-1 converted... ]
> On Tue, 28 Apr 2020 10:21:46 -0400 (EDT),Wietse Venema <wie...@porcupine.org>
> wrote:
>
>
> >That brings the question, how do you maintain these files? One way
> >to temporarily 'lose' aliases is if you manage the files with scp
> >which overwrites, instead of using rsync which creates a copy under
> >a temporary name, and renames the copy to the permanent name after
> >the file is complete.
> >
>
> The file /etc/postfix/virtual and virtual_regexp are rather static and
> maintained manually.
>
> -rw-rw-r--. 1 root postfix 6227 2019-06-22 12:51 virtual_regexp
> -rw-rw-r--. 1 root postfix 20528 2020-02-17 20:02 virtual
> -rw-r-----. 1 root postfix 53248 2020-04-28 01:05 virtual.db
>
> The example domains (currently two observed with problems) are all located in
> the 'virtual' file
>
> postmap is used once every night at 1:05 AM to generate the virtual.db file
> including some addresses
> from a database.
>
> /usr/sbin/postmap /etc/postfix/virtual
> /usr/sbin/postmap -i hash:/etc/postfix/virtual </etc/postfix/mailinglists.txt
>
> There is thus considerable time between regenerating the database and the
> wrong delivery
> and at 2020-04-25T07:20:25.630342+02 one hour before one of the incorrect
> deliveries a correct
> delivery was made. During this hour no change was made to the virtual.db file.
Your logs show that within seconds from each other, an smtpd process
finds the virtual alias expansion while a cleanup process does not.
Possibilities:
- The cleanup daemon did not look up the virtual alias expansion.
That happens when some limit is reached, but Postfix would have
logged a warning message ("unreasonable xxx map nesting", or
"unreasonable xxx map expansion size"). The variables are
virtual_alias_expansion_limit and virtual_alias_recursion_limit.
This can happen when you have a large mailing list a in virtual
alias.
- The cleanup daemon did look up the virtual alias expansion, but
the Berkeley DB library linked into the cleanup daemon did not
find one, even if the Berkeley DB library linked into the smtpd
process did find an alias expansion a second ago.
You could find out with 'cleanup -v'.
- Something changed the on-disk memory image of Postfix or (Berkeley
DB) library code. You would have seen sporadic process crashes.
- Your mail server hardware suffers from bit flips (no ECC memory
error correction?) that change data or code. You would have seen
sporadic process crashes.
There are no known memory corruption bugs in Postfix. Surely a
missing aliias expansion would have been noticed by other people.
Wietse
