Welcome NetMail/3000 Customers
This is the third e-mail newsletter sent to our NetMail/3000 customers; it is intended to let those of you with support contracts know about new and planned features of NetMail/3000, 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.
Finally, if you have questions about NetMail/3000 or any other 3k Associates product (DeskLink, PopServer, Gopher Server, Ftp Server, Fax Server) feel free to give us a call at +44 1480 492400 or e-mail us at sales@3kassociates.com or support@3kassociates.com.
Now that we're done with that...
In this issue:
1) A new/easier patch process for Internet users 2) Support for Minisoft MS92 "save file" format in NetMail/3000 3) Making your mail system "spammer unfriendly" (SMTPMSG file) 4) Redirecting incoming mail (using the ALIASES.DATA.THREEK file) 5) A sample command file to e-mail from an application 6) Sending HTML mail files 7) Configuring "auto-cleanup" of old mail messages
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 rocess 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.
Good news for Minisoft MS92 (Win92) terminal emulator users; NetMail/3000 can now attach mpe files encoded using the MS92 "save file" format (the same format MS92 uses when you download a file from the 3000 and select the "save file attributes" checkbox). This makes it easy for us to send program files to those of you out there that don't use Reflection or Business Session (the two formats NetMail/3000 already supports), and can make it easy for you to transport MPE-specific files to your users, associates, or business partners that use MS92.
When you attach an MPE file in NetMail/3000, you'll see a new option on the list of available "types":
Application/vnd.minisoft-hp3000-save
Select this type and the attached file will be encoded such that a MS92 terminal emulator can "upload" the file to an HP3000.
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. Individual users with "advanced capabilities" (as set by the admin user on the mailbox) can set their own forwarding address via the pull-down menu labelled "Options" in NetMail/3000.
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.
NetMail/3000 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 NetMail 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
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.)
A common application nowadays is e-mail a file or files from an application running on the HP3000. While we provide an application programming interface (API) to access the mail system directly and efficiently, it is still possible - and relatively easy - to e-mail files from an application by simply invoking NetMail/3000 from your own application - or via a command file like the following example.
The following example command file was created to easily mail a file from within any application and demonstrates several control features which you can utilize to verify the status of your mailed message.
First the command file itself, then we'll expand on some of the features.
---------------------command file starts---------------------- PARM recip_addr,mailbox,mailpass,replyto_addr,noticefile comment comment This command file sends the message contained in the file 'noticefile' comment to the mailbox specified by 'recip_addr', with a reply-to address comment set to 'replyto_addr' comment comment Warning; this command file removes the reply-to address when done. comment comment Example usage: comment (assuming this file is called 'sendfile.xeq') comment :XEQ sendfile.xeq,joe@acme.com,east-coast@mycorp.com,notice1.data comment setvar netmail_mailbox '!mailbox' setvar netmail_mailbox_pwd '!mailpass' setjcw netmailsigprompt=2 CONTINUE PURGE tmpx,temp > $NULL ECHO SET REPLYTO !replyto_addr > tmpx ECHO SEND !noticefile >> tmpx ECHO >> tmpx ECHO Notice subject goes here >> tmpx ECHO !recip_addr >> tmpx ECHO // >> tmpx ECHO SET REPLYTO $REMOVE >> tmpx ECHO EXIT >> tmpx RUN NETMAIL.SYS.THREEK,BATCH;STDIN=TMPX;STDLIST=$NULL PURGE TMPX,TEMP comment comment if this message was sent successfully, then the jcw comment CMCM1T1 = 1 comment M1 designates 1st message for this execution comment T1 designates 1st To: recipient for this message comment '1' = successful; anything else indicates a problem with this comment recipient comment deletevar netmail_mailbox deletevar netmail_mailbox_pwd ----------------------command file ends-----------------------
You'll notice from the command file itself the sample usage and explanation of it's
parameters. In implementing a command file to run
NetMail/3000, the first thing you need to realize is that when NetMail/3000 is executed as
a batch-type process, it runs with a command-line syntax as described in the NetMail/3000
Command Line Interface manual. This command file runs the mail program by creating a
$STDIN file and writing the appropriate commands to it. The command file then runs the
mail program using the "BATCH" entrypoint - which tells NetMail/3000 to use the
command line interface even though this may be executed from an interactive session whose
own mailbox might be configured to use the menu interface.
This command file writes a command (SET REPLYTO) to change the mailers reply-to header. While most applications won't need this, it demonstrates the possibility. Since NetMai/3000 always automatically determines the mailbox name to use (based on the MPE logon running the program) you sometimes can't control the mailbox name being used when this command file is run, but at least by setting the reply-to header to some known address, you can control any replies that might be made to the message.
Three CI variables you probably haven't seen before are also used in this command file:
setvar netmail_mailbox '!mailbox'
setvar netmail_mailbox_pwd '!mailpass'
setjcw netmailsigprompt=2
As we mentioned, NetMail/3000 automatically determines the mailbox to use based on the MPE logon of the session or job running it. You can however, map more than one mailbox to a given session; for example, as one customer did, give specific users mailboxes fully qualified by their session or user and account names, but still define some "generic" mailboxes, mapped to "@,@.@" in the "mailbox aliases" which can be accessed by anyone. Ordinarily, if NetMail/3000 finds more than one possible mailbox to use, it prompts you to find out which mailbox to use. This might be annoying if you run the program several times a day - and would definitely be a problem when the program is invoked via a command file - possibly from within some application. So, by setting the "netmail_mailbox" variable you can override the prompt and tell NetMail/3000 which mailbox to use. If the mailbox you select has a password, you can also provide the password in the "netmail_mailbox_pwd" variable and prevent the program from having to prompt the user for that as well.
Another useful option is the setjcw netmailsigprompt=2. By default, netmail will prompt you (even in batch mode) as to whether you want to include your .sig (signature) file. When running in batch mode (and possibly not knowing ahead of time whether the user's mailbox has a .sig file or not) it is more convenient to set a default condition so as to skip the prompt. This jcw tells netmail to:
If =0 (or not present) prompt if sig file present, don't if not
=1 don't include sig file whether specified or not (but don't prompt)
=2 include the sig file if specified, don't if not (but don't prompt)
The command file then writes the command "SEND filename", followed by a blank line (response to the "filename to attach" prompt), then the subject of the message, then one recipient (e-mail address) per line, with a "//" to terminate the list. It then removes the reply-to address setting and terminates.
Once done, the application can check the setting of the jcw "CMCM1T1" to see if the e-mail address was accepted for delivery (NetMail/3000 will return an error if a badly formatted address is entered, or a bad local mailbox, or an unknown host is entered). Note that if the host is a remote system, NetMail/3000 doesn't know if the remote mailbox part is valid until it tries to deliver the message, so you won't get an error in the CMCM1T1 jcw - instead you'll get a returned message from the remote system telling you that the remote recipient wasn't valid. [This is an instance where the advanced features of the API give you more control]
There is one JCW set per recipient per message; after the "CMC" part, the "M1" means message #1 for this process (M2 would denote message #2). The "T1" part indicates "To" recipient number 1. "To" recipient #2 would be T2... etc. "CC" recipient #1 would be C1, and "BCC" recipient #1 would be B1. So, for example, if there were 2 "To" recipients, 1 "Cc" and 3 "BCC" recipients in the first message sent for this process, you would have the following JCWs available:
CMCM1T1 CMCM1T2 CMCM1C1 CMCM1B1 CMCM1B2 CMCM1B3
If you send more than one message per execution of NetMail/3000, you'd also have "CMCM2..." and "CMCM3..." etc. variables set.
A final note; you can also provide files to "attach" to the message. In this command file example we don't provide any attachments, and thus provide a blank line for that prompt. By simply adding filenames at that point (though still terminating the list with a blank line) you can attach as many files as you like to the message(s).
As of NetMail/3000 B.07, you can now send a "text/html" file as the main
message part (before this, the main part of a message had to be plain
text "text/plain" - though attachments could always be of any type).
Per the "PCFILES.DATA.THREEK" filecode directory, HTML files should use a filecode of "2133", so by simply putting a filecode of 2133 on the file you intend to send - and of course, making sure the file itself contains valid HTML commands - you can send a message which will be interpreted by GUI clients as HTML. This can give you excellent formatting control by utilizing <pre></pre> (for formatted columns or report data) for example.
A simple but useful example of this process is the "sendhtml.xeq.threek" command file now distributed with netmail. You can use this command file to automatically e-mail a spoolfile (after the command file automatically pre-pends the appropriate <html><body><pre> tags to the report).
The "Janitor" program handles the auto-deletion of old mail messages (if you
choose to enable it). This gives you, as the mail administrator, the
capability to enforce an archival strategy on mail storage. NetMail/3000's mail archival
must be enabled for EACH mailbox you want to auto-process, by setting the "days to
keep old mail" option in the NETMAINT user maintenance screen to something other than
zero(0). This setting establishes your policy. To actually enable the cleanup process
however, you must also schedule the "janitor" process that does the scanning and
cleanup. You do this via the option "3" from the first menu upon running
NETMAINT. Select option "1" on the next menu "Schedule delete of old
messages". This brings up a screen that allows you to control when and how often the
cleanup process is executed.
This screen starts with a start date and time, which establishes the first (or next)
time the cleanup process will run. The next set of fields control
the frequency (how often) the process will run. Next to each of these boxes
(Monthly/Daily/Weekly/Hourly) is a box you can fill in; "1" next to monthly
indicates once a month - a "3" would mean every 3 months. Likewise you can
schedule weekly (or every 2..n weeks), daily (or every 2/3/4/5/6 days) or even several
times a day by selecting an hourly setting (though we don't recommend this). Finally on
this line is a start/stop time, which should be left blank (it's not used for this type of
event).
Below this is a set of boxes where you can specifically override the schedule for given days of the week. For instance, say you wanted to run every day (daily=1) but not on mondays; you would set the "Monday" box to "N" and every other day of the week to a "Y". If the schedule attempts to run on a day which you have flagged as "N", the cleanup is NOT run, and instead automatically re-scheduled for the next time it would have run.
Finally, every time the cleanup (janitor) process runs it generates a report indicating which messages (by subject/index) it will delete by mailbox. You can check this process any time by running the janitor program manually;
:RUN JANITOR.PUB.THREEK
You can also route it's output to a printer by issuing a file equation for "JANITOR", like follows:
:FILE JANITOR;DEV=LP,1
When janitor is run manually, it will not delete any mail - just report on what WOULD be deleted. If you do wish to actually have it delete mail when you run it, use the "UPDATE" entry point;
:RUN JANITOR.PUB.THREEK,UPDATE