Smtp sendmessage using tcl does not work on windows, cannot open crypt.dll

1

Hi,
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

package require tls
package require smtp
package require mime

proc send_email {to subject body { attachment ""} } {
    set opts {}

    lappend opts -servers "smtp.something.com"
    lappend opts -ports 587
    lappend opts -username "someone@something.com"
    lappend opts -password "password"
    lappend opts -header [list "Subject" $subject]
    lappend opts -header [list "From" "xyz@gmail.com"]
    lappend opts -header [list "To" $to]

    if { $attachment == "" } {
        set mime_msg [mime::initialize -canonical "text/plain" -string $body]
    } else {
        set textT    [mime::initialize -canonical text/plain -string $body]
        set attT     [mime::initialize -canonical "name=\"[file tail $attachment]\"" -file $attachment]
        set mime_msg [mime::initialize -canonical multipart/mixed -parts [ list $textT $attT ]]
    }

    smtp::sendmessage $mime_msg {*}$opts -usetls 1
    mime::finalize $mime_msg -subordinates all
}
2

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

There’s an example in the SMTP man page showing TLS 1 being forced, which would obviously not be what you would want now, but shows the way.
https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/modules/mime/smtp.md

3

Hi,

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 ]]

Any idea what is wrong with it?

Cheers
Daniel

4

That sounds like mime::initialize is seeing different encodings between the two parts. It’s able to make the right choice when given one individually, but does not when both are present.
https://www.tcl.tk/community/tcl2004/Tcl2003papers/kupries-doctools/tcllib.doc/mime/mime.html#1
Windows will be using different encodings that Linux does, so that also might explain why it’s only Windows having the problem.

5

Thank you for your response again. Please, do you know any cure for this issue on windows?

Regards
Daniel

6

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.

7

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?

8

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.