Bob,

I  was addressing my description of the architecture to a general list
audience,  so  some  expansion  may  be  in  order.  But your response
contains several crucial errors.

> Actually,  except  under a couple of circumstances, WM just drops it
> in the queue.

Huh???  This  is patently untrue. According to repeated API traces, WM
runs  IMAIL1.EXE,  and unless MaxQueProc would be exceeded, IMAIL1.EXE
in  turn  runs SMTP32.EXE. The only time files would simply be left in
the  queue  for  the  next  queue  run  is if all SMTP32 processes are
exhausted.

> When  the SendName is called for a queue run the third party program
> could  check  for  new  files in the queue prior to calling the SMTP
> deliver process.

How  do  you  make  sure everything's undeliverable the first time--by
downing  your  router?  This  is  not  viable virus protection, and is
actually  pretty  silly.  One  cannot  possibly expect the SendName to
touch WM files simply because some may be deferred!

> An  alternate  way:  The  way  that  WM  drops it in the queue is by
> calling  IMail1.exe  (with  parameters).

You're  leaving  out  a step again: IMAIL1.EXE is hard-coded to launch
SMTP32.EXE  immediately  against  the  Q  file...this  is  not  simply
"dropping in the queue"!

> So the message could be intercepted with an IMail1 wrapper there.

By  "wrapper" you mean impersonating the executable; while that's just
the  sort  of  thing  I  love  to  tinker with, that's an embarrassing
workaround  for  a  broken  feature.  And  this  exactly what the beta
Declude  architecture  does, though it impersonates SMTP32.EXE instead
of  IMAIL1.EXE  for  continuity.  The  fact  remains  that SendName is
totally  ignored by Web Messaging, or this type of dual implementation
wouldn't be necessary.

> Under  the  exception  circumstances  WM  sends directly to the SMTP
> service, which puts the message in the loop.

I  won't  even  ask what those exceptions are, though they are further
examples  of  WM  ignoring  the  ostensible  "hook"  provided  by  the
SendName.

> And  IMail  AV  doesn't "hook" WM. We own the delivery process so we
> wrote the hooks into it.

That's true, IMail AV certainly doesn't have to do anything special to
get  messages  from SMTP32, since SMTP32 was rewritten specifically to
take  advantage  of  IMail AV. Perhaps it would be more appropriate to
say  that  SMTP32  hooks  IMail  AV.  Whatever the language, it is the
proprietary  daisy-chain  of  WM,  IMAIL1,  and SMTP32 that breaks the
SendName feature.

-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/

Reply via email to