In <[log in to unmask]> [log in to unmask] writes:
> Contrary to some of the other opinions on this list, I think Exchange is a ver
> ry
> good system. I speak from experience as I have used it for several years. It
> t
> has a lot of flexibility and is very stable, especially in the 5.5 version.
<rant>
I *strongly* disagree. While M$ bloatware seemingly works fine when commun-
icating strictly with other M$ tools, when it comes to interoperability, it's
horrendous.
I can quote (and have in other forums) half a dozen cases where Exchange/
Lookout blatantly violate or ignore Internet standards; this completely aside
from the load they've single-handedly inflicted on the 'net since their
introduction... Notice that instead of simple (short) text messages, M$
triples (or more) the size of every message sent over the 'net to include
their "cutesy" html alternatives (which you may have noticed are so hacked up
they shouldn't be labelled as text/anything since they're completely unread-
able except by other M$ clients).
If you've ever toyed at the SMTP levels, you might also notice that M$ is too
dumb/lazy/??? to ever refuse a message -- no matter how bogus the recipient
address is. Instead it *always* accepts the message, only to later have to
try and deliver a "new" "undeliverable notice" to the sender. So much for the
immediate notification many mail servers utilize when sending mail. To top it
off, the group that wrote Lookout's POP client functionality apparently used
the lame exchange server as a model, and in violation of the standards, their
client depends on whatever server they use never refusing a message. Point it
to a server that does (correctly) inform the sender that a recipient is
bogus, and the client used to gag (printing some kind of "tcp transport lost
error"). Later fixed to not gag as bad, but last I checked it still wouldn't
report back *which* recipient (if there was more than one on the message) was
the bad one...
I shudder to think of the tens of thousands of dollars in time/labor we've
personally spent "working around" bugs in M$'s mail package. Don't ever count
on M$ fixing THEIR bugs... at least not within our lifetimes.
</rant....for now>
> What you need to look at at this time, is MAPI. You will need to write a smal
> ll
> MAPI aware application on NT to which you will forward the message to be sent
> and the address(es) to which to send said message.
MAPI won't help them if the goal is to get messages "off" a 3000. MAPI's not
available for HP3000s (though "CMC" - the standard MAPI was based on is; in
our API product... <plug I suppose>).
Anyway... What you need is a mail "client" on the 3000, capable of sending a
message to a remote mail server (in this case Exchange). As a few other folks
mentioned, you have a couple choices; NetMail (our product) will do this
easily. Sendmail will also do this if you're a real do-it-yourselfer...
sendmail is a very powerful mailer, and it's configuration options can be
dizzying. Telamon also gives away a very basic mail client that will submit
a simple message to a remote server. Anyway, here's some pros/cons for you
(caveat that I am a bit biased, though I'll try to present a helpful
picture of all the options):
Telamon's mail client is easy to use and setup, but has no "retry" capability
(i.e. if the remote server is not available/down or the network is not
working the mail fails to be delivered. "real" smtp server systems have
built-in retry capability and can automatically use fallback hosts to deliver
to if necessary; both NetMail and sendmail fall into this category.
Both sendmail and NetMail will also utilize DNS servers to find alternate
mail servers (using "MX" records) if necessary. Probably not a concern in
your scenario unless your organization keeps banks of mail servers running
and counts on the failover capability.
A bigger issue for sites using Exchange is that sending plain text messages
to Exchange, you'll often find them "mangled" as Lookout...er.Outlook tries
to "pretty up" the delivered text. You'll find reports get words or lines
highlighted or bolded almost without rhyme or reason. Exchange also (in
violation of mail standards and common practices) linewraps your plain text
messages anywhere it feels like it, and in most of the versions of Outlook
I've worked with, will treat plain text messages as if they were encoded using
a method called "quoted printable". This means that if you are unfortunate to
include text strings that look like quoted-printable sequences, which are
=nn where 'nn' is a two digit number, you will find these sequences converted
to their 'ascii character' equivalent (i.e. =10 is a linefeed, =13 carriage
return, etc). Makes it fun it you ever e-mail a pc-style 'ini' file...
Your defense here is to encode everything you send to Exchange as text/html.
This can be done pretty easily (merely add a few html commands to the beginn-
ing of files you send, and make sure your mail client can attach the correct
MIME headersin the message). We include a command file 'sendhtml' that does
this for you with NetMail; I think someone else (Mark B?) posted a similar
command file for use with sendmail. Don't know if this is doable with the
Telamon client(?). Be aware that Exchange/Outlook is also very sensitive to
the exact MIME headers(labels) used; they disobey many defaults and even
appear to be case-sensitive in at least one case (which is another blatant
violation of the mail standards...but I digress ;-) ). You're also in for
more fun if you want to try and control how attachments are displayed (inline
versus treated as 'attachments'). Different versions of Outlook interpret the
headers differently (and ALL versions are wrong in different ways); you may
have to experiment with a given version of Outlook to get the message to
display the way you want.
And I guess (putting on the vendor's hat) I better throw in a couple of
blatant pluglets re: NetMail:
1) We also can auto-encode/auto-decode MPE files based on filecodes. Upload
a file to your 3000 (like an Excel spreadsheet, .exe, .zip, etc) and put
the appropriate filecode on it (we provide a copy of the official list,
though the codes are registered separately) and NetMail will automatically
label and encode (if necessary) the file when you attach it to a message.
2) NetMail has a batch interface easily utilized by command files (which we
include several samples of) to imbed mail-to jcl in job streams; and we
set various JCWs for you so you can check on the status of the message in
the JCL also
3) We provide an API (the CMC standard API, which MAPI was based on) so that
you could also write calls right into your programs to send a message,
lookup an address, pull mail out of a mailbox, etc.
4) Incoming mail (should you want to use it) can easily be routed (piped) to
any MPE command file. We've provided sample auto-responder examples; even
our 'listserv' (though not fancy) utilizes this easy-to-use but powerful
interface. Write your own program, have the command file pass it the body
of the message, let it read for commands, update a database...etc.etc.
5) Setup (after restoring files, which is usually <10 minutes) usually takes
less than 10 minutes. Mail to Exchange is one of our most common setups,
and if you don't feel like reading the manual, one of our support people
can talk you through the setup and have mail bouncing around in minutes.
6) It's supported. Reach us by phone (800 NetMail), Fax (503 361-8895), and
(of course) email: [log in to unmask]
</plugs>
sendmail and telamon's client are free. NetMail/3000 starts at $1500 (this
is the package you would use if you chose NetMail; unless you want to also
add the API which is a separate option). All three packages are available for
download off the 'net; we can also send you NetMail/3000 on tape/dds if you
prefer.
Actually, sendmail is really about $40 I believe.. as you're gonna need to
buy the O'Reilly 'sendmail' book for reference if you're going to use it. ;-)
Hope this helps...
-Chris Bartram
______________________/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
Chris Bartram Sales (US): 800 Net-Mail Fax:+1 503 361-8895
______ +1 503 361-8850 mailto:sales at 3k.com
/__ | \__________ Sales (Europe):+44(1480)414131 Fax:+44(1480)414134
/ / | / ________ Sales (Pacific):+61 3 9488 4333 Fax:+61 3 9482 5124
| /_ |< ______ Tech Support:+1 503 361-8833
\ __)| \ ___ mailto:support at 3k.com Me: rcb at 3k.com
\______/Associates, PO Box 6003, Springfield VA 22150
_________________Inc._/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_
Gopher: gopher.3k.com Anon-FTP: ftp.3k.com WWW: http://www.3k.com/
|
