* Replaced all "Citadel/UX" references with "Citadel"
[citadel.git] / citadel / techdoc / netconfigs.txt
1  
2            Description of the files in the "netconfigs" directory
3
4  These files contain a set of network configurations for a room.  They are
5 stored in the directory $BBSDIR/netconfigs and are named according to each
6 room's internal ID number.  When a room is deleted, its network configuration
7 file is deleted as well.
8   
9  The configuration file contains one or more lines of text, each line
10 containing a configuration option.  These lines may specify message pointers,
11 room sharing instructions, mailing list recipients, etc.  Fields are separated
12 by the vertical bar character ("|") and there will always be at least one
13 field on each line.
14   
15  
16  INSTRUCTION:  lastsent
17  SYNTAX:       lastsent|0000000
18  DESCRIPTION:
19     Defines the *local* message number of the last message in this room which
20 we have performed outbound network processing on.  Any batch job which sends
21 out messages should do stuff.
22  
23  
24  INSTRUCTION:  listrecp
25  SYNTAX:       listrecp|friko@mumjiboolean.com
26  DESCRIPTION:
27     Defines a recipient to whom all messages in this room should be sent.  This
28 is used for "list serve" applications.
29  
30  
31  INSTRUCTION:  digestrecp
32  SYNTAX:       digestrecp|friko@mumjiboolean.com
33  DESCRIPTION:
34     Defines a recipient to whom all messages in this room should be sent.  This
35 is used for "list serve" applications.  The difference between listrecps and
36 digestrecps is that the latter will have messages embedded inside a message
37 sent by the listserver.  The message will appear to be sent by the room's
38 e-mail address instead of the sender's e-mail address.
39  
40  
41  INSTRUCTION:  ignet_push_share
42  SYNTAX:       ignet_push_share|uncnsrd
43  DESCRIPTION:
44     Specifies that the second argument is the name of a neighboring node on an
45 IGnet (Citadel networking) network, to which this room should be pushed
46 (spooled).  Conceptually, this node will have a corresponding record pushing
47 data in the other direction.
48  
49   
50  INSTRUCTION:  subpending
51  SYNTAX:       subpending|friko@mumjiboolean.com|listrecp|A234Z|1234567890|http://foo.com/lists
52     "Subscription pending" for the specified address.  This means that
53 someone has requested to subscribe an e-mail address (in this case,
54 friko@mumjiboolean.com) to the list.  The third parameter is either "list"
55 or "digest" to specify a normal subscription or a digest subscription.
56 The fourth parameter is an authentication token which is generated by the server
57 and e-mailed to the specified address.  When the user comes back and supplies
58 this token, the subscription is complete.  The fifth parameter is a simple
59 timestamp, so that we may purge old records which were never confirmed.
60  
61  The sixth field is the URL of the web page used to enter the subscription
62 request, minus any parameters.
63  
64  INSTRUCTION:  unsubpending
65  SYNTAX:       unsubpending|friko@mumjiboolean.com|A234Z|1234567890|http://foo.com/lists
66     Similar to the 'subpending' command, except this one is for unsubscribe
67 requests.  The same rules apply with regard to the token and the web page.