I'm trying to send mail via gmail by executing

set parts [list]
lappend parts [mime::initialize \
-canonical text/plain \
-string "...1, 2, 3."]
lappend parts [mime::initialize \
-canonical text/html \
-string "<div>...1, 2, <u>3</u>.</div>"]

set tok [mime::initialize \
-canonical multipart/alternative \
-parts $parts]
smtp::sendmessage $tok \
-username sender.address@gmail.com \
-password <password> \
-servers smtp.gmail.com \
-ports 587 \
-header {Subject {"Testing, testing..."}} \
-header {To recipient.address@gmail.com} \
-header {From sender.address@gmail.com}
mime::finalize $tok

This fails in smtp::sendmessage with the error above.

If I specify the body as either plain text or html, without the nested
mime parts, all is well.

Earlier, I was using multipart/mixed, rather than multipart/alternative
for the parent mime part, but with an empty list of parts and that
failed at the same point; however, even earlier, when I mistyped the
mime type as "multipart.mixed" there was no crash.

I'm really just interested in fixing this, and would be delighted simply
to download crypt.dll and save it somewhere sensible, but when I
searched for the error message I couldn't find anything more helpful
than "remove and re-install the program" and links to some dodgy-looking download sites.

Any help or pointers much appreciated,
Alan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alan,

could you also post the result of: the TCL stack trace ?

catch {your command} err errdict
dict get $errdict -errorinfo
dict get $errdict -errorstack

There should be some context, where this is called.

Take care,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 10-Mar-2023 17:06, Harald Oehlmann wrote:

catch {your command} err errdict
dict get $errdict -errorinfo
dict get $errdict -errorstack

There should be some context, where this is called.

You'd expect so, wouldn't you?

In practice, both [dict get] commands fail with "key ... not known in dictionary. The error dictionary is simply

-code 7 -level 0

As I said in my original post, I'm principally interested in how reolve
the error by getting hold of a copy of crypt.dll.

While I could apparently work around the problem by sending the body
part as either text/plain or text/html rather than both, the full use
case also includes sending a couple of files as attachments, and that
fails with the "cannot open crypt.dll" error.

I don't think I've supplied the package versions; I'm using smtp 1.15.1
and mime 1.7.0

The error occurs in the call to sendmessageaux from sendmessage at
approx line 323 (it's hard to be precise, because I've added some trace)
just before the comment "Send the message to bcc recipients as a MIME attachment".

Within sendmessageaux, there is an error in the call to wtext at around
line 38, after the loop around all the recipients.

Within wtext, an error - "cannot open crypt.dll"! - is returned by the
call to wtextaux a little over halfway through, just after sending "300
DATA" and checking for a 354 response.

Within wtextaux, there is a comment about working around "a bug with
stacking channels on top of TLS". The code immediately after this sets
trf to 0 because the tls entry exists in the state array and has value
1. Because of this, we call mime::buildmessage rather than
mime::copymessage. mime::buildmessage returns an error.

Within buildmessage, the error is returned by the call to
buildmessageaux almost at the top of the proc. This proc is called via

set code [catch {mime::buildmessageaux $token} result]

and at this point, errorInfo has the value

cannot open crypt.dll
while executing
"md5 -- $key"
(procedure "getContentType" line 15)
invoked from within
"getContentType $token"
(procedure "getheader" line 20)
invoked from within
"getheader $token"
(procedure "copymessageaux" line 11)
invoked from within
"copymessageaux $token $chan"
(procedure "mime::buildmessageaux" line 4)
invoked from within
"mime::buildmessageaux $token""
code: "1", result: "cannot open crypt.dll"

I'm really not sure that it will help for me to dive any deeper into the
code.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 11.03.2023 um 14:56 schrieb Alan Grunwald:

On 10-Mar-2023 17:06, Harald Oehlmann wrote:

catch {your command} err errdict
dict get $errdict -errorinfo
dict get $errdict -errorstack

There should be some context, where this is called.

You'd expect so, wouldn't you?

In practice, both [dict get] commands fail with "key ... not known in dictionary. The error dictionary is simply

-code 7 -level 0

As I said in my original post, I'm principally interested in how reolve
the error by getting hold of a copy of crypt.dll.

While I could apparently work around the problem by sending the body
part as either text/plain or text/html rather than both, the full use
case also includes sending a couple of files as attachments, and that
fails with the "cannot open crypt.dll" error.

I don't think I've supplied the package versions; I'm using smtp 1.15.1
and mime 1.7.0

The error occurs in the call to sendmessageaux from sendmessage at
approx line 323 (it's hard to be precise, because I've added some trace)
just before the comment "Send the message to bcc recipients as a MIME attachment".

Within sendmessageaux, there is an error in the call to wtext at around
line 38, after the loop around all the recipients.

Within wtext, an error - "cannot open crypt.dll"! - is returned by the
call to wtextaux a little over halfway through, just after sending "300
DATA" and checking for a 354 response.

Within wtextaux, there is a comment about working around "a bug with
stacking channels on top of TLS". The code immediately after this sets
trf to 0 because the tls entry exists in the state array and has value
1. Because of this, we call mime::buildmessage rather than
mime::copymessage. mime::buildmessage returns an error.

Within buildmessage, the error is returned by the call to
buildmessageaux almost at the top of the proc. This proc is called via

        set code [catch {mime::buildmessageaux $token} result]

and at this point, errorInfo has the value

cannot open crypt.dll
    while executing
"md5 -- $key"
    (procedure "getContentType" line 15)
    invoked from within
"getContentType $token"
    (procedure "getheader" line 20)
    invoked from within
"getheader $token"
    (procedure "copymessageaux" line 11)
    invoked from within
"copymessageaux $token $chan"
    (procedure "mime::buildmessageaux" line 4)
    invoked from within
"mime::buildmessageaux $token""
    code: "1", result: "cannot open crypt.dll"

I'm really not sure that it will help for me to dive any deeper into the code.

Ok. The man-page of the md5 command gives some insight:

https://tmml.sourceforge.net/doc/tcllib/md5.html

It is perhaps a failed critcl compile run?

Just an idea,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12/03/2023 12:00, Harald Oehlmann wrote:

Am 11.03.2023 um 14:56 schrieb Alan Grunwald:

<snip>

I'm really not sure that it will help for me to dive any deeper into
the code.

Ok. The man-page of the md5 command gives some insight:

https://tmml.sourceforge.net/doc/tcllib/md5.html

It is perhaps a failed critcl compile run?

I guess you're referring to the second paragraph of the description in
the manpage:

"If you have critcl and have built the tcllibc package then the
implementation of the hashing function will be performed by compiled
code. Alternatively if you have either cryptkit or Trf then either of
these can be used to accelerate the digest computation. If no suitable
compiled package is available then the pure-Tcl implementation wil be
used. The programming interface remains the same in all cases."

It's Windows. Installation is sufficiently effort free that I don't
remember where I got the tcl installation from. I see that it's
installed in C:\ActiveTcl, which I guess provides quite a clue! I'm
fairly sure that I haven't built the tcllibc package. Nor do I,
knowingly, have cryptkit or Trf. How can I check for tcllibc, cryptkit
and Trf?

I've assumed up to now that I have some package or other missing, which
would provide crypt.dll; you seem to be suggesting that there may be a
problem with the way that the md5 command determines what sort of
installation I have.

I shall dive back into the code!

(By the way, I have not mentioned up to now that the code works fine on
Linux.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 12.03.2023 um 14:09 schrieb Alan Grunwald:

It's Windows. Installation is sufficiently effort free that I don't
remember where I got the tcl installation from. I see that it's
installed in C:\ActiveTcl, which I guess provides quite a clue! I'm
fairly sure that I haven't built the tcllibc package. Nor do I,
knowingly, have cryptkit or Trf. How can I check for tcllibc, cryptkit
and Trf?

I've assumed up to now that I have some package or other missing, which
would provide crypt.dll; you seem to be suggesting that there may be a problem with the way that the md5 command determines what sort of installation I have.

I shall dive back into the code!

(By the way, I have not mentioned up to now that the code works fine on Linux.)

I am also on Windows. I never used critcl. It is a library, which
creates dll files on the fly. That is great but fragile.

I suggest to switch to the more recent TCL distribution by Ashok
(Magicsplat). To my knowledge, ActiveState TCL is not maintained any more.

Take care,
Harald

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 12-Mar-2023 17:50, Harald Oehlmann wrote:

Am 12.03.2023 um 14:09 schrieb Alan Grunwald:

It's Windows. Installation is sufficiently effort free that I don't
remember where I got the tcl installation from. I see that it's
installed in C:\ActiveTcl, which I guess provides quite a clue! I'm
fairly sure that I haven't built the tcllibc package. Nor do I,
knowingly, have cryptkit or Trf. How can I check for tcllibc, cryptkit
and Trf?

I've assumed up to now that I have some package or other missing,
which would provide crypt.dll; you seem to be suggesting that there
may be a problem with the way that the md5 command determines what
sort of installation I have.

I shall dive back into the code!

(By the way, I have not mentioned up to now that the code works fine
on Linux.)

I am also on Windows. I never used critcl. It is a library, which
creates dll files on the fly. That is great but fragile.

I suggest to switch to the more recent TCL distribution by Ashok (Magicsplat). To my knowledge, ActiveState TCL is not maintained any more.

Take care,
Harald

1) Thank you Harald. I have installed Ashok's Magicsplat distro, and
using it, the following code, which very closely replicates my full use
case (alternative plain text and html body; two attached files),
completes correctly:

set bits [list]
lappend bits [mime::initialize \
-canonical text/plain \
-string "... 1, 2, 3"]
lappend bits [mime::initialize \
-canonical text/html \
-string "<div>... <i>1</i>, <b>2</b>, <i><b>3</b></i></div>"]

set parts [list]
lappend parts [mime::initialize \
-canonical multipart/alternative \
-parts $bits]
lappend parts [mime::initialize \
-canonical {text/plain; name=.bashrc} \
-file .bashrc]
lappend parts [mime::initialize \
-canonical {text/plain; name=.emacs} \
-file .emacs]

set tok [mime::initialize \
-canonical multipart/mixed \
-parts $parts]
smtp::sendmessage $tok \
-username sender@gmail.com \
-password $pwd \
-servers smtp.gmail.com \
-ports 587 \
-header {Subject "Testing, testing..."} \
-header {To recipient@gmail.com} \
-header {From sender@gmail.com}
mime::finalize $tok

2) I was mistaken; I apologise. Now that the code is working, I find
that I am *very* interested in knowing why it failed. (Principally
because I am used to the way ActiveTcl is installed and lays out its
files; rather than learn how Ashok lays out the files for Magicsplat, I
would build Tcl from sources myself on Windows, and I'd rather not do
that, so I'm prepared to put some effort into fixing the unsupported
ActiveTcl installation.)

I'm curious why it is that although both my ActivState and my Magicsplat
builds are providing the same versions of the mime and smtp packages (respectively 1.7.0 and 1.5.1 - I have installed the latest tcllib
(1.21) into ActiveTcl alongside the supplied version (1.18), again
apologies for not stating this explicitly before now) the builds behave differently.

I have yet to investigate how the failing call

md5 -- $key

is operating, but I note that on the (failing) ActiveTcl installation
provides a command md5, while the (working) Magicsplat installation
provides a proc mime::md5.

--
Alan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14-Mar-2023 14:00, Alan Grunwald wrote:

2) I was mistaken; I apologise. Now that the code is working, I find
that I am *very* interested in knowing why it failed. (Principally
because I am used to the way ActiveTcl is installed and lays out its
files; rather than learn how Ashok lays out the files for Magicsplat, I
would build Tcl from sources myself on Windows, and I'd rather not do
that, so I'm prepared to put some effort into fixing the unsupported ActiveTcl installation.)

A few minutes thought about the problem with ActiveTcl suggest that the problems occurred at installation time. The installation process seems
to be somewhat opaque, so I have turned to building Tcl/Tk from sources.

This went rather better than I feared and I now have bright, shiny
tclsh.exe and wish.exe, both at 8.6.13.

(I have a very minor issue with the build instructions for Windows at https://www.tcl-lang.org/doc/howto/compile.html#win:

The text below the bulletted list states that you need to modify
makefile.vc to specify required paths - as far as I can tell, you don't.)

I now have problems building or otherwise getting hold of a working tdom
with support for -html5. See another thread...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)