Getting started
Running the server
For further information on SMTP and POP3, see RFC 821: Simple Mail Transfer Protocol and RFC 1225: Post Office Protocol, Version 3. Of interest may also be RFC 1912: Common DNS Errors.
AutoShare 2.2 is compatible with the message file format changes introduced in EIMS 2.1 and furthermore benefits from its New User AppleScript command.
With the release of version 1.2.1, SIMS (Stalker Internet Mail Server) too may be used with AutoShare. Click here for instructions.
Are you ready for AutoShare? The highly configurable feature cornucopiua puts the sizzle in this razzle-dazzle extravaganza. AutoShare is truly the house of generosity when it comes to features and functionality. And yet at the same time, AutoShare is a jumping jackpot racing to do its thing without asking for much memory, even when your lists has tens of thousands of subscribers. AutoShare is the fun town that never sleeps!
When configuring your EIMS accounts and your AutoShare preferences, always test your configuration first before letting your subscribers do it.
Before setting up your first list server list, decide whether subscriber addresses should be based on the RFC From address (where to reply to) or the SMTP envelope sender (where it is coming from) of the subscription requests; if the former, then configure accordingly. RFC is an abbreviation for Request for Comments, which comprises more than just e-mail related matters.
When upgrading, here are some version-specific changes to look out for.
AutoShare supports EIMS as the mail server sending and receiving mail, and transactions between the two servers are based on the use of fast file transactions rather than the use of mail protocols. The basic flow is that EIMS stores received message files in a Filed Mail folder for AutoShare and that AutoShare processes the message files and puts them as outgoing mail in the Incoming Mail folder for EIMS.
In order to use AutoShare, a thorough knowledge of the EIMS account types is required (EIMS documentation is available here):
MLM (mailing list manager, e.g. AutoShare), MTA (mail transfer agent, e.g. EIMS) and MUA (mail user agent, e.g. Eudora) are abbreviations that you are likely to come across from time to time. More common terms however may be list server, mail server and mail client respectively.
You may also have heard of complex Unix software with specific names such as LISTSERV, Majordomo or ListProc (to obtain the MLM software FAQ, write 'get mlm-software faq' in the body of mail to listserv@listserv.net). You may be aware of commercial Macintosh list server software such as StarNine's ListSTAR (formerly eMOD) as well, which was released June 26 1995.
The list server feature has been developed as a natural extension within AutoShare and of EIMS. The list server account is merely an auto-response account with a number of special features added to it; the list server lists are set up using separate EIMS accounts (although not possible here, integrating the list server features into the list account itself would lead to far too dangerous events: imagine you wanted to unsubscribe from a list, but misspelled the command, then everyone on the list would receive the message!).
Each auto-response service may optionally include a BinHex enclosure.
AutoShare (or similar) = folder with AutoShare server application Filed Mail (or similar) = EIMS, Saved as files folder Incoming Mail = EIMS, Incoming Mail folder Documents (or similar) = folder with user named subfolders with text files List Server (or similar) = folder with list server mailing lists Archives (or similar) = folder with archive files Filters (or similar) = folder with filter files AutoShare = folder storing preferences, logs and more AutoShare Temp = folder storing outgoing mail until completedThe last two folders reside inside the System 7 savvy Preferences folder, with the latter residing inside the former.
The illustration below puts the folders in perspective.
When doing the initial configuration (see also the quick tutorial below), it is recommended that you start out creating a folder, e.g. Auto, inside the harddisk root folder for your AutoShare folders. Then create the Filed Mail folder (and other folders) inside the Auto folder. As for EIMS, the Saved as files accounts must specify the Filed Mail folder.
AutoShare = server application Default etc = list server and auto-response documents Default.hqx etc = Binhex 4.0 enclosures for auto-responses Subscriber list files = EIMS mailing lists in list server folder Archive files = list server list archives Filter files = filter documents AutoShare Preferences = preferences file AutoShare Log = log fileIn the Documents folder (e.g. inside the Auto folder), user subfolders should be created, one per account; the following documents are likely to reside within each subfolder:
Let's get going on the initial configuration for the AutoShare server.
As the List Server and Documents folders already contain the files for the Fun-L list and AutoReply auto-response services, we'll now configure EIMS accordingly.
To create another auto-response service, AutoShare requires you to create a Default document inside a new folder (named after the service) in the Documents folder, and EIMS requires you to create an auto-response account.
To create another list service, AutoShare requires you to create a list document (named after the service) in the List Server folder, and EIMS requires you to create one account configured as Save As Files and two accounts configured as Mailing List.
The following illustration shows how AutoShare interacts with all of its standard folders (not including folders for the software, the documentation or the preferences).
When a request for an auto-response is processed, the document in question is fetched from the Documents folder, and before the auto-response file is created, the filter file in question is checked in the Filters folder. Commands to the list server also use the list files in the List Server folder, and list contributions furthermore update the digest and archive files in the Archives folder.
Creating a vacation notice service is almost identical to creating an auto-response service. The only two minor differences are that the mail account is configured a little differently and that a filter file is used for the one vacation notice only feature.
Enter the addresses for the administrator and bounce accounts first. When people send personal mails to the administrator, they use the administrator address. Mail to the bounce address, often error messages, on the other hand is originated by your or other servers (the domain of the bounce account must indicate the domain of your server!).
The other basic settings are Log, Format and Commands. The log setting determines how detailed your logs should be (Brief is fine for most purposes). The format setting indicates whether your archives should be formatted as text and/or HTML. The commands setting decides where AutoShare is looking for list server commands in subscriber mails (Body is recommended).
You may configure AutoShare for various amounts of log information:
Off = no logging
Always = important messages that are always logged (unless Off)
Brief = a single line per transaction
Tech = detailed information per transaction
Logs are automatically being mailed to the AutoShare administrator and
initialized at scheduled times configured in the Times dialog box (from the Preferences menu, choose the Times menu item). The scheduled times for the digests are configured in the dialog box as well; choose digests from the pop-up menu at the top.You may schedule the times for a particular interval of days and within the day a specific time. If either every <number> days or at <time> has changed and you press the OK button, the new settings take effect immediately; you may update the settings for both logs and digests with a combined single OK.
If the settings have just been updated, every <number> days implies that the first log or digest will be mailed in <number> of days (if set for 1 day, then tomorrow). If you want it to happen later the same day of the configuration, click at that time in the Now checkbox without altering any other settings; you may use the Now checkbox whenever you need more frequently mailed logs or digests in a temporary situation.
The primary transaction information listed as single lines (formatted as a series of transaction information tokens using space delimiters) in the logs applies to the following transaction types (the tokens are listed after the colon):
The AutoShare Admin(istrator) offers a visual interface allowing you complete configuration of AutoShare. The AutoShare Admin communicates, locally or remotely, with the AutoShare server application by acting as a client sending AppleEvents. The Admin behaves very gentleman-like and for instance does not update the AutoShare Preferences file directly, but rather asks the AutoShare server application to do it. The sole role of the AutoShare Admin is the configuration of the AutoShare server by sending events to it, even if the two applications run on the same Mac.
The Admin is written using FaceSpan version 2.1 and includes many scripts taking full advantage of the scripting dictionary of AutoShare. It is FAT, thereby being native to both 68K and PowerPC, and comes as a Miniature application, which means that the FaceSpan Extension must reside in the System 7 Extensions folder for the Admin to work.
The FaceSpan Extension is expecting to find the QuickTime and QuickTime PowerPlug extensions in the system before it can be resolved. Both of these extensions are part of a standard Mac OS install. If you are experiencing such problems using the AutoShare Admin, it is more than likely they have been turned off via the Extensions Manager.
The AutoShare Admin may be used on any Mac on the same AppleTalk network that the Mac running AutoShare is located on, in Mac OS 9.0 also via TCP/IP. Please read about the AutoShare scriptability for configuration of Program Linking. When using the Admin remotely, be sure to put a copy of the AutoShare application on the Mac (preferably in the same folder as the Admin) on which you are using the Admin, so that the AutoShare AppleScript dictionary can be read by the Admin. Or you may use the ResEdit file entitled AutoShare (must reside in the Admin folder, and does so in the release archive), which contains the AutoShare AppleScript dictionary only.
Balloon help, serving as brief reminders of the documentation that you are reading here, has been added to all windows, so that you may instantly read about the various fields of these windows.
The fields entitled Misc Stuff (Command-J in the Admin; AppleScript: the Misc Stuff property in Misc Options) and List Stuff (Command-L, Yet more list in the Admin; AppleScript: the List Stuff property in List Options) are of particular interest, as they are packed with minor settings that are either on or off. A given setting is turned on by adding its respective letter in the field. Consult the balloon help for details.
In AutoShare environments using the multiple preference sets feature, remember to switch to a given preference set before administering preferences (and remember to switch back to All when you're done!).
Although not needed, technical details on configuration are available in the section describing the AutoShare Preferences and list-specific configuration.
Apple menu: Space = About File menu: (N = New) (O = Open) W = Close (S = Save) (P = Print) Q = Quit Edit menu: Z = Undo X = Cut C = Copy V = Paste (A = Select All) Preferences menu: M = Miscellaneous J = More Miscellaneous F = Folders K = More Folders T = Times U = Multiple Preferences Configuration menu: E = Where B = Statistics L = Lists D = Documents I = Filters H = Hosts Y = Keep Applications Up Extras menu: (no letters used) (G, R are not used)
Apple Events scripting using AppleScript is perhaps the most important addition to System 7. This was enhanced in System 7.5 by introducing the scriptable Finder. AutoShare is fully scriptable, allowing you a convenient way of remote configuration. If you haven't tried using AppleScript, please locate the part of your System software that includes the files such as the Script Editor.
Once you have completed the installation of the Apple Events system software, you may want to look into features like Program Linking, which enables you to control scriptable software from another Mac on the same AppleTalk network, even if you have access to the network via AppleTalk Remote Access (ARA). Program Linking is configured this way.
A number of AppleScript commands, SetRes, GetRes, Analysis, Subscribe, Unsubscribe, GetSubscriber, GetSubscribers, SetList, GetList, GetLists, SetMisc, GetMisc, SetFolders, GetFolders, SetTimes, GetTimes, SetHosts, GetHosts, SetKeepUp, GetKeepUp, GetCreatorApp, SetFilters, GetFilters, Review, Write Log, GetStat, File Mail, Send Mail, SetPreference, GetPreference, GetPreferences and RunScript, have been added to AutoShare's support for scripting. The required commands, Run and Quit, are of course still supported. Furthermore, a single AppleScript script can perform several changes.
On the topic of errors, it is important to distinguish between actual AppleScript errors (most often unlikely) and a given AutoShare request not being successful (likely to happen from to time). When issuing for instance the GetSubscriber command, no result will be returned, if an AppleScript error, e.g. when fetching a property, occurs. On the other hand, an empty result will be returned, if there are no AppleScript errors, but, say, the subscriber could not be found. Your AppleScript scripting should take these kinds of situations into consideration.
The two AppleScript commands, SetRes and GetRes, set and get 'STR#' (or 'STR ') resources in the AutoShare Preferences file (or another file). The feature is aimed at users who prefer not to use ResEdit (for the few times that is needed).
Another three AppleScript commands, Analysis (generate an Analysis file), Subscribe (subscribe a user) and Unsubscribe (unsubscribe a user), have been added, as they may come in handy for remote
configuration using Program Linking.
The Unsubscribe command supports the list being all, so all lists are processed.
The AppleScript command, SetList is aimed at configuring the list-specific settings.
When the List property is not used, the remaining properties are directed towards the general list settings.
The Review command supports the list being all, so all lists are processed.
The RunScript AppleScript command in AutoShare includes a scriptPath parameter, which may be used to specify a path of an AppleScript text file to be compiled and executed or a compiled script file to be executed; it may also be used to specify an application (by path or creator) to be launched, or an AppleScript one-liner may be entered directed when preceded by *.
AppleScript code specified in a message body may be compiled and executed via the Script command in remote administration by e-mail.
While process extenders are often applications, they may be compiled script files as well. As such, continuous application memory is not needed, you don't have to save as application, and there is no need to specify an idle handler; there is on the other hand a slight overhead every time the AutoShare application executes the compiled script.
Compiled AppleScripts placed in the Scripts folder inside the main AutoShare preferences folder may be executed from the Extras menu in the AutoShare application. The script response is shown in the Status window.
Since the list server account is also an auto-response account, remember to create an autoshare subfolder inside the Documents folder. Inside the autoshare subfolder, create the Default document as well as documents for all list server request commands, each getting its file name from the command. Each document (except the Default document) should include a token for the respective command (e.g. /=LIST for the LIST command), while the rest of the text contents is up to you.
List server list archives, formatted as text and/or HTML, are created automatically. A set of archive files (e.g. Current.text and Current.txt), located in a subfolder (named after the list) inside the Archives folder, will accumulate continuously. Digest files accumulate temporarily.
Whenever a list contribution takes place, the set of digest files (Digest.text and Digest.txt) and the set archive of files (e.g. Current.text and Current.txt) are updated: the message and toc (table of contents) parts are formatted and then appended to the respective files. With the GET command, further formatting is added to form a single text or HTML document (within the begin/end block of the returned message following the GET request).
The list server commands in subscriber mails appear in special command lines (either the subject or the first line(s) of the body), which trigger certain events. Other commands, e.g. including HELP, can be made available as well of course.
LIST
REVIEW <list> [<e-mail>]
SUB <list> [<name>]
UNSUB <list>
SET <list> <option>
INDEX <list>
GET <list> <file>
WHICH
RELEASE
QUERY <list>
SEARCH <list> <string>
Several alias commands are available as well:
SUB: subscribe, join
UNSUB: unsubscribe, leave, signoff
LIST: lists
REVIEW: rev, recipients, who
INDEX: ind
GET: send
All may be used for the Unsub, Query, Set, Index, Get, Review and Search commands to apply the command to all subscribed lists, e.g. query all.There is no HELP command, but it is surely okay to create a document called HELP.
If your list server has been configured to accept command requests in the body, the subscriber may include several such requests in one and the same mail. When 1. a body line is found which does not begin with a valid command, or 2. there are no more body lines, AutoShare will stop processing the mail.
sub fun-l Mikael Hansen set fun-l ack set fun-l conceal query fun-l review fun-l blah blah listIn the above example, the first five command lines will be processed and returned as five separate mails; the sixth line is not valid (and will generate no response mail), and so the processing halts.
<list>-on@domain = subscribes <list>-off@domain = unsubscribes <list>-sub@domain = subscribes <list>-unsub@domain = unsubscribes <list>-digest@domain = turns digests on <list>-nodigest@domain = turns digests off <list>-request@domain = list commandsAll commands, formal or informal, requiring no parameter or just the list parameter may also be used with the request address format, as in <list>-<command>@domain.
The <list>-request specification requires a command in the body (or the subject, if so configured). If further parameters are called for, they are pushed one word to the left, as the standard command format includes the list name as the second word, not needed when using a request address.
The creation of corresponding mail server accounts is needed.
When adding the letter G to the List Stuff field (see the Admin or AppleScript), the List-Subscribe and List-Unsubscribe RFC fields show this type of request format. When adding the letter T instead, the <list>-request format is shown.
List subscribers are stored in subscriber list files inside the List Server folder. The file name of each list file is the list name, and a list is considered defined by the mere creation of the list file in the List Server folder.
Each subscriber takes up a separate line within a list file.
0: concealed (if visible, then no 0)
1: digest (if messages, then no 1)
2: no mail (if mail, then no 2)
3: acknowledgement (if not, then no 3)
4: not allowed to post (if post, then no 4)
Examples:
meh@dnai.com (Mikael Hansen)
meh@dnai.com
meh@dnai.com (Mikael Hansen..0)
meh@dnai.com (..0)
meh@dnai.com (Mikael Hansen..012)
meh@dnai.com (..01234)
The codes 5 and upwards are not used.
Built-in database format
The built-in database format for subscribers is aimed at going beyond the current subscriber format (including e-mail, name and options only) by having additional (optional) fields.
The built-in database format is enabled via the Database property in the AppleScript List Options (use dbBuiltin) or via the Database Format field in the Admin's More List window.
While the list file is still required in the List Server folder, this file may be empty as the subscribers are automatically stored in a file (having the same name) in the Databases folder inside the AutoShare preferences folder.
List files in the old standard format can be converted to the new built-in database format by dragging the list file in the List Server folder onto the AutoShare application icon (set to dbBuiltin first).
While business is then as usual, two new AppleScript, SetSubscriberDB and GetSubscriberDB, may be used additionally to access the new (optional) fields (it is suggested that standard pre-database AppleScript commands such as Subscribe and GetSubscriber be used for the standard pre-database subscriber data).
The AutoShare archive includes an Optional Fields sample process extender, which illustrates how to automate the use of optional fields in the built-in database format.
Script database format
The external script database support for subscribers is also aimed at additional (optional) fields and stores subscribers in external databases, one each per list.
The external database support is enabled via the Database property in the AppleScript List Options (use dbScript) or via the Language field in the Admin's Yet More List window.
The AutoShare server application communicates with the external database application via scripting. The AutoShare archive includes a Database sample process extender targeted for FileMaker Pro. While the approach illustrated by the sample is complete, it has also turned out to be a good deal slower than using any of the built-in formats.
The change is that AutoShare now offers binary searches of the line-based subscriber lists, so that a search for a given address is completed much faster than before. This is in part accomplished by verifying at start-up that the lists are sorted, and when not, sort them using a QuickSort algorithm.
The searching, sorting and insertions for lists are configured using the List Sort property in the Options (Misc); the new status will be saved to the disk settings immediately, but will not become active until the Run command has been issued or AutoShare is restarted. The property may be set to Domain, User or Unsorted; when configured as the latter, AutoShare will not check for lists being ordered when starting up and will apply a simple linear search when looking up subscribers; new subscribers will in this case be appended to the end of the list file.
When sorting, the AutoShare application heap memory is utilized as tightly as possible. Each subscriber takes up 4 bytes plus the number of characters in the address line in question. With an average subscriber string length of 36 characters, a list file of 1,000 subscribers requires around 40K at the time of sorting. It may be noted that if you stick with the same configuration from day one, no sorting will ever have to be applied as new subscribers are placed in their proper location from the very beginning, always leaving the list file sorted.
When subscriber records are added (sub), replaced (set) or deleted (unsub) for a ordered list, an efficient file processing technique optimizes the speed dramatically. Even huge list files will require little time to stay fully updated at all times.
EIMS supports the SMTP EXPN command, which is an optional part of RFC 821: Simple Mail Transfer Protocol. This allows anyone to telnet to your server on port 25 and 'expand' an EIMS mailing list to the full list of addresses. If you don't want the names of your subscribers accessible to the public this way, you can enter an alternate name for the EIMS .m and .d accounts in the Work Lists field of AutoShare Admin's List window. Someone could still telnet to your server, but unless they can guess the account name you supply, they won't be able to EXPN your list. For example, you could enter xyzzy in the work lists field. In EIMS, name your accounts xyzzy.m and xyzzy.d. In the field at the bottom of the EIMS account setup window, where you give the path to the mail list file, use the same path you normally would. In other words, if your list is called Fun-L, you'd continue to use Fun-L.m and Fun-L.d as the names of the actual lists, since using the Work Lists field has no effect on those names. Work Lists merely gives an alternate name for the EIMS accounts that point to the mail list files.
The contents of a list server command document is mostly text that you decide on your own how to reflect the context of the command. Standard list server documents also include at least one token line to trigger a given action. Each token pair (a switch and a command) comes without any delimiter.
Standard tokens:
/=original = picks up the original message /=forward <address> = sends copy of original message to address /=redirect <address> = redirects original message to address /=pe <parameter> = see the Token process extenderCommand tokens:
/=list = displays the lists
/=review = lists the subscribers for a given list
/=sub = confirms the subscription of the user
/=unsub = confirms the cancelled subscription
/=set = updates various options:
conceal: conceals the subscriber (review)
nonconceal: makes the subscriber visible
digest: one daily mail with all list messages
nodigest: individual mail messages
mail: you receive list mail
nomail: subscribed, but no mail
ack: you receive a list contribution copy
noack: no acknowledgment contribution copy
post: allowed to post (admin only)
nopost: cannot post (admin only)
/=index = lists the archive files for a list
/=get = returns a list archive file
/=which = informs you of the lists you are on
/=release = information about the list server software
/=query = information about your subscription status
/=search = returns the hits of an archive search
Token lines are placed in documents at appropriate locations depending on the text contents. While the /=original token can be placed in any document, command-specific tokens should only be added to respective command documents.
All of the list server documents may be made list-specific by replacing the document with a folder having the same name and including documents inside this folder with names of "Default" (must be present) or the list. This also applies to both standard documents for commands without a list parameter and non-standard documents such as Help and Info, as long as the list name is specified as the only parameter.
When a contribution is sent to a moderated list, it gets redirected to the listmaster, who may choose to post it or not; if the moderator uses Eudora, the Redirect (or Redirect To) is recommended when posting other people's contributions. When a contribution is sent to an announcement list, the contribution is returned to the sender. In both cases, only the listmaster is able to post to the list. The listmaster address is fetched from the administrator address (from the Preferences menu, choose Miscellaneous).
It may be added that the list-specific configuration enables list-based defaults for the subscription Options. If you prefer subscribers to for instance receive copies of their own contributions without any separate update of the subscriber's options, this is the way to go.
Posting privilegies may be turned on or off for individual subscribers (subscription, open and private lists). The post and nopost tokens may be applied as any other SET option, but with one important restriction: the subscriber cannot successfully use the two new tokens as a valid option within a SET command. They are administrative tokens only (whose option code is '4') to be used by the administrator (scripting commands, remote administration by e-mail or direct editing of main list files).
A simple script has been included in the samples folder (the SetAllSubscribersToNoPost1 script is interesting, but the SetAllSubscribersToNoPost2 script is much faster), which disables posting for all subscribers for a given list, whose name is specified at the top of the script. When a non-moderator contributes to a moderated list, the contribution is forwarded to all moderators (never more than the first 20 in a list though).
The SetAllSubscribersToNoPost2 script illustrates a hidden high-speed trick of the Subscribe AppleScript command: when the e-mail address is @, the option changes are applied to all subscriber entries!
AutoShare has historically used the envelope sender, not the RFC From field, to determine the address of a list subscriber, as the envelope sender is generally considered to be the real address, although not visible when viewing the mail message. The SMTP envelope sender is where the mail actually came from, while the RFC From address is where a reply should go to. This definition of the RFC From address is however aimed less at server replies (e.g. EIMS) than at client replies (e.g. Eudora), as POP-based e-mail software (and POP-based list server software too!) cannot download the SMTP envelope and so has no choice (unlike e.g. SMTP-based or file-based list server software, which has access to the SMTP envelope information needed).
If you would like new subscriber addresses to be extracted from the RFC From field, you may use the RFC From property in the AppleScript Options (Misc) to enable this. This means that the list files will contain the RFC From addresses for new subscribers, which will be used whenever a list server request or a list contribution takes a place. The envelope recipient of a list server request to be returned will furthermore be updated to the address in the RFC To field.
Using address protection prevents the action of harvesting e-mail addresses for unauthorized purposes.
When a subscribe command takes place, the list-specific index file in the Protected Addresses folder inside the AutoShare folder of the System 7 savvy Preferences folder is updated (entry is added). Same for an unsubscribe command (entry is removed). When a review command is issued, the e-mail addresses are replaced by corresponding address tokens.
When a subscriber posts, nothing is initially different. But when the list server receives the list contribution, the RFC From field body is replaced with a special address token, and all RFC X-Sender fields are removed. It is important that the body of your list contribution does not display your e-mail address.
When the subscriber would like to e-mail another subscriber off the list, the mail, with '<list>space<address token>' placed in the subject, is sent to the 'protected@<domain>' e-mail account, which redirects the mail to the recipient.
The envelope recipient gets updated, and the mail message is moved to the Incoming mail folder. If there is no match for the envelope recipient in the index file, the mail is returned to sender.
When sending an initial mail this way, it is encouraged that you be brief and merely state the purpose of your initiative, so that the communication may switch to the direct use of actual e-mail addresses on both sides. It is not intended that the server be allowed access to the contents of your mails more than necessary.
The address protection feature is enabled in AppleScript by the Address Protection property in List Options; the Admin, see the More List window.
We now move onto the issue of what is entitled spam, a term generally used loosely for various abuse of e-mail. You may think of spam as junk mail of many flavors.
It is next to impossible for a computer to figure out if a given mail is abusive, as the contents isn't reviewed in a meaningful fashion. Several steps may be taken though: 1. applying address protection prevents the spammer from harvesting e-mail addresses, 2. spam mails are often lengthy, and limiting the number of lines for list contribution bodies often helps, 3. writing a Before Processing process extender, which parses the mail for various words and optionally deletes the message file before it gets processed, and 4. using mail-back confirmation requires an additional effort from the spammer, who often prefers to move onto another easier target.
The format per entry is alias address, so if the subscriber addresses are envelope sender based, the RFC From address becomes the alias, and if the subscriber addresses are RFC From based, the envelope sender address becomes the alias.
When an unsubscribe request (standard message files only) takes place and the address isn't found in the main list file, the address will then serve as an alias and be looked up in the index file, and if the corresponding address is present in the list file, this address will be unsubscribed.
To make this feature active, you may use the Subscriber Aliases property in the AppleScript Options (Misc).
A digest is a text formatted collection of list contribution messages, mailed to digest subscribers often every day at a given time, and the digest file is then emptied on the server, thereby being ready for a new day.
A list archive carries a quite different rhythm in time. In order to prevent an extraordinarily large number of archives, they are generally rolled over after a substantially longer time has elapsed. The archive roll-over, which may be triggered by perhaps 100 list contributions, does not delete, but instead renames the archive file in question, so that it may later be accessed via the Index and Get list server commands.
AutoShare offers both text formatted and HTML formatted list archives. The feature of the fully automated web archives takes it all the way. Once initially configured, the listmaster can sit back and relax, knowing that the continuous stream of incoming list contributions is reliably turned into an at all times fully updated hierarchy on the web server, which may be accessed by the subscriber directly across the Internet using a web browser.
It is strongly recommended that you update all current files in your Archives folder to reflect the new convention!
You may choose both text and HTML formatted archives (rather than just one or the other). Having chosen this option (in the AutoShare application or using AppleScript; the Admin, see the Misc window), both text and HTML formatted archive files are created if necessary and updated when a list contribution is processed. The Index command will list both .text and .html file names. The Get command will format according to the file extension. The Search command will search both .text and .html files.
When a rollover archive file is created, a note is added to the log file, so that the listmaster becomes aware of it. In the case of HTML formatting selected, the listmaster may then choose to issue a GET command to receive the fully formatted HTML file by mail, save it to a text file and store it in a folder on a web server, thereby offering a convenient access to the archives. This may be further enhanced by using the new search and indexing tool Apple e.g. at www.cybertech.apple.com/.
The entry point folder path is configured within the list-specific settings, in AppleScript using the Web Path property in the Options (List). You may apply the one that is used most often as a general setting, but given lists such as private lists may choose to override with another path using a setting specific to the list. By assigning an invalid path, no web folders or files are created.
If you prefer to use your own html file in the entry point folder, then simply give this file a name other than index.html and make references to this file. It is assumed that your file references the index.html files inside the list subfolders.
Whenever a contribution takes place and the standard archives are updated, so are the web archives plus both the entry point level index.html file and the list subfolder index.html file.
A few changes have been made: all archived files now use hyphens instead of spaces, and some cosmetic changes have been updated for the archive files. It is recommended that prior archives be updated to reflect the new changes.
Specific to individual lists only (the general setting is always the above complete tree), the entry point folder may be configured to be the list folder itself; the upper layer of the subtree (the top-level folder and the top-level index.html) is not created, and the list folder is moved up one level to match that of the entry point folder. In AppleScript, use the Web Archives property (Complete versus Minimal) in the Options (Misc) to configure this selection.
Both Mac-to-HTML and MIME-to-HTML character conversions are automatically applied to both the standard and the fully automated web archives.
Archives can become searchable by using the Search AppleScript command.
The web archives include formats on three levels: a top-level index.html, which displays a list of list names, for each list a medium-level index.html, which displays a list of web archive files for the given list and lastly web pages, which display the content of a given web archive file. These formats may be made configurable by adding a folder entitled Web inside the AutoShare preferences folder. The Web folder contains a folder and file structure similar to that of the actual web archives folder. A sample Web folder is available.
The Web folder may include a top-level index.html as well as a folder entitled Default and folders named after lists; these subfolders may include medium-level index.html files and also Default files, with latter being targeted at the archives themselves. The purpose of each of these files is to outline the format of the actual web archives and do so in part by using tokens to indicate where actual data is to be inserted. The generic tokens are [date], [address] and [name], with the latter two indicating the listmaster, and the loop tokens for respective levels are [list], [toc], [body] and [file]. If for instance the top-level outline index.html includes a single line that includes the [list] token, then all lists are displayed, each in the specified format. The [list] token by the way may be used as a generic token at other levels.
The list-specific MIME digest as attachment feature is enabled by adding the letter L to the List Stuff field (see the Admin or AppleScript).
The AutoShare Hosts file was added to ease the use of EIMS non-default domains with AutoShare. Assuming that the EIMS default domain is used with the AutoShare bounce address, the domains in the AutoShare Hosts file must match the remaining EIMS domains for list contributions to work properly.
The AutoShare host entries may be added in the Admin application. It may be noted that host entries were formerly created in the AutoShare Hosts text file in the AutoShare folder inside the System 7 savvy Preferences folder; type in one domain name per line; AutoShare still accepts new host entries this way though when starting up. Verify the list of domains by choosing the AutoShare Analysis menu item from the server and viewing the AutoShare Analysis file; the bounce address is listed first followed by the domains in the hosts file.
When using the automated bounce feature, it is strongly recommended that the bounce account not be identical to the EIMS postmaster account, as mail received by the bounce account is for AutoShare only. And as usual, it is a must that the domain of the bounce address reflect that of the mail server.
Whenever bounce mail arrives, AutoShare's bounce module will process the message file and subsequently send the admin a mail if a list subscriber could not be located. Otherwise the list subscriber is updated in the Bounces On Hold file located in the AutoShare folder inside the System 7 savvy Preferences folder. The subscriber address, the list name, a sent counter (initialized to zero), a received counter (initialized to zero) and an entry created time are the five pieces of information, which are added to each entry in the Bounces On Hold file.
Every so often (using the Bounce Send Mail property in the Miscellaneous Options), AutoShare sends a mail to each entry in the Bounces On Hold file, and the sent counter is incremented by one. If the subscriber address continues to bounce, the new bounce message causes the received counter of the entry to be incremented by one (additional bounces will not cause the value of the received counter to grow beyond the value of the sent counter, as it should not be a factor how busy the given list is), and once the received counter hits a given threshold (using the Bounce Received Threshold property in the Miscellaneous Options), the subscriber get unsubscribed, and the entry is removed from the Bounces On Hold file.
If the subscriber address does not continue to bounce, the sent counter continues to grow while the received counter does not, and once the difference of the two values is beyond a given threshold (using the Bounce Sent Threshold property in the Miscellaneous Options), the entry is considered stable and removed from the Bounces On Hold file.
Entries are also deleted when the current time exceeds the entry created time by a given threshold value (using the Bounce Delete Threshold property in the Miscellaneous Options). The purging takes place every time test bounces are sent.
The Bounces On Hold file includes entries based on soft bounces only. Hard bounces get unsubscribed immediately per the default behaviour (which includes sending a mail to the listmaster), but may be configured to act as soft bounces. A hard bounce is defined as a sender situation which is not likely to change (such as the sender's address not known), while a soft bounce relates to a temporary situation (e.g. the mail server of the sender may be down due to a network problem). Of the bounce formats supported by AutoShare, the 550 code (user unknown) is the only one so far to trigger a hard bounce status.
Version 2.1 significantly expands on the number of supported bounce formats and also incorporates subscriber alias files as one of several refinements. Test bounces include an X-AutoShare-Bounce-List header, making it easier to identify the list name within the bounce message caused by a test message. Furthermore, if the Misc Stuff property in the Miscellaneous Settings contains the letter f, AutoShare removes the subscriber from all lists rather than just the list in question.
Version 3.0 extends the bounce module to take into account bounces that may arrive after a subscriber has been softly unsubscribed, so that the listmaster no longer receives unresolved bounce mails for these. The Bounce Grace Period property in the Miscellaneous Options (with this as well as the above, see alternatively the More Miscellaneous window in the Admin) specifies the length of additional time.
The List- and X-List- RFC field headers and respective field bodies are:
You may replace subscribe and unsubscribe with join and leave by adding the letter R in the Admin's Misc Stuff field.
Other related field headers and respective field bodies are
All of the above fields may optionally and individually be turned on and off on a per-list basis (with the exception of the List-Software field), see the list-specific configuration for AppleScript or the Admin.
Further information is available at Mail List Command Specification, RFC 1738: Uniform Resource Locators (URL), RFC 2368: The mailto URL scheme, RFC 2369: The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields and List-Id: A Structured Field and Namespace for the Identification of Mailing Lists (draft).
You may instead create a "Month" folder and store list-named files inside. Add only a Default document if non-specified lists are to receive a help file.
Both message and digest subscribers receive the monthly help files. RFC List- headers are added to the monthly help files. See also the Month command in remote administration by e-mail.
If a + (plus sign) is appended to the prefix, the prefix will appear at the end of the subject instead.
Headers and footers also appear at the beginning of and end of digests. The "Header.<list>" and "Footer.<list>" files are used in digests, unless "HeaderD.<list>" and "FooterD.<list>" files are present.
To free the Documents:autoshare folder of clutter, you may instead create "Header", "Footer", "Header.D" and "Footer.D" folders and inside each of them put a Default document and <list> documents.
For a moderated list, the list contributions forwarded to the list master do not include headers or footers. They will be inserted when the list master posts the contribution to the list.
If several lists are to share one header or footer document, you may create aliases reflecting the normal file name format and pointing to the same document.
To reinforce that the unquoted part of a response contribution must be at least a given percentage of the complete message body, change the proper list-specific setting to this percentage. If it does exceed more than the percentage, the message is returned to sender. John Norstad's NewsWatcher applies this restriction to news responses (50% only though), if the news server in question is configured to reject postings which contain more quoted text than new text.
Auto-response documents are located in subfolders inside the Document folder. The subfolder names must correspond to the user names of the AutoShare accounts in EIMS. Inside each subfolder, create a default document called Default. This document is used for senders not specifying a particular string in the subject line. Alternate documents may be created, and the subject line of the sender's e-mail must match one of the names of these documents for it to work. The character '-' (minus) in an alternate file name will match the character ':' (colon) in a message subject.
The contents of an auto-response command document is mostly text that you decide on your own how to reflect the context of the command. Standard auto-response documents also include at least one token line to trigger a given action. Each token pair (a switch and a command) comes with or without any delimiter.
Standard tokens:
/=original = picks up the original message /=include <file path> or <file name> = inserts contents of file /=forward <address> = sends copy of original message to address /=redirect <address> = redirects original message to address /=pe <parameter> = see the Token process extenderAuto-response tokens:
/=subject <field> = overrides the RFC Subject field body /=reply-to <field> = inserts an address in the RFC Reply-To field /=poll = activates poll mechanism /=mailback = processes message file as mail-back /=rfcfrom = updates envelope recipient to RFC To /=rfcsame = kills message if RFC To is not env recipient /=header = picks up the original RFC header only /=hdr = includes minimal headers only /=body = includes message body only /=attach <file path> = secondary BinHex on-the-fly file attachments /=prefix <prefix> = adds specified prefix to the subject fieldToken lines are placed as separate lines in documents at appropriate locations depending on the text contents.
BinHex encoding on-the-fly is available. When an auto-response document, e.g. 'autoreply', has another file, e.g. 'autoreply.', in the same folder, the trailing period triggers a BinHex on-the-fly conversion, e.g. 'autoreply.hqx'; if this file is already available, no conversion takes place. The file having the trailing period may be a Finder alias to another file anywhere.
The standard (pre-)BinHex file for an auto-response document may be accompanied by secondary (pre-)BinHex files, if the auto-response message is MIME-compliant. This is triggered via the /=attach token followed by the full path of the file; multiple such token lines are allowed. Keep in mind that the primary (standard) (pre-)BinHex file must be specified, or the secondary files are cancelled.
Anyone may vote on a given topic by sending a mail to the Poll address. The topic of the vote is based on the specific subject line. The actual vote of the sender is based on the first line of the body. Whenever a sender tries to vote, the overall vote statistics are returned. If it's the sender's first try, the pool of votes gets updated, and following attempts results in informing the sender of the number of attempts so far.
The poll account may be used to gather all kinds of distribution data based on the key strings (max 20 characters each) in the body. The poll account rejects all subjects which have no corresponding document or uses the Default document. The poll action is triggered by the /=poll token, which should be placed in all documents, also the Default document, in the poll folder. The poll status returned to the sender shows the overall distribution sorted by selection, and graph bars help illustrate the results.
A set of pre-defined key strings may be attached to a poll. When an invalid key string is encountered, AutoShare returns a note to the sender asking for another try. The series of case-insensitive key strings resides in the 'STR ' resource, beginning at 1001 and upwards, of the poll file in question; you can use the SetRes AppleScript command or the Admin's Resource window to configure this.
Filtering can be enabled, so that vacation notices are not returned to for instance list server lists or mailing lists. The filtering applies to From, To, Subject, Reply-To, Sender or any header being one of the five. Inside the Filters folder, documents containing the filter definition lines are named according to the user names of the AutoShare accounts in EIMS.
A particular aspect is the ability to configure a user's filter file, so that any given sender will receive one vacation notice only regardless of how many messages the sender mails to the user on vacation.
In order to reduce of the risk of vacation notices being returned to list server lists, filtering is automatically applied to any messages with a Precedence RFC header field having a field body of bulk, list or junk. In the case of an AutoShare list server, a Precedence RFC header field is added to list contributions.
To prevent forwarded messages, the /=rfcsame token in vacation documents and other standard auto-response documents compares the RFC To field address with the SMTP envelope recipient address, and if they are not identical, the processed message is filtered and no message is returned to the sender.
Incoming UUCP: The EIMS POP account is configured as 'Save as archive' to an inspool folder/user (e.g. 'EIMS HD:Misc:inspool:meh'); this forwarding option satifies Eudora's expections of the mail drop being in the standard Unix mailbox format. The Eudora part (Settings, POP Account, e.g. '!EIMS HD:Misc:inspool:meh') is made possible thru the use of file sharing applied to the EIMS server's harddisk.
Outgoing UUCP: The Eudora part (Settings, SMTP, e.g. '!MEH HD!EIMS HD:Misc:Filed Mail:!meh!0000') is possible thru the use of file sharing to the standard Filed Mail folder. AutoShare automatically acts upon detection of the D./X. UUCP pair of files by converting them into one properly formatted file sent to the EIMS Incoming Mail folder and finishes by deleting the UUCP pair of files.
The contents of the D. file is transferred directly to the data part of the new mail file; the resource part is updated based on the X. file (sender (appends the domain from the Bounce address) as well as (multiple) recipient(s)).
It is recommended that you choose to reduce the file sharing to include the two above folders (the inspool folder and the Filed Mail folder). The mail spooled by Eudora to the Filed Mail folder will stay there for a very brief moment and as such poses no major risk in terms of security. Access to the inspool folder may be adjusted to include the individual user only.
The AppleScript configuration of unique application creator codes is accomplished via the SetKeepUp (adds or deletes an application creator), GetKeepUp (returns the list of active creators) and GetCreatorApp (returns an application name from a creator) commands.
The Admin's Keep Applications Up window makes the configuration particularly easy, in part because the window's Select button allows you to choose an application without knowing the creator in advance.
The name Cron is a little known linguistic misunderstanding. While it is common in Greek mythology to have just about everything personified, time as such is an exception from this rule. Cronos (Cronus, Kronos), a titan who dethroned his father Uranos and ruled the universe until dethroned himself by his son Zeus, did not personify khronos, Greek for time. The Greek words khronos (that the word chronological is derived from) and Cronos (that the word Cron can be said to be derived from, although that was probably not the intention at Bell Labs) are not linguisticly related. The conception of the twelve titans, Cronos in particular, lead to the creation and motion of time however!
Put Finder application aliases in Launch and Quit folders inside the AutoShare folder inside the System 7 savvy Preferences folder. The syntax for the file names of the Cron aliases is Minute Hour Date Month Dayofweek; 0-59, 0-23, 0-31, 1-12 and 1-7 respectively, and * may be used to specify any time for a given token. When applied to the Launch folder, "0 * * * *" launches the application every hour on the hour, "0 22 * * *" launches the application every day at 10 pm, "0 12 * * 2-6" launches the application every Monday through Friday at noon, "0 12 1,15 * *" launches the application every 1st and 15th of the month at noon. A combo such as "-5,8-10,12,15- * * * *" is fine. For system restarts and shutdowns, use aliases to the Finder application.
Auto-replies and vacation notices also insert Precedence: bulk. Furthermore, incoming messages with Precedence: junk and Precedence: list also get suppressed.
The filtering applies to the five fields below in the e-mail header. It also applies to any header being one of the five. Below, the first column indicates which field is to be applied, and the second column lists how to begin a definition line; the rest of this line is a substring aimed at searching in the e-mail header line in question.
From: 'From: '
To: 'To: '
Subject: 'Subject: '
Reply-To: 'Reply-To: '
Sender: 'Sender: '
Any Header: ''
Examples:
Simple filter file:
qualcomm yalevm.cis.yale.edu
qualcomm yalevm.cis.yale.edu *****When user@domain mails you, it will look like this:
qualcomm yalevm.cis.yale.edu ***** user@domainAnd later:
qualcomm yalevm.cis.yale.edu ***** user@domain user2@domain2Remember to clear and move the file, when you return!
You may choose to configure this behaviour differently. The level of suppression of list server commands in subjects and first body line is configured using the Suppress Command property in the AppleScript Misc Options: 1 = always suppressed, 2 = never suppressed, 3 = body only is suppressed.
The configuration per list requires a language document (see sample template) to be put in the Languages folder inside the AutoShare preferences folder and then have its name be specified via the Language field in the Admin's Yet more list window.
First of all, it is important to understand the difference between real and RFC header addresses: while the RFC header addresses reside in the e-mail RFC header of the message, the real addresses are found in the resource part of the message file, namely the STR (8192, From) and the STR# (8192, To) resources (in the world of UUCP, the D. file reflects the data part, whereas the X. file reflects the resource part).
Taking advantage of the bounce feature (either On or Empty is an important step towards limiting potential problems with loops (circular references). For all auto-responses and admin log mailings, the STR resource will be updated as coming from the bounce account rather than the auto-response account in question (no change in the e-mail header's From field). This ensures that all messages, which bounce back to your server, are sent to your bounce address (and this one only).
It is recommended that you configure your AutoShare preferences, so that the Admin address is set for a Listmaster account and the Bounce address is set for a dedicated account for error messages. It certainly does not have to be so, but it does serve as an excellent and easy-to-remember solution.
The following examples illustrate various loop situations, in which real addresses tend to differ from RFC header addresses.
Your basic bounce
The list server (in fact any AutoShare account) returns an auto-response to a user, whose mail system is malfunctioning at the time. The message bounces back to the mail system of your list server, but although the list server account is listed in the To field of the e-mail header, the bounce account receives the mail: it is the actual recipient because it was originally the actual sender.
Mail to the same account
You have enabled the vacation notice feature; in terms of EIMS, this means that you have turned on 'Save as files' with the 'Keep' button checked. After having sent the message, your account receives the message; furthermore, the other copy is put in the Filed Mail folder: AutoShare compares the To and From resources, and since they are identical, no vacation notice is triggered. This feature applies mostly, when the bounce feature is not used.
Incoming list mail
An example involving not AutoShare, but EIMS only is messages generated from a mailing list being put into the Filed Mail folder: the To in the e-mail header is the list address, while the To in the resource is the final recipient. While this is not a loop issue per se, it illustrates the difference between the two types of To addresses (this distinction relates to the feeding of the archives thru the use of the 'Save as files' Archives account, which AutoShare benefits from).
NewsWatcher
You have enabled the vacation notice feature and then press Command-Option-L in NewsWatcher, which mails you the news article. The actual sender is you, not the person who posted the article, so there is no problem.
Mail to Cc recipient
This example affects the e-mail header only, but I'll include it anyway. An AutoShare account receives a message, and the address of this account is placed in the Cc field. In this case, AutoShare doesn't use the address in the To field when creating the From address for the auto-response message; instead the newly created From resource is inserted into the From field in the e-mail header.
Whenever a file arrives in the Filed Mail folder with a first body line beginning with your admin password, remote administration sets in. The list-specific admin password is configured in AppleScript by using the SetList command (or using the AutoShare Admin), as the following example illustrates:
SetList Options {List: "fun-l", Remote Password: "rosebud"} When applying remote administration by e-mail, let the first body line (if the subject mode for list server requests, then the subject field instead) follow this word pattern:
<password> <command> <e-mail> <list> <rest>for instance
rosebud subscribe a@b fun-l Mr. XCommands supported so far are subscribe (the 5th word is just the rest of the line), unsubscribe (the name is not needed), set (the option is the 5th word), review (use a dummy e-mail address as the 3rd word) and analysis (the password and the command are adequate; the 3rd and 4th words may be used too, the latter for specifying a section per the analysis AppleScript command). The password is case-sensitive, the remaining parameters are not. All of these commands returns an e-mail to the sender with a status; the original command line is included, but the password is replaced by a generic word for safety reasons.
The post command is different from the above commands in several ways. You may use it to post to a list regardless of your client software's configuration, as the e-mail address and user name are picked up from the e-mail and rest tokens respectively. The list token is used to update the recipient, so the contribution gets posted to the list; no e-mail is returned to the sender or the contributor. The body of the contribution message is what follows the initial passworded line (if the subject mode, then put the passworded line in the subject and the subject as the first body line).
The password command may be used to change the password. Enter the new password as the 3rd word. If no list is specified, the request is aimed at the overall password. Both the old and the new passwords are replaced by generic words in the returned message. An e-mail is returned to the sender with a status.
The application and system commands have been added to accomplish remote launching and quitting of applications as well as system restart and shutdown. For either command, you may enter Launch or Quit as the 4th word, and the application command requires the 4 character creator (signature) code of the application in question in the 5th word. The 3rd word is ignored. List may be used as the 4th word with the application command to a receive a list of processes. Dir may be used as the 4th word with the system command to a receive a list of items in a folder, whose path is specified as the 5th word.
The log command mails log messages beyond the scheduled time. If the remote password for the main listmaster is roseall, the following command mails log messages to the listmasters similar to when the logs are scheduled, except that the log file is not initialized by default.
roseall logWhen a list name is specified, the log for that list only is mailed to the listmaster in charge. The remote passwords for the list-specific or main listmaster are both valid. E-mail addresses without @ or with @ only are ignored as such.
rosebud log x fun-lIf a non-existing list name is specified by the main listmaster, only the main log is mailed.
roseall log x bad-lThe log file may furthermore be initialized using the main listmaster's password, if the e-mail address specified is the @ character and no list name is specified.
roseall log @If an e-mail address is specified, the log(s) may be sent to this address.
rosebud log a@b fun-lThe alias command (main listmaster password only) may be used to create a Finder alias file for a target file on the Macintosh running AutoShare. Enter the absolute path of the target file as the 5th word (or more words if needed), and enter the file name of the Finder alias as the 4th word. The 3rd word specifies a code for the folder, in which the alias is to be created (the Apple Menu Items folder is amnu, the Startup Items folder is strt, the Desktop folder is desk, etc). To move the alias file to another folder, the rename command of an ftp client can be used if you have an ftp server running on the server Macintosh.
You may also specify the alias folder path as a regular path ending with a colon (as the command line is likely to become longer this way, it is recommended to turn off word-wrapping in your mail client). If you want to delete an alias file (or another file), omit the target path (the 5th word). And if the 3rd word is not four characters long or does not end with a colon, the 5th word is interpreted as a path to be resolved.
roseall alias disk:aliaspath: aliasfile disk:targetfolder:targetfileThe setres, getres and run commands (main listmaster password only) function much like their AppleScript counterparts. The setres command updates a STR# value in the AutoShare Preferences file, and the getres command returns it. As many preference values are also loaded into memory at start-up, the setres command often needs to be followed by the run command to make sure that the values in memory reflect the values stored in the disk file; list-specific settings at STR# 1001 and upwards though are not kept in memory. The section on the AutoShare Preferences file and its list-specific configuration describes the STR# value structure of the preferences file.
roseall setres 1999 1 blah... roseall getres 1999 1 roseall runThe month command may be used to send monthly help files to all lists or to a given list. The e-mail address parameter (with @ in it) may be specified for testing help files sent to that address.
The script command may be used to compile and execute AppleScript text code specified in the message body, when the first line is the main password followed by the word Script. Also supported is executing compiled AppleScript files, when the path of the compiled script file is specified in the 5th word.
Multiple lines using the above remote format are supported (in the body mode only). AutoShare stops processing the body once there are no more lines beginning with a valid password. While a post line must be the last of one or several passworded lines, it need not be the first.
For safety reasons, I highly recommend the recipient be autoshare@....
The passwords for remote administration by e-mail have been made list-specific in version 1.3, so you need to update all of your passwords to make your configuration current, using the Admin or AppleScript (if you edit your Preferences using a resource editor, please pay close attention).
If AutoShare detects a valid list in 4th word, the list-specific password works as well as the overall password, which works whether or not a valid list has been specified.
It may be added that the somewhat more complex Script By Mail AppleScript sample package offers the alternative of issuing AppleScript commands via e-mail.
The Token process extender is supported by remote administration by e-mail. As no response document is used, a document entitled Remote Process Extenders in the AutoShare Preferences folder is used instead. Enter the command as the 1st word in a line and the unique word passed to kOptions as the 2nd word. This also ensures that the process extender is not called