No announcement yet.

deferral: TLS_unable_to_load_control/tlshosts//_

  • Filter
  • Time
  • Show
Clear All
new posts

  • deferral: TLS_unable_to_load_control/tlshosts//_

    Hi all,

    We seem to have an issue with delivery of email being deferred for a small number of email addresses.

    I'm unsure how long this has been going on for, but I suspect it may be since the qmail update on 2019-02-06.

    For each deferral, the send-current log states:

    delivery 418: deferral: TLS_unable_to_load_control/tlshosts//_

    The messages will then remain in the mail queue until they expire.

    A Google search for the above error message doesn't give anything useful. Has anyone else seen this before, or can hazard a guess as to the cause?

  • #2
    Hi sim79

    I have not seen that error before sorry

    What distro and IW version are you using

    Does tlshosts file exist

    Have you restarted qmail and if not resolved, have you restarted server

    It could be because TLSv1 has been stopped in latest version, and if host your connecting to requires TLSv1 then I guess it would fail (not on all email sending though, as there will be a mix of v1 v1.1 and v1.2)

    This is a quick fix though, as you need to create a file called TLSCiphers I think but I will look up the exact thread and post for you

    If all fails, I would open a support ticket with your license provider

    Many thanks



    • #3
      Hi sim79

      Sorry here’s the thread

      Many thanks


      Issues with Outlook 2010 Sending Mail following RHEL7 QMail update...


      • #4
        Hi John,

        Hope you are well, and thanks for responding.

        I might have resolved the issue (though time will tell).

        I updated /var/qmail/control/tlsserverciphers and /var/qmail/control/tlsclientciphers to the following and restarted SMTP:


        (This list of ciphers was obtained from

        Since I did that, no messages have been deferred and the obscure "TLS_unable_to_load_control/tlshosts//_" message no longer appears in the logs. Naturally, I'll need to monitor it for a longer period before I can say whether the issue is permanently fixed.

        However, I don't really understand *why* the above apparently fixed the issue and what other (if any) consequences changing the ciphers to those shown above would have, which makes me a little bit cautious.

        I'll update this thread in a day or two to let you know if the issue returns or not.


        • #5
          Hi sim79

          Excellent news and look forward to your update

          It could be the TfL’s protocol or looks more likely to tight ciphers. It looks like you relaxed them but RC4 ciphers I thought we’re not meant to be used any longer. Sorry maybe thinking of something else

          Many thanks



          • #6
            Seems to have held up fine over the weekend, so I guess we can file this under "resolved".