Playing dice with smtp package
in [TCL]
|
Prev: canvas $pathname -wrap 1
Next: An expanding tablelist
From: drscrypt on 7 Jul 2010 12:55 On 7/7/2010 12:36 PM, Gerald W. Lester wrote: > Your reports have been the first against smtp in *years*. I don't know if everyone reports it or whether they specifically say smtp. But with a simple google search, here is one from April: http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/5d560e747f81f3cd/0261df82f0c16eac?lnk=gst&q=smtp#0261df82f0c16eac Another one from 2008: http://groups.google.com/group/comp.lang.tcl/msg/4a39aee713c539fe Here is another that acknowledges a similar issue, for whom it was resolved by removing Trf: http://groups.google.com/group/comp.lang.tcl/msg/ae5c1120d1593af4 So I am sure there are others too; not counting the wiki. > When your initial report came in, I verified (using gmail.com and > cox.net) that I could send a fairly large attachments using 8.5 and 8.6. I am using 8.4. Can you run the same tests again with a recent version of Tcl 8.4.x and Tcllib 1.12? What script are you using? > As Uwe Klein suggest, in this thread and several of us in your previous > thread, try against another MTA -- I think several of us suspect the > fault lies in the MTA or your connection. > Well, when I send a small attachment of a few hundred bytes, all is OK. When the attachment size grows, problems start. I am on a pretty fast connection so it is not an issue. My MTA is yahoo. I don't have another MTA at the moment. Are you saying it is not working with yahoo? DrS
From: Uwe Klein on 7 Jul 2010 13:33 drscrypt(a)gmail.com wrote: > Well, when I send a small attachment of a few hundred bytes, all is OK. > When the attachment size grows, problems start. I am on a pretty fast > connection so it is not an issue. My MTA is yahoo. I don't have > another MTA at the moment. Are you saying it is not working with yahoo? > > > DrS Could this be due to some misconfigured MTU value "somewhere" in the path ? Can you do a(n automated) testseries that increases message size on every iteration by a "small" amount ? Plot the resulting failure data? uwe
From: drscrypt on 7 Jul 2010 13:59 On 7/7/2010 1:33 PM, Uwe Klein wrote: > Could this be due to some misconfigured MTU value "somewhere" in the path ? > If that were the case, the MTU would not be successful on the small messages though, is that right? In any case, if you have recommendations on what that path should look like, I am eager to try it. DrS
From: Craig on 7 Jul 2010 14:16 MTU, Maximum Tranmission Unit, is the largest message size for a chunk of data for a protocol. larger messages get broken up into chunks <= MTU. I think Uwe is suggesting that if the MTU (possibly on the MTA's side) were assumed to be different sizes in different places, then messages above a certain size might be getting trashed. craig drscrypt(a)gmail.com wrote: > On 7/7/2010 1:33 PM, Uwe Klein wrote: >> Could this be due to some misconfigured MTU value "somewhere" in the >> path ? >> > > If that were the case, the MTU would not be successful on the small > messages though, is that right? In any case, if you have > recommendations on what that path should look like, I am eager to try it. > > > DrS > > >
From: Uwe Klein on 7 Jul 2010 14:15
drscrypt(a)gmail.com wrote: > On 7/7/2010 1:33 PM, Uwe Klein wrote: > >> Could this be due to some misconfigured MTU value "somewhere" in the >> path ? >> > > If that were the case, the MTU would not be successful on the small > messages though, is that right? In any case, if you have > recommendations on what that path should look like, I am eager to try it. > Please look up MTU : http://en.wikipedia.org/wiki/Maximum_transmission_unit There need to be other breakage too. You would see a pronounced error at certain packet length. Further you might be interested in a google search: http://www.google.com/search?q=MTU+mta+yahoo You are not alone in having issues with the Yahoo MTA uwe |