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, [EMAIL PROTECTED] Cambridge, England. Phone: +44 1223 334714. Get the Exim 4 book: http://www.uit.co.uk/exim-book -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
