SMTP Email Error 54

[murchak]

It is definitely not worthless. I guess I wouldn't use disparaging remarks because someone spent time to wrote that code for the benefit of others.

I did say useless for me, because no matter what I do, I keep getting errors (1172). I did a search of that error, and really took me nowhere. 

I guess it is human nature to look for simple things to solve more complex problems. One would think a powerful program like LabVIEW should have

simple built-in VIs that would send emails without so much hassle. Or it shouldn't have taken until 2012 or 2013 version to make this task simple.

[rolfk]

The problem about sending emails is that it is anything but simple. In theory it is enough to read the RFCs and implement everything that is described in there to have a fully working solution. In practice you are talking about several dozen of RFCs that are specifically about different aspects of handling Simple Mail Transfer Protocol. All of them are meant to be THE authoritive description of those various aspects, but are often anything but trivial to understand or even unambigous. Also the RFCs that are about the security specific features, which is where LabVIEW had and still has been having problems are generally written in a very specific encryption technology language that is about as far away from normal everyday language as what you would read in legal documents.

Add to that that there are many implementations of email servers that do not fully conform to the RFCs, some because the developer was not able to fully understand the RFC documents, others because they couldn't care less about following a standard but rather set their own standard whenever possible. Your seemingly simple task suddenly is anything but simple. If it would be so simple as you claim it is, why haven't you written your own solution already?

NI not being in the business of writing email servers and clients is simply just another little stone to the entire problem. If it was simple it would have been done years ago, and not by NI but by many different LabVIEW users in the LabVIEW community. The fact that it hasn't been done is proof enough that it is not simple and maybe just as important that there is no money to make from writing such a solution, despite many people getting upset about the fact that they can't do it with every possible server out there.

The fact that you even fail to do it by using .Net should tell you enough. The failure you see has nothing to do with LabVIEW. It is a failure happening in your .Net SMTPClient class, either because that class hasn't be written to handle the specifics of your server you want to connect too, or maybe more likely because you haven't setup the client correctly in some ways, before attempting to make a connection.

[rolfk]

---

@Dennis_Knutson wrote:

To bring your support up to date, I believe you have pay for all the years you missed. Check with your sales engineer.

---

It's not that bad actually. You do pay more if you let your SSP expire and in the worst case you end up paying about half the price of a new license. Depending on the software license and additional toolkits this might be about two or three SSP payments. If the SSP has only expired for less than 3 months I believe, the extra costs are a lot less than half the original license.

[murchak]

Thanks Rolfk for the remarks. I don't fundamentally disagree with anything you said.... But once an application (in this case LabVIEW) has access to my email

environment (say by me supplying the username and password), it shouldn't take much coding to make my email account send an automatic email to a bunch

of recipients. It is not labVIEW's job to worry about all layers of security, as that is already handled between the parties that are responsible for sending and receiving emails.

For example, I can log into my yahoo mail account and send an email to my gmail mail account. All layers of security and complexity of this process are handled by Yahoo and Google (and my ISP).

WHETHER I manually type www.yahoo.com, click on mail, put in my username and password, then compose and send an email by clicking the send button, OR I use a simple

scripting langauge to automate this process, should not create the need for the scripting langauge to worry about security and mail handling issues between Yahoo and Google.

As a last remark, yes whatever complexity is involved, I expect an application that cost > $4500 in license to be able to handle (in a rather simple manner) automation of sending and receiving emails. NI LabVIEW's key

selling point is instrument control and automation, yet the automation of sending emails is all of sudden anything but simple. No acceptable.

I agree with Dennis that the SMTP Email VIs were written when most servers didn't require authentication, and it was shortsightedness on NI's part to not account for that in the future. Bear in mind that my LabVIEW version

is not from the 1990s, it is from 2011. 

[Dennis_Knutson]

Well, it's a matter of priorities. There was a known work around with the .net examples and it has been modified, finally, which you can use if you upgrade.

[tst]

---

@murchak wrote:

...I expect an application that cost > $4500 in license to be able to handle (in a rather simple manner) automation of sending and receiving emails. 

---

You might. Others might not. Like Dennis said, it's a matter of what users require and setting priorities accordingly. I can say that I do automation, but the number of systems in which I actually send emails is quite low.

In any case, you do have a rather simple manner of doing this - the SMTP VIs have been around for a long time and do this. Since their old version doesn't handle authentication (the same problem I and others ran into when trying to do this), you can use the rather simple .NET class, just like any other programmer in the world. I can attest that I have seen it working on some computers and not working on others (although in that case the functionality wasn't important enough for me to investigate). Since you got an exception when running the .NET code, the next logical step would be to search for details on that exception and see if other people ran into the same problem when using the .NET class. That's one thing programmers do when they run into a problem. Putting the text into Google shows quite a lot of results.

[1984]

Try this... as I suggested first try with gmail, as it has less unknown factors. Make sure you change all the necessary string constants to match your account details.

[rolfk]

---

murchak wrote:

For example, I can log into my yahoo mail account and send an email to my gmail mail account. All layers of security and complexity of this process are handled by Yahoo and Google (and my ISP).

WHETHER I manually type www.yahoo.com, click on mail, put in my username and password, then compose and send an email by clicking the send button, OR I use a simple

scripting langauge to automate this process, should not create the need for the scripting langauge to worry about security and mail handling issues between Yahoo and Google.

---

Your problem here is that you ccompare Yahoo and LabVIEW together, which are two VERY different animals in the world. One is an online end user application platform to get involved in various online communities among which also through the good old email. The other is a Rapid Application Develeopment platform that allows YOU as its user to write end user applications. In Yahoo everything they want you to be able to do in terms of online activities is ready cooked for you, anything else you will be hard pressured to find a way to do in Yahoo.

LabVIEW is a programming environment that allows you to do just about everything you as a programmer can imagine but it requires usually some programming work for this. Try to write a production tester application in Yahoo, or a Vision inspection tool, or maybe just a simple data acquistion application! You most likely won't even consider to do that!

Sending emails from any of these applications is not an uncommon request, but not one I would consider the a core feature. In fact I have never in my 20 years of programming industrial applciations with LabVIEW, incorporated direct email sending from within the application itself.

As to the SMTP options you have in LabVIEW, I'll try to put them once more on a list:

1) The old Internet Toolkit based SMTP VI's. They are fully implemented in LabVIEW diagram code, but don't support ESMTP (quite easy to add) or security (authentification and encryption).

2) The new SMTP VIs in LabVIEW 2012 and newer. They use a shared library (DLL) developed by NI in C++ whcih does all the protocol handling including security functions. This library can handle most current email servers but is for various reasons not possible to install in older LabVIEW versions, one of the reasons is that the security support used in the shared library relies on components that are part of these LabVIEW distributions.

3) Using an external SMTP implementation such as the .Net SMTPClient, or some other shared library, Active X or .Net library. Here you simply use LabVIEW as accessor and how you have to call that external library is really your own business. Use of the .Net client for an NI provided solution is not a viable option for NI since LabVIEW runs on several other platforms than Windows too, and .Net is a pure Windows only technology (and no Monos is not a solution for this, since the installation, configuration and potential license problems are to serious to allow NI to even think about using that).

[murchak]

Okay, well, thanks Dennis, 1984, tst, and Rolfk for all the feedback and interesting/helpful feedback.

I will try the .NET way and update this post when I get it to work for my PC.

[1984]

The file I have attached couple hours ago is the .net version, work for me like a charm.