Smtp bug
in [TCL]
|
Prev: freewrap ico
Next: Smtp - wrong error message
From: Christian Nassau on 18 Jun 2010 15:51 We saw a similar problem when we upgraded from Tcl 8.4 to 8.5: the Trf package was not functioning correctly with 8.5 (there probably is a Trf gadget involved with the $converter from your error message). You could try to disable Trf by renaming its "pkgIndex.tcl" to "pkgIndex.disabled". It *might* be that smpt uses a workaround then and that this already fixes your problem. HTH, C. Am 06/16/2010 04:53 PM, drscrypt(a)gmail.com wrote: > Hello, > > A script I have used for a long time to send a notification email is > failing after upgrading tcllib from 1.10 to 1.12. I am attaching the > error trace below. The funny thing is even though it results in an > error and stops the script, the email does go out fine. > > > Any ideas what is causing the problem? Should I revert to the previous > version? > > > DrS > > > >> error writing "sock908": invalid argument >> while executing >> "puts -nonewline $channel [$converter -mode encode -- $state(string)]" >> ("string" arm line 15) >> invoked from within >> "switch -- $state(value) { >> file { >> set closeP 1 >> if {[info exists state(root)]} { >> # FRINK: nocheck >> vari..." >> (procedure "mime::copymessageaux" line 75) >> invoked from within >> "mime::copymessageaux $token $channel " >> invoked from within >> "mime::copymessage $part $channel" >> ("foreach" body line 3) >> invoked from within >> "foreach part $state(parts) { >> puts $channel "\n--$boundary" >> mime::copymessage $part $channel >> ..." >> ("default" arm line 4) >> invoked from within >> "switch -glob -- $state(content) { >> message/* { >> puts $channel "" >> foreach part $state(parts) { >> ..." >> ("parts" arm line 7) >> invoked from within >> "switch -- $state(value) { >> file { >> set closeP 1 >> if {[info exists state(root)]} { >> # FRINK: nocheck >> vari..." >> (procedure "mime::copymessageaux" line 75) >> invoked from within >> "mime::copymessageaux $token $channel " >> invoked from within >> "::mime::copymessage $part $state(sd) " >> invoked from within >> "wtextaux $token $part " >> invoked from within >> "smtp::sendmessage $msgMime > >
From: drscrypt on 18 Jun 2010 16:33 On 6/18/2010 3:51 PM, Christian Nassau wrote: > We saw a similar problem when we upgraded from Tcl 8.4 to 8.5: the Trf > package was not functioning correctly with 8.5 (there probably is a Trf > gadget involved with the $converter from your error message). > > You could try to disable Trf by renaming its "pkgIndex.tcl" to > "pkgIndex.disabled". It *might* be that smpt uses a workaround then and > that this already fixes your problem. > > HTH, > C. > Interesting! It seemed to have done the trick. I removed the package altogether and it worked. I then installed it again via teacup. This time, it worked again. Even though the previous version I removed was the same (2.1.4). I will run more tests later to make sure I am not overlooking something. Thanks! DrS
From: drscrypt on 18 Jun 2010 16:55 On 6/18/2010 4:33 PM, drscrypt(a)gmail.com wrote: > Interesting! It seemed to have done the trick. I removed the package > altogether and it worked. I then installed it again via teacup. This > time, it worked again. Even though the previous version I removed was > the same (2.1.4). OK - with Trf, the problem comes back occasionally. I guess I will just have to remove it altogether. It is ironic though - it seems that all it does is provide the C versions of base64, md5, etc. DrS
From: Gerald W. Lester on 18 Jun 2010 19:44 drscrypt(a)gmail.com wrote: > On 6/18/2010 4:33 PM, drscrypt(a)gmail.com wrote: >> Interesting! It seemed to have done the trick. I removed the package >> altogether and it worked. I then installed it again via teacup. This >> time, it worked again. Even though the previous version I removed was >> the same (2.1.4). > > OK - with Trf, the problem comes back occasionally. I guess I will just > have to remove it altogether. It is ironic though - it seems that all > it does is provide the C versions of base64, md5, etc. Ok, unless I hear otherwise from you I'll drop the issue with the SMTP package. -- +------------------------------------------------------------------------+ | Gerald W. Lester, President, KNG Consulting LLC | | Email: Gerald.Lester(a)kng-consulting.net | +------------------------------------------------------------------------+
From: drscrypt on 21 Jun 2010 11:52
On 6/18/2010 7:44 PM, Gerald W. Lester wrote: > drscrypt(a)gmail.com wrote: >> OK - with Trf, the problem comes back occasionally. I guess I will >> just have to remove it altogether. It is ironic though - it seems that >> all it does is provide the C versions of base64, md5, etc. > > Ok, unless I hear otherwise from you I'll drop the issue with the SMTP > package. > I just sent out a few emails that were failing before and it seems to work fine now. However, I am a bit uneasy with the way we resolved this: 1) Is the Trf really unnecessary? Reading its description, it seems to be doing something cool. 2) Why and how does Trf cause trouble with smtp? 3) What are the implications of taking out Trf? Searching where it is used, it seems that Trf is recommended for tls to work correctly, but needs to be removed for smtp to work correctly. What happens if someone needs both tls and smtp? Also, it is clear that others are having problems with the package and have come up with their own ways to fix these problems. So, instead of moving on, I would really urge you and the maintainers to have a deeper look at the smtp package and see what is causing these issues and fix them once and for all. DrS |