Re: It is possible for Postfix logging to bypass journald?
On 1/9/2019 5:55 PM, Robert L Mathews wrote: On 1/9/19 4:05 PM, Curtis wrote: We recently switched our Postfix mail servers to Ubuntu Server 18, which uses journald for logging. Since we have monitoring systems that parse /var/log/maillog, we enabled rsyslog with imuxsock so we still can parse the log like we did before journald. But, it's unreliable. Our monitoring systems are reporting failed deliveries of messages because of missing log lines in /var/log/maillog. We had this problem. It was fixed by putting this in /etc/systemd/journald.conf: # allow for busy mail logs; allows 1000 per second RateLimitInterval=5s RateLimitBurst=5000 And/or by putting this into /etc/rsyslog.conf: $SystemLogRateLimitInterval 0 (The latter is supposedly no longer necessary, but it used to be, and does not appear to be harmful.) Thanks for your input. Unfortunately, even after playing with these settings, we see no improvement. When you run "systemctl status systemd-journald" do you see any messages like this? Jan 28 18:16:01 [somehost] systemd-journald[25662]: Forwarding to syslog missed 6 messages. If others are not seeing this issue, then I am wondering if it has something to do our setup being inside of an LXC container. For now, we ended up fixing our log parsing script to make journalctl calls so that no lines are missed. Overall, journald seems like a huge downgrade for us... I get the impression it was designed for desktop users, not for servers. That said, I noticed in another thread that Wietse announced that Postfix has an option to log to a file now... ftp://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-3.4-20190127-nonprod-logger.RELEASE_NOTES We're not ready to upgrade right now, but I'm looking forward to trying this option out in the future.
Re: smtp_tls_security_level = dane but have encrypt as fallback
Wietse Venema: > Viktor Dukhovni: > > > On Jan 28, 2019, at 7:59 AM, Stefan Bauer wrote: > > > > > > But in cases where remote sites do not have published key material, the > > > fallback is may with dane, which is a step back in terms of security and > > > not wanted. > > > > > > How can we specify: > > > > > > 1, Always use at least encrypt > > > 2, When TLSA-records are found and valid, use only this to encrypt > > > 3, When no TLSA-records are found or the ones found can not be used, fall > > > back to encrypt, if not possible, fail. > > > > That requires new code. Sorry about that. The issue is in part > > whether a point-fix would be appropriate with a fallback level > > when DANE TLSA records are not found, or whether a more general > > mechanism should be implemented that can specify more complex > > policy: > > Yes, please. something like a minimum level, like we discussed > before I switched jobs (for example, a minimum of 'may', but try > stronger if available). Or a sequence of acceptable levels. > Wietse > > > In Postfix, when we do something, we tend to skip half measures > > and do it "right", i.e. in a general way. So the question is > > whether "DANE or else encrypt" is the right design or not. > > > > One can certainly imagine specifying a "minimum" security > > level, and then fallback would never use anything weaker. > > That would look like: > > > > * dane with hard failure > > * dane with warning and fallback to floor level on failure > > and silent use of floor level when TLSA not present. > > * verify/secure with hard failure > > * verify/secure with warning fallback to floor level on failure > > > > and would simpler than a more complex chain of levels with > > "on-error" and "not-found" branches. Essentially a little > > DSL for a recursive state-machine: > > > > tls_state_machine policy = do > >case level policy of > > dane > >-- Pre-connection policy fallback: > >| not-published <- tlsa > > -> tls_state_machine encrypt > >| unusable <- tlsa > > -> tls_state_machine encrypt > >-- Post-connection policy fallback: > >| auth-failure > > -> do > >warning > >if dnssec-ok > >then tls_state_machine verify match=hostname) > >else tls_state_machine (verify nexthop:dot-nexthop) > >| tls-handshake-failure > > -> tempfail > >| pre-data-lost-connection -- TLS interop issue? > > -> tempfail > >| success -- implicit > > -> deliver > > verify > >| auth-failure > > -> ... > >| tls-handshake-failure > > -> ... > >| success -- implicit > > -> deliver > > ... > > > > the DSL needs to be usable, not overly complex, and yet cover > > the plausibly useful cases. It has not yet been designed... > > > > -- > > Viktor. > > > > >
Re: smtp_tls_security_level = dane but have encrypt as fallback
Viktor Dukhovni: > > On Jan 28, 2019, at 7:59 AM, Stefan Bauer wrote: > > > > But in cases where remote sites do not have published key material, the > > fallback is may with dane, which is a step back in terms of security and > > not wanted. > > > > How can we specify: > > > > 1, Always use at least encrypt > > 2, When TLSA-records are found and valid, use only this to encrypt > > 3, When no TLSA-records are found or the ones found can not be used, fall > > back to encrypt, if not possible, fail. > > That requires new code. Sorry about that. The issue is in part > whether a point-fix would be appropriate with a fallback level > when DANE TLSA records are not found, or whether a more general > mechanism should be implemented that can specify more complex > policy: Yes, please. something like a minimum level, like we discussed before I switched jobs (for example, a minimum of 'may', but try stronger if available). Wietse > In Postfix, when we do something, we tend to skip half measures > and do it "right", i.e. in a general way. So the question is > whether "DANE or else encrypt" is the right design or not. > > One can certainly imagine specifying a "minimum" security > level, and then fallback would never use anything weaker. > That would look like: > > * dane with hard failure > * dane with warning and fallback to floor level on failure > and silent use of floor level when TLSA not present. > * verify/secure with hard failure > * verify/secure with warning fallback to floor level on failure > > and would simpler than a more complex chain of levels with > "on-error" and "not-found" branches. Essentially a little > DSL for a recursive state-machine: > > tls_state_machine policy = do >case level policy of > dane >-- Pre-connection policy fallback: >| not-published <- tlsa > -> tls_state_machine encrypt >| unusable <- tlsa > -> tls_state_machine encrypt >-- Post-connection policy fallback: >| auth-failure > -> do >warning > if dnssec-ok >then tls_state_machine verify match=hostname) >else tls_state_machine (verify nexthop:dot-nexthop) >| tls-handshake-failure > -> tempfail >| pre-data-lost-connection -- TLS interop issue? > -> tempfail >| success -- implicit > -> deliver > verify >| auth-failure > -> ... >| tls-handshake-failure > -> ... >| success -- implicit > -> deliver > ... > > the DSL needs to be usable, not overly complex, and yet cover > the plausibly useful cases. It has not yet been designed... > > -- > Viktor. > >
Re: smtp_tls_security_level = dane but have encrypt as fallback
> On Jan 28, 2019, at 7:59 AM, Stefan Bauer wrote: > > But in cases where remote sites do not have published key material, the > fallback is may with dane, which is a step back in terms of security and not > wanted. > > How can we specify: > > 1, Always use at least encrypt > 2, When TLSA-records are found and valid, use only this to encrypt > 3, When no TLSA-records are found or the ones found can not be used, fall > back to encrypt, if not possible, fail. That requires new code. Sorry about that. The issue is in part whether a point-fix would be appropriate with a fallback level when DANE TLSA records are not found, or whether a more general mechanism should be implemented that can specify more complex policy: * dane or else encrypt or else fail * dane or else verify [match=...] or else fail * dane or warn and delivery anyway * ... In Postfix, when we do something, we tend to skip half measures and do it "right", i.e. in a general way. So the question is whether "DANE or else encrypt" is the right design or not. One can certainly imagine specifying a "minimum" security level, and then fallback would never use anything weaker. That would look like: * dane with hard failure * dane with warning and fallback to floor level on failure and silent use of floor level when TLSA not present. * verify/secure with hard failure * verify/secure with warning fallback to floor level on failure and would simpler than a more complex chain of levels with "on-error" and "not-found" branches. Essentially a little DSL for a recursive state-machine: tls_state_machine policy = do case level policy of dane -- Pre-connection policy fallback: | not-published <- tlsa -> tls_state_machine encrypt | unusable <- tlsa -> tls_state_machine encrypt -- Post-connection policy fallback: | auth-failure -> do warning if dnssec-ok then tls_state_machine verify match=hostname) else tls_state_machine (verify nexthop:dot-nexthop) | tls-handshake-failure -> tempfail | pre-data-lost-connection -- TLS interop issue? -> tempfail | success -- implicit -> deliver verify | auth-failure -> ... | tls-handshake-failure -> ... | success -- implicit -> deliver ... the DSL needs to be usable, not overly complex, and yet cover the plausibly useful cases. It has not yet been designed... -- Viktor.
smtp_tls_security_level = dane but have encrypt as fallback
Hi, we would like to go the next step, enable smtp_tls_security_level = dane. Currently we have encrypt site-wide. But in cases where remote sites do not have published key material, the fallback is may with dane, which is a step back in terms of security and not wanted. How can we specify: 1, Always use at least encrypt 2, When TLSA-records are found and valid, use only this to encrypt 3, When no TLSA-records are found or the ones found can not be used, fall back to encrypt, if not possible, fail. *Stefan*
