Welcome DeskLink Customers
This is the third e-mail newsletter sent to our DeskLink customers; it is intended to let those of you with support contracts know about new and planned features of DeskLink, along with a few tips on ways you can use the system you have which you may not be aware of. We will try to make this a regular feature (one issue every 1-2 months), while also trying not to take too much of your valuable time by sending too many issues.
Those of you with Internet e-mail addresses should receive this by e-mail, others will
receive it via fax. If you get a fax but have an Internet e-mail address you would prefer
us to use, please let us know. Those of you who do not want to receive any more notices
(these are intended to highlight features you have already paid for; not merely plugs for
additional products) may let
us know and we will remove you from the distribution list. Note that we will also use this
list to make you aware of important problems or bug reports if applicable, so I urge you
to have someone at your site at least review these messages. Also - anyone who would like
us to add other mailboxes to our distribution (others at your site that might be
interested) you may also let us know.
Now that we're done with that...
In this issue:
With the B.07 release of DeskLink, we have provided a choice in the interface you use when exchanging messages with HPDesk. Formerly DeskLink used only the FSC (Foreign Service Connection) gateway in HPDesk. This gateway, though generally reliable, has some failings and it's dependence on MPE message files causes occasional problems for those who encounter system failures (and thus must "recover" all message files that were open at the time of the failure). Also, the FSC interface did not allow us to provide complete distribution lists on messages going into HPDesk; we could only include the other HPDesk recipients in the distribution lists.
With DeskLink B.07 you now have the option of using HPDesk's Intrinsic interface with DeskLink. The Intrinsic interface uses a different means of transporting messages into and out of HPDesk. It works on all supported HPDesk sites (OpenDesk Manager and OpenDesk Manager Plus), and can run one the same system as the FSC process (at the same time even). In fact, existing FSC gateway users can configure an Intrinsic gateway and experiment with that interface while still using the FSC gateway for production. The new processes still execute under the same background job so no operational changes are required. If you do choose to run both simultaneously however, you may need to enter the other hostname in your DNS server(s) or hosts file(s).
The DeskLink installation supplement (available on our web site -www.3kassociates.com in the manuals area) has been updated to reflect instructions for setting up the Intrinsic gateway. The basic steps are similar to the FSC gateway; in Desk, set up the "igateway", create a location, then add a route from the location to the gateway. In NETMAINT, you use our new Intrinsic gateway setup screen to designate a hostname that points to the HPDesk Intrinsic interface (you can use one hostname to point to the FSC interface and another to point to the Intrinsic gateway simultaneously). To run both gateways simultaneously, your users will send outbound messages to the location which corresponds to the gateway the wish to use; inbound messages will be routed based on the hostname used (the gateway automatically appends the hostname that will route replies back via the same gateway as the message was sent out).
The big change HPDesk users will notice with the new gateway is that they will see complete distribution lists on messages they receive via the gateway. All addresses are reply-able, so reply-alls work in the HPDesk user interface as well as any of the OpenDesk clients.
HPDesk users beware - our contacts at HP inform us that there is a Y2K problem in HPDesk which causes the HPDesk user interface program to no longer run. If you try to run HPDesk after December 31, 1999, the program will halt and report an error something like "the software is out of date".
HP has a fix for this problem, but you will probably have to order it yourself (it may not make it into a general release). Call your HP support representative (or the HP Response Center) and request patch OD3013.
On a related note, there may also be issues (though not as severe) with the OpenDesk cc:Mail client in the 2000 year which may or may not get fixed by HP. If there are users out there using this client (and planning to keep using it in 2000, we'd be happy to forward requests back to our contact in the labs). E-mail us directly at "support@3kassociates.com" and we will forward your notes on to HP for consideration.
For those of you with direct Internet access from your HP3000 and MPE/iX 5.0 or later running, we have released a new patch process that makes getting software updates easier than ANY other HP3000 update process in the industry!
If you have received an update of the B.07 release of DeskLink or NetMail/3000 you will find a new job in the JOB.THREEK group. The job is called "getupd", and it "gets your update file". If you don't have it on your system already, you can get it by FTP'ing to ftp.3kassociates.com, login as anonymous, and "cd" into the "support" directory. The job is called "getupd.job" and is stored as a plain ascii file.
Just stream the job anytime you like; it will create a new group in the THREEK account (UPDATE.THREEK) and will retrieve (via ftp) the latest patch files and release documentation from our ftp site. You can review the update files; which consist of:
FIXINFO - program by program listing of all enhancements/bug-fixes by date FEATURES - new features for NetMail/3000 or POP Server users FEATURED - new features for DeskLink users
If you decide you'd like to install the patch, simply log on as MGR.THREEK and type :UPDATE.XEQ
The patches will be extracted and installed while you watch, and this process can even be run while others are using the NetMail or DeskLink software - including while the background job is still running. The whole process should take less than 5 minutes, and when complete, you merely need to stop and restart the background job to have the patches take effect.
NetMail/3000 interactive (terminal) users merely need to exit the netmail program and go back into it - and they need only do this at their convenience - you don't need to force them to logoff/etc. Upon restarting the program, they'll be using the new version.
The patch file is retrieved by the "getupd" job, and is about 6 Mb (it's a compressed archive file) so retrieving it make take a while if you have a slow Internet connection. You might want to schedule it overnight so you can review the changes and decide whether to process the update the next day.
**This process requires that you be able to ftp from your HP3000 and that you be running MPE/iX 5.0 or later. If either of these aren't true, you won't be able to use this update process, though you can still pick up updates from our web or ftp sites which can be installed using Reflection, or contact us and have an update sent to you.
Whenever another mailer connects to your system to deliver e-mail, the first thing that mailer receives is the equivalent of a "welcome" message; by default, NetMail/3000's "welcome message" looks something like this:
220 NetMail/3000 B.07 98/03/20 @RIKER.3K.COM Ready Tue, 14 Apr 1998 17:17:44
Most end-users never see this message (though you can if you want to by simply running any TELNET program and connecting to a system on port 25); but mail logs on many systems do sometimes record this information.
What this means is that for those of you with no-spam policies (i.e. you don't want any and actively follow up on received spams) you can add just a little ammunition to your "legal" standing by enhancing your mailer's welcome message to indicate your policy. 3k actually experimented with billing spammers for messages they sent to our business address (with little success so far however) - though at least one other site we know of has done the same with much better success (and actually collects some "fees" for processing unsolicited e-mails - congrats Joe!). Anyway, here's a sample message - the one we use on our primary mail servers:
220-NetMail/3000 B.07 98/03/20 @RIKER.3K.COM Ready Tue, 14 Apr 1998 17:26:54 - 220-Unsolicited commercial e-mail is *NOT* welcome here! 220-Review fees of US$250 per message will be billed for unsolicited 220-commercial e-mail. Our receipt of such messages constitutes your 220-agreement to pay this fee. 220-E-mail relay services are subject to a US$10/recipient charge when 220-arrangements are made in advance. A US$1000 per incident charge will 220-be made for relays made without prior written permission, in addition 220 to per-recipient charges noted above.
Every line except the first is taken verbatim from a file called SMTPMSG in DATA.THREEK. The file will be appended to the mailer welcome message only if it's present and accessible (we don't ship this file so if you want one you'll need to create it). It's a normal 80 byte ascii file created in an editor (kept UNNUMBERED). You can put whatever you want in it, but be aware of *two* IMPORTANT notes:
Most of you probably know that you can redirect mail to a given mailbox by setting "forwarding" information on that mailbox; administrators can do this by setting the "forward to mailbox" and "on node" fields in the Netmaint mail user's screen. Likewise HPDesk users can set their own forwarding address from within HPDesk.
Yet another means of forwarding mail exists, copied from the Unix world; an "aliases" file (from the /etc/aliases file used by Unix mailers). Our aliases file must exist in the DATA group of the THREEK account, and is simply a 72 or 80 byte ascii text file which you can create in any editor. (Keep the file UNNUMBERED though!)
Aliases records look like: oldadress@somehost.com:newaddress@myhost.com
On the left side of the colon (":") is an incoming address, which should be fully qualified (i.e. use "name@host.domain.org" not just "name"). Any mail that comes into the system *VIA SMTP* from another system will automatically be redirected to the "new" address (the address on the right side of the ":").
Note that only *one* address may be on each side of the ":", but you can have as many address-redirections (one per line in the file) as you like. Also, the *new* address may be a local address, a remote address (i.e. on another system entirely), or a local (publicly available) mailing list name.
At first glance, this may seem a bit redundant. After all, you can accomplish basically the same thing using the above mentioned methods. While this method is slightly easier to maintain, it does have one more important advantage.
DeskLink has the capability to allow any given machine running it to accept mail for any number of domains (we have 15-20 on one of our mail servers!). However, since mailbox names are unique, if each of these domains wants their own "sales" or "info" mailbox, and DeskLink can only allow one "sales" or "info" box, how do you accommodate them all? By using the aliases file. For instance, some sample entries from an aliases file:
sales@3kassociates.com:sales-us@3kassociates.com sales@businesscyberlink.com:sales-sc@3kassociates.com sales@hpmemory.com:mikeo@hpmemory.com sales@3000newswire.com:rseybold@zilker.net joe_user/loc1/sl@hpdesk.acme.com:wil_e_coyote/acme@roadrunner.com
All these domains may point to the same machine (you need only enter a host entry in netmaint for each and tell DNS to point to that machine for e-mail) and now each can have their own (virtual) sales mailbox.
(Remember to use the "alias" type of host entry; i.e. IP address of either all zeros -for DeskLink- or all 255's -for NetMail- and a network of all "9"s.)
Some of you may have noticed that by default, messages that arrive in HPDesk without a specified subject on them end up with the rather boring "FSC INPUT DOCUMENT" as their subject. You can have DeskLink replace this with a slightly more friendly "[No Subject given]" subject line by setting the JCW "DESKADDSUBJECT=1" in your DeskLink job stream.
DeskLink users tired of seeing "forwarded" messages (including those messages auto-forwarded from their HPDesk mailbox) show up with the original message in an "attachment" now have an option. By setting the JCW DESKPROCESSRESENTS =1 in the DeskLink job, forwarded messages will be tagged with "Resent" headers (i.e. resent-from; resent-to:, etc.) mixed in with the other headers of the message, and the text of the message will NOT be imbedded as an attachment.
The only downside to this process is that some mail clients still do not understand (or simply may not display Resent- headers) even though they were defined with the very first Internet mail standards back in the 1970s. So, if you or your users have such a client, getting one of these "resent" messages may be a little confusing (i.e. figuring out who it was from or what address it was actually sent to). Caveat emptor. Most users won't have any problems with the new format (and will probably prefer it to the "imbedding original messages as attachments" format) but be aware of all possibilities.
Now for users with periodic mail transport problems or those that just want to track in more detail the "comings and goings" of mail traffic through their systems, we offer a feature set we call "extended logging".
Extended logging can be enabled on a per-module basis to track only the type of events you are interested in. Extended log records are written to the file "extlog.netmail.hpoffice". If this file is not present on your system and you wish to use extended logging, you will need to build it:
:BUILD extlog.netmail.hpoffice;rec=-132,,f,ascii;disc=100000;cir
Once you have the file built, you can enable logging by setting the EXTLOGGING jcw in the DeskLink job (check the comments in the job for instructions on how to do this and what modules are available). You can also enable extended logging temporarily (while the DeskLink job is running) by using the command file "extlog.xeq.threek". Invoking this command file with a parameter to enable extended logging will set the flag within the job until that job logs off or until it is changed by another invocation of the command file.
Extended logging records all protocol-related transactions. Opening connec- tions to other hosts or receiving incoming connections, doing dns lookups, and all SMTP commands passed between computers are also recorded. Log records are plain ascii text beginning with a "<" (an incoming message) or a ">" (an outbound message), followed by a date/time stamp, then the PIN# of the process reporting the message, then the module name, finally followed by the actual message text. Note that since all modules record to the same file, multiple conversations may be intermixed in the file and you should utilize the PIN#/module names to track individual processes. A sample of what you might see in the extlog file if you have enabled logging for the SMTPOUT module:
>1998050113251006/64/SMTPOUT/Mail Queue delivery attempted for host=xyz.com >1998050113251008/64/SMTPOUT/Looking up the host. >1998050113251904/64/SMTPOUT/Done.
These records indicate the mail queue attempting delivery for a given host, dns lookup works (no error about it not being found) after which it quits. This indicates that it was unable to establish a connection to the remote host at this time. If it had, you would see records before the "Done." line looking something like:
>1998050419112204/54/SMTPOUT/Opened SMTP conn >1998050419112606/54/SMTPOUT/HELO PICARD.3K.COM <1998050419112606/54/SMTPOUT/250 Hello PICARD.3K.COM >1998050419112607/54/SMTPOUT/MAIL FROM:<RCB@3kassociates.com> <1998050419112607/54/SMTPOUT/250 Ok >1998050419112703/54/SMTPOUT/RCPT TO:<sales@xyz.com> <1998050419112710/54/SMTPOUT/250 Ok >1998050419112808/54/SMTPOUT/DATA <1998050419112820/54/SMTPOUT/354 Send us your data. <1998050419112903/54/SMTPOUT/250 SAA25948 Message accepted for delivery >1998050419112906/54/SMTPOUT/RSET <1998050419112907/54/SMTPOUT/250 Reset state >1998050419112908/54/SMTPOUT/QUIT <1998050419112909/54/SMTPOUT/221 closing connection
Those familiar with "SMTP" will immediately recognize the dialogue. Even those who haven't been exposed to this level of mail transport though should not have much trouble interpreting what is happening. More importantly, it should be easy for even relative novices to be able to identify problems in mail conversations or repeated failures to deliver mail. All exchanges are recorded - EXCEPT the actual contents of messages.
SMTPSERV, the corresponding module that handles incoming mail messages will report similar dialogue, though the sender/receiver roles would be reversed. In all, there is a substantial amount of information in these log records; so much so in fact, that we do not recommend you leave the extended logging enabled for too long without monitoring it. The file we have you build is a 100,000 record circular file, which on a moderately busy mail server could easily fill up (and start rolling over) in a day or two. You may be surprised at the amount of transaction data that can build up very quickly.
There are RFCs (Internet standards documents) available that define exactly what the commands being exchanged are and their syntax - if you don't know where to find them feel free to contact our support personnel.