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.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
