> But it's pretty dumb risk, with no payoff to cover the risk of > screwing up the queue
The payoff is performance significantly beyond that of loopback SMTP. > since the gain in performance is nil That's not true, Len. Queueing up without incoming SMTP removes network overhead, and has no additional file I/O demands. (If you'd like me to do some hard benchmarks, let me know.) > the reliability across just Imail versions is not guaranteed. 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. For an in-house app, regression testing before rolling out an upgrade should be SOP. 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. -Sandy 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/
