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/