Re: [exim] Help needed on hosts_require_tls

Just as information how I now accomplished what I wanted (bad hack):
1.) TLS transport won't be called by the main exim server but sent to a
smarthost.
2.) The smarthost does ONLY do TLS/SSL transport.
3.) Both are pointing to each other for relay_from_hosts

Ok. It does what I want. But basically I now have 2 exims running to
accomplish it. Not really elegant.



On Fri, 2005-05-27 at 17:10 +0100, Philip Hazel wrote:
> On Thu, 26 May 2005, Matthias Menk wrote:
>
> > remote_ssl_smtp:
> > driver = smtp
> > hosts_require_tls = *
> >
> > remote_smtp:
> > driver = smtp
>
> > The problem is that if someone sets the header to just allow delivery
> > over TLS and the corresponding host doesn't support TLS I get an
> > error "a TLS session is required for XXXX, but the server did not offer
> > TLS support". Which is fine so far. BUT as soon as someone then wants to
> > send a mail NOT using TLS, the host is still waiting for the next retry.
>
> The retry logic was invented a very long time ago, before TLS support
> was even contemplated. It is not flexible enough for this.
>
> > Question: Is there any way to configure the retry rule per transport?
>
> Unfortunately not.
>
> > Like having one retry rule for remote_ssl_smtp and one for remote_ssl?
>
> The retry rules currently set up a retry time for any connection to the
> host, whatever the transport, and whether or not TLS is to be used. They
> would have to be extended to set up a retry time for a (host,transport)
> combination or (host,with-tls?) combination instead. This isn't really a
> matter of changing the retry rules, it's a matter of changing how they
> are used.
>
> > Is there any way I can prevent the blocking of the destination without
> > setting it's retry time to zero?
>
> I don't think so, but others on this list may be more creative.
>
> I will note the existence of the problem.
>