I am trying this code to send an email with an attachment from TCL 8.6.9. While this code works with and without attachment in linux it fails with the following message on windows when trying to attach a file 400: cannot open crypt.dll message. Tried on windows 7, 8.1 and 10. Any idea? I appreciate your help. Google does not give any useful hints on crypt.dll
It looks like this code will only turn tls “on” or “off” and that’s probably not good enough now. TclTLS 1.7.13 and higher have support for specifying the version of TLS you want to use, which is important, because following POODLE, the weaker versions of TLS are often disabled. https://core.tcl-lang.org/tcltls/wiki/Documentation
thank you for your response. Following your recommendation to force tls 1 did not help.
package require tls
tls::init -tls1 1 ;# forcibly activate support for the TLS1 protocol
I am still getting this weird message 400: cannot open crypt.dll. As I mentioned in the original question this only happens if I want to attach a file to the email body.
If I remove plain text body and send attachment on its own it works, if I send body without attachment it also works. Looks like this line is causing a problem when combining both into the message:
set mime_msg [mime::initialize -canonical multipart/mixed -parts [ list $textT $attT ]]
You should confirm that’s the problem before coding a solution, but it the attachment is indeed a different encoding, you probably need a code loop to check for attachments if the system is windows, convert any attachments to an encoding that matches the email or convert the mail to an encoding that matches the attachment if that’s easier, and then move on to mime::initialize.
It doesn’t work that way. MD5-package tryes to open “crypt.dll” while doint smtp/mime, wich in fact is not present on the system.
Where can i get “crypt.dll” and what do i have to do, that the system works with it?
Maybe an enviromen tvariable?
I’ve been digging into the mime handling code. In SMTP, attachments appear to be encrypted independently and prior to any encryption of the email itself. When it comes to time to decrypt the attachment, yes, tcl mime hands off to trf, and when trf is asked to decrypt attachments in mime email, it hands off to trfcrypt.
trfcrypt is an add-on for trf, and it looks like we don’t include it.
I would assume that was decision made many years ago in order to be compliant with regulations on the transfer of cryptography over international borders. I’m having trouble finding any examples of trfcrypt or a crypt.dll anywhere in our legacy materials/downloads.