Smtp bug
in [TCL]
|
Prev: freewrap ico
Next: Smtp - wrong error message
From: Gerald W. Lester on 21 Jun 2010 21:54 drscrypt(a)gmail.com wrote: > 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. I don't maintain TRF, in fact I tend to use the pure Tcl versions of base64 most of the time (off hand I think that it is just used for base64 encoding by smtp if it is present). Sorry, but getting into the C code of TRF is way not high on my priority list -- I want to stay at the Tcl level where my limited time can have more of a payoff. Sorry, but you need to bug the TRF guys. -- +------------------------------------------------------------------------+ | Gerald W. Lester, President, KNG Consulting LLC | | Email: Gerald.Lester(a)kng-consulting.net | +------------------------------------------------------------------------+
From: drscrypt on 22 Jun 2010 12:11 On 6/21/2010 9:54 PM, Gerald W. Lester wrote: > I don't maintain TRF, in fact I tend to use the pure Tcl versions of > base64 most of the time (off hand I think that it is just used for > base64 encoding by smtp if it is present). > > Sorry, but getting into the C code of TRF is way not high on my priority > list -- I want to stay at the Tcl level where my limited time can have > more of a payoff. > > Sorry, but you need to bug the TRF guys. > Hi Gerald, Thanks for your help - I definitely did not mean to ask you to delve into Trf or other packages. I was pointing out some of the questions I had. So if smtp relies on Trf just for base64, then any changes will be limited to the performance of the C vs. Tcl implementations of it. Then, perhaps it would be wise to change the smtp to just rely on the Tcl-only version of base64 by default. Drs
From: Andreas Kupries on 1 Jul 2010 14:14
drscrypt(a)gmail.com writes: > 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? Right now taking out Trf seems to be only a performance issue. I had re-read smtp to remember how it is using Trf. It uses Trf in two ways (1) To convert pieces of the message to base64, quoting-printable, i.e. the mime encoding stuff. This is done by simply using [base64 -mode encoding -- $data], or other converter. I.e. simply call, with result coming back. (2) When trf is available smtp also uses the 'transform' command to setup up a custom channel transformation, which is stacked on the channel. This used to quote '.' characters at the beginning of lines in the message (quoted form is '..'). As a transform this is then executed invisbly with every puts command, by Tcl channel system. Without Trf the same action is done by smtp itself, without stacking a transform, before it invokes 'puts' on the full message. See smtp::wtextaux for the procedure doing the transform setup etc. The advantage of the transform is that smtp can avoid building the whole message in memory, attachments and all. It can build it piecemal, puts the pieces to the channel, and the transform kicks in. This is the difference between the copymessage and buildmessage calls in the wtextaux. That trf has to be disabled when tls is active could be a bad interaction between the two, TLS is also a channel transform. IIRC we have trouble with TLS alone sometimes as well, wait, that is when reading from TLS and getting empty strings while it is doing things internally ... Still, there might be asimilar problem when writing. Regardless of the reason, taking out Trf is not a problem, as you can see that smtp has pure Tcl fallbacks in all the places, whose use mainly degrades performance, in speed and memory consumption. I believe it would be interesting to trace the calls of smtp::wdata, which is the handler for the Tcl side of the transform of (2). This however goes into full-blown debug territory, something which is difficult to handle on netnews. I have cc'd myself at my office address, allowing for more immediate communication between us. > > 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 > > -- So long, Andreas Kupries <akupries(a)shaw.ca> <http://www.purl.org/NET/akupries/> Developer @ <http://www.activestate.com/> ------------------------------------------------------------------------------- |