Muhammad Asif
asked on
Verify the connection is made on SMTP Over TLS
I have mentioned the email header below. Can someone please confirm that email received by email security gateway " esg1.abc.com" from sl.ab-bev.com [104.168.167.27, is through connecting a connection on SMTP over TLS/
Moreover what is mean by verify=NO in the below header.
Moreover what is mean
from sl.ab-bev.com (sl.ab-bev.com [104.168.167.27]) by esg1.abc.com with ESMTP id iYM5xoyaE6GTt8HE (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GC M-SHA384 bits=256 verify=NO)
Moreover what is mean by verify=NO in the below header.
Moreover what is mean
from sl.ab-bev.com (sl.ab-bev.com [104.168.167.27]) by esg1.abc.com with ESMTP id iYM5xoyaE6GTt8HE (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GC
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Re-reading your question, what you're asking is a bit vague, as it's unclear if you're talking about authenticated submission or promiscuous submission.
1) For authenticated, port 587 submission, this will always require an authenticated login. If the protocol type is forced to TLS, then the connection will always be TLS... at the protocol level (like TLSv1.2) setting of the MTA being used.
2) For promiscuous TLS submission, see my previous comment.
1) For authenticated, port 587 submission, this will always require an authenticated login. If the protocol type is forced to TLS, then the connection will always be TLS... at the protocol level (like TLSv1.2) setting of the MTA being used.
2) For promiscuous TLS submission, see my previous comment.
ASKER
I have found the answer on Technet.
Yes, its using TLS.
In this context, Verify typically means the authenticity of the cert and its chain wasnt verified, because it doesnt need to be, all the matters is that a cert exists. This is common with Opportunistic TLS
Yes, its using TLS.
In this context, Verify typically means the authenticity of the cert and its chain wasnt verified, because it doesnt need to be, all the matters is that a cert exists. This is common with Opportunistic TLS
Tip: As I recall, last time I hit this type of problem I just generated a https://LetsEncrypt.org TLS cert for use with Opportunistic TLS.
That's all that can be determined, from the outside.
Looking at logs will tell you the details of a connection pair.