MAPI v. Outlook API

  • Thread starter Thread starter Siegfried Heintze
  • Start date Start date
S

Siegfried Heintze

Does the Outlook API supersede MAPI?

If I implement a SPAM filter using MAPI to automatically delete messages
from the message store, will other clients like Eudora benefit?

If I implement a SPAM filter using Outlook to automatically delete messages
from the message store, will other clients like Eudora benefit?
Thanks,
Siegfried
 
Siegfried,
Does the Outlook API supersede MAPI?
You may want to ask this question "down the hall" in one of the Outlook,
Exchange or Messaging newsgroups. If you have not already. Not sure which
one:

I would start with one of these:
microsoft.public.exchange.clients
microsoft.public.outlook.program_forms
microsoft.public.platformsdk.mapi
microsoft.public.win32.programmer.messaging

The short answer is: My understanding is that the Outlook API supersedes
MAPI, but you still need MAPI to do some things... Just like you need CDO to
do some other things. (I liken it to taking a Knife, Hatchet & Saw camping
with you, all three "cut things" but each has a specific use).
If I implement a SPAM filter using MAPI to automatically delete messages
from the message store, will other clients like Eudora benefit?
By MAPI do you mean Extended MAPI or CDO? Client side or server side?
If I implement a SPAM filter using Outlook to automatically delete messages
from the message store, will other clients like Eudora benefit?
I can check with some friends, if I find out anything I will get back to
you.

Are you working against an Exchange Server or something else?

Hope this helps
Jay
 
I definitely need to be SMTP server brand neutral.

I'll check out those other links too.

Can I assume that if I use CDO, I'm no longer SMTP server neutral?

Siegfried
 
Siegfried,
I definitely need to be SMTP server brand neutral.
Don't you mean POP3 server brand neutral, as SMTP is for sending mail, POP3
is for receiving mail. Also don't forget about IMAP.

No CDO is not SMTP or POP3 server neutral, per se. Remember CDO & Outlook
are built upon Extended MAPI, they all assume you want the mail local.

I got a couple ideas back from some of my fellow Outlook MVPs.

Rather than paraphrase it, one suggested: "AFAIK, the only way to write a
spam filter that works with multiple clients is to access the original Inbox
on the server directly. Most do it by downloading to a locally installed POP
server, which Outlook (or another client) must then connect to."

Which I think might be a 'better' approach for you.

Matthew MacDonald's book "Microsoft Visual Basic .NET Programmers Cookbook"
from MS Press covers a simply class that will receive mail via POP3. You
could extend this class to offer mail via POP3. This class would then filter
the mail. Taking this approach I would consider creating it as a Windows
Service project.

Hope this helps
Jay
 
Back
Top