SMTP or MAPI
The following is made from
a thread on news.softvelocity.com, Topspeed.Topic.Third_Party group entitled
"SMTP or MAPI – Pros and Cons", started by Jono Woodhouse on 31 July 2003
Question: What's the difference between SMTP and MAPI
Email Sending? Which one is better?
Answer: The answer to this question really lies in what you are trying to do.
Below is a list of Pros and Cons for each, which should help you make a good
decision.
MAPI Pros:
- Can interface directly
into the users Inbox and Outbox.
- If the user has already
configured MAPI on his machine, then no extra setup is required.
- All mail is routed through
the users Outbox, so a copy is automatically kept in the Sent folder
- If the user doesn’t
have a permanent Internet connection (ie has Dial-up), and MAPI is already
installed (and configured) then your program works, out-the-box very nicely.
MAPI Cons:
- Not all email clients
support MAPI. (For example some of the earlier versions of Outlook Express
didn't support it). Does anyone know if Netscape Mail, Eudora support MAPI?
Pegasus does not support MAPI.
- Outlook Express 5.0 and
younger require you to turn on MAPI in their settings.
- Different versions of
Windows support different versions of MAPI.
- You may have no control
as to what email client your customers are going to be running.
- If your application gets
run on a server, there is no guarantee that an email client is installed on
the server machine.
- If Betty in the office
decides she's going to change her email client to Eudora (or whatever), your
application will not be able to detect this?
- What happens if Tom decides
to re-install Windows and suddenly your application stops sending email?
- If you are writing a
multi-user application (i.e. server and EXE sit in one place, many workstations
run the application), you could end up with a situation where some workstations
can send emails and others can't.
- Some people don't like
emails being added to their outbox. (Specially if it's a bulk email application
that sends out 500MB of emails<g>)
- Some folk don't want
an application changing the emails in your Inbox, marking messages as read,
deleting messages etc. (For example: My PDA can talk with MAPI software on
my PC. If I look at a message in my PDA it marks the message as read in my
Inbox (plus there is no way in my PDA to mark it unread again). Further more
it will delete the message in my Inbox if I delete the email in my PDA. I
get tons of emails, but only want a few in my PDA.)
- Because each machine
has to be configured separately, it can make installing on a network time
consuming.
- Different Email clients
can behave differently when emails are sent in this way. For example Outlook
opens a confirmation window for each email, Outlook Express does not.
MAPI Solutions:
SMTP Pros:
- Completely independent
of the user's email client. (You can of course send emails that can read be
read in email clients and receive emails that were written in an email client).
- Sends email directly
to or from an SMTP Server.
- In a multi-user environment,
you only have to setup your email settings once on the server, and then no
matter how many changes there are to the workstations email clients, windows
versions your application keeps working.
SMTP Cons:
SMTP Solutions:
SMTP Tips:
- If your clients prefer
to retain copies of the emails that your applications send in their Sent Items
folder, you can CC the email to your client (typically the sender) and setup
a message rule so the email is forced into the client's Sent Items or any
other folder.
Some General comments from Users :
Gus M. Creces
- The Clarion Handy Tools Page
Here's my experience - from the perspective of someone who uses both MAPI and
SMTP. Each has a place and a reason for being.
MAPI has been around for quite some time. It's mainly a MS standard which MS
themselves don't always follow.
The idea of MAPI is that your application can control the MAPI-compliant email
client on your computer in order to send and receive emails. There is
a standardized set of (M)API calls that allow you to do this. 4-5 years ago
when our toolkit introduced MAPI classes and templates we did an extensive
survey to ascertain MAPI compliancy for various email clients out there. We
found various levels of compliancy, with only the MS products Outlook and
Outlook Express working 100 percent reliably and storing registry values in
a consistent way so that it was easy to determine which client was
installed, etc. etc.
Since MS has gone on it's security-above-all kick they've basically made Outlook
(I don't mean Outlook Express) totally useless as a MAPI client. It
still works but is a pain in the butt to use because of the nags that come up
and can't easily be made to go away. While Outlook used to work really
well via MAPI, I've been telling our users for over a year now to avoid it like
the plague if they possibly can.
Outlook Express, on the other hand, is - an continues to be - a marvelous MAPI
client and you can make it jump through hoops. Now to all those MAPI
nay sayers let's use a little imagination. So you don't use OE and nor do your
customers, you say. Ergo you're MAPI dead in the water, you say.
Consider that Outlook Express these days is really part of the operating system.
Just like Internet Explorer is part of the operating system. Despite
what the US Justice Department would have you believe. You have to work hard
NOT to get it installed with your XP or Win2K installations. Since it's
almost defacto nowadays, it's there whether you or your clients use it or not.
And it can be utilized by your applications for sending and receiving
purposes. Despite what you've been told, a MAPI email client is no harder (or
no easier) to configure than an SMTP client. In fact, the information
required to make either one work is identical - SMTP server and local email
address (for outgoing), POP server (if you want incoming) and Email account
name, and email account password (again to satisfy incoming mail requirements).
If OE already has one or more email accounts set up, your MAPI program can present
a list of them to the user and ask which should be used, or it can
simply be made to use the default account. That being the case, your user needs
to do nothing to make your email work application work. If OE does not
have any accounts set up you have to provide instructions on how to configure
one or more OE accounts or you can simply pop up a Clarion dialog
window the way you would have to anyway for an SMTP configuration, and collect
the necessary email account information, drop it in the registry for
OE to use and you're off to the races. OE does not have to be your default email
client. It's easy enough to determine the default email client when
your app does its thing, swap it out for OE, do your thing with OE, and swap
it back. All of this could be done even with an existing default email
client running in the foreground or background.
So, to review, since O.E. is essentially a part of the operating system, you
can rely on it to be there, and warn if it isn't. You can configure it, and
use it in the background (or foreground) the way you use other operating system
features, DLLs and API's. It can send and receive and redirect as
necessary. It logs all incoming and outgoing mail for you at no extra programming
cost to you. (unlike SMTP) We've even figured out how to make it
into an email scrubber and how to make bulk mailings (where we don't necessarily
want every outgoing mail item logged into your outbox) go away.
Because it's also a NNTP newsgroup client you can treat newsgroup messages just
as if they were mail, vetting, scrubbing, massaging them into standard
data bases. All this power comes built-in.
The CHT toolkit also has an SMTP implementation. SMTP has some advantages when
it comes to transport-style email and structured, HTML-style mail. But
configuration wise, it's no easier to get up and running than MAPI. In fact,
where we're presenting an SMTP configuration dialog, we generally look at the
Registry to see if Outlook or OE don't already have an account set up that lists
the SMTP server and local email address and we present that as a
starting point.
Which methodology you use is really tied the intended outcome required by your
application. Sometimes it's just a matter of personal preference. I use
both depending on intended use.
From Bruce
Johnson - CapeSoft
Apparently more recent Windows releases are better, but in the "old days"
(win 95, 98, me) MAPI was an optional component. Some machines didn't have MAPI.
And it seems to vary a lot from one email client to the other.
In my situation I can afford to document, and get the user to set up (once)
the correct SMTP settings. What I can't afford is to have to revist the client
every time they do a mail-client, or windows re-install (or upgrade).
If MAPI was 100% "just works" on every machine then I think it would
be an ideal solution.
From Darron Pitman
The program I use it in mainly is used by Joe Public on personal home PC or
small businesses/police forces - they, I am happy to report have no
problems - if I used SMTP they would and I would be receiving a lot of calls.....
about how to set it up.....
The main used function in this app is email to multiple recipients using BCC
- no problems reported with that either........
Now if SMTP could be installed transparently and used transparently I would
have no problem switching - but then again - I think they also like the sent
box to hold a history.....
A small app I sell on the side is neighborhood watch usually run by elderly
people....
Ask them to enter pop3 or relay account details and I think their eyes might
glaze over - equally in Local Authorities - end users wouldn't have a clue
what you were talking about. In UK in corporates IT depts are so bad - they
are a last recourse......
From Benjamin
Krajmalnik
I run an application written in Clarion as our core business application. Up
until Office 2K, everything worked fine. As of Office 2002 things went
awry.
The problem is that MAPI is not always implemented the same. If the MAPI client
is Outlook 2002 (not Outlook Express) there are issues. I cannot
recall right now if it had problems with multiple recipients or multiple CC's,
but there was definitely a problem. The code was based on the simple
MAPI code available as one of the examples in one of the kb's.
OTOH, SMTP is rock solid - much more so than MAPI. Also, the issue of connectivity
is becoming less of an issue as broadband is
adopted. The way around this is simple, even for a small network. You run an
internal SMTP server - that way you never loose your e-mail. The SMTP
server will in turn make the required connection.
As for having a copy of the e-mails, well, this is definitely an issue in some
cases. The solution isn't one or the other, but rather what the
end-user requirements are.
Disclaimer
: This article is the opinion of the author/s, and is not necessarily the opinion
of any other person or company.
Specifically it may not be the opinion of the owners, or host, of this site.
