> Am 03.04.2017 um 16:07 schrieb Christian Rößner > <c...@roessner-network-solutions.com>: > >> >> Am 03.04.2017 um 15:43 schrieb Wietse Venema <wie...@porcupine.org>: >> >> Wietse Venema: >>>> After I ran this (in fact I was too slow ;-) ), I sent a mail from >>>> external MTA mail.sys4.de and this mail did not run through any >>>> of the milters. It is much more worse than I thought, because each >>>> mail after that "mail loop" above was not scanned by any milters >>>> anymore! I also stopped postfix and started it again and still no >>>> milters got connected when sending test mails from external MTA. >>> >>> If this problem persists after stopping and starting Postfix, then >>> you have proved that either it is not a Postfix problem or that your >>> measurement procedure is in error. >>> >>> There is no POSTFIX Milter-related state that persists across >>> restarts, but there may be such state elsewhere: rate-limiting >>> policy servers, state in the kernel's networking stack, clients >>> deciding to deliver mail elsewhere, ... >> >> Especially relevant for logging is system-effing-d log rate limiting, >> which reportedly has lower thresholds than rsyslog log rate limiting, >> meaning that systemd throws away events before rsyslogd can log them. >> This mechanism persists across Postfix restarts. > > I am not using systemd. (Gentoo Open-RC) > > Also both milters add headers, which are missing in the received test mails. > Which indicates that the milters did not run. > > Also this is a very low traffic server. After doing the 100 mail loop, I sent > three or four test mail with 30 second delays. No other mails passed the > system. So no logger would suppress this. > > I alo found out that sending from submission does not solve the problem. I > repeated my test. It seems there exists some kind of timeout somewhere that > is postfix stop/start aware. After that time period milters start working > again. I only can guess: 2-5 minutes later milter begin working again. > > I only have the Dovecot-Quota policy service (non else) and I have no other > services that would cache things. Only two milters (vrfydmn and a anti-spam > milter as shown in my first mail).
I did the opposite test now and disabled the smtpd_milter_maps parameter. After that I did the same tests again and milters work always. So enabling this map starts producing the described issue. Christian -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
smime.p7s
Description: S/MIME cryptographic signature
