OS/2 Shareware BBS: 35 Internet/35-Internet.zip/shuff110.zip/SHUFFLE.DOC

Text File | 1994-02-23 | 14KB | 325 lines

                 SHUFFLE v1.10
            (C) 1993 by D.L. Meyer

    An E-mail re-director for use with IBM's TCP/IP for OS/2 SENDMAIL


The one annoying thing I found about IBM's SENDMAIL handling was that mail
could be sent to any 'user'@my.machine.address, and show up as my mail.
With no method to sort mail into separate queues for special processing,
either.

So I wrote this little utility, which watches the incoming mail queue
administered by SENDMAIL, and redirects mail for defined users to separate
mail queues, or in-boxes, in specified directories.  I then set my LaMail
instance to look at my defined 'inbox', with the certainty that it will only
see mail addressed to *my* defined userid.  This allows me to set up another
'inbox' for my wife, without my having to wade through her mail and her
through mine.  It also allows me to set up separate inboxes for email which
requires special processing, perhaps automated processing.

Note that I use "Inbox" above, and not "Folder".  This is because LaMail keeps
mail that it has received and processed in what it calls 'folders'.  The storage
method LaMail uses is not the same as what is used by SENDMAIL & SHUFFLE,
and what LaMail understands as its "InBox".

Also, I included the ability to specify a command to execute when mail is
received.  This allows specialized processing instead of simply dumping
the newly arrived mail into a queue.


A More In-depth How-It-Works:

SHUFFLE runs in the background, and watches the main inbox index.  When
SHUFFLE detects that the index has been updated by SENDMAIL, it rescans the
index to pick up the filename(s) of the newly arrived email message(s). It
pulls the "To:", "Cc:", and the first "Received:" line out of the message header
info, and parses out the userid(s).  The first "Received:" line can, through a
very minor modification to your SENDMAIL.CF file, inform of the userid the
incoming message is intended for.  (How to do the modification is outlined below.)
If the userid cannot be pulled from the "Received:" line, then the "To:" and "Cc:"
lines are used.

[ Note:  If the "Received:" method is not activated through the modification,
    then 'Blind carbon-copies' (Bcc:) and mail to a userid but without a valid
    userid in "To:" line, as well as mail lacking a "To:" line, will not be processed
    correctly.  ]

If the userid found is listed in the USERID file which is read at SHUFFLE
startup, then the new message is copied to the separate inbox for the userid,
and then removed from the main inbox.  Mail addressed to undefined userids
are simply left in the master inbox for later perusal/manual disposal.  Multiple
recipients of the same message on the same machine each receive their own
copy, and duplicate messages (determined by comparing Message-Ids:) are
automatically deleted.

An added feature allows SHUFFLE to spawn separate processes on the
arrival of mail to specified userids.  This allows specialized processing of
particular types of mail, by user crafted routines.  Also, unidentified userids
can be trapped, and processed in a like manner.  A REXX Script is included
in this package which will "bounce" these messages back to the sender.

Also, all mail addressed to the userid "root" is automatically redirected to
the first userid in the userid list.

Simple, eh?

Theoretically, SHUFFLE would suck CPU cycles by constantly checking
the master inbox.  I handled this by putting a configurable sleep period in the
loop.  It defaults to scanning once a second.  (See SHUFF_DELAY below.)
Even then, SHUFFLE only looks to see if the index file's timestamp is more
recent than the last time it ran a full scan.  If the timestamp is new, only then
is a processing run performed.


Parameters & Setup:

Setup is simple.  Just put SHUFFLE.EXE on your path, or anywhere really.
Place the EMX.DLL in a directory on your LIBPATH. (Which is defined in your
CONFIG.SYS.)

Next, create a text file containing a list of USERIDS to sort for.  Each line
should be of the format "Userid   d:\inbox-path", where Userid is a case-
sensitive, single word userid.  (If you want "userid" & "Userid" to be
equivalent, simple add a line for each, pointing to the same inbox.)

For instance:
    user1    d:\tcpip\etc\mail\user1
    user2    d:\tcpip\etc\mail\user2
    User2    d:\tcpip\etc\mail\user2
    ...

Notice line #3 above - SHUFFLE is case-sensitive by default, but you can account
for varied capitalizations of the Userid by having several similar Userids pointing
to the same InBox directory.

Now, you want to spawn a specialized process for all mail arriving for 'user3' -
what do you do?  Quite simple, actually.  Simply substitute the command for the
process for the path in the examples above.  Preface the command with a "%" to
indicate to SHUFFLE that it is a command and not a path.

Within the command, you can include several character variable tags which will
tell SHUFFLE to substitute in various parameters.  These character tags
consist of "&&" + one of the following characters:

    "F"    Fully qualified filename of the mail message
    "f"    The message's filename only
    "P","p"    The mailpath - the directory where SENDMAIL leaves messages
    "R","r"    The "Return-To:" address  (Sender's address)
    "H"    The local host address
    "U"    The userid to which the message was sent
    "#"    The child number of the process being spawned.
            (Shuffle's #, not a PID)

For instance, the command for the automated mail bouncing would be:

    %d:\path\BOUNCE.CMD &&F &&H &&R &&#

This brings up the issue of default processing of unidentifiable userids.  To
enable this feature, (Disabled by default)  you must include a line in your userid list
with the character "*" as a UserID.  Therefore, the complete line would be:

    *   %d:\path\BOUNCE.CMD &&F &&H &&R &&#

A caveat for specialized processing -- the called special process carries the
responsibility of disposing of the original mail message after the processing
is completed.  When a mail message is passed to a special process, it is
erased from the Inbox's index, and SHUFFLE "forgets" about it.  Therefore,
If the special process doesn't dispose of the incoming files, then they will
accumulate in the mail directory, doing nothing but taking up space.

Oh, by the way, SHUFFLE can be 'DETACHed', but it is probably not a good
idea if you are going to be using the special processing functions.  (Including
the automatic bouncing function.)


Command-line parameters:

  -U=    designates the file to load for the list of userids & inbox paths.
  -M=   specifies the full path to the main (master) inbox.  (The one
        that SENDMAIL controls.  Default is the current directory.)

Example:
    SHUFFLE -u=c:\shuffle\userids.lst -m=c:\tcpip\etc\mail


Environment variables:

  Set SHUFF_TO=      userid & inbox paths list file
  Set SHUFF_FROM=    full path to the main inbox.
  Set SHUFF_DELAY=   sleep period, in milliseconds, between each scan of
                     master inbox.  (Default is 1000)

IBM TCPIP requires the environment variable HOSTNAME to be set to your
machine's name.  SHUFFLE will use this to match against the To: address
of incoming mail in case of multiple addressees.  Since HOSTNAME is
usually only the first part of the multipart hostname.domain scheme, you
can set the variable HOSTADDR to the complete multipart name in order to
improve the validity of the checking that SHUFFLE does.  In most cases,
however, just the HOSTNAME will do.

Example:
  Set HOSTADDR=larch.ag.uiuc.edu

SHUFFLE also detects duplicate messages transmitted closely together,
in many cases to multiple recipients on the same machine.  This version
processes all recipients in a message, and automatically deletes duplicate
message files that it detects.

This automatic deletion can be turned off by setting the 'NOKILLDUPS'
environment variable to 'YES' before running Shuffle.

Example:
  Set NOKILLDUPS=YES.


Precedence -- Command line parameters override any environment variables.


Modifying the SENDMAIL.CF file:

In order to properly process 'Blind Carbon-Copies' and mail without a "To: line,
a small modification is required in the SENDMAIL.CF file on your OS/2 machine.
On most implementations of Sendmail on multi-user machines, the "Received:"
line(s) contain a field "for userid" (or "for userid@host") to signify the intended
recipient.  Since OS/2 is intended to be a single-user system, IBM decided to
omit this property in its implementation of Sendmail -- making the assumption
that any mail arriving was meant for whoever was using the machine.  This
doesn't mean that IBM's OS/2 Sendmail is incapable of doing it, however,
it just means that we must tell it to.

While we would like to have Sendmail use the "for userid@host" format, the
current versions of OS/2 Sendmail do not seem to provide this capability.  But
it does allow use of the "for userid" format, fortunately

Here's how we make the change to include the "for userid" field --

From an OS/2 command prompt, type:

   copy %etc%\sendmail.cf %etc%\sendmail.bak <Return>

This makes a backup copy, in case something goes awry.  Now type:

   e %etc%\sendmail.cf <Return>

When the editor loads and the file is loaded, search for the text "Received:".
(Select [Edit]->[Find], and type in "Received:", pressing [OK] when done.)
The search should locate pair of lines closely resembling the following:

   HReceived: $?sfrom $s $.by $j ($v/$Z)
         id $i; $b

(The second line is a continuation of the first.)

Now, change the second line to read:

         $?ufor $u; $.id $i; $b

(Actually the added text, "$?ufor $u; ", can be placed anywhere in the second
line, or at the end of the 1st line.  I recommend the second line, however, since
the first line gets pretty long already.)

After the change is complete, save the file and exit.  (Select [File]->[Save],
then [File]->[Exit].)  Be sure to kill & restart the Sendmail server process
(or simply shutdown & restart your machine) in order to place the changes
into service.



How to use with LaMail:

Now, how do you get LaMail to work with these separate inboxes?  Here's
what I do:

By default, LaMail creates its own INI file, and wants to locate it in the \OS2
directory.  (I prefer the \TCPIP\ETC directory, but that's me.)  LaMail also
likes to make this file Read-Only.  What I do is make a duplicate of the LAM.INI
file for each separate UserID / InBox, under a different name.  (USERID.INI,
for instance.)

I then create a batch file which does the following:
  1) Removes the Read-Only attribute from LAM.INI
  2) Copies USERID.INI to LAM.INI
  3) Runs LAMAIL.EXE
  4) Copies LAM.INI to USERID.INI on exit to save changes.

This is mine, as an example.  Modify it to suit your paths, etc.

LAM.CMD:
@ECHO OFF
IF ~%1==~ GOTO OUT
IF NOT EXIST %ETC%\%1.INI GOTO NO_FILE
ATTRIB -R %ETC%\LAM.INI
COPY %ETC%\%1.INI %ETC%\LAM.INI >nul
LAMAIL
COPY %ETC%\LAM.INI %ETC%\%1.INI >nul
GOTO OUT
:NO_FILE
ECHO Could not find %ETC%...
:OUT


To run LaMail, use the command:
    LAM userid



Other related applications:

I've noticed some other possible applications for this utility as well.
Although intended for use on a single machine, one could use it to have
multiple users' mail sent to a common SENDMAIL receiver, and then parceled
out to individual Inboxes on a shared drive on a LAN.  The incoming mail is
still automatically sensed by LaMail running on other machines, which I really didn't
expect.  However, in order to reply to email, a sendmail process must be running
on the other machines.  The usefullness of this method is when a user has his/her
LaMail configuration set to "Reply To:" the common SENDMAIL receiver, thereby
allowing the reading of mail from any networked machine which can use/see the
person's inbox.  Outgoing email is sent from whatever machine the person is working
from, yet any replies to the outgoing mail are sent back through the common
SENDMAIL receiver due to that address being in the "Reply To:" field.

This allows a user who may use any of a number of machines in a LAN to receive
email to a specific address, yet be able to read and respond to it directly from
whatever machine the user might be working on.

Who knows, with a little imagination, you might come up with something
similar, or maybe something different...


Limitations:

SHUFFLE only handles incoming email - it does not (cannot) touch outgoing
mail.

I haven't done extensive sharing tests, yet.  But from what I've seen so far,
recovery from a sharing error is quite graceful.

Also, when you modify the USERIDS.LST file, any currently running SHUFFLE
process must be killed, and SHUFFLE must be restarted to pick-up your
modifications.  (I'm looking into a PM port which will allow updating on-line,
as well as allowing a shutdown with one less "Do you want to close the
session without saving...?" question.)


Distribution & Terms:

While I felt that taking a copyright on SHUFFLE was prudent, I am making
this version freely available for use to all who might find a use for it.
SHUFFLE version 1.10 is to be freely copyable as long as no money
changes hands.  (Now, paying for the transfer media is an obvious
exception... )

As always, if you have any suggestions, or any "bugs" to report, I want to
hear them.  Please e-mail them to '[e-mail]'.

If you find SHUFFLE useful, please consider a small donation, if only to
entice further development of Shuffle.  Anyone sending $5 or more, and
their e-mail address, will be placed on a list to automatically receive
uuencoded updates via e-mail when they become available.

    Address:    D.L. Meyer
        745E County Rd. 2175N
        Champaign, IL 61821