>That's not true, Len. Queueing up without incoming SMTP removes >network overhead
delivering memory-to-memory to the local tcp/ip tcp port is a noticeable overhead, especially given that nearly all Imail servers have much idle MHz,a and given the SMTP is probably the most reliable, tuned modules in the IMail suite? You're splitting theoretical hairs, there is no practical penalty writing to port 25, with a huge gain in portability and stability. >True, it's not guaranteed. But since Imail's own modules (IMAIL1, >IMAILSRV) write directly to the queue, it's pretty easy to tell when a >change has been made. jeez, why bother trying to detect changes and test it when a new version comes out? plus when it does change, you have to change your code, test, install, support, etc. >rolling out an upgrade should be SOP. exactly, so use SMTP for sending mail and forget the direct i/o to queue files. > For a shrink-wrapped app, the >risk is greater, but still may be acceptable--witness the JIT upgrades >that Scott and Ron have had to make to their products on occasion due >to unanticipated shifts in the underlying architecture. These >occasional glitches don't prevent them from trusting Imail as a >pluggable system. The RFC SMTP protocol will always be more stable and therefore more trustable as a programming interface than a proprietary, undocumented, unsupported interface. Len www.menandmice.com/8000/8100_course_schedule.html: DNS Training http://BIND8NT.MEIway.com : ISC BIND for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Please visit the Knowledge Base for answers to frequently asked questions: http://www.ipswitch.com/support/IMail/
