AutoShare 3.0 introduces two database formats for subscribers as its major feature and furthermore offers support for list-specific languages for subscribers, MIME digests as attachments and additional commands for remote administration by e-mail. As always, support for more bounce formats has been added. See also the notes on upgrading, post-releases and minor improvements and bug fixes.
The major feature in AutoShare 2.0 is Multiple instances of preference sets.
To subscribe to the AutoShare Talk list, send mail to autoshare-talk-on@frutiger.staffs.ac.uk.
If you're in a rush or find the documentation daunting at first, the quick tutorial is for you :-)
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.
What are EIMS and SIMS?
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.
What is AutoShare?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!
Using AutoShare for the first timeWhen 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.
Upgrading AutoShareVersion 3.0 introduces the Verify File, SetSubscriberDB and GetSubscriberDB commands. It also adds the Database and Language properties to the List Options class, the Bounce Grace Period property to the Misc Options class and the standardSub property to the GetSubscribers command.
Version 2.4 adds the Bypass Blank property to the Write Log AppleScript command and the Notice property to the Filters Options class. The Clear property in the Filters Options class has been refined. The SetRes and GetRes commands have been restructured and expanded.
Version 2.3 adds the Unknown Addresses property to the Misc Options.
Version 2.2 updates the AppleScript dictionary by applying enumerations (constant classes). 'SetMisc Options {Log: "Brief"}' as an example is now to be replaced by 'SetMisc Options {Log: Brief Log}'. The advantage is that a compiled script will reveal an invalid enumerated property value (perhaps due to a typo) as an immediate syntax error (when compiled or when run), whereas a string value is a matter of contents rather than syntax and as such cannot be detected by the AppleScript language per se.
A total of 15 enumerations including 51 enumerators and 60 enumerator instances have been changed in the server application. Affected are 4 classes (List Options, Misc Options, Times Options and Filter Options) and 7 commands. The AppleScript dictionary, which is merely the tip of the iceberg as the code to support it took the most time, illustrates how the property values are placed along with the property names rather than in the comments.
The sets of enumerated values in the AppleScript dictionary correspond to the sets of radio buttons in the Admin, as they both reflect the same multiple choice situations.
The comments for boolean and enumerated values have been fully updated in the dictionary to reflect defaults whereever not indicated previously. The same goes for optional and read-only indicators.
Additionally and extending the above totals, the value for the Lists parameter in the GetFilters command is now enumerated as well.
The Listserv property in the Folder Options class has been renamed to List Server. The Listserver Name property in the Misc Options class has been renamed to List Server Name. The Listserver Label property in the Misc Options class has been renamed to List Server Label. The XSeeAlso property in the List Options class has been renamed to List Help.
The RunScript AppleScript command has furthermore been added, which is used to call the Script process extender via the AutoShare server.
Version 2.1 updates the AppleScript dictionary by adding the Bypass Add to the Subscribe command. The Misc Stuff and List Stuff properties (aimed at my fence-sitting) in the Misc Options and List Options respectively may be used with various letters, whose functionality is described elsewhere in this document.
When upgrading to version 2.0, notice that the AutoShare Temp folder has been moved into the AutoShare folder inside Preferences folder; you may go ahead and delete the Temp folder at its former location in the Preferences folder.
Version 2.0 also updates the AppleScript dictionary by adding the Suppress Command, Listserver Label and Locking properties to the Misc Options. A new AppleScript property in the Stat Options is LockingFiles. New optional AppleScript parameters in the Send Mail command are File Quote and File Delete. New AppleScript commands used with multiple preferences sets are SetPreference, GetPreference and GetPreferences. Furthermore, the SetKeepUp, GetKeepUp and GetCreatorApp commands make the Keep applications up feature completely scriptable.
If you are using EIMS 2.0, please notice that the Mail Folder has been moved inside the EIMS 2.0 application folder, which means that you must reconfigure your Incoming Mail folder in AutoShare.
When upgrading to version 1.4, be aware that new file extensions (.text and .txt) have been assigned to digests and text archives.
Version 1.4 also updates the AppleScript dictionary in a number of ways. The Quote property in List Options has been changed from a boolean value to a number (indicating a percentage). New List Options properties are RFC Headers, List Stuff, Address Protection, Tip Of The Day, Approval Both and Hard Unsubscribe. All boolean types in List Options have changed to non-boolean types to accommodate the default/override values. New Misc Options properties are Line Format, Keep Up, Processing, Status Window Position, Hide Window (formerly a command!) and Misc Stuff.
EIMS and AutoShareAutoShare 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):
What is a list server?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!).
Auto-responsesEach auto-response service may optionally include a BinHex enclosure.
Vacation notices System requirements Applications Folders
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.
Files
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:
Folder and file names An introductory tour The folders on your server
Configuring AutoShare and EIMS
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.
Testing AutoShare as a user AutoShare server applicationEnter 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).
Bounce account LogsYou 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):
AutoShare Admin applicationThe 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 MacOS 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. 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), 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. Further details on configuration are available in the section describing the AutoShare Preferences and list-specific configuration.
As the user interface of the Admin forms a complete and well-structured version of the basic user interface of the server application, no manual on the Admin is available per se. Simply keep in mind that the Miscellaneous and Lists windows are the key to the AutoShare configuration.
Menu selectionsFile 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 L = Lists D = Documents I = Filters H = Hosts Y = Keep Applications Up Extras menu: (no letters used) (B, G, R are not used)
AutoShare scriptabilityApple 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.
AppleScript commands
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 AppleScript commands, SetMisc, SetFolders, SetTimes and SetHosts, are directed towards the configuration also accessible via the AutoShare server user interface. The AppleScript syntax is much like that of SetList:
The AppleScript command, Review, enables a subscriber list to be mailed to the main listmaster or a specificed e-mail address. Write Log enables you to send and insert a string into the log. GetStat returns various status information. File Mail lets you create a message file in the Filed Mail folder, as if a sender sent a command to the list server, and Send Mail is a scriptable way of sending your own mail .The Review command supports the list being all, so all lists are processed.
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 server and list basics List server commands
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
UNSUB: unsubscribe, 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.
Request addresses<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.
Subscriber list files and formats Standard subscriber formatList 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.
Searching and sorting subscriber listsThe 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.
The message and digest list filesEIMS 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.
List server documents and tokensThe 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 messageCommand 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.
List-specific documentsAll 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" 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.
List typesWhen 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).
ModeratorsA 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!
Tip of the day lists Subscriber addressesAutoShare 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.
Subscriber address protectionUsing 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.
Subscriber aliasesThe 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).
List-specific logs Archives and digestsA 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.
Text and/or HTML archivesIt 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 List 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.
Rollover of archive filesWhen 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/.
Automated web archivesThe 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.
MIME digests as attachmentsThe list-specific MIME digest as attachment feature is enabled by adding the letter L to the List Stuff field (see the Admin or AppleScript).
Advanced features Multi-domain hostsThe 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.
You create the AutoShare Hosts text file in the AutoShare folder inside the System 7 savvy Preferences folder; type in one domain name per line. 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.
Automated bouncesWhen 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.
Miscellaneous features List- and X- RFC fieldsThe List- and X-List- RFC field headers and respective field bodies are:
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 RFC 2369: The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields.
Monthly help filesBoth message and digest subscribers receive the monthly help files.
If several lists are to share one monthly help document, you may create aliases reflecting the normal file name format and pointing to the same document.
Subject prefixesIf a + (plus sign) is appended to the prefix, the prefix will appear at the end of the subject instead.
Headers and footersHeaders 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.
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.
Rotating banners Other list related issuesTo 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.
Auto-response tokensThe 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 messageAuto-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 /=header = picks up the original RFC header only /=rfcfrom = updates envelope recipient to RFC To /=forward <address> = sends copy of original message to address /=include <file path> or <file name> = inserts contents of file /=mailback = processes message file as mail-back /=rfcsame = kills message if RFC To is not env recipientToken lines are placed as separate lines in documents at appropriate locations depending on the text contents.
Setting up a pollAnyone 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.
Suppressing messages using filters General filtersAuto-replies and vacation notices also insert Precedence: bulk. Furthermore, incoming messages with Precedence: junk and Precedence: list also get suppressed.
Specific filtersThe 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
The one vacation notice only feature added:
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!
List server requests on listsYou 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.
List-specific language supportThe 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.
Loop detection and eliminationFirst 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.
Remote administration Remote administration by e-mailSetList 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 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 runMultiple 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.
Subscriber and administrator web formsUpon arrival, AutoShare parses the message body to determine if the message stems from a web form with a mailto: action (does not rely on the Content-type: application/x-www-form-urlencoded RFC field anymore) and subsequently turns the mirrored web-originated message files into standard message files (list server requests and remote administration by e-mail respectively). Complete URL decoding is applied to the data received from the web browser.
A subscriber form may use the command, list, name and option tokens as well as the subscribe, unsubscribe, set and review commands.
The remaining commands, new in version 1.4, are: list, index, get, which, release, query, search and help, and new tokens are file (for Get) and string (for Search).
An administrator form may furthermore use the password and email tokens as well as the analysis command (the post, password, application and system commands are not supported in web forms).
New in 2.0 is the comments token, which comes in handy when addressed to auto-response addresses, as the body of the token forms the body of the standard message file.
Mail-back confirmationsTwo new folders are introduced, the Mail Back folder and the Hold Mail folder, which must be specified in order to enable mail-backs (see the More Folders window in the Admin). The mail-back feature works on a per account basis, so if you would like mail-back enabled for a given account, you re-configure the EIMS Save as files account to point to not the Filed Mail folder, but the Mail Back folder instead. Once the message file appears in the Mail Back folder, AutoShare moves it to the Hold Mail folder and puts a new message file in the Incoming Mail folder, asking the user to confirm by replying to the mail; the first line in the body (or in the subject if you add the letter J to the Misc Stuff field) displays the confirmation key, which is the unique name of the original file generated by EIMS. When the confirmation message file arrives in the Mail Back folder, AutoShare checks the first line in the body, and if it matches the name of a file in the Hold Mail folder, this file is moved into the Filed Mail folder, and the confirmation file is deleted.
The contents of the returned mail-back message to the user will go beyond including just the confirmation key in the first line of the body, if you put a line-based text file entitled Mailback in the Documents/autoshare folder. A blank line and the contents of this file will be added, thereby explaining the user what to do. The /=original and /=subject tokens are supported in the Mailback file (if the confirmation keyword is configured to appear in the subject, the /=subject token string is in front of the keyword).
Deletion of unconfirmed message files takes place automatically. The Hold Mail Check property in the Options (Misc) indicates in minutes (default is 10 minutes) how often AutoShare should check for expired files, and the Hold Mail Expire property indicates in minutes (default is 600 minutes = 10 hours) the duration before expiration takes place from the time the file was created by EIMS.
The AutoShare account is a unique and more complex case, as you may want some commands enabled for mail-back and others disabled. To feature this, a new list-specific Mailback property is introduced in the AppleScript Options (List). If the string is blank, the general setting is looked at, and if the string there is blank too, no mail-back is enabled for the given list. You may add N (None) to the list-specific string to avoid use of the general setting.
The A (All) enables mail-back for all commands for a given list, and if a command does not contain a reference to a list, the general setting is used. Here are the letters for the various commands: S=sub, U=unsub, E=set, Q=query, R=review, I=index, G=get, H=search, W=which, L=list, C=release.
The list-specific string SUQL indicates that the sub, unsub and query commands are mail-back enabled, while others are not; the status of the list command is determined by the general setting, as it is not specific to any given list.
If both the general and list-specific mail-back strings are blank (default), no mail-back takes place for the list server account. It therefore doesn't matter whether the EIMS account points to the Mail Back folder or the Filed Mail folder.
Process extendersWhen AutoShare comes across a hook, AutoShare sends an AppleEvent to the process extender is question, if available. A list of parameters, which the process extender may use, is included in the AppleEvent.
The parameters in the passed list of the AppleEvent are
BP AP SU US AD CA TB SY FI SC ST SD BL EL DB OF 1-8 x x x x x x x x 9 x x x x x x x x x x x 10 x x x x x 11-13 x x x x x x x x 14 x x x 15-16 x x 17-19 xFor suggested variable names for the above parameters, see the Template process extender sample of type Before Processing, which is located in the Sample Process Extenders folder.
AutoShare script commands are processed and returned immediately in process extenders. Be sure however to leave the script at a reasonably calm state when AutoShare script commands are called.
Process extenders reside at the top level inside the Process Extenders folder, which resides in the same folder as the AutoShare application. Aliases are supported for process extenders, so that these may physically reside elsewhere.
There are several sample process extenders inside each sample type folder. One from each folder may be made active by placing it at the top level inside the Process Extenders folder. All sample files are script applications with the source preserved ("Save As..." Application with both "Stay Open" and "Never Show Startup Screen" enabled).
The following describes the various AutoShare process extenders and also makes references to some of the sample process extenders. The class and event IDs used are in parenthesises after the process extender name.
Before Processing ('AuBP', 'aUBP')Within the Before Processing sample folder, the Template process extender illustrates the basic starting-point. The main AppleScript handler merely picks up the call from AutoShare. The purpose of the idle handler is to reduce processing time being allocated to the application when the main handler is not being called.
The List Parameters process extender displays the various parameters being passed from AutoShare. Be sure to have AutoShare running in the background when testing this sample.
The Unconditional Filter process extender intercepts the main AutoShare processing by copying the message file to another folder and completes this task before AutoShare begins its actual processing of the file. If the process extender deletes or moves the file, AutoShare is left with no processing of its own to do.
The Write Log process extender writes a line to the AutoShare log. This sample is particularly interesting, as the sample application calls the very same AutoShare application, which triggered it. AutoShare waiting for the process extender to complete its task causes a Catch-22 situation, because AutoShare does not respond to high-level events during instances of its main processing phase to avoid various high-level event and open file conflicts. The trick is to let the process extender have its calls to AutoShare bypass its requests for high-level event replies; the actual task will be processed instantly though.
As it may be nice for users themselves to be able to turn on and off vacation services and furthermore update the wording of vacation notices without the assistance of the administrator, the Before Processing Vacation sample makes this possible and requires no modification to be used. The idea is that a user sends a mail to an auto-response account entitled vacation@ and specifies one of three words in the subject:
After Processing ('AuAP', 'aUAP') Subscribe ('AuSU', 'aUSU')The FileMaker Pro sample creates a new record in a FileMaker Pro database file having a very simple data structure.
The Send Message sample sends a basic welcome message to the new subscriber.
Unsubscribe ('AuUS', 'aUUS')The FileMaker Pro sample looks up the subscriber in the database and sends a message of when the original subscription took place.
After Digest ('AuAD', 'aUAD') Contribution Alert ('AuCA', 'aUCA')You distinguish among the various contribution alert types by using the code of the contribution alert type parameter. The sample shows this in full.
Test Bounce ('AuTB', 'aUTB')As the parameters reflect the Test Bounce file in the AutoShare Temp folder, you may choose to delete this file and instead send another message to the subscriber in question.
Remote ('AuSY', 'aUSY') Filter ('AuFI', 'aUFI') Script ('AuSC', 'aUSC') Startup ('AuST', 'aUST') Shutdown ('AuSD', 'aUSD') Begin Log ('AuBL', 'aUBL') End Log ('AuEL', 'aUEL') Database ('AuDB', 'aUDB') Optional Fields ('AuOF', 'aUOF') MIME RFC fieldsWhen the MIME property in the AppleScript Options (Misc) is set to Text Plain (default), the following MIME RFC field is inserted after the Mime-Version field:
Content-Type: text/plainAnd when the property is set to MIME QP or QP Always, the following MIME RFC fields are inserted after the Mime-Version header field:
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Mac-to-MIME conversion is applied accordingly in the body of the outgoing message.MIME QP: The MIME property makes a difference for the outgoing message files that are originated by AutoShare and not directly derived from message files arriving in the Filed Mail folder (such as logs, digests and admin notifications). For list contributions and auto-responses, Mac-to-MIME conversion will depend on the MIME RFC fields of the original message as well; the Mac-to-MIME conversion does not take place unless the 'Content-Transfer-Encoding: quoted-printable' field is located (besides the MIME property being set to MIME QP).
QP Always: The MIME Quoted-Printable encoding takes place whether the message file is originated by AutoShare or not.
AutoShare offers MIME Quoted-Printable support for auto-responses with enclosures as well. (The name of the enclosure file will be added to STR# 8193,1 (2-5 are also used) of the outgoing message to insure that boundary lines are inserted correctly at the time of the Mac-to-MIME conversion.) It may be added that if the original mail requesting an auto-response with an enclosure is having a MIME header and no CTE QP header, MIME enclosure handling will be enabled.
See also RFC 1341: MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies.
Multiple instances of preference setsThe AutoShare Preferences file is designed to run one instance of for instance the list server, and the user interface of the server reflects the actions within one status window.
AutoShare 2.0 offers multiple preference sets, so that you may run multiple instances of for instance the list server, with each instance displayed within its own status window. This comes in handy when configuring EIMS 2.0 to handle multiple domains, as you can also have one list server address per domain.
Non-default preference sets are created in the above AutoShare folder by simply creating empty subfolders having names beginning with the @ sign. When starting up, AutoShare creates respective preference sets within such non-default subfolders.
The configuration of each AutoShare 2.0 preference set must generally correspond to the account configuration of a given EIMS 2.0 domain. It is however possible to arrange for multi-preference sets within a single-domain environment as long as you avoid conflicting user names for the special accounts (autoshare@, poll@, protected@), which is accomplished by adding trailing labels to these user names; use the Listserver Label property in the AppleScript Misc Options to configure the labels.
When using the Listserver Label, it is suggested that no label be configured for the default preference set, so that the list server user name remains autoshare@ for the default preference set. By applying a label of 1 to a non-default preference set, the listserver user name becomes autoshare1@ for this preference set (and so forth).
The user%domain@server configuration in an EIMS multi-domain environment is only necessary when you need to configure a client's POP account to tell the server what domain the account is in.
AutoShare distributes the processing of the preference sets in a round robin fashion. When configuring a given preference set, you must first set it to be the only activated preference set temporarily. You may accomplish this via the Multi-preference entry from the Preferences menu in the AutoShare server user interface by selecting a given preference set. Once the configuration has been completed, you may return to normal processing by selecting All via the same Multi-preference entry.
Temporarily activating a given preference set is also supported by the AppleScript commands entitled SetPreference (which activates a given preference set: <name>, Default or All), GetPreference (which returns the current preference set selection) and GetPreferences (which lists the preference set names).
Unknown accountsBy doing so, the mail server configuration of all accounts normally specifying AutoShare's Filed Mail folder is no longer necessary! No <list>@ accounts, no autoshare@ account and no auto-response accounts need to be individually configured.
When processing, AutoShare will initially perform all special cases, and when it then is about to process the standard stuff, a check will be done: if the recipient address is not a list (based on a file in the List Server folder) or an auto-response (based on a subfolder in the Documents folder), then the address is unknown and subsequently processed according to your Unknown Addresses configuration in AutoShare (see the Admin or AppleScript):
Folders and aliasesThe AutoShare folder in the System Preferences folder may figure as a folder alias. The alias to the actual folder located elsewhere is resolved when AutoShare starts up.
AutoShare Temp folder Processing modesThe normal processing mode may be manually disabled and enabled, either via the toggling disable/enable processing menu item in the server Preferences menu or via the AppleScript NonProcessing property in the SetStat command. If you accidently leave AutoShare in the non-processing mode, there is no reason to worry, as AutoShare will check every so often (defaults to 60 minutes) to see if it is okay to re-enter the normal processing mode.
Locking filesIt may be manually disabled and enabled, either via the toggling disable/enable locking menu item in the server Preferences menu or via the AppleScript LockingFiles property in the SetStat command. If you accidently leave AutoShare in the locked mode, AutoShare will check every so often (defaults to 60 minutes) to re-enter the normal unlocked mode.
Resource fork verification Out of memory and low on disk spaceSituations relating to AutoShare being low on memory are often temporary, so one reminder only per incident will be issued. Future transactions will be processed in a normal fashion, although some specific transactions may cause history to repeat itself, at which times further reminders will be issued.
When a disk is close to being full, the situation is not likely to change much by itself. Both periodical and pre-processing checks applied to all involved volumes will be performed based on a worst-case scenario, and when the threshold has been hit, the processing of the current task will be completed if possible, the reminders will be issued, and AutoShare enters the non-processing mode. Once the situation has been resolved, AutoShare resumes normal processing.
When AutoShare gets low on disk space, it no longer shut downs, but instead moves into the non-processing mode. Messages are mailed to the listmaster every hour to inform of the low disk space situation. When adequate disk space has been restored (checking for this every so many minutes (defaults to 60); AppleScript, see the Processing property in Misc Options; the Admin, see the More Misc window), AutoShare returns to normal processing.
Shutdown alert dialogsAlert dialogs come in handy as they offer an explanation of why for instance the server may shut down just after being started up, e.g. because another AutoShare process is already running.
Drag and drop onto AutoShareIf the name of a dropped file is that of a list, the file's address lines create respective subscription message files in the Filed Mail folder, which is a convenient way of adding many new addresses at one time while also providing the subscribers with returned notifications. Notice though that the dropped file may not be any list file in the List Server folder for this to occur.
If the dropped file however is a list file in the List Server folder and the list is configured for the built-in database format, then the list's subscribers are imported into the respective database file in the Databases folder. If the list is not configured for the built-in database format, nothing happens.
If the name of a dropped file contains an '@' sign, then the first e-mail address of each line will be extracted and output to another text file, whose name is appended with '.1'. The output file may then be used as a standard list file. If the output file already exists or if the input file name contains more than 29 characters, nothing happens.
The terms default and override are used often in this section. The generic meaning of these two words is applied to the list-specific configuration of AutoShare to indicate, that if you don't go out of your way to configure a given setting for a list, the respective general setting will be used instead. Many lists frequently share the same settings, which conveniently may be configured on the general level (a list-specific setting defaults to a general setting), whereas truly list-specific settings may be configured on a list level (a list-specific setting overrides a general setting). As a rule, strings being blank and numeric values of -1 are most often the override values indicating default.
The AutoShare Preferences file resides in the AutoShare folder within the System 7 Preferences folder and is created automatically by AutoShare, when starting up.
List-specific settings
AutoShare also initializes the list-specific settings in this file by creating standard default values, when starting up. The list-specific configuration is stored in STR# 1001 and upwards, one STR# per list. Index numbers for fields and description of values within these are:
General list settingsSTR# 1000 holds the general configuration for lists and uses the layout of fields and values for the list-specific settings. You probably have to update the configuration for only some of the fields for a given list: if the fields marked in the general configuration contain the same data as you would like to apply to the list, they are considered default values for the list if you leave the respective list-specific fields alone.
Miscellaneous settingsSome server configuration not relating to lists is kept in STR# 201 (string values default to blank):
All of the configuration data may be viewed in the AutoShare Analysis file. Or perhaps best is the user interface of the AutoShare Admin, which communicates with AutoShare via scripting.
The development environment of AutoShare does not rely on a framework such as PowerPlant or MacApp. The PowerPC native version is compiled and linked directly from sources to application and does not use a PowerPC conversion tool such as MacApp2PPC.
When AutoShare 1.0 was released, it was the first 68K list server for the Mac, and with the release of version 1.1, AutoShare was also the first true PPC native list server for the Mac.