trustymail

trustymail copied to clipboard

e.g. cardinalhealth.com

[STARTTLS] In starttls_scan at /usr/local/lib/python3.6/dist-packages/trustymail-0.5.0.dev0-py3.6.egg/trustymail/trustymail.py:125: Connection unexpectedly closed

Seems like this might be anti-DoS? @jsf9k

@seanthegeek, I do see some "Connection unexpectedly closed" stuff when I scan, but I never really investigated it. How do you know this is related to Cisco Iron Port hardware?

Because I work for Cardinal Health :)

Ha! :relaxed:

Getting similar results here on our Ironport appliances:

[STARTTLS] In starttls_scan at /opt/pyenv/versions/3.6.1/lib/python3.6/site-packages/trustymail/trustymail.py:117: [Errno 111] Connection refused, [STARTTLS] In starttls_scan at /opt/pyenv/versions/3.6.1/lib/python3.6/site-packages/trustymail/trustymail.py:117: timed out, [STARTTLS] In starttls_scan at /opt/pyenv/versions/3.6.1/lib/python3.6/site-packages/trustymail/trustymail.py:117: [Errno 111] Connection refused, [STARTTLS] In starttls_scan at /opt/pyenv/versions/3.6.1/lib/python3.6/site-packages/trustymail/trustymail.py:117: timed out

I have a friendly volunteer with a Cisco IronPort device who has agreed to help troubleshoot. I'm going to be looking into this next week.

The IronPort device that I troubleshooted against worked fine.

In our case it turns out the issue was a misconfiguration in a particular Ironport Mail Flow Policy. All other MFPs were configured correctly, which is why my mxtoolbox.com and checktls.com tests were always successful (those senders fell under a different MFP which was set correctly). I haven't had a chance to go back through all the logs, but I assume that the IP address(es) that the DHS/NCATS tests are done from fell under a Sender Group tied to this MFP which is why our reports showed non-compliance.

@Y054i, thank you for following up! That's good information.