| # | Name | Location | Type | Details | Index | Description |
|---|---|---|---|---|---|---|
| .001 | number | 11 | Used to have VA fileman only have one entry in the file. | |||
| .01 | domain name(+) | 0;1 | POINTER | 4.2 | B | This is the name of this installation of MailMan, as it is known to the rest of the network. It must appear in the DOMAIN file. This name applies to all CPUs or Volume sets which access this ^XMB global. |
| 1 | time zone(+) | 0;2 | POINTER | 4.4 | This field defines the timezone in which this domain is located. Note that Standard and Daylight savings times are considered two different timezones, requiring that the timezone be changed with the changing of daylight savings. The timezones are located in the MailMan timezone file. The values of the cross references on this field are appended to message dates as they are sent over the network. | |
| 2 | subordinate domain | 1;0 | MULTIPLE | 4.31 | This field is not currently used. This field describes the domains which are subordinate to this one; that is, those domains which consider this domain a parent. | |
| 3 | parent | 0;3 | POINTER | 4.2 | This field holds the name of the domain which is considered the parent of this domain. The parent domain's subordinate domain list will contain this domain, also. Parent domains are used for routing messages when a subordinate domain does not know a direct path to the selected domain. Domains are connected to their parents as follows: 1. The local domain is named. 2. The parent is named at the local site. 3. A script from the parent to the subordinate domain is created. 4. A christening operation is performed by the parent domain. When the subordinate domain is christened, the domain is connected to the network. (Mail may be addressed to remote domains) | |
| 4 | date christened | 0;4 | DATE-TIME | This holds the date on which this local domain was christened by its parent domain. | ||
| 4.301 | no-purge days buffer | .14;1 | NUMERIC | This field is used by the unreferenced messages purge to avoid purging the last few days worth of messages in the message file. It should be a number sufficiently high so as to avoid purging messages which are in danger of being purged before they can be delivered. This includes incoming network mail messages. The minimum (and default if this field is null) is two days. For example, if this field is 2, then messages up to and including those whose local create date is 2 days ago are subject to possible purge. | ||
| 4.302 | purge audit | .1;0 | MULTIPLE | 4.302 | This multiple contains a history of Message file purges. Generally, a record of the last 20 purges is kept. MailMan has two ways to purge messages. The option XMAUTOPURGE is generally run after XMCLEAN (the waste basket cleaner) and will purge any messages that are not pointed at by any recipients nor the sender. The option XMPURGE-BY-DATE can also be run to purge messages that have an origination date older than one used to initiate the process. It is recommended that before XMPURGE-BY-DATE is used, users be notified of the proposed purge date so they have a chance to preserve important texts. These are the only options that actually kill off entries in the message file. The XMPURGE option does the same thing as XMAUTOPURGE, but is meant to be run in foreground and displays data as it proceeds. Unlike XMPURGE and XMAUTOPURGE, which only remove messages that no one holds in their mail baskets any more, XMPURGE-BY-DATE will remove messages from users' mail baskets and then delete them from the message file (3.9). | |
| 4.303 | automatic integrity check | .12;1 | SET OF CODES | 0:YES 1:NO | XMAUTOPURGE is generally run at least once a week at most sites. It is the process that purges messages that are no longer referenced. Before it is run, XMCLEAN is generally run. XMCLEAN removes messages from WASTE baskets so that they will be unreferenced when XMAUTOPURGE comes along. XMAUTOPURGE kicks off the part of XMUTCHECKFILE that checks the Mail Box file. XMUTCHECKFILE also resets and cleans up the x-refs of this file. If your system has had fairly clean runs of XMUTCHECKFILE or if the entire XMUTCHECKFILE process is run regularly as a separate process, it is not necessary for XMAUTOPURGE to run any part of it again. | |
| 4.304 | weekday days to purge | NOTOPURGE;1 | NUMERIC | When the unreferenced messages purge runs, it purges messages from the message file, ^XMB(3.9, which are no longer referenced, meaning they aren't in anyone's mailbox. If this field is null, OR if the purge is run on Saturday, the purge starts at the beginning of the message file. If this field has a value, AND the purge is run on Sunday through Friday, the purge starts at the message create date calculated by subtracting the number of days from today's date. So, if this number is 45, the unreferenced message purge would start with messages created 45 days ago, and work from there forward. | ||
| 5 | show institution in mailman? | 0;5 | BOOLEAN | y:YES n:NO | This field controls whether mailman will show the user's organization after his name. This is useful when MailMan has many remote users, who may not know each other's location or affiliation. | |
| 5.1 | message action default | 0;15 | SET OF CODES | I:IGNORE D:DELETE | This is the default for the user prompt, "Message Action". The user may over-ride this default by selecting his own under "Edit User Options". | |
| 5.11 | copy limit - recipients | .11;1 | NUMERIC | This field enables site management to control whether a message with more than a certain number of recipients may be copied. A user may not copy a message which has more than this number of recipients. If this field is null, then the limit is 2999. | ||
| 5.12 | copy limit - responses | .11;2 | NUMERIC | This field enables site management to limit the number of responses to a message that may be copied. A user may not copy more than this number of responses to a message. If this field is null, then the limit is 99. | ||
| 5.13 | copy limit - lines | .11;3 | NUMERIC | This field enables site management to limit the number of lines that may be copied from a message and its responses. A user may not copy more than this number of message lines. If this field is null, then the limit is 3999. | ||
| 7 | require introductions? | 0;6 | BOOLEAN | y:YES n:NO | If this is turned on, then users must introduce themselves when they first log in to MailMan. This forces users to describe themselves, and enter their phone numbers and addresses for others to query with the HELP options in MailMan. | |
| 7.01 | fwd test message to postmaster | FORWARD;1 | SET OF CODES | 1:NO 0:YES | Messages are sent automatically to a user's forwarding address if he changes it. If you want these messages to be sent to the Postmaster, also, so that he is aware that the forwarding addresses are proper mark this field with "YES". | |
| 7.2 | big group size | 0;7 | NUMERIC | During message addressing, when a user addresses a message to a mail group with a lot of members, it can seem to take forever to process the group. (Dots of death!) This field, BIG GROUP SIZE, can help. IF you enter a number in this field, AND - If the group contains member groups or - If the group contains distribution lists or - If the number of local members plus the number of remote members exceeds or equals the BIG GROUP SIZE boundary THEN the user is asked whether s/he wants to queue the group for later delivery, and avoid waiting while the group is processed. The user is also warned that if s/he chooses to queue delivery, then recipients may not be 'minus'ed from the group. If the user chooses not to queue delivery, then processing proceeds in the foreground, as usual. If the user chooses to queue delivery, then s/he is asked when the delivery should take place. The group is then queued for processing and delivery at the specified time (by the same background job which 'news' messages). There is no default. (If BIG GROUP SIZE equates to zero, then groups are processed in the foreground as usual.) | ||
| 7.3 | show duz when address message | 0;8 | BOOLEAN | 0:NO 1:YES | When someone addresses a message to a local user, should the DUZ of the local user be displayed? (If this field is null, the default answer is "no".) Disadvantages: - Your site's DUZs may be SSNs. They should not be displayed. - Users may be confused by the display. Advantages: - A DUZ is unique, whereas some users may share the same or very similar name. If a user knows the addressee's DUZ, the DUZ may be used to address a message, instead of the name. | |
| 7.4 | show address on user lookup | 0;10 | BOOLEAN | 0:NO 1:YES | Option XMHELPUSER displays user information. Among the items displayed are the address fields (.111 through .116) from the NEW PERSON file. Some sites have home address information in these fields, which should not be displayed. If the address fields should be displayed, answer YES; otherwise, answer NO. If this field is null, the default answer is NO. | |
| 7.5 | cpu (uci,vol) for filer to run | 0;12 | FREE TEXT | Enter the UCI,VOL of where you want the background filer routines to run. It is recommended that the XMB global also reside in this location. If you are unsure what to enter, leave this field blank. | ||
| 7.6 | ftp address for blob | FTP-GET;1 | FREE TEXT | If your images are on a network that is available via FTP from your main node and you have no other way of accessing those message to get them onto you main node so that you can FTP them to other sites, put the IP address of the machine that you will GET your images from into this field. | ||
| 7.7 | ftp receive directory | DISK/VOL;1 | FREE TEXT | This field is used to store the path for BLOBs to be received in. It is communicated to the transmitter of messages containing BLOBS so that they can be FTP'd to the correct directory once the disk has been designated with field 7.711. If the receiving system is a DOS system the disk portion of the path is in the field 'FTP RECEIVE DISK'. | ||
| 7.71 | ftp receive network location | FTPNETLOC;1 | FREE TEXT | This field should be the name of an entry in your 2005.2 file (Network Location). It maps where incoming BLOBs will be placed and is the logical equivalent of field 7.7. | ||
| 7.711 | ftp receive disk | FTPRCVDISK;1 | FREE TEXT | This field contains the name of the physical disk that the FTP Receive Network Location is on if the receiving system is a DOS system. | ||
| 7.72 | ftp address for blob receive | FTP-RCV;1 | FREE TEXT | This is the IP address that you will advertise to other sites that wish to send you images that attach to multimedia messages. | ||
| 7.73 | ftp username | FTPUSER;1 | FREE TEXT | This is the VMS username that the sender will be told to use when he FTP's BLOBs to this domain. | ||
| 7.731 | ftp password | FTPPWD;1 | FREE TEXT | This is the password if any that a BLOB sender needs to have when he FTPs into the system. | ||
| 7.7999 | ftp notes | FTP-NOTES;0 | WORD-PROCESSING | This field holds site specific notes for this site on FTP operations. It is not used by MailMan. | ||
| 8.11 | lpc checksum | LPC;E1,245 | FREE TEXT | The code in this field will be obsolete after installation of KERNEL 6, if the "LPC" node in ^%ZOSF [^%ZOSF("LPC")] is defined. This field is inserted by the MailMan POST-init if the ^%ZOSF("OS") is defined, contains "DSM" and does not contain "VAX". This is because of a situation that exists where DSM for PDP-aa series used to use on $ZCALL anbd in the updated version uses a slightly different one. Both do not exist in one system. The way it is inserted is by setting an error trap and then trying one. If it doesn't work, it must be the onther. | ||
| 8.12 | tcp channel - maximum to use | 0;17 | NUMERIC | This field contains a value that is checked before starting a process to transmit mail via a TCP/IP channel. If there are already as many processes running as is in this field, no process is started. | ||
| 8.13 | stats normalization | 7;1 | FREE TEXT | This option allows the user to customize the normalized report. | ||
| 8.14 | large message report lines | XMUT2-LINES;1 | NUMERIC | This field is used by the large message report. Any message with more than this many lines is included in the report. If this field is null, the default is 100. | ||
| 8.15 | tcp/ip poller run flag | 0;18 | SET OF CODES | 1:STOP RUNNING 0:OKAY TO RUN | This field is checked every time the background tcp poller, XMRTCP, starts to process poller request. If it is set to 1, XMRTCP stops running. If it is null or zero, XMRTCP processes the next entry. If XMRTCP is not running it will not be restarted if the field is set to 1. If it is null or 0, and XMRTCP is not running, a background task will be created to restart it. | |
| 8.2 | record netmail transcript? | 0;14 | BOOLEAN | 1:YES 0:NO | This field allows the site manager to turn on and off (toggle) whether or not MailMan records all script transcripts in background. The send portion of scripts played (using the 'Play Script' option) will not be recorded. | |
| 8.21 | xmits till error message | NETWORK;1 | NUMERIC | How many times will a transmission be attempted before a message is sent to the Postmaster indicating that there have been multiple, unsuccessful transmissions to a domain. | ||
| 8.22 | dns aware | NETWORK;2 | BOOLEAN | 0:NO 1:YES | In order for MailMan to be DNS aware, the site must have installed the requisite Kernel patches for DNS. - DNS IP (field 51 in file 8989.3) must contain an IP address for a DNS server. - Routine ^XLFNSLK must exist. If you answer 'no', MailMan will use the IP addresses in the domain scripts. If you answer 'yes', MailMan will use the IP addresses in the domain scripts, but if they fail, or don't exist, MailMan will use DNS to ascertain other IP addresses to try. MailMan will replace failed script IP address with the successful DNS IP address. | |
| 8.23 | tcp/ip communications protocol | NETWORK;3 | POINTER | 3.4 | For TCP/IP connections, the scripts (the TEXT field, 2, in the TRANSMISSION SCRIPT multiple, 4, of the DOMAIN file, 4.2) can be built on-the-fly, if they don't exist, and if both this field and field 8.24 are filled in. We identify the TCP/IP transmission scripts in file 4.2 by the TYPE field, 1.2, within the TRANSMISSION SCRIPT multiple. Those whose TYPE is 'SMTP', 'TCPCHAN', or null are considered TCP/IP transmission scripts. We can build the scripts, because they are standard. Here's an example of one for FORUM: O H=DOMAIN.EXT,P=TCP/IP-MAILMAN C TCPCHAN-SOCKET25 In this script, the TCP/IP-MAILMAN refers to the communications protocol to use. This field should point to the communications protocol in file 3.4 that should be used for TCP/IP connections. | |
| 8.24 | tcp/ip transmission script | NETWORK;4 | POINTER | 4.6 | For TCP/IP connections, the scripts (the TEXT field, 2, in the TRANSMISSION SCRIPT multiple, 4, of the DOMAIN file, 4.2) can be built on-the-fly, if they don't exist, and if both this field and field 8.23 are filled in. We identify the TCP/IP transmission scripts in file 4.2 by the TYPE field, 1.2, within the TRANSMISSION SCRIPT multiple. Those whose TYPE is 'SMTP', 'TCPCHAN', or null are considered TCP/IP transmission scripts. We can build the scripts, because they are standard. Here's an example of one for FORUM: O H=DOMAIN.EXT,P=TCP/IP-MAILMAN C TCPCHAN-SOCKET25 In this script, the TCPCHAN-SOCKET25 refers to the transmission script to use. This field should point to the transmission script in file 4.6 that should be used for TCP/IP connections. | |
| 8.25 | tcp/ip device | NETWORK;5 | FREE TEXT | For TCP/IP connections, the physical link/device to be used is usually standard - some sort of NULL device. This field is a free-text pointer to that device in the DEVICE (#3.5) file. The device pointed to by this field will be used for a TCP/IP connection if, in the DOMAIN (#4.2) file, the device field is null in both of the following fields: - PHYSICAL LINK / DEVICE (#1.3) field of the TRANSMISSION SCRIPT (#4) multiple - PHYSICAL LINK DEVICE (#17) field For more information, see the PHYSICAL LINK DEVICE (#17) field in the DOMAIN (#4.2) file. | ||
| 8.3 | network - max lines send | NETWORK-LIMIT;1 | NUMERIC | This field enables site management to limit the number of lines which a message may have when it is addressed to a remote recipient. A user may not send a message across the network with more than this number of lines. If this field is null, there is no limit. | ||
| 8.31 | network - max lines receive | NETWORK-LIMIT;2 | NUMERIC | This field enables site management to limit the number of lines which a message may have when it is received from a remote site. Any message received from a remote site which has more lines than this number is automatically rejected. If this field is null, there is no limit. KIDS and PackMan messages are not affected by this limit. | ||
| 8.32 | network - block size receive | NETWORK-LIMIT;3 | SET OF CODES | A:255 B:512 | *** This field is reserved for future use. Not currently used. ***
This is the maximum number of characters to read at a time when
receiving incoming transmissions. Default is 255.
Limiting factors are:
- Maximum string length on the system.
- Maximum global length on the system. In particular, maximum
(desirable) length of a line of message text in the MESSAGE file:
S ^XMB(3.9,xmz,2,x,0)= | |
| 8.4 | directory request flag | 8.4;1 | SET OF CODES | 0:Requests will NOT be granted. 1:Requests will be granted. | This field controls whether or not the XMMGR-DIRECTORY-RECV option will grant request from remote site to send domain user directory information. If the value is null or zero, request is rejected. If the value is one, a request is granted and domain user directory will be made available to the remote site. | |
| 10 | in-basket-purge days | 0;9 | NUMERIC | This field is used by the IN BASKET PURGE to identify inactive messages and mark them for purging. A message is considered inactive if it has not been accessed in the past number of days specified here. The default is 30 days. The IN BASKET PURGE sends a message to each user listing all messages which it has marked for purging and stating that they will be purged in an additional 30 days if they remain in the 'IN' basket and are not accessed again. | ||
| 10.01 | in-basket-purge type | .15;1 | SET OF CODES | 0:IN BASKET ONLY 1:ALL BASKETS | This field controls the extent of the IN-BASKET-PURGE. If is is not filled in the effect on the IN-BASKET-PURGE is the same as it would be if the value of the field is zero. The field can have the following values: 0 or null = The IN-BASKET-PURGE will affect user IN baskets only. 1 = The IN-BASKET-PURGE will affect all user baskets. (This is not the normal way for this process to be run. It is recommended that you discuss this with site management and get user input before doing this.) In either case the users will be sent the now familiar message listing the messages that will be deleted from their baskets in 30 days. In either case the field 'IN-BASKET-PURGE DAYS' will control how long a message can remain inactive in a basket before it is considered okay to put on the list of messages to be considered for deletion. | |
| 10.03 | date purge cutoff days | .18;1 | NUMERIC | This field is used by the option XMPURGE-BY-DATE. When this option is run, the date purge will be set to purge all messages originating this many days ago and before. If this field is null, the default will be 730 days (2 years). | ||
| 10.04 | date purge grace period | .18;2 | NUMERIC | This is the number of days' warning the users get before the date purge, XMPURGE-BY-DATE, is run. This field is used by the option XMPURGE-BY-DATE only if that option is scheduled, not if it is run interactively. At the scheduled date/time, the bulletin, XM DATE PURGE WARNING, is broadcast to all users to warn them of the coming date purge, and the actual date purge is then queued to run this many days later. If this field is null, the date purge will run at the scheduled date/time, and no bulletin will be sent. | ||
| 10.1 | background filer hang time | 0;13 | NUMERIC | This field is used by the background filer when it is started up to determine the amount of time it will hang between deliveries of messages. Since mail is not delivered, even to the sender, unless the backgournd filer delivers it, it should not be too long a period so that your users are inconvenienced. If this field is not filled in the background filer will hang for 5 seconds between deliveries. 5 to 15 seconds is the recommended range. | ||
| 10.2 | background filer run flag | 0;16 | SET OF CODES | 1:STOP RUNNING 0:OKAY TO RUN | The background filer checks this field every time it is about to deliver a message or response. If it is set to 1, it stops running, and will not restart until it is set to null or zero. If it is null or zero, and is already running, it continues. If it is null or zero, and is not running, a background task will be created to restart it. | |
| 10.3 | background filer run priority | .13;1 | NUMERIC | This field is used by the background filer to set its priority at runtime. | ||
| 16.1 | p-message line limit | .16;1 | NUMERIC | This field enables site management to limit the number of lines which may be printed to P-MESSAGE. If this field is null, there is no limit. | ||
| 17.1 | max digits for message number | .17;1 | NUMERIC | This field is used to control the size of the message number in ^XMB(3.9, the MESSAGE file. If this field is null, its default will be 8 digits. If the message number becomes greater than this many digits, the message numbers will recycle back to the next vacant message number after 999999. In this way, message numbers will cease being too ungainly in size. So message numbers will be re-used. If MailMan is not able to find a vacant message number less than this number of digits, then MailMan will take the next available message number, no matter how many digits it has, AND MailMan will change this field to reflect the new maximum. It is very important that the unreferenced messages purge and/or the date purge be run on a regular basis to free up message numbers for re-use. | ||
| 21 | forward priority mail to group | 2;1 | BOOLEAN | 0:NO 1:YES | Enter YES if you wish to allow users to forward priority messages to mail groups. Enter NO if you don't. (This is the default, if this field is null.) Then only the message originator or anyone with the XM GROUP PRIORITY key may forward priority messages to mail groups. | |
| 22 | drop out of restricted group | 2;2 | BOOLEAN | 0:NO 1:YES | Enter YES if you wish to allow users to drop out of non-self-enrolling mail groups. The user will be warned that this is a non-self-enrolling group, and that they won't be allowed to rejoin later, and then they will be asked to re-confirm the decision to drop out. Enter NO if you don't. (This is the default if this field is null.) Then users will have to contact IRM or the mail group coordinator to ask to be dropped. | |
| 23 | title source | 0;11 | SET OF CODES | S:SIGNATURE BLOCK TITLE T:TITLE | Where in the NEW PERSON file should the user's title come from? Enter 'S' if the user's title should come from field 20.3, SIGNATURE BLOCK TITLE. If that field is empty, then we'll try field 8, TITLE. Enter 'T' if the user's title should come from field 8, TITLE. If that field is empty, we won't show any title. The default is 'T', if this field is not filled in. | |
| 31 | auto-forward limited? | 3;1 | BOOLEAN | 0:NO 1:YES | For security or privacy reasons, you may wish to limit the sites to which users may have their mail auto-forwarded. If so, set this field to YES, and enter the approved sites in the AUTO-FORWARD APPROVED SITE multiple. For VA sites, this field must be set to YES. The only approved sites are those ending in ".DOMAIN.EXT". If this field is set to YES, MailMan will limit auto-forwarding to only those sites whose names are in (or end in the ones in) the AUTO-FORWARD APPROVED SITE multiple. | |
| 31.1 | auto-forward approved site | 3.1;0 | MULTIPLE | 4.33 | ||
| 31.2 | auto-forward waiver site | 3.2;0 | MULTIPLE | 4.34 | ||
| 40 | prevent message relay? | 4;1 | BOOLEAN | 1:YES 0:NO | Answer YES if you want to prevent outside sites from sending mail through your site to other outside sites. Spammers and Virus propagators use this technique to disguise the source of their mail, and to make it appear to come from a trusted source, namely your site. Answer NO if you want your site to act as a relay site for anyone. It is strongly recommended that you answer YES to prevent your site from unwittingly relaying destructive mail. If you answer YES, you should define your "inside" sites in the MY DOMAIN (field #41) multiple, so that MailMan can distinguish them from outside sites. Note: This does NOT prevent users from receiving mail from outside sites. It also does NOT prevent users from forwarding mail to outside sites. Such actions are perfectly acceptable. | |
| 41 | my domains | 4.1;0 | MULTIPLE | 4.341 | ||
| 50 | limited broadcast | 5;0 | MULTIPLE | 4.32 | ||
| 51 | limited broadcast default | 0;20 | NUMERIC | When sending a limited broadcast message, this is the default which will appear when the user is presented with limited broadcast choices. If you don't want a default to appear, delete this entry. | ||
| 142 | no-purge days buffer (local) | .14;2 | NUMERIC | This field is used during the un-referenced-messages purge to avoid purging the last few messages in the message file, according to their local create date. We subtract the NO-PURGE DAYS BUFFER (LOCAL) from today's date, giving a 'no-purge date'. Local messages which were created on or after that date and which were sent to remote sites are not subject to purge. Other messages are not affected by this buffer. If this field is not filled in, it defaults to 7 days. This is the recommended value. It should not be less than the NO-PURGE DAYS BUFFER (field 4.301) or it will have no effect. One situation in which this buffer may be useful is in the case of a message sent only to a remote site. Such a message is unreferenced and would otherwise be subject to purge. If a reply came from the remote site after the original message had been purged, the sender would have access only to the reply and not to the original message. The NO-PURGE DAYS BUFFER (LOCAL) could be set to a reasonable number of days to allow for a reply. | ||
| 143 | fax enabled | 0;19 | BOOLEAN | 0:no 1:yes | Your site is fax enabled if you have the suite of fax software and files (^AKF) and fax capability and you choose to allow faxes to be sent via MailMan. To send faxes via MailMan, Mail groups (file 3.8) must first be populated in the fax recipient and fax group multiples. Then, when a user sends a message to a mail group, the message is also faxed to any fax recipients in that mail group. Responses to the message are not faxed. | |
| 217 | default institution(+) | XUS;17 | POINTER | 4 | This field is the default institution that is shown for any user who hasn't chosen one under "edit user options" | |
| 241 | background message deliverers | 6;1 | FREE TEXT | This field is used by the background filer to determine how many message delivery queues (and tasks) there should be and how to separate them. | ||
| 242 | background response deliverers | 6;2 | FREE TEXT | This field is used by the background filer to determine how many response delivery queues (and tasks) there will be and how to separate them. |
Not Referenced