J. Thomsen:
[ Charset ISO-8859-1 converted... ]
> I have checked the possibilities below, and none of them appear applicable to
> this case.
> I have been running with cleanup -v for several days as well as removing the
> amavis spam check loop
> from the received emails.
> The first few days nothing happened, men now we are back to the intermittent
> behaviour.
> The Fedora 31 server has just been been fully updated and rebooted yesterday,
> but it did not appear
> connected to the problem.
>
> I have sent an extraction of the log and email header to Wietse privately due
> to size and privacy
> issues.
Does your server have ECC memory? I can't see that rom the logs.
It would save me an immense amount of time if you could also send
the same logging a for 'good' example.
Can you also send output from:
postconf -nf
postconf -Mf
Because there is all kinds of other stuff going on with SRS and bcc
maps. To make sense of the logs, it is helpful to know why something
is logged.
Wietse
>
> /J?rgen Thomsen
>
>
>
> On Tue, 28 Apr 2020 12:32:47 -0400 (EDT),Wietse Venema <wie...@porcupine.org>
> wrote:
>
> >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
>
