Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 26 subscribers
  • Views 9981 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to resolve SSL_connect() failures

Chris Shipley

I have some emails that are not being sent out when the system is in MTA mode and is the handler for outbound email.  In my awarrenmta.log file, I see some issues with this particular email around SSL_connect().  If the email has 17 recipients, it will send to some of them fine, then say it will fail on the 10th recipient.  It has an SSL_connect() failure here.  However, instead of moving on to the next 6 recipients, it simply stalls at this point, sends it into a retry queue, and moves onto the next message to processing.  Eventually this will fail completely and return a "failure to deliver" after 7 days back to the sender.

First, how do I get the log to keep more than 4 days?  That would be really helpful.  It happened on Sep 29 and my log stops at Sep 30.  Can I dump all the logs somewhere to keep them longer?  Is there a configuration I'm missing for this?

This particular email I'm researching appears to fail consistently at the primary MX record.for the domain its trying to deliver to.  It doesn't try any of the other priority records - can I get the system to skip the primary and try the last?

Here is part of the cleaned log.  I masked the IPs, domains, and email addresses.  I could not get you the parts that show the successful deliveries this time because that was on Sep 29 and the log doesn't go back that far.

The log also specifies that this is retry number 1, it is absolutely not the first retry.

--------------

INF Oct 02 09:44:39 [0xc00007ac]: Resolved A record for domain 'xxx.xxx.xxx': 'x.x.x.x'
INF Oct 02 09:44:42 [0xc00007ac]: Resolved A record for domain 'yyy.yyy.yyy': 'y.y.y.y'
INF Oct 02 09:44:45 [0xc00007ac]: Resolved A record for domain 'zzz.zzz.zzz': 'z.z.z.z'
MSG Oct 02 09:44:45 [0xc00007ac]: Mail Transaction Started from localIP:19126 to x.x.x.x:25 (fdid:381)
MSG Oct 02 09:44:45 [0xc00007ac]: Connecting to server ...
ERR Oct 02 09:44:45 [0xc00007ac]: SSL_connect() failed; tunnelling..
ERR Oct 02 09:44:45 [0xc00007ac]: tunnel_READ: read error: Bad file descriptor
INF Oct 02 09:46:47 [T___WORKER]: check_mail_node: node with UID '0xc00007ac' is frozen(timediff:259200)
INF Oct 02 09:46:47 [0xc00007ac]: Processing session '200026a2'
INF Oct 02 09:46:47 [0xc00007ac]: forwarder_loop() Forwarder session inited. Retry #1
INF Oct 02 09:46:47 [0xc00007ac]: message id 'c00007ac-1506692807' for current mail
INF Oct 02 09:46:47 [T___WORKER]: verify_cnode_state: node with UID '0xc00007ac' is frozen



This thread was automatically locked due to age.
  • 0

    Hi Chris,

    It seems that the SSL handshake is getting failed, could you enable debug for awarrenmta and DM me the logs. To start the debugging, execute this command in the Advanced Console.

    service <service name>:start/restart/stop/debug –ds nosync

    Thanks

  • 0 in reply to sachingurung

    sachingurung said:

    Hi Chris,

    It seems that the SSL handshake is getting failed, could you enable debug for awarrenmta and DM me the logs. To start the debugging, execute this command in the Advanced Console.

    service <service name>:start/restart/stop/debug –ds nosync

    Thanks

     

    Like so?

    XG125w_XN02_SFOS 16.05.7 MR-7# service awarrenmta:debug -ds nosync
    200 OK
    XG125w_XN02_SFOS 16.05.7 MR-7#

  • 0 in reply to Chris Shipley

    I also ran:

    service awarrenmta:stop -s nosync

    service awarrenmta:start -s nosync

  • 0 in reply to Chris Shipley

    Chris,

    something is fixed on MR8, did you upgrade already?

    Thanks

  • 0 in reply to lferrara

    Yes, I upgraded last night and the errors are still being thrown, specifically for the same x.x.x.x server above.  The OpenSSL update for MR8 didn't help this issue.

  • +1 in reply to lferrara

    OK I finally worked out my own solution while I was on hold waiting for Sophos Support to read my ticket and all the logs I sent.  I simply added x.x.x.x, y.y.y.y, and z.z.z.z to the TLS skip list.  While I'd prefer not to do that because I'd like to encrypt email wherever possible opportunistically, this particular client of mine uses SPX Encryption which doesn't rely on TLS encryption, so I'm not particularly worried about confidential data traversing the Internet.  Sophos Support helped me check the logs and yes, my log jam is over.  Now I'm going to pour through all the logs to find others that might be throwing the same errors.

    BTW - if you need to look past the data that's in awarrenmta.log - simply look in awarrenmta.log.0 :)

     

    Do add them to the domain skip list, have to first add them as FQDN Host entries in the Hosts and Services area, then go to Email \ General and add them to the Skip TLS Negotiation Hosts/Nets area of the SMTP TLS Configuration