LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Help with SMTP and attachments - curl error

Hi - can anyone help?

 

I'm using LV2024, and the latest SMTP VIs. 

 

With no attachments, I can send email no problem, so the server settings are definately OK. If I attach a plain text document, that will work OK too. But if I try to attach a .zip file, or a .bin file (what I really want to attach!) - I get a mysterious error:

 

Possible reason(s):

LabVIEW: (Hex 0x58C03) An unknown error occurred in the curl libraries.


Complete call chain:
LabVIEWSMTPClient.lvlib:Send.vi:2280002
Action.UploadByEmail.SendEmail.vi

 

Does anyone with more experience of SMTP than me have any ideas?

Many thanks in advance!

Jon

 

0 Kudos
Message 1 of 8
(200 Views)

Is it possible that the email server has a restriction on certain attachment types?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 8
(196 Views)

I didn't realise that was a thing! I'll check with the mail host.

 

0 Kudos
Message 3 of 8
(187 Views)

As mentioned, some domains do not allow zip files. This is usually a policy of the company's I.T. department to whom you're sending the message, not a restriction imposed by the mail server itself.   But this restriction can be circumvented by renaming the file extension (.zip => .z-i-p).  You could try this instead. 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 4 of 8
(145 Views)

If changing the extension doesn't work, it might still be filtering out zip files.

 

We used to rename *.zip files to *.piz, but our latest email system at work actually looks inside attachments to determine the type. So changing the extension doesn't work anymore. 

0 Kudos
Message 5 of 8
(139 Views)

I tried renaming files to various things - it didn't help. The only thing I can get to send via LabVIEW is a very short bin or text file. But anything more than 55bytes causes the "curl" error described above.

 

With LabVIEW:

Port 465 gives a timeout whether the TLS switch is on or off

Port 587 sends fine whether the TLS switch is on or off, BUT any attachement causes the "curl" error.

 

With Outlook:

Port 465 using SSL/TLS encryption - works fine with and without ANY attachment.

Port 587 using "auto" encryption - works fine with and without ANY attachment.

 

It seems to me that LabVIEW is behaving differently to Outlook. Which suggests it's nothing to do with the mailserver at all. 

 

I'm just using the standard "Send email using SMTP Client" example, but with the attachments VI added. 

Tournifreak_0-1738191267494.png


Any further thoughts, anyone?

 

 

 

0 Kudos
Message 6 of 8
(114 Views)

I ended up giving up with the native LabVIEW VIs - they're just not working very well. And actually they're pretty limited in what they can do.

 

I've used SwithMail before. CC licence, and very flexible and very reliable, in my experience.

https://www.tbare.com/software/swithmail/

 

I've attached my VI wrapper. I've made very little effort on error handling, but it works nicely - maybe it's useful to someone.

0 Kudos
Message 7 of 8
(60 Views)

Most basic SMTP functionality is going to be a no-go at this point. Most email senders, in addition to receiving servers, now try to block every means they know of for distributing malware and phishing attempts. (You know all those annoying test emails your IT probably sends out every 2-3 months? These emails look just like those to servers) I can't even attach a vipm .vip to emails anymore (because they're just ZIPs afterall)

 

You can sometimes get around this by using newer authentication methods (which SMTP definitely does not to) but all still run the risk of getting blocked by recipients which the sender won't know about unless they know the recipient and get told. Doubly true for mail services that don't generate errors, the receiving server might still block the email.

 

Welcome to the more secure modern age of web.

~ G stands for Fun ~
Helping pave the path to long-term living and thriving in space.
0 Kudos
Message 8 of 8
(51 Views)