On Fri, Feb 28, 2014 at 09:16:56AM +0100, Peer Heinlein wrote:
> > Fifth option (best): short queue life time, to that Postfix does
> > not give up after the first MX host failure...
>
> ...but to that Postfix will start having Problems with Greylistung and
> that makes Postfix bouncing mails even in case of REAL temporarily
> failures of the destination server.
Why is notification of delay due to lack of transport security not
acceptable, while delay for other reasons (remote system down and
never coming back, address typo results in mail adddressed to parked
domain, ...) is acceptable?
There are lots of reasons for mail to linger in the queue and
eventually bounce. Implementing delay notices is the right way to
let the sender know that their message may not get through.
If you set the delay notice time, or if you prefer maximum queue
lifetime, sufficiently high, you will rarely run into greylisting
related problems.
minimal_backoff_time = 225s
maximal_backoff_time = 1h
delay_warning_time = 2h
# or instead:
# maximal_queue_lifetime = 4h
It is a mistake to apply a mandatory transport encryption policy
to destinations that don't implement TLS. What is the user supposed
to do when the mail bounces or they get a delay notice?
You probably need a log watcher that detects mail to new TLS-capable
domains, and applies the right mandatory security settings when
opportunistic TLS is consistently successful for some time.
You likewise need to revert back to opportunistic TLS when mandatory
TLS fails consistently to previously reachable domains, this could
involve a notification system to a human operator who determines
why TLS is failing (what changed) and whether to relax the policy.
Ideally, domains losing TLS capability will be a relatively infrequent
event.
--
Viktor.
