Smtp bug
in [TCL]
|
Prev: freewrap ico
Next: Smtp - wrong error message
From: drscrypt on 18 Jun 2010 13:56 I have been dealing with the smtp bug that I reported a couple of days ago after upgrading to tcllib1.12. My quick fix of putting catch statements around the offending code was not successful. After looking at the code, and the actual message for which it fails, I believe I have found the offending bug. It seems the the smtp package explicitly uses 4096 as block size. So, if there is an html attachment (as a mime object) of over twice that size (anything over 8192 bytes), the code fails with the error message I attached in the original thread. It seems to fail 8-9 times out of ten. I am not sure why yet - but I would like ask if others can verify this and if possible suggest a solution. DrS
From: drscrypt on 18 Jun 2010 13:57 On 6/18/2010 1:56 PM, drscrypt(a)gmail.com wrote: > After looking at the code, and the actual message for which it fails, I > believe I have found the offending bug. It seems the the smtp package > explicitly uses 4096 as block size. So, if there is an html attachment Update: Not just html but even plain text attachments cause the same trouble too. DrS
From: drscrypt on 18 Jun 2010 14:03 On 6/18/2010 1:56 PM, drscrypt(a)gmail.com wrote: > It seems the the smtp package > explicitly uses 4096 as block size. So, if there is an html attachment Increasing the block size works - it solves the problem. However, I am afraid it would then simply fail on a larger attachment. DrS
From: Gerald W. Lester on 18 Jun 2010 15:05 drscrypt(a)gmail.com wrote: > On 6/18/2010 1:56 PM, drscrypt(a)gmail.com wrote: > >> It seems the the smtp package >> explicitly uses 4096 as block size. So, if there is an html attachment > > Increasing the block size works - it solves the problem. However, I am > afraid it would then simply fail on a larger attachment. Could you send me the line number of where you made the change or a diff? Could you send me the line number of where you made the change or a diff? I've used it with large attachments before, it should not be a problem. Also if you could send me a sample of what fails (remove any data I should not see) it would be helpful. I have two SMTP servers I can test against. My gut still says this is a badly behaved server, but it seems like we should make -blocksize a configure option. -- +------------------------------------------------------------------------+ | Gerald W. Lester, President, KNG Consulting LLC | | Email: Gerald.Lester(a)kng-consulting.net | +------------------------------------------------------------------------+
From: drscrypt on 18 Jun 2010 15:18
On 6/18/2010 3:05 PM, Gerald W. Lester wrote: > I've used it with large attachments before, it should not be a problem. Same here - this was from a script that has been working for quite some time. It only stopped working after the upgrade. > Also if you could send me a sample of what fails (remove any data I > should not see) it would be helpful. I have two SMTP servers I can test > against. % diff mime-1.5.4.tm modified-mime 1560c1560 < -blocksize 4096] --- > -blocksize 8192] 1987c1987 < set blocksize 4096 --- > set blocksize 8192 To reproduce the problem, just create an attachment or two (plain text or html) and send it via smtp::sendmessage. I used [string repeat a 8192] and then added a few characters to it between tests. > My gut still says this is a badly behaved server, but it seems like we > should make -blocksize a configure option. Well, I also tested it against Yahoo - same results. I tried supplying it as an option in my calls to mime::* proc's but it complained about unknown option. I suspect it is used internally and not exposed. Thanks for looking into this. DrS |