LabVIEW
SMTP Email Send Message Error
Thanks for pointing me to that VI, i finally saw my emails on my account. But what i need is to send emails not to read them so this is what i have learned so far:
-Labview native SMTP VI's doesnt support simple authentication ( user name and password), much less SSL or TSL (gmail) 
- Open G SMTP VI's support simple authentication, but not SSL or TSL ( who can blame them i know is something difficult to develop without motivation $$$$)
These facts( i think...) take us to these solutions:
- We need to have corporate accounts or personal mail servers to use those accounts with the available free VI's.
-Buy Internet toolkit ( $$) i bet that for 500 dollars they include some precius SMTP VI's that support Gmails accounts!!! ( just guessing)
So i will go for the firs option ( my boss cant spend a lot of money in toolkits every tme i get stuck in a part of the project) .
What do you think?
Because of the encryption algorithme needed. And the security implications that has. Doing a secure SMTP client with enccryption is serious business which is not correct when it works but only when it is reviewed by security specialists.
@smercurio_fc wrote:
Almost all email servers nowadays (including Hotmail and GMail) require a username and password for authentication. The SMTP VIs that ship with LabVIEW do not support authentication. I have yet to figure out why NI left this out for so long. You can use the OpenG SMTP Library that you can find here. NOTE: These won't work with servers that use encryption.
Basically implementing the different encryption algorithmes is not trivial and there are many different ones and many servers choose to support only particular ones because the others are considered to complicated or sometimes also to insecure, depending on the stance in security standards that developer holds. For instant Base64 encoded username password is a joke since anyone with a network sniffer can simply extract the password. Also the MD5 encrypted password algorithme the OpenG library uses is not considered safe anymore for public network access, since cracking that encryption is a matter of minutes nowadays. The more involved encryptions however are a lot more complicated to implement.
Another problem is testing them. You need known servers to test them with and not just one but a few dozen different ones. A nice and taunting task to install and configure one of them already, not so nice to do a dozen different ones.
Also you should not forget about other aspects of the implementation. For instance negotiating the correct encryption algorithme on connection build-up is not trivial. You need to allow the server to tell you what it supports, but can not allow it to dictate the used encryption protocol. Otherwise a man in the middle attack can intercept the messages and modify them to force your client software to connect with a known unsafe method. An error many email packages have made in the past in the wrong assumption to be more forgiving in quirks in server implementations. The client that came with Mozilla for instance did that for a long time.
Rolf Kalbermatter
@Isaac84 wrote:Thanks for pointing me to that VI, i finally saw my emails on my account. But what i need is to send emails not to read them so this is what i have learned so far:
There are servers that support SMTP after POP. What this basically means is, that a client first connects by POP using its login information and then immediately follows that connetion with an usafe connection through SMTP. The server sees the SMTP connection request coming from the same IP address as the successful POP login just a moment ago and grants access based on that fact.
Not terribly secure but not really worse than Base64 encoding or MD5 encryption login.
-Buy Internet toolkit ( $$) i bet that for 500 dollars they include some precius SMTP VI's that support Gmails accounts!!! ( just guessing)
500 $ for an SSL implementation in LabVIEW??????? You are choking!
The SMTP VIs from the Internet Toolkit where incorporated into the Full development system of LabVIEW back in LabVIEW 6.1 or so and are basically still the same if they didn't remove them from that Toolkit in the meantime.
The money for the Internet Toolkit buys you other things such as an HTTP server that supports some form of CGI, HTTP VI libraries, an XML library using Xerces, FTP protocol VIs, Telnet library and utility libraries to support those protocols.
Rolf Kalbermatter
Message Edited by rolfk on 04-09-2008 08:23 AM
Username/password authentification without some form of encryption is not very useful. Any server allowing Base64 encoded username/password encoding but not unauthentificated connections is basically kidding the users. It has no security at all and poses the risk of publically making passwords available.
@smercurio_fc wrote:@rolfk wrote:Rolf, I wasn't referring to the LabVIEW SMTP VIs not supporting encryption. I was referring to them not supporting basic username/password authentication, which the OpenG VIs do. I know that encryption is quite difficult (we've actually been down this road before, if you recall), and I'm not surprised that the LabVIEW SMTP VIs don't support that.Because of the encryption algorithme needed. And the security implications that has. Doing a secure SMTP client with enccryption is serious business which is not correct when it works but only when it is reviewed by security specialists.
@smercurio_fc wrote:
Almost all email servers nowadays (including Hotmail and GMail) require a username and password for authentication. The SMTP VIs that ship with LabVIEW do not support authentication. I have yet to figure out why NI left this out for so long. You can use the OpenG SMTP Library that you can find here. NOTE: These won't work with servers that use encryption.
Rolf Kalbermatter
