> Am 03.04.2017 um 16:47 schrieb Christian Rößner > <c...@roessner-network-solutions.com>: > >> >> 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.
And some more tests and information: I enabled the smptd_milter_maps again and triggered the problem again. After that I counted seconds. And while counting, I sent mails from remote each 5 seconds. I aborted after more than 6 minutes. Then I waited about 80 seconds and sent again and milters worked again. It seems the milters stay unused as long as there exists traffic. So the system only starts using the milters again, if there is some silence on the system. I think I have tested as good as I could. Hopefully you have enough information now. Christian -- Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345
smime.p7s
Description: S/MIME cryptographic signature
