Hi Dev,
Sounds like you've found nearly all the issues we're running
across as well (Mainly WebMail responding to the wrong
interface/network). We're in the process of shelving 9 Imail servers
and moving to something more stable, hopefully with a company behind it
that will admit and correct bugs instead of making excuses for them.
-Mark
-----Original Message-----
From: Dev [mailto:[EMAIL PROTECTED]]
Sent: Sunday, December 29, 2002 12:43 PM
To: [EMAIL PROTECTED]
Subject: Re[2]: [IMail Forum] FIXED! Imail SLOW When Running On Fast W2K
Hardware
(Todd, sorry about the late response--I missed your
post to the list and happened to see it in the
archive.)
Congratulations! Glad myself and others could be of
some help in your success!
I've been wondering why Imail is the ONLY app flummoxed
by certain high-end NICS, and then only on Win2000
machines. I haven't done any serious coding in 20
years, so I will have to leave it to people far wiser
than myself to figure out if these observations relate
at all:
1. If I understand correctly, W2K's I/O Manager
apparently handles integrated systemboard devices
during startup differently than the devices found on
the PCI bus. Perhaps this is why I had to disable the
NIC in the BIOS to completely fix the issue. Not sure
exactly why mind you, but it may be a starting point
for further investigation.
2. Windows 2000 made significant revisions and
enhancements in I/O processing and thread handling.
Perhaps the way W2K now handles certain Imail calls
"behind the scenes" brings out a nascent timing issue
in some poorly-written Imail code--and then only in the presence of a
very fast bus/processor/NIC.
3. The above assumes that Imail code is not taking any "shortcuts" in
the way it handles I/O. This is speculation, but I now suspect that the
programming team is being forced to patch an ageing core codebase that
has deep structural flaws dating back to the original 1996 release.
Evidence? Try Imail's continuing inability to associate a socket to a
specific local IP address--and this in a $1000 program marketed in 2003!
This "let's bind to all IP's" silliness is simply
intolerable--especially on busy multi-site webservers and dual-homed
boxes. For users, it contributes to WebMail often being slow and glitchy
while the iwebmsg server inanely responds on the wrong local interface.
So if it's not some gawd-knows-what structural
limitation leftover from Imail's programming roots, why
doesn't Ipswitch simply use SOCKADDR data with BIND and
fix this serious issue once and for all? After years of deafening
silence on the subject, the only conclusion we're left with is that they
CAN'T--without rewriting most of the code. I sincerely hope Ipswitch can
and will prove me wrong on this point, but I doubt it.
All that being said, I'm still eagerly looking forward
to whatever incremental improvements and fixes are
slated for 7.14. (And hopefully a COMPLETE rewrite for 8.0--including
native IPv6 support.) But if Ipswitch doesn't address some of these
absurdly longstanding issues SOON, I'm done recommending Imail--and any
non-Exchange mail servers I build for clients in the future will likely
be Linux-based.
Todd, congrats again on successfully making Imail
behave in a fast W2K environment--and for sparking
several VERY interesting threads!
Best Regards,
Dev
--------------
Dev Anand MCSE,CCNA,A+
Network Manager
Biomorphic VLSI, Inc.
Westlake Village, CA 91362
dev_at_biomorphic_dot_com
pcpro_at_vcnet_dot_com
Thursday, December 19, 2002, 5:06:52 AM, you wrote:
TR> Folks,
TR> I have successfully gotten my mail upgraded to Windows 2000. I
TR> followed Dev's suggestions and everything is working fine now. I am
TR> not 100% sure that I would have had the problem after the upgrade,
TR> however. Originally when I encountered this problem, I move IMail
TR> from an NT4 BDC (Dell Poweredge 1400 866Mhz, Intel Pro100s) to a
TR> Windows 2000 DC (Dell PowerEdge 2550 1Ghz, Intel Pro100s, BroadComm
TR> Gig) as a temporary step while I rebuilt the original mail server as
TR> Win2000. But I never got that far because it ran like crap on the
TR> 2550. That's when this whole thread started.
TR> Because of installing IMail, removing IMail, enabling NICs,
TR> disabling NICs, adding different NICs, and a few other domain
TR> related issues, I had serious AD replication problems that took a
TR> lengthy phone call (5.5 hours) to Microsoft to clean up. So I
TR> decided that I will NOT experiment on my live 2000 domain to get
TR> IMail working.
TR> Soooo...what I finally did was to build a second NT BDC and
TR> temporarily move mail to it. Then I wiped the original mail server,
TR> put in a 3C905C, disabled the onboard Intel NIC in the bios, built
TR> it as 2000 (member server), installed IMail and tested. Seemed to
TR> run OK. Waited a few days to see how it ran. Once I was satisfied,
TR> I promoted it to a DC and again watched for problems. Still OK.
TR> This morning I moved the mail to it and downed the old NT4 box. So
TR> far so good. IMail is once again screaming but this time on 2000.
TR> No more NT! Yippee!!
TR> It kinda bothers me that I won't really know what fixed the problem
TR> since I am not running IMail on the same machine I where I
TR> originally had problems. But I don't want to jeopardize my domain by
TR> testing on that machine. But it's now working and I am pretty
TR> confident that disabling the Intel NIC in hardware and installing
TR> the 3c905c is what made it work. And that probably would have
TR> worked on the 2550 as well.
TR> Many thanks to Dev and everyone else who invested significant
TR> amounts of time and brainpower on this one. I would still like to
TR> hear from others who had the same problem and if these steps took
TR> care of it.
TR> Thanks everyone! This group of folks is an incredible resource!
TR> --Todd.
TR> ----- Original Message -----
TR> From: "Dev" <[EMAIL PROTECTED]>
TR> To: <[EMAIL PROTECTED]>
TR> Sent: Wednesday, December 11, 2002 1:32 PM
TR> Subject: [IMail Forum] FIXED! Imail SLOW When Running On Fast W2K
TR> Hardware
>>
>> Hopefully the following may be of some help to others.
>>
>> I had a similar problem as Todd. Here is a part of his
>> thread:
>>
>> http://www.mail-archive.com/[email protected]/msg59929.ht
>> ml
>>
>> In my case, an existing NT4 Imail installation was
>> moved to a new, very fast (P4-2.4GHz/512MB) Dell
>> PowerEdge running W2K, hardware RAID, Imail 7.13, and
>> KWM 3.0.
>>
>> The result? We had inexplicably slow logins, flaky mail downloads,
>> GLACIAL webmail, and random SMTP/POP hangs--and all with CPU
>> utilization near ZERO. Oh yeah, and a lot of ticked-off users!!
>>
>> Anyway, after a week of debugging, hardware swapping,
>> cloned testbeds, performance logging, and analyzing
>> over 200 MB of packet captures, I now have it humming
>> along quite nicely, thank you.
>>
>> The usual caveat here: The following fixes worked for
>> me, your mileage may vary. :)
>>
>>
>> 1. My dual-homed Dell server was equipped with an Intel Gigabit
>> ethernet integrated into the motherboard, along with an Intel
>> Pro100/S NIC. I noticed in a post that Todd extracted from Ipswitch
>> TechSupp the stunning admission that Imail is incompetent at reliably
>> communicating with two popular server adapters:
>>
>> http://www.mail-archive.com/[email protected]/msg59332.ht
>> ml
>>
>> Guess what? Tech support is right. My tests showed that Imail would
>> randomly just stop communicating for varying periods of time over
>> these two adapters. This particular "going into limbo" issue was
>> resolved by replacing them with two 3C905C's.
>>
>> Note that to fully eliminate this issue, it was
>> necessary to completely DISABLE the onboard Gigabit
>> Ethernet adapter in the server's CMOS setup. The second Intel Pro
>> adapter card was also physically removed from the box.
>>
>> ISSUE SUMMARY: No fast, server-quality NICs are allowed within sight
>> of an Imail box. Ipswitch apparently wants us to continue running the
>> latest 1998-era hardware. :)
>>
>>
>> 2. Packet captures indicated that Imail did not like operating over a
>> NIC with more than one IP address assigned to it. This may be
>> somehow related to the Imail programming blunder of binding to all IP
>> address. Inexplicably, the speed of the machine may also play a
>> role, since an identical multiple IP setup cloned to a
>> P2/266 had no such Alzheimer's issues. And yes, the
>> Imail address WAS the primary IP. The fact is that
>> removing the second IP on this P4 made a HUGE
>> difference in Webmail stability and speed. It doesn't
>> make sense, but as I said, YMMV.
>>
>> ISSUE SUMMARY: Only one IP address per NIC on a Pentium
>> 4 box running Imail.
>>
>>
>> 3. Once the above was sorted out (users--especially WebMail--noticed
>> a HUGE difference in performance and reliability with the two fixes
>> above), there was still a mysterious 1.5 - 6 second delay on some
>> incoming SMTP and POP sessions.
>>
>> The cause? In this case, it was NetBIOS name lookups
>> timing out.
>>
>> To verify the problem, look for this unanswered NBT
>> query request string in your packet
>> captures: "*<00...(15)>"
>>
>> Without getting too involved in the machinations of
>> NetBIOS or of our internal network and firewall layout, basically
>> Windows 2000 (or perhaps a 'getHostAddress()' call by Imail) was
>> insisting on performing an unnecessary reverse lookup (computer name
>> from IP
>> address) on the incoming connection. It was sending a
>> node status request directly to the perceived
>> source--my NAT Public IP address (the equivalent of a "nbtstat -A
>> <ip_address>").
>>
>> The irony? After NetBIOS repeatedly times out and
>> finally gives up trying to resolve the name, W2K then
>> simply ignores the timeout and successfully proceeds
>> with the SMTP/POP connection! Sheeesh!
>>
>> The solution? If the NetBIOS query can't be resolved
>> with properly configured WINS/DNS, go into the HOSTS
>> file (systemroot\winnt\system32\drivers\etc\) on your
>> Imail box and give the IP address query that is timing
>> out a name to satisfy the lookup. In my case (failing
>> to resolve the NAT Public IP), this is what it looks
>> like:
>>
>>
>> 127.0.0.1 localhost #existing entry
>> ... ... #more existing entries
>> 207.178.203.99 anyname.mydomainname.com #BINGO!
>>
>>
>> Note that the NetBIOS timeout issue was not present on
>> an otherwise identically configured NT4 box.
>>
>> ISSUE SUMMARY: Look for unexplained response delays of multiples of
>> 1.5 seconds. If you have them, sniff the wire (make sure to check ALL
>> interfaces on multi-homed
>> boxes!) for unresolved NetBIOS queries. If necessary,
>> simply create a suitable Hosts file entry to make
>> Windows happy!
>>
>> By the way, the Hosts file is checked every time name resolution is
>> attempted. Changes in it take effect immediately and do NOT require a
>> reboot!
>>
>> As I said, the box absolutely rocks now. I don't claim
>> to know why some of these fixes worked, just that they
>> did. Perhaps this will provide a helpful starting point
>> to others facing similar inexplicable slowdowns.
>>
>> Cheers,
>>
>> Dev
>>
>> --------------
>> Dev Anand, MCSE,CCNA,A+
>> Network Manager
>> Biomorphic VLSI, Inc.
>> Westlake Village, CA 91362
>> dev_at_biomorphic_dot_com
>> pcpro_at_vcnet_dot_com
>>
>>
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
