LabVIEW
E-Mail lost on Exchange Server using TLS
Solved!
Hi Everybody,
I tried to send an E-mail via Labview2013 using TLS to an Exchange Server (tested internal and external Office 365). The Server CA check is Off!
Unfortunately the E-mail seems not going through, but I get no Error!
Does anyone have an idea what this could be?
Best regards!
I have tried to test it using the two possibilities I have found in Labview.
@Lab_CD wrote:
I tried to record the packets on the interface and it seems that the client and the server are exchanging information via TLSv1.2.
How can I identify the "mail received"?
Unfortunately I cannot monitor the mail delivery on the server.
I tried with Office365 and Labview showed the same behaviour (no error, no email).
Has anyone succeeded to send a mail via Office365?
To me, this sounds like a server-side issue. And I'm pretty sure somebody somewhere is able to send email through Office365. 😉
Some email clients have a debug mode where it can log communications between client and server. Maybe that might help. Sorry, that's all I have.
@Lab_CD wrote:
Could it be a LabView-issue?
Well, depends what you consider a LabVIEW issue. Email has been getting very complicated in comparison to the 80ies and 90ies of last century, with not only encryption being required nowadays but often an explicit login mechanism to authenticate yourself as being allowed to send mail through the server. Without that anyone can find open mail servers and abuse them for spam campaigns and similar.
The problem here is that there is not one single authentication method for this, as everybody had his own ideas about this. The original SMTP protocol does not provide any authentication method since the problem of spam abuse was pretty much not imaginable by the creators of email. POP3 however and other later protocols to retrieve emails had such a mechanism as the creators did not want anyone to be able to read someone elses email Inbox. So the first approach of some authentication was that a client had to first login into his POP3 mailbox and after that he could create a connection to the SMTP server which saw that the request came from the same client as the earlier POP3 connection and then would allow it.
Since then there have been several extensions to SMTP that allow authentication directly, but there are more than one way to do it, with different cryptography approaches. It's very possible that the Office365 servers require a specific authentication that the LabVIEW SMTP implementation doesn't support. And since spam is still such an omnipresent problem, many email servers are configured to not return authentication errors on such attempts but at best log them somewhere, appear to handle everything as if nothing was wrong and send the traffic to /dev/null. This means that you need to have access to someone with administrator access to the server, who can monitor the server directly as you attempt to send a mail, and then can tell you why the server dropped the mail message. Under normal operation, those server logs are only routinely scanned by automated scripts for specific malicious patterns and then discarded. Someone trying to send mails without proper authentication is seldom even flagged, as any SMTP server that is visible on the internet is routinely targeted by spam campaigns many times each day.
