Jozsef Kadlecsik: > On Fri, 4 Sep 2009, Victor Duchovni wrote: > > > On Fri, Sep 04, 2009 at 12:57:09PM -0400, Wietse Venema wrote: > > > > > Jozsef Kadlecsik: > > > > On Fri, 4 Sep 2009, Wietse Venema wrote: > > > > > > > > > Jozsef Kadlecsik: > > > > > > The policyd can't generate log entries out of the blue - but why > > > > > > those > > > > > > messages were not logged then by postfix? > > > > > > > > > > What policyd messages are you referring to? > > > > > > > > Home-breed, but free to use by anyone: > > > > http://www.kfki.hu/cnc/projekt/postfilter/. > > > > > > Your logfiles are not available at that URL. > > > > > > What activity has policyd logged that has no Postfix logging equivalent? > > The activities are policy daemon queries and the result codes to Postfix. > The policy daemon logs just before returning the result code to Postfix, > into SQL, the following data: sender and recipient address, client name > and address, username (from SASL authentication), the restriction class > and policy of the policy daemon configuration which resulted the return > code to Postfix, the final action to Postfix (i.e. pass the message or > not), and a timestamp. > > What puzzles me that there's no even queue file generation logs from > Postfix.
Maybe your policyd records correspond to a different timezone than the Postfix records. To verify this, manually generate some transactions and check that policy server and Postfix agree on what happens. Maybe the Postfix SMTP server cannot reconnect to the syslog socket after syslog daemon restart, because the dameon does not listen on a socket under /var/spool/postfix. To verify this, rotate your logs (or whatever causes the syslog daemon to close the socket) in the middle of an SMTP session. And so on. Sofar you have not given any concrete information in this discussion, except for the URL of a program that you use for policy service. Unfortunately I do not have time for speculation about what might have happened. > > Note, policy daemons log envelopes not messages. If a client gives up > > before ".", it is perfectly normal to see lots of noise in policy service > > and SMTP server logs, with no corresponding deliveries. That was someone else. Wietse