Description of the files in the "netconfigs" directory These files contain a set of network configurations for a room. They are stored in the directory $BBSDIR/netconfigs and are named according to each room's internal ID number. When a room is deleted, its network configuration file is deleted as well. The configuration file contains one or more lines of text, each line containing a configuration option. These lines may specify message pointers, room sharing instructions, mailing list recipients, etc. Fields are separated by the vertical bar character ("|") and there will always be at least one field on each line. INSTRUCTION: lastsent SYNTAX: lastsent|0000000 DESCRIPTION: Defines the *local* message number of the last message in this room which we have performed outbound network processing on. Any batch job which sends out messages should do stuff. INSTRUCTION: listrecp SYNTAX: listrecp|friko@mumjiboolean.com DESCRIPTION: Defines a recipient to whom all messages in this room should be sent. This is used for "list serve" applications. INSTRUCTION: digestrecp SYNTAX: digestrecp|friko@mumjiboolean.com DESCRIPTION: Defines a recipient to whom all messages in this room should be sent. This is used for "list serve" applications. The difference between listrecps and digestrecps is that the latter will have messages embedded inside a message sent by the listserver. The message will appear to be sent by the room's e-mail address instead of the sender's e-mail address. INSTRUCTION: ignet_push_share SYNTAX: ignet_push_share|uncnsrd (or) ignet_push_share|uncnsrd|Foo Bar Baz DESCRIPTION: Specifies that the second argument is the name of a neighboring node on an IGnet (Citadel networking) network, to which this room should be pushed (spooled). Conceptually, this node will have a corresponding record pushing data in the other direction. If the third argument is present, it is the name of the corresponding room on the remote node. This allows a room to be shared even when the room name is different on each node. Such a configuration *must* be configured mutually: each node must know the name of the room on the other. INSTRUCTION: subpending SYNTAX: subpending|friko@mumjiboolean.com|listrecp|A234Z|1234567890|http://foo.com/lists "Subscription pending" for the specified address. This means that someone has requested to subscribe an e-mail address (in this case, friko@mumjiboolean.com) to the list. The third parameter is either "list" or "digest" to specify a normal subscription or a digest subscription. The fourth parameter is an authentication token which is generated by the server and e-mailed to the specified address. When the user comes back and supplies this token, the subscription is complete. The fifth parameter is a simple timestamp, so that we may purge old records which were never confirmed. The sixth field is the URL of the web page used to enter the subscription request, minus any parameters. INSTRUCTION: unsubpending SYNTAX: unsubpending|friko@mumjiboolean.com|A234Z|1234567890|http://foo.com/lists Similar to the 'subpending' command, except this one is for unsubscribe requests. The same rules apply with regard to the token and the web page.