Can't Send Email?
Date: 9/5/2006
Recently I've been talking with a customer who has this weird problem with sending email. The connection establishs ok and the normal SMTP session progresses up till the point where InScribe sends the end of message marker (\r\n.\r\n). At which point the server stops responding and the socket connection eventually times out. I got a hex dump back from the user that confirmes this.

I wasn't holding my breath on a solution for this as it sounds too weird to be a general problem with the software. However that all changed this morning when the mother of my children had the same issue. And when she has an email problem "It Better Get Fixed Right Now(TM)" ;)

So I fire up the debugger and watch it do the whole send the email, send the end of email line and... hang... and time out... and return the blank error message. Nice.

I consulted the oracle, and it informed me on Path MTU which I found interested. So the next hour was filled with frigging with every TCP/IP and MTU setting I could get me hands on. At one point setting the MTU to 1470 let some of the mail go through, but not all 11 messages, just some of them. So with 6 email still to send I called my cable tech support to see if they knew anything about this sort of error. Oh course they were dumb as nails and wouldn't let me speak to a real engineer about the network and server setup. However they did make me setup Outlook and sure enough that worked. *grumble* stupid Microsoft product actually working *grumble*, but it made me think about what differences there could be between Outlook and InScribe.

In amongst all the other reading about MTU settings and email I ran across a little tid bit of information relating to sendmail (also used by my ISP Optus) it appears that in some network environments it matters which packet the end of mail ("\r\n.\r\n") line is in. i.e. if it's in it's own little packet things don't work. And of course I looked at the hex dump from InScribe and each line was it's own network "send". I would've thought that Windows implements Nagles algorithm and joins all those little packets up in the network stack. But just out of curiosity I quickly implemented a memory buffer for the outgoing email so that the entire message is assembled in memory and written to the socket in one system call. This of course works doesn't it. *grrrrr*

So I guess I'm re-engineering the encoding of email so it goes through a memory buffer. However that may introduce new complexities that I hadn't had to deal with before, like whats a good buffer size (4k!)? And should I vary it when it doesn't work (no)? And what if it doesn't like that on '98 (who cares)? The list goes on and on, but then again, thats why I have "test" releases so that a change like this gets 3-6 months of field testing before going into a major stable release.

Now you too know more than is healthy about TCP/IP. <nelson>haha</nelson>
28/05/2006 9:22am
Reading your blog every morning, fret!
Hm... finding nothing new about that weird sending problem.
Don't forget it, please ...
I think "the mother of your children" is waiting for that, too. ;-)
Or is it already fixed???
28/05/2006 11:20am
No, we have a fix in place. I'm hoping it works for you too. I have just finished the mail2 export that needs to go in the next release as well so apart from clean up and so on, there is nothing outstanding for test3. I doubt I'll get it out tonight but in the next day or so I'll release test3 and you should try that. I'm hoping my fix works for you.
28/05/2006 8:20pm
Sounds good - thank you. :-)
Email (optional): (Will be HTML encoded to evade harvesting)
Remember username and/or email in a cookie.
Notify me of new posts in this thread via email.