home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.wwiv.com
/
ftp.wwiv.com.zip
/
ftp.wwiv.com
/
pub
/
BBS
/
WM41_WC3.ZIP
/
WM4FILES.DAT
/
WM41.DOC
< prev
next >
Wrap
Text File
|
1994-11-30
|
535KB
|
12,676 lines
WILDMAIL! v4.11
Echomail Processor for WILDCAT! v4+
(c) Copyright 1991, 1994 by Integrated Solutions
2995 Van Buren Blvd A-13-189, Riverside, CA 92503
Voice: (909) 695-6677 BBS: (909) 695-6676
All Rights Reserved
Revised: 11/30/94
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 1
WHAT IS WILDMAIL! . . . . . . . . . . . . . . . . . . . . . . 1
Multiline Operation . . . . . . . . . . . . . . . . . . 2
Single Line Systems . . . . . . . . . . . . . . . . . . 2
FEATURES LIST . . . . . . . . . . . . . . . . . . . . . . . . 3
WMCONFIG! Features . . . . . . . . . . . . . . . . . . . 3
WILDMAIL! Features . . . . . . . . . . . . . . . . . . . 4
GENERAL . . . . . . . . . . . . . . . . . . . . . . 4
NODE SPECIFIC . . . . . . . . . . . . . . . . . . . 4
CONFERENCE SPECIFIC . . . . . . . . . . . . . . . . 4
30 DAY EVALUATION KEY FILE . . . . . . . . . . . . . . . . . 5
WILDUUCP! AND MAIL GATING . . . . . . . . . . . . . . . . . . 5
REGISTRATION/ORDERING INFORMATION . . . . . . . . . . . . . . 6
REGISTRATION FEE . . . . . . . . . . . . . . . . . . . . 6
PAYMENT METHOD . . . . . . . . . . . . . . . . . . . . . 6
UPGRADE FROM PREVIOUS v1.xx/v2.xx . . . . . . . . . . . 6
UPGRADE FROM PREVIOUS RELEASES . . . . . . . . . . . . . . . 7
UPGRADE PROCESS . . . . . . . . . . . . . . . . . . . . 7
DUPLICATE CHECKING . . . . . . . . . . . . . . . . . . . 7
FIRST TIME INSTALLATION . . . . . . . . . . . . . . . . . . . 8
BATCH FILE ENTRIES . . . . . . . . . . . . . . . . . . 10
COMMAND LINE USAGE . . . . . . . . . . . . . . . . . . . . 11
? . . . . . . . . . . . . . . . . . . . . . . . . . . 11
TOSS . . . . . . . . . . . . . . . . . . . . . . . . . 11
SCAN . . . . . . . . . . . . . . . . . . . . . . . . . 11
PRETOSS . . . . . . . . . . . . . . . . . . . . . . . 12
MAILIN . . . . . . . . . . . . . . . . . . . . . . . . 12
MAILOUT . . . . . . . . . . . . . . . . . . . . . . . 12
NETMAIL . . . . . . . . . . . . . . . . . . . . . . . 12
PACK . . . . . . . . . . . . . . . . . . . . . . . . . 13
PURGE . . . . . . . . . . . . . . . . . . . . . . . . 13
AREAMGR . . . . . . . . . . . . . . . . . . . . . . . 13
NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 14
-O . . . . . . . . . . . . . . . . . . . . . . . . . . 14
-T<conf #>,<last extracted msg #> . . . . . . . . . . 14
-A . . . . . . . . . . . . . . . . . . . . . . . . . . 15
USER INTERFACE . . . . . . . . . . . . . . . . . . . . . . 16
Context Sensitive Help . . . . . . . . . . . . . . . . 16
CRT Display Modes . . . . . . . . . . . . . . . . . . 16
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page i
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
Status Bar . . . . . . . . . . . . . . . . . . . . . . 17
DOS Shell . . . . . . . . . . . . . . . . . . . . . . 17
Read-Only Mode . . . . . . . . . . . . . . . . . . . . 17
Database Formats . . . . . . . . . . . . . . . . . . . 18
WMCONFIG! SETUP AND CONFIGURATION . . . . . . . . . . . . . 19
DATA FILES USED . . . . . . . . . . . . . . . . . . . 19
WMCONFIG.DAT . . . . . . . . . . . . . . . . . . 19
WMAREAS.DAT/IX . . . . . . . . . . . . . . . . . 19
WMNODES.DAT/IX . . . . . . . . . . . . . . . . . 19
WMORIGIN.DAT . . . . . . . . . . . . . . . . . . 19
WMCONFIG.HLP . . . . . . . . . . . . . . . . . . 19
MENU SELECTIONS . . . . . . . . . . . . . . . . . . . 19
SYSTEM INFORMATION . . . . . . . . . . . . . . . . . . . . 21
System operator name . . . . . . . . . . . . . . . . . 21
Bulletin board name . . . . . . . . . . . . . . . . . 21
Primary address . . . . . . . . . . . . . . . . . . . 21
Also Known As (AKA) addresses . . . . . . . . . . . . 22
Inbound path1 . . . . . . . . . . . . . . . . . . . . 22
Inbound path2 . . . . . . . . . . . . . . . . . . . . 23
Outbound path . . . . . . . . . . . . . . . . . . . . 23
Netmail path . . . . . . . . . . . . . . . . . . . . . 24
Bad msgs path . . . . . . . . . . . . . . . . . . . . 24
Mailer type . . . . . . . . . . . . . . . . . . . . . 25
FrontDoor . . . . . . . . . . . . . . . . . . . . 25
Intermail . . . . . . . . . . . . . . . . . . . . 25
D'Bridge . . . . . . . . . . . . . . . . . . . . 26
LYNXMAIL! . . . . . . . . . . . . . . . . . . . . 26
Binkley . . . . . . . . . . . . . . . . . . . . . 26
Mail router . . . . . . . . . . . . . . . . 26
Parameters . . . . . . . . . . . . . . . . . 26
HLO/CLO mode . . . . . . . . . . . . . . . . . . 27
None . . . . . . . . . . . . . . . . . . . . 27
(^) Delete . . . . . . . . . . . . . . . . . 27
(#) Truncate . . . . . . . . . . . . . . . . 28
Network mode . . . . . . . . . . . . . . . . . . . . . 28
Single Line . . . . . . . . . . . . . . . . . . . 28
DOS 3.3 Share . . . . . . . . . . . . . . . . . . 28
Novell . . . . . . . . . . . . . . . . . . . . . 28
Log file options . . . . . . . . . . . . . . . . . . . 29
DIAGNOSTIC LOG OPTIONS . . . . . . . . . . . . . 29
Activity log path . . . . . . . . . . . . . . . . . . 30
VIEW FUNCTION . . . . . . . . . . . . . . . . . . 30
Min free disk space (Gen) . . . . . . . . . . . . . . 30
Min free disk space (Msg) . . . . . . . . . . . . . . 31
MISCELLANEOUS INFORMATION . . . . . . . . . . . . . . . . . 32
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page ii
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
Default archive format . . . . . . . . . . . . . . . . 32
Create extended area info . . . . . . . . . . . . . . 32
Verify control info in msgs . . . . . . . . . . . . . 32
Del archives before tossing . . . . . . . . . . . . . 33
Forward PKTs not 'TO' you . . . . . . . . . . . . . . 34
Delete null/empty messages . . . . . . . . . . . . . . 35
Force INTL kludge line . . . . . . . . . . . . . . . . 35
Flag Netmail as Kill/Sent . . . . . . . . . . . . . . 36
Use EMS for database needs . . . . . . . . . . . . . . 36
Use XMS/EMS for swap file . . . . . . . . . . . . . . 37
Save Ctl-A FLAG line . . . . . . . . . . . . . . . . . 38
Prohibit message importation . . . . . . . . . . . . . 38
List of names to exclude . . . . . . . . . . . . . . . 38
[INS] - Create an Exclude Name . . . . . . . . . 39
[DEL] - Delete an Exclude Name . . . . . . . . . 39
[ENTER] - Edit an Exclude Name . . . . . . . . . 39
Size of duplicates database . . . . . . . . . . . . . 39
Purge entries after nn days . . . . . . . . . . . . . 40
Save dupes found as MSG file . . . . . . . . . . . . . 40
Temporary swap file path . . . . . . . . . . . . . . . 40
Save duplicate messages path . . . . . . . . . . . . . 41
Program to run before packing . . . . . . . . . . . . 41
Program to run after unpacking . . . . . . . . . . . . 41
MAIL ARCHIVE DEFINITIONS . . . . . . . . . . . . . . . . . 43
InUse Flag . . . . . . . . . . . . . . . . . . . . . . 43
Type . . . . . . . . . . . . . . . . . . . . . . . . . 43
Special Format - NONE . . . . . . . . . . . . . . 44
Method . . . . . . . . . . . . . . . . . . . . . . . . 44
Program . . . . . . . . . . . . . . . . . . . . . . . 44
Parameters . . . . . . . . . . . . . . . . . . . . . . 45
Archival Process . . . . . . . . . . . . . . . . . . . 45
ORIGIN LINE MAINTENANCE . . . . . . . . . . . . . . . . . . 46
Active Keystrokes . . . . . . . . . . . . . . . . . . 46
Up/Dn Arrow Keys . . . . . . . . . . . . . . . . 46
[ENTER] - Edit an existing Origin line . . . . . 47
[DEL] - Delete an Origin Line . . . . . . . . . . 47
What is an Origin/Tear line . . . . . . . . . . . . . 48
What are Tag lines . . . . . . . . . . . . . . . . . . 48
2D/3D ADDRESS MANAGEMENT . . . . . . . . . . . . . . . . . 49
Assign Zone to Net/Node Address . . . . . . . . . . . 49
[INS] - Create a definition . . . . . . . . . . . 49
[DEL] - Delete a definition . . . . . . . . . . . 49
[ENTER] - Edit a definition . . . . . . . . . . . 50
BBS SPECIFIC OPTIONS . . . . . . . . . . . . . . . . . . . 51
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page iii
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
Netmail conference number . . . . . . . . . . . . . . 51
Pre-process echomail . . . . . . . . . . . . . . . . . 52
Update quick statistics . . . . . . . . . . . . . . . 53
Notify user of new Netmail . . . . . . . . . . . . . . 54
Force netmail to private . . . . . . . . . . . . . . . 54
Maintain message levels . . . . . . . . . . . . . . . 54
Send status msgs to SysOp . . . . . . . . . . . . . . 55
Netmail message flags . . . . . . . . . . . . . . . . 56
Honor crash flag on msg . . . . . . . . . . . . . . . 56
Valid crash mail users . . . . . . . . . . . . . . . . 56
Extract Netmail sent TO: an AKA . . . . . . . . . . . 57
Delete netmail after scan . . . . . . . . . . . . . . 58
Allow netmail file attaches . . . . . . . . . . . . . 58
Import netmail as .MSG . . . . . . . . . . . . . . . . 58
Database lock count . . . . . . . . . . . . . . . . . 59
WILDCAT! home path . . . . . . . . . . . . . . . . . . 60
Pre-processing path . . . . . . . . . . . . . . . . . 60
File attach path . . . . . . . . . . . . . . . . . . . 61
NODE MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . 62
[INS] - Add a new Node Address . . . . . . . . . . . . 62
[DEL] - Delete a Node Address . . . . . . . . . . . . 62
[ENTER] - Edit a Node Address . . . . . . . . . . . . 62
[ALT-F] - Finding a Node Address . . . . . . . . . . . 62
NODE SPECIFIC SETTINGS . . . . . . . . . . . . . . . . . . 63
Node address . . . . . . . . . . . . . . . . . . . . . 63
Net membership . . . . . . . . . . . . . . . . . . . . 63
Active node . . . . . . . . . . . . . . . . . . . . . 63
Selected confs . . . . . . . . . . . . . . . . . . . . 64
CRITICAL SETTING . . . . . . . . . . . . . . . . 64
UNIVERSAL SELECTION METHOD . . . . . . . . . . . 65
SysOp name . . . . . . . . . . . . . . . . . . . . . . 65
BBS Name . . . . . . . . . . . . . . . . . . . . . . . 65
Voice # . . . . . . . . . . . . . . . . . . . . . . . 66
BBS # . . . . . . . . . . . . . . . . . . . . . . . . 66
Maximum messages PKT . . . . . . . . . . . . . . . . . 66
Maximum uncompress bytes . . . . . . . . . . . . . . . 66
PKT file format . . . . . . . . . . . . . . . . . . . 67
Type 2 . . . . . . . . . . . . . . . . . . . . . 67
Type 2.2 . . . . . . . . . . . . . . . . . . . . 68
Type 2 Plus . . . . . . . . . . . . . . . . . . . 68
Inbound PKT password . . . . . . . . . . . . . . . . . 68
PASSWORD ERRORS . . . . . . . . . . . . . . . . . 69
SESSION PASSWORDS . . . . . . . . . . . . . . . . 69
Outbound PKT password . . . . . . . . . . . . . . . . 69
Flags on netmail msg . . . . . . . . . . . . . . . . . 70
Uncompressed PKT path . . . . . . . . . . . . . . . . 70
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page iv
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
Use standard naming . . . . . . . . . . . . . . . . . 71
Compression format . . . . . . . . . . . . . . . . . . 72
Kill orphaned messages . . . . . . . . . . . . . . . . 72
Use tiny SEEN-BY: lines . . . . . . . . . . . . . . . 73
Node activation date . . . . . . . . . . . . . . . . . 74
Set inactive upon expiration . . . . . . . . . . . . . 74
Expiration date . . . . . . . . . . . . . . . . . . . 75
Send expiration message . . . . . . . . . . . . . . . 75
Message frequency . . . . . . . . . . . . . . . . . . 75
Message sent . . . . . . . . . . . . . . . . . . 76
Date sent . . . . . . . . . . . . . . . . . . . . 76
Send status message to SysOp . . . . . . . . . . . . . 76
Last payment recvd . . . . . . . . . . . . . . . . . . 76
Payment amount . . . . . . . . . . . . . . . . . . . . 77
Allow AreaRequest functions . . . . . . . . . . . . . 77
Allow conference querying (-Q) . . . . . . . . . . . . 77
Exclude during notifications . . . . . . . . . . . . . 77
Auto-add for new conferences . . . . . . . . . . . . . 78
Send help on bad request . . . . . . . . . . . . . . . 78
Send text message on notify . . . . . . . . . . . . . 79
Response message origin address . . . . . . . . . . . 79
Flags on response message . . . . . . . . . . . . . . 79
AreaRequest password . . . . . . . . . . . . . . . . . 80
AreaRequest security . . . . . . . . . . . . . . . . . 81
AreaRequest flags . . . . . . . . . . . . . . . . . . 82
Extended % commands . . . . . . . . . . . . . . . . . 82
[SPACEBAR] - Select/Deselect . . . . . . . . . . 83
[F10] - Save . . . . . . . . . . . . . . . . . . 83
Mailing Addr . . . . . . . . . . . . . . . . . . . . . 84
Comments . . . . . . . . . . . . . . . . . . . . . . . 84
City . . . . . . . . . . . . . . . . . . . . . . . . . 85
State . . . . . . . . . . . . . . . . . . . . . . . . 85
Zip . . . . . . . . . . . . . . . . . . . . . . . . . 85
CONFERENCE AREA MANAGEMENT . . . . . . . . . . . . . . . . 86
[INS] - Add a new Conference . . . . . . . . . . . . . 86
[DEL] - Delete a Conference . . . . . . . . . . . . . 86
[ENTER] - Edit a Conference . . . . . . . . . . . . . 86
[F9] - Filter Networks . . . . . . . . . . . . . . . . 86
[F5] - Sort Conferences . . . . . . . . . . . . . . . 86
[ALT-F] - Find Conference Area/Conference Number . . . 87
CONFERENCE SPECIFIC SETTINGS . . . . . . . . . . . . . . . 88
FTSC Area name . . . . . . . . . . . . . . . . . . . . 88
WHAT IS AN AREA NAME? . . . . . . . . . . . . . . 88
Active conference . . . . . . . . . . . . . . . . . . 89
Selected nodes . . . . . . . . . . . . . . . . . . . . 89
CRITICAL SETTING . . . . . . . . . . . . . . . . 89
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page v
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
UNIVERSAL SELECTION METHOD . . . . . . . . . . . 90
Passthrough area . . . . . . . . . . . . . . . . . . . 90
BBS conference . . . . . . . . . . . . . . . . . . . . 91
Ctrl line processing . . . . . . . . . . . . . . . . . 91
Restrict importation . . . . . . . . . . . . . . . . . 92
COMMON CONFIGURATION PROBLEM . . . . . . . . . . 92
Use domain in MSGID . . . . . . . . . . . . . . . . . 92
Origin address . . . . . . . . . . . . . . . . . . . . 93
Origin line . . . . . . . . . . . . . . . . . . . . . 94
Extract private messages . . . . . . . . . . . . . . . 94
Extract file attaches . . . . . . . . . . . . . . . . 94
Notify users of new mail . . . . . . . . . . . . . . . 95
Add nodes to SEEN-BY:'s . . . . . . . . . . . . . . . 95
Grunged message processing . . . . . . . . . . . . . . 96
BOUNCING GRUNGED MESSAGES . . . . . . . . . . . . 96
FILE ATTACH VERSES MESSAGE COPY . . . . . . . . . 97
ADDRESS DETERMINATION . . . . . . . . . . . . . . 97
SELECTION METHOD . . . . . . . . . . . . . . . . 98
Delete Message . . . . . . . . . . . . . . . 98
Save Message . . . . . . . . . . . . . . . . 98
Bounce-Save Message . . . . . . . . . . . . 98
Bounce-Kill Message . . . . . . . . . . . . 98
Determine To: address from msg . . . . . . . . . . . . 99
Alternate To: address . . . . . . . . . . . . . . . . 99
Origin address on message . . . . . . . . . . . . . . 99
Flags on message . . . . . . . . . . . . . . . . . . . 99
Originating node . . . . . . . . . . . . . . . . . . . 100
Source differs from Network . . . . . . . . . . . . . 100
Deactivation address . . . . . . . . . . . . . . . . . 101
AreaRequest security . . . . . . . . . . . . . . . . . 101
AreaRequest flags . . . . . . . . . . . . . . . . . . 102
AREAREQUEST MANAGER . . . . . . . . . . . . . . . . . . . . 104
SECURITY LEVELS . . . . . . . . . . . . . . . . . . . 104
AREAREQUEST FLAGS . . . . . . . . . . . . . . . . . . 105
AREAREQUEST SPECIFIC SETTINGS . . . . . . . . . . . . . . . 106
AreaRequest help file . . . . . . . . . . . . . . . . 106
[ALT-V] - View File . . . . . . . . . . . . . . . 107
Notify msg text file . . . . . . . . . . . . . . . . . 107
[ALT-V] - View File . . . . . . . . . . . . . . . 107
Activity log file . . . . . . . . . . . . . . . . . . 107
[ALT-V] - View File . . . . . . . . . . . . . . . 108
Flag definitions . . . . . . . . . . . . . . . . . . . 108
[INS] - Add a Flag . . . . . . . . . . . . . . . 108
[DEL] - Delete a Flag . . . . . . . . . . . . . . 108
[ENTER] - Edit a Flag . . . . . . . . . . . . . . 108
Delete processed msgs . . . . . . . . . . . . . . . . 109
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page vi
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
USING AREAREQUEST . . . . . . . . . . . . . . . . . . . . . 110
NETWORK MANAGEMENT . . . . . . . . . . . . . . . . . . . . 120
[INS] - Defining a Network . . . . . . . . . . . . . . 120
[DEL] - Delete a Network . . . . . . . . . . . . . . . 120
[ENTER] - Edit a Network . . . . . . . . . . . . . . . 120
WHAT IS A NETWORK? . . . . . . . . . . . . . . . . . . . . 120
NETWORK DEFINITIONS . . . . . . . . . . . . . . . . . 121
NODE MEMBERSHIPS . . . . . . . . . . . . . . . . . . . 122
NETWORK SPECIFIC SETTINGS . . . . . . . . . . . . . . . . . 123
Network name . . . . . . . . . . . . . . . . . . . . . 123
Description . . . . . . . . . . . . . . . . . . . . . 123
Domain name . . . . . . . . . . . . . . . . . . . . . 123
Originating node . . . . . . . . . . . . . . . . . . . 124
Valid AreaRequest 'To:' names . . . . . . . . . . . . 125
[INS] - Add an Alias . . . . . . . . . . . . . . 125
[DEL] - Delete an Alias . . . . . . . . . . . . . 125
[ENTER] - Edit an Alias . . . . . . . . . . . . . 126
Required AreaRequest flags . . . . . . . . . . . . . . 126
Required security level . . . . . . . . . . . . . . . 127
Purge abandoned areas . . . . . . . . . . . . . . . . 127
Auto-Add origin address . . . . . . . . . . . . . . . 128
Auto-Add origin line . . . . . . . . . . . . . . . . . 128
Allow remote operation . . . . . . . . . . . . . . . . 129
Security level for remote . . . . . . . . . . . . . . 129
Remote access password . . . . . . . . . . . . . . . . 129
'To:' name on request msg . . . . . . . . . . . . . . 130
Destination address . . . . . . . . . . . . . . . . . 130
'Fm:' name on request msg . . . . . . . . . . . . . . 130
Origination address . . . . . . . . . . . . . . . . . 131
Netmail message flags . . . . . . . . . . . . . . . . 131
Subject line of msg . . . . . . . . . . . . . . . . . 131
GLOBAL MODIFY OPTIONS . . . . . . . . . . . . . . . . . . . 133
[F9] - Filter Networks . . . . . . . . . . . . . . . . 133
[F5] - Sort Conferences . . . . . . . . . . . . . . . 133
[ALT-F] - Find Conference Area/Conference Number . . . 133
GLOBAL ADD CONFERENCES . . . . . . . . . . . . . . . . . . 134
[F10] - Start Global Add . . . . . . . . . . . . . . . 134
GLOBAL DELETE NODES/CONFERENCES . . . . . . . . . . . . . . 135
[DEL] - Start the Global Delete . . . . . . . . . . . 135
GLOBAL MODIFY NODES/CONFERENCES . . . . . . . . . . . . . . 136
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page vii
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
MASTER CONFERENCE LIST . . . . . . . . . . . . . . . . . . 138
[F9] - Filter Networks . . . . . . . . . . . . . . . . 138
[ALT-F] - Find Conference Area . . . . . . . . . . . . 138
[DEL] - Delete a Conference . . . . . . . . . . . . . 138
[INS] - Add a Conference . . . . . . . . . . . . . . . 138
[ENTER] - Edit a Conference . . . . . . . . . . . . . 139
MASTER CONFERENCE SPECIFIC SETTINGS . . . . . . . . . . . . 140
Area name . . . . . . . . . . . . . . . . . . . . . . 140
Description . . . . . . . . . . . . . . . . . . . . . 140
Network . . . . . . . . . . . . . . . . . . . . . . . 140
ECHOLIST MANAGEMENT . . . . . . . . . . . . . . . . . . . . 141
[INS] - Add a Definition . . . . . . . . . . . . . . . 141
[DEL] - Delete a Definition . . . . . . . . . . . . . 141
[ENTER] - Edit a Definition . . . . . . . . . . . . . 142
ECHOLIST SPECIFIC SETTINGS . . . . . . . . . . . . . . . . 143
Network name . . . . . . . . . . . . . . . . . . . . . 143
Update changed descriptions . . . . . . . . . . . . . 143
Purge entries not in import file . . . . . . . . . . . 143
Create differential report . . . . . . . . . . . . . . 143
Differential report name . . . . . . . . . . . . . . . 144
[ALT-V] - View File . . . . . . . . . . . . . . . 144
Import ASCII text file name . . . . . . . . . . . . . 144
[ALT-V] - View File . . . . . . . . . . . . . . . 144
Export ASCII text file name . . . . . . . . . . . . . 145
[ALT-V] - View File . . . . . . . . . . . . . . . 145
Export text file format . . . . . . . . . . . . . . . 145
Paginated . . . . . . . . . . . . . . . . . . . . 145
Line by Line . . . . . . . . . . . . . . . . . . 145
Page length . . . . . . . . . . . . . . . . . . . . . 146
WHAT ARE POINT ADDRESSES? . . . . . . . . . . . . . . . . . 147
BOSS NODE . . . . . . . . . . . . . . . . . . . . . . 147
ADDRESSING SCHEMES . . . . . . . . . . . . . . . . . . 148
POINT DESCRIPTIONS . . . . . . . . . . . . . . . . . . . . 148
3D POINT ADDRESSES . . . . . . . . . . . . . . . . . . 148
DESIGN CHANGE . . . . . . . . . . . . . . . . . . . . 149
4D ADDRESSING . . . . . . . . . . . . . . . . . . . . 150
POINT CONFIGURATIONS . . . . . . . . . . . . . . . . . . . 151
IF YOU'RE A BOSS NODE . . . . . . . . . . . . . . . . 151
IF YOU'RE A 4D POINT . . . . . . . . . . . . . . . . . 151
TROUBLESHOOTING . . . . . . . . . . . . . . . . . . . . . . 153
COMMON QUESTIONS/PROBLEMS . . . . . . . . . . . . . . 153
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page viii
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
LOGGING INFORMATION . . . . . . . . . . . . . . . . . 159
WILDCAT! ERROR.LOG FILE . . . . . . . . . . . . . . . 159
LICENSING AND DISTRIBUTION AGREEMENT . . . . . . . . . . . 160
NO WARRANTY . . . . . . . . . . . . . . . . . . . . . . . . 162
TECHNICAL SUPPORT . . . . . . . . . . . . . . . . . . . . . 163
30 DAY EVALUATION COPY . . . . . . . . . . . . . . . . . . 163
TECHNICAL SPECIFICATIONS . . . . . . . . . . . . . . . . . 164
Memory Requirements . . . . . . . . . . . . . . . . . 164
Conference Areas Supported . . . . . . . . . . . . . . 164
Node Addresses . . . . . . . . . . . . . . . . . . . . 164
Downlink Nodes per Conference . . . . . . . . . . . . 164
Tossing Mail in Date/Time Order . . . . . . . . . . . 165
Large Messages . . . . . . . . . . . . . . . . . . . . 165
No Content/Null Messages . . . . . . . . . . . . . . . 165
Maximum AKA Addresses . . . . . . . . . . . . . . . . 165
Maximum Forward Lists . . . . . . . . . . . . . . . . 165
Maximum Zone Assignments . . . . . . . . . . . . . . . 165
APPENDIX A - PACKER/UNPACKER PARAMETERS . . . . . . . . . . 166
ARCA v1.28 . . . . . . . . . . . . . . . . . . . . . . 166
ARCE v3.1b . . . . . . . . . . . . . . . . . . . . . . 166
PKARC v3.5 . . . . . . . . . . . . . . . . . . . . . . 167
PKXARC v3.5 . . . . . . . . . . . . . . . . . . . . . 167
PKPAK Version 3.61 . . . . . . . . . . . . . . . . . . 168
PKUNPAK Version 3.61 . . . . . . . . . . . . . . . . . 169
ARJ 2.30 . . . . . . . . . . . . . . . . . . . . . . . 170
LHARC v1.13c . . . . . . . . . . . . . . . . . . . . 171
LHA version 2.13 . . . . . . . . . . . . . . . . . . . 172
PAK . . . . . . . . . . . . . . . . . . . . . . . . . 173
PKZIP (R) v1.10 . . . . . . . . . . . . . . . . . . . 174
PKUNZIP (R) v1.10 . . . . . . . . . . . . . . . . . . 175
ZOO archiver v2.00 . . . . . . . . . . . . . . . . . . 176
APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS . . . . . . . . . 177
ASSOCIATED BATCH FILES . . . . . . . . . . . . . . . . . . 177
CAT.BAT . . . . . . . . . . . . . . . . . . . . . . . 177
DOBBS.BAT . . . . . . . . . . . . . . . . . . . . . . 177
EXEBBS.BAT . . . . . . . . . . . . . . . . . . . . . . 177
SYSTEM FLOW . . . . . . . . . . . . . . . . . . . . . . . . 178
CAT.BAT FILE . . . . . . . . . . . . . . . . . . . . . 181
DOBBS.BAT FILE . . . . . . . . . . . . . . . . . . . . 184
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page ix
WILDMAIL! v4 TABLE OF CONTENTS
─────────────────────────────────────────────────────────────────
EXEBBS.BAT FILE . . . . . . . . . . . . . . . . . . . 185
InterMail Systems . . . . . . . . . . . . . . . . 185
APPENDIX C - WHAT IS NETMAIL/ECHOMAIL? . . . . . . . . . . 188
System Addressing . . . . . . . . . . . . . . . . . . 188
File Attachments . . . . . . . . . . . . . . . . . . . 188
Sharing Message Bases . . . . . . . . . . . . . . . . 188
Hub Creation . . . . . . . . . . . . . . . . . . . . . 190
Netmail Definition . . . . . . . . . . . . . . . . . . 191
Echomail Definition . . . . . . . . . . . . . . . . . 191
Summary . . . . . . . . . . . . . . . . . . . . . . . 192
APPENDIX D - OBTAINING A NODE NUMBER . . . . . . . . . . . 193
Which Network to Join . . . . . . . . . . . . . . . . 193
What's a Nodelist . . . . . . . . . . . . . . . . . . 193
Obtaining a Nodelist . . . . . . . . . . . . . . . . . 193
Locating the Closest Hub . . . . . . . . . . . . . . . 194
Contacting the Hub SysOp . . . . . . . . . . . . . . . 194
Netmail Transfer Capability . . . . . . . . . . . . . 194
Receiving Your Node Address . . . . . . . . . . . . . 195
APPENDIX E - PERFORMANCE TUNING . . . . . . . . . . . . . . 196
Disk Caching Software . . . . . . . . . . . . . . . . 196
DOS File Count Limitation . . . . . . . . . . . . . . 197
Database Safety Mode . . . . . . . . . . . . . . . . . 199
Preprocessing Mail Deliveries . . . . . . . . . . . . 201
Summary . . . . . . . . . . . . . . . . . . . . . . . 201
APPENDIX F - ERRORS UNCOMPRESSING MAIL . . . . . . . . . . 203
Errorlevel Checking . . . . . . . . . . . . . . . . . 203
Logfile Entries . . . . . . . . . . . . . . . . . . . 203
APPENDIX G - PATH: AND SEEN-BY: LINES . . . . . . . . . . . 204
MASTER INDEX LISTING . . . . . . . . . . . . . . . . . . . 206
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page x
WILDMAIL! v4 INTRODUCTION
─────────────────────────────────────────────────────────────────
INTRODUCTION
Integrated Solutions is a third party software developer for
WILDCAT! BBS systems. We have been producing utility programs
for over 5 years now and have been running Bulletin Boards since
early '87. Over that period of time we've accumulated a vast
amount of experience in the management and implementation side of
BBSing. We bring forward that experience in the software that we
develop by offering ease of use and powerful features.
WILDMAIL! was born out of a need from Mustang Software Inc., the
authors of WILDCAT! BBS software, to have echomail messages
tossed into and out of their message databases for WILDCAT! v3.0.
At first we were a bit reluctant because of the magnitude of the
project, but having been involved in the early beginnings of
echomail, we knew we could produce an all in one package that
would greatly simplify the old archaic methods of the past.
In the early days of WILDMAIL!, we attended the school of hard
knocks, and learned probably more than we wanted to about the
echomail arena and the people that use it, and have applied what
we've learned to this release. We think you'll find that v4 far
exceeds your expectations, and will provide you with many
pleasurable hours of trouble free echomail use.
WHAT IS WILDMAIL!
WILDMAIL! v4 is an echomail processor for WILDCAT! BBS systems.
WILDMAIL! processes standard Fidonet compatible mail for
transmission by FrontDoor, D'Bridge, InterMail or BinkleyTerm.
It also processes specially formatted Netmail messages used by
your downlink nodes to automatically activate and or deactivate
message conferences.
After unpacking, WILDMAIL! processes the .PKT files and tosses
the messages contained within them into either .MSG files or
directly into the corresponding message conferences. It also
forwards messages to the Uplink and Downlink Node addresses
specified in the configuration.
WILDMAIL! will also extract new messages from the WILDCAT!
message databases and output them into the Fidonet standard .PKT
format. It will then bundle up the PKT files creating a standard
Fidonet mail archive and pass that to the front end mailer to
process as outbound mail.
AreaRequest is a powerful feature allowing your downlink node
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 1
WILDMAIL! v4 INTRODUCTION
─────────────────────────────────────────────────────────────────
addresses to turn on/off conferences to their system
automatically by the use of Netmail messages. This relieves you
from having to manually toggle these conferences on or off. When
a request comes in for a conference that you don't carry on your
system, WILDMAIL! will automatically generate a message to your
uplink address requesting the new conference. Once it's
received, it will be activated for the requesting node.
Multiline Operation
As with all previous releases, you may execute WILDMAIL! while
your multiline copy of WILDCAT! is up and running. Notice the
key word here is multiline. You MUST have the multiline copy of
WILDCAT! otherwise you run the risk of corrupting your message
databases.
WILDMAIL! fully supports file locking/sharing in the WILDCAT!
environment. It obtains the necessary information about the type
of multiline environment like DOS Share, Novell and so on from
the WILDCAT! configuration files.
Currently only one copy of WILDMAIL! may be executing at any
time. The key word here is executing! If you attempt to run
another copy of WILDMAIL! while the first is running, a message
is displayed stating so and the second copy's execution is
aborted. This also holds true for WMUTIL! and WMCONFIG! which
use the same configuration and database files. The bottom line
here is simple, only one program may access WILDMAIL!'s data
files at any given time.
Single Line Systems
If you have the single line version of WILDCAT!, before executing
WILDMAIL!, you must bring your WILDCAT! system down and then
start the mail process. There are *no* exceptions to this.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 2
WILDMAIL! v4 FEATURES LIST
─────────────────────────────────────────────────────────────────
FEATURES LIST
WILDMAIL! v4 can easily be considered a feature rich mail
processor that performs many functions that most systems will
never use. It does so in a manner that won't get you lost in all
the technical mumbo jumbo of todays high tech world of echomail.
For those systems that need these advanced features, you'll
appreciate the clarity of presentation and usefulness of the
power that is available to you.
Shown below is a partial list of the features of both WMCONFIG!,
the configuration program, and WILDMAIL!, the actual mail tosser.
WMCONFIG! Features
o Protected operating mode, prevents changes
o 25/43/50 line CRT video modes
o Context sensitive online help
o User friendly interface
o Shell to DOS
o Automatic configuration verification
o Global change for Nodes/Conferences
o Extracts conference info from WILDCAT!
o Automatic Origin line length checking
o Protected fields dictated by configuration
Due to the fact that multiline systems are becoming more and more
popular, when WMCONFIG! obtains and/or saves information into the
various databases, it fully supports file locking and sharing.
So you may safely execute WMCONFIG! when your multiline WILDCAT!
BBS is up and running. However, you may not execute WMCONFIG! or
WMUTIL! when WILDMAIL! is processing mail.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 3
WILDMAIL! v4 FEATURES LIST
─────────────────────────────────────────────────────────────────
WILDMAIL! Features
GENERAL
o Significantly increased performance
o Separate Echomail and Netmail processing
o PreTossing for significant speed gains
o True four dimensional addressing (4D)
o Outbound PKT size definition
o FredMail and Multi-Zone Gating support
o Packer/parameters definition for Binkley
o Exclude specific names from mail importation
o Direct D'Bridge outbound queue support
o Swap file path definition
o Inbound/Outbound zone matching
o Conference level manager for Origin lines
o Automatic conference activation/deactivation
o Disable conference activation/deactivation
NODE SPECIFIC
o Active/Inactive status
o Type 2 and Type 2+ PKT output formats
o Configurable mail status flags
o PKT level password assignment
o AreaRequest security and flag assignments
o Zone gating output path definition
o Strip SEENBY line information
o Selectable archive naming convention
CONFERENCE SPECIFIC
o Active/Inactive status
o Long descriptions
o Origin address definition
o Origin line selection
o Originating Node or Uplink/Feed address
o Extract private echomail
o Restrict import of mail from undefined addresses
o Extract echomail file attachments
o AreaRequest Security and Flag assignments
o SEEN-BY: line processing - Display, Hide or Delete
o Add selected addresses to SEEN-BY: lines
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 4
WILDMAIL! v4 30 DAY EVALUATION
─────────────────────────────────────────────────────────────────
30 DAY EVALUATION KEY FILE
WILDMAIL! utilizes a special file to activate its usage for a
period of 30 days. This method allows the program to be fully
utilized with all options enabled for the duration of the
evaluation period. If the product hasn't been registered after
the thirty days, WILDMAIL! will inform you it has expired and
will simply cease to run.
Since the current method of distribution prevents a "dated" key
file from being included in the distribution archive files, you
must dial up the support board (listed below) and create this
special key file. The Main Menu option "Create Evaluation Keys"
initiates this process and you simply enter in the required
information and then follow the instructions for downloading.
The WILDMAIL! support board may reached by dialing:
(909) 695-6676 - Microcom 28.8bps (10 lines)
Only one key per person/registration number will be allowed.
WILDUUCP! AND MAIL GATING
In todays complex world of mail transfers, it's common for
systems to gate mail from one network to another. This means
messages from one network could be sent to another network. This
process involves some very special handling in order to operate
properly.
WILDMAIL! now permits you to create outbound mail in raw,
uncompressed PKT file format in any directory you specify on a
node by node basis. This feature coupled with the Tiny SEENBYs
option (this strips out all the SEEN-BY: information from the
messages and only puts the Origin and Destination address in the
SEEN-BY: lines) allows you quite a bit of control in this area.
Since this is performed on a node basis, you may have as many
gates as you need limited only by available disk space.
For those systems running WILDUUCP!, this provides an incredibly
easy way of tying your system into the Internet. Simply create a
fake node address, specify mail type as NONE and enter the path
to WILDUUCP!'s inbound directory and you're off and running.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 5
WILDMAIL! v4 30 DAY EVALUATION
─────────────────────────────────────────────────────────────────
REGISTRATION/ORDERING INFORMATION
Please see the enclosed REGISTER.DOC file for full ordering
information.
REGISTRATION FEE
Registration price for WILDMAIL! v4 is $99 plus $10 shipping and
handling. California orders MUST include 7.75% on the $99
portion for local taxes.
PAYMENT METHOD
You may register the product several ways. You can call up the
support BBS and use the online questionnaire, you can fill out
the enclosed registration form and mail it in. Or you may call
us directly Monday through Saturday 9am-5pm PST and place a
credit card order. We presently accept VISA, MasterCard and
Discover. For those people that pay by check, there is a 10 day
hold period to allow sufficient time for your check to clear the
bank.
UPGRADE FROM PREVIOUS v1.xx/v2.xx to v4
Registered WILDMAIL! users can upgrade their current release for
$35 plus $10 shipping and handling. CA residents must add 7.75%.
Simply send in the UPGRADE.DOC form enclosing your payment.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 6
WILDMAIL! v4 UPGRADE FROM PREVIOUS RELEASES
─────────────────────────────────────────────────────────────────
UPGRADE FROM PREVIOUS RELEASES
As with any major release, there's usually some form of structure
change that makes it incompatible with any of the earlier
releases. Unfortunately, this is the case here with WILDMAIL! v4
but included is a program called WMINSTAL that greatly simplfies
this process.
UPGRADE PROCESS
Because of all the time and effort you've spent configuring your
system, we've created a program called WMINSTAL. This is a
standalone utility that reads the contents of your old
configuration and then imports this information into the new
database structures of WILDMAIL! v4.
This is a very fast and painless process to perform and it
protects all the time and effort you've put into your current
configuration. Please refer to the contents of WMINSTAL.INF
(included in the distribution archive) for specific information.
DUPLICATE CHECKING
With this new release comes new and more advanced methods of
checking for duplicate messages. Because of this, your old
duplicates database files called WMDUPES.DAT/.IX will no longer
be compatible with this release.
Consequently, for the next few mail runs, your system will have
to build a completely new list of messages to check. This is done
automatically and there is no method by which you can convert
your existing duplicate database over.
Because of this, there is a slight chance that if duplicate
messages do come to your system, they may not be caught by
WILDMAIL!. Fortunately, this will only be for the first couple
of mail runs after the conversion and from that point on, your
system should have built up enough of a duplicates database of
messages to effectively catch them in the future.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 7
WILDMAIL! v4 FIRST TIME INSTALLATION
─────────────────────────────────────────────────────────────────
FIRST TIME INSTALLATION
First time installations of any product can be a taxing process
at times, especially with a complex product such as WILDMAIL!.
Although the product has been designed to be as user friendly as
possible, there's simply no substitute for experience. If you're
new to echomail, the best advice we can offer is to take your
time, read the documentation and have it handy when you go
through all the options.
If you're an old hand at this, you'll appreciate some of the more
advanced features available to you, but don't overlook the
documentation. An extensive amount of effort has been applied in
this area in order to be as informative and insightful as
possible, hopefully allowing you to understand the reasons for
each of the various options. We think you'll agree, there is a
wealth of information contained within these pages!
Shown below is the step by step process to perform an initial
installation of WILDMAIL! v4.
BBS DOWNLOAD
If you've downloaded this new release from a BBS, you should
create a temporary directory and uncompress the contents of the
distribution archive using PKZIP into that directory.
Similar to: C: <Press Enter>
MD \tempdir <Press Enter>
COPY WM41-WC3.ZIP C:\tempdir <Press Enter>
CD \tempdir <Press Enter>
PKUNZIP WM41-WC3 <Press Enter>
When choosing a temporary directory to install from, you should
NOT use one called \WM40, especially of it's on the drive you're
attempting to install to. Instead, simply use a different name.
From there you would simply execute WMINSTAL from the DOS prompt
such as:
WMINSTAL <Press Enter>
and follow the instructions on the screen. If you're unsure
about a particular option, position the highlight bar on that
field and press [F1] for online help information.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 8
WILDMAIL! v4 FIRST TIME INSTALLATION
─────────────────────────────────────────────────────────────────
INSTALLATION DISKETTE
If you are installing from the installation diskette, you simply
need to change to that drive and type WMINSTAL.
Similar to: A: <Press Enter>
WMINSTAL <Press Enter>
From here, simply follow the instructions on the screen. If
you're unsure about a particular option, position the highlight
bar on that field and press [F1] for online help information.
Depending on your installation requirements, this program has up
to two major steps to it. The first step performs the creation
of subdirectories, moving of files etc. The second, if so chosen
will convert your previous installation of WILDMAIL! v3 to the
new data structures.
Listed below are the available installation types.
Normal Install
WMINSTAL! will require you to enter the destination drive
along with your primary address as well as the location
where you pick up your mail from. This is typically referred
to as your "hub" or "uplink/feed" address.
You may begin the installation by pressing [F10] and then
after some initial checking configuration checking,
WMINSTAL! will create the necessary directories and then
proceed to uncompress the contents of WM4FILES.DAT into the
\WM40 directory. Once the uncompression process is complete
and the files are moved to their respective directories, a
screen will be displayed indicating the installation is
complete and you will be returned to the previous menu.
At this point, you should now have the documentation handy that
was printed out in step #4 for easy reference. You should go
through all the options available making any necessary changes.
At any point within the configuration program if you have any
questions regarding a certain option, simply position the
highlight bar on that field and press [F1]. This brings up help
information specific to the field the cursor is on. When you're
satisfied with the configuration, pressing [ESC] from the Main
Menu allows you to exit and save the configuration.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 9
WILDMAIL! v4 FIRST TIME INSTALLATION
─────────────────────────────────────────────────────────────────
BATCH FILE ENTRIES
WILDMAIL! can be executed various ways, but by far the most
common method is from a batch file. This can be part of your
mailers batch file or from the one that executes your BBS. For
FrontDoor/Intermail systems, an example set of batch files have
been included in one of the sections in the back of this
documentation.
Typically, you would want to do a minimum of two things in the
batch file that executes WILDMAIL!.
1) Change directories to \WM40 or whatever you call the
WILDMAIL! v4 directory.
2) Execute WILDMAIL! along with the necessary command line
parameters.
Typically, the command to execute WILDMAIL! would be:
WM SCAN TOSS NETMAIL
Of course there are various different methods of doing this, but
the minimum is to have WILDMAIL! extract any newly created
messages and to toss any newly received messages.
Because WILDMAIL! now supports the ability to process Echomail
separately from Netmail messages, you should make sure that
ultimately you are doing both operations. You don't have to do
both at the same time, or even the same day, but you should make
sure that mail that comes to your system is processed and any
outbound mail is processed as well.
For additional information, please refer to the command line
parameter section for the specifics of each of the commands.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 10
WILDMAIL! v4 COMMAND LINE USAGE
─────────────────────────────────────────────────────────────────
COMMAND LINE USAGE:
WM TOSS SCAN NETMAIL AREAMGR MAILIN MAILOUT PRETOSS
-O
-T<conf #>,<extract count>
-A
Below is a list of all the available command line parameters that
can be used when running WM.
? This will cause WM to display a help screen that allows
menu style selection of command line parameters for
specific help information.
Example Usage: WM ?
From that screen, you will be able to select the
desired topic by pressing the corresponding letter.
Pressing [ESC] returns you to the DOS prompt. Actually
any invalid or mis-matched combination of parameters
will also invoke the help menu.
TOSS This parameter will cause WM to toss messages into
their respective message bases.
Example Usage: WM TOSS
This process starts off by scanning your defined
BADECHO directory for any .MSG files and if there's a
defined conference, tosses them into their respective
conferences. Next, it proceeds to decompress the first
mail archive found in the INBOUND directory and then
starts the process of tossing/adding echomail messages
to their respective conferences.
It should be noted that Netmail message will not be
processed with this option.
If the Maintain message limit option is enabled, then
WM will purge the oldest message before adding a new
one if the conference is at its defined limit as
specified in MAKEWILD.
SCAN This is used to search for newly entered echomail style
messages, (not Netmail messages) then extracts and
forwards them to their downlink and/or Uplink
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 11
WILDMAIL! v4 COMMAND LINE USAGE
─────────────────────────────────────────────────────────────────
addresses.
Example Usage: WM SCAN
Any new echo mail message found will be packed up for
each node in its proper format and a corresponding
Netmail file attach message will be generated and
placed in the Netmail directory for transmission by
your mailer. (Frontdoor/Intermail systems only)
PRETOSS This parameter looks in the Preprocessing path for PKT
files to toss into the WILDCAT! message bases. Only
mail existing in this directory will be processed.
This option is only functional if you've previously
enabled the Preprocessing option.
Example Usage: WM PRETOSS
It should be noted that this parameter must be the only
one in use (at a time) and thus may not be used in
combination with any other parameters.
MAILIN This command line parameter is similar to the TOSS
parameter except it will only toss inbound Netmail
messages. Any echo mail PKT files will not be
processed.
Example Usage: WM MAILIN
MAILOUT This option is similar to the SCAN option except it
only scans for newly entered Netmail messages. Any new
echo mail messages will not be extracted.
Example Usage: WM MAILOUT
NETMAIL This command line parameter combines the functions of
both the MAILIN and MAILOUT parameters. Normally this
is the command line parameter you will be using the
majority of the time.
Example Usage: WM TOSS SCAN NETMAIL
The above example is by far the most common usage for
tossing and extracting ALL forms of messages found on
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 12
WILDMAIL! v4 COMMAND LINE USAGE
─────────────────────────────────────────────────────────────────
your system.
PACK This option is only used when BINKLEY has been selected
as the Mailer type.
Example Usage: WM PACK
At present WM does not support its own internal
packing, bundling and routing of outbound mail for
mailer types selected as Binkley. This parameter will
however, call an external program that you have
specified in the Mailer specific options from the Main
Menu selection, System Information. (for BinkleyTerm
systems)
PURGE This will maintain the allowable message count defined
in MAKEWILD for each message conference configured for
your system.
Example Usage: WM PURGE
Normally, this option would be used if you have set the
Maintain message levels option to N (under WILDCAT!
specific options) and could be run as a scheduled BBS
event. There would be a minor savings in time to
process the incoming mail, minimizing downtime of that
node for processing mail. However, disk space will be
taken up for those unused blank slots in the message
database.
AREAMGR This command line parameter is used to invoke the
AreaRequest manager.
Example Usage: WM AREAMGR
For this to operate properly, you must have previously
enabled its use by the Main Menu option, AreaRequest
Manager, Process AreaRequest Msgs. With this set to Y,
WILDMAIL! will scan the Netmail directory for any names
matching those defined and if they have NOT been
received, will process them accordingly. This
parameter may be used with others as needed such as
TOSS, SCAN, NETMAIL and so on.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 13
WILDMAIL! v4 COMMAND LINE USAGE
─────────────────────────────────────────────────────────────────
NOTIFY This option scans the Nodes database and produces a
message for each node showing the conferences they are
currently picking up from your system.
Example Usage: WM NOTIFY
This parameter must be the only one used for this
option to function properly. Any nodes that have been
configured to be excluded from this feature will not
have the message sent to their system. For specifics
on excluding nodes, please refer to the Notify Exclude
option found in the AreaRequest Manager section of
WMCONFIG!.
-O This option enables a cleanup of the outbound
directory.
Example Usage: WM -O
Most mailers automatically clean up the outbound
directory, so this option would normally not be used.
If your mailer does not clean up the outbound
directory, ie. does not delete all the mail archives
after transmission, then you should use this option.
-T<conf #>,<last extracted msg #>
Resets the last extract message count to the number
specified for the conference.
Example Usage: WM -T14,100
Note the "," comma between the <conf #> and the <last
extracted msg #> as well as the conference number NEXT to
the -T parameter (no spaces). The above example would reset
the last extract number in conference 14 to 100. All
messages numbered ABOVE 100 would then be sent during the
next execution of "WM SCAN".
If you would like to reset all the conferences to the
highest message number, you may use the following:
Example Usage: WM -THIGHMSG
This is handy because WILDMAIL! will determine the settings
for each conference automatically for you.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 14
WILDMAIL! v4 COMMAND LINE USAGE
─────────────────────────────────────────────────────────────────
CAUTION!
If the conferences SEEN-BY: line processing option has been
set to DELETE, DO NOT USE THIS OPTION because the SEEN-BY:
line information was stripped before the message was
originally saved in WILDCAT! Because of this, you are
GUARANTEED of creating duplicates in the network!
If the SEEN-BY: line processing option for the selected
conference is set to HIDDEN, then you may use this option
with little fear of creating duplicate messages.
-A
If the Extract echo mail attaches option has been enabled,
(for any of your conferences) this command line parameter is
used to instruct WILDMAIL! to scan the defined \WM30\ATTACH
directory and find the files that don't have a corresponding
Netmail message and then delete them.
Example Usage: WM -A
These are the files that have already been transmitted to
their destination and thus no longer have a corresponding
Netmail message. The file attachments are the ones that the
callers to your system have attached to the messages in the
WILDCAT! message bases.
By default, WILDMAIL! leaves these files alone and they can
build up if you don't use this parameter. Normally you
would use this parameter together with your TOSS, SCAN
NETMAIL and so on parameters when executing WILDMAIL!.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 15
WILDMAIL! v4 USER INTERFACE
─────────────────────────────────────────────────────────────────
USER INTERFACE
WMCONFIG!, the configuration program for WILDMAIL! has been
designed from the ground up with the novice user in mind. A lot
of extra care has been spent in thinking through the features in
an effort to somewhat simplify the complex area of echomail and
its varied methods of configuration/implementation.
Industry standard selection and entry techniques are employed
throughout the program as well as good old fashioned common sense
programming. The [ESC] key is used to abort any process, and
pressing [F1] brings up help information. Pressing [F10] is used
to save a particular option or database entry or initiate a
specific function.
Context Sensitive Help
Full context sensitive help is available anywhere by simply
pressing the [F1] key. This means that whatever the current
cursor position is, pressing the [F1] key brings up help
information relative to that field.
You may also press [F1] a second time to display a list of
help topics to choose from. Simply position the highlight
bar on the desired topic and press [ENTER]. Once you've
finished viewing the help information, pressing the [ESC]
key returns you to the previous configuration screen.
Throughout the help topics, certain portions of the help
text may contain highlighted words or phrases. For those
viewing in color, this is White Text on a Cyan background
and mono systems is White Text on a Black background.
This highlighted text indicates that a relative subtopic is
available for viewing. Simply position the cursor to the
highlighted text and press [ENTER]. When you've finished
viewing this subtopic, pressing ALT [F1] will return you to
the previous help topic.
CRT Display Modes
The configuration program has been designed to operate in
any of three display modes. The standard mode of 25 lines,
43 and 50 line modes. Depending on the section being
configured, the window sizes will adjust themselves
automatically, including those for the online help.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 16
WILDMAIL! v4 USER INTERFACE
─────────────────────────────────────────────────────────────────
For those screens that contain more information than can be
displayed in the standard 25 line mode, all the available
options will be displayed on the screen.
Status Bar
Throughout the configuration process, a status bar located
at the bottom of the screen (25, 43 and 50 line modes)
always indicates the available options. Depending on where
you're at in the configuration process, these options will
change automatically.
DOS Shell
Since WMCONFIG! has been designed with the user in mind,
there may come a time when you're in the middle of the
configuration process and you need to go to DOS to check on
the location of a file or subdirectory. Holding down the
ALT key and pressing the letter D causes WMCONFIG! to swap
itself out of memory and return you to the DOS prompt.
As part of the swap process, only a small kernel of memory
is taken up, making available nearly all of your memory to
execute another program in. Once you have finished with
your work in DOS, at the prompt, typing the command:
EXIT
will return you to same section within WMCONFIG! you
originally exited from, and allows you to resume normally.
Again, you may press ALT-D anywhere within the configuration
process to shell to DOS.
Read-Only Mode
When you first start up WMCONFIG!, it comes up in what is
called Read-Only Mode (displayed in the top RH corner of the
screen). This means you can move about the configuration
options but are not allowed to change anything. This mode
is handy if you wish to view your current configuration
without the possibility of accidently making a change.
If you wish to exit this mode, pressing [F8] toggles you
back into Edit Mode (as indicated at the top RH corner of
the screen). From here you can make any changes desired.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 17
WILDMAIL! v4 USER INTERFACE
─────────────────────────────────────────────────────────────────
Once the [F8] has been toggled to Edit Mode, you may not go
back into Read-Only mode.
This is due in part to the various data files used to store
your configuration. Plus it may give you a false sense of
protection when in reality you may have accidently changed
something before toggling the setting a second time.
Database Formats
The conference area and node address databases both make use
of special, high speed indexed B-Tree formatted files. The
Crash Mail users list is actually special flag information
stored in the WILDCAT! users database. This allows you full
access to all the callers on your system without having to
maintain a duplicate set of user names.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 18
WILDMAIL! v4 WMCONFIG! SETUP AND CONFIGURATION
─────────────────────────────────────────────────────────────────
WMCONFIG! SETUP AND CONFIGURATION
As stated earlier, WMCONFIG.EXE is the configuration program used
the define the operational characteristics of WILDMAIL! including
conferences, nodes and the networks databases. This program must
be executed from the WILDMAIL! directory and may not be executed
while WILDMAIL! is processing mail.
DATA FILES USED
Shown below is a description of the various datafiles WMCONFIG!
maintains/uses for proper configuration of WILDMAIL!.
WMCONFIG.DAT Main configuration settings including
defaults, paths, archivers, and so on.
WMAREAS.DAT/IX Each conferences unique configuration
settings.
WMNODES.DAT/IX Node definition information for each of the
systems you will be transferring mail with.
WMNETS.DAT/IX All of the network definitions for your
configuration.
WMLIST.DAT/IX Master List database of conferences for all
of the defined networks.
WMECHO.DAT Database containg all of the echolist
definitions containing paths/file names of
the ASCII text files of all the areas for a
given network.
WMORIGIN.DAT All of your Origin line information is stored
here.
WMCONFIG.HLP This is the online help file used when
pressing [F1] on a selected field. This file
is not editable and must exist in the
WILDMAIL! directory.
MENU SELECTIONS
The following pages are divided up into categories as selected
from the Main Menu. Each category having its own options and
sub-menus and are presented in the order they appear on the Main
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 19
WILDMAIL! v4 WMCONFIG! SETUP AND CONFIGURATION
─────────────────────────────────────────────────────────────────
Menu.
You may select the desired option by either pressing the
associated hot key (accentuated by a different colored letter in
the option name) or by positioning the highlight bar by using the
Up/Dn arrow keys and pressing [ENTER].
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 20
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
SYSTEM INFORMATION
This category is used to define subdirectory paths for inbound
and outbound mail, mailer specific information along with SysOp
and BBS names etc.
Shown below is a complete breakdown of the available
configuration options from this screen.
System operator name:
The Master SysOp name in First Name Last Name format as
defined in your BBS configuration program.
This information is used for various purposes including
System Generated messages. These messages would typically
be sent to the SysOp informing him/her of problems
encountered during mail processing.
So for proper notification etc, the name specified here must
accurately reflect the SysOp name used on the BBS.
Bulletin board name:
The name of your Bulletin Board. Typically, this is the
same name as defined in your BBS configuration program.
The name specified here will also be used as a default value
in case the Origin line defined for a given conference
during a global modify combined with the origin address
exceeds the line length limit of 79 characters.
While the above is considered the exception to the rule, you
should be aware that it can be used in those rare cases.
Primary address:
Because more and more networks are popping up on a regular
basis, most systems usually have more than one address. A
default address must be known in certain situations and this
option is used to specify which of your addresses is to be
considered your primary or default address.
The address specified here must be in <zone:net/node.point>
format similar to 1:161/123.0. Normally, this is the same
address you've previously defined as your primary address in
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 21
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
your front end mailer.
Pressing [ENTER] on this field pops up another window
allowing you to specify the individual zone, net, node and
point numbers that make up your entire address.
The primary address is also used in a somewhat unique
manner. If you've enabled the "Pre-processing echomail"
option found on the BBS Specific Options screen, this
address will have mail forwarded to it and placed into the
defined pretoss directory. The To: and From: addresses used
on the PKT files will contain this address and will be
handled separately.
Also Known As (AKA) addresses:
Because there are literally hundreds of different networks
in existence today, most require you to have a unique
address assigned to you by that network. Besides your
primary address, these additional addresses are referred to
as AKAs (an acronym for Also Known As). This option allows
you to specify up to 20 different AKA's.
WILDMAIL! uses these addresses to match incoming Netmail
messages and PKT files containing the echomail messages to
their respective network addresses for any additional
processing.
After pressing [ENTER] on this field, a list of previously
defined AKAs are displayed from which you may add, delete or
edit the AKA definitions.
You may not define an address that is listed in the Node
Management database nor can you specify your primary address
as an AKA. Any attempt to do so will display a screen
informing you of your error.
Inbound path1:
During the course of WILDMAIL!'s execution, it will need to
look in a specific directory for newly received mail that
needs to be processed. This option allows you to specify
the actual subdirectory that will contain these newly
received mail bundles.
Typically, this is identical to the inbound directory path
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 22
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
specified in your front end mailers setup. i.e.
FrontDoor C:\FD\FILES\
InterMail C:\IM\SECURE\
D'Bridge C:\DB\FILE\
Binkley C:\BINK\INBOUND\
In order to support some of the more advanced features of
the front end mailers, this field is also shared with its
counterpart of "Inbound path2". Both FrontDoor and
InterMail have both secure and non-secure inbound
directories. If you would like to take advantage of this
feature, you should specify the appropriate subdirectories
in both of the inbound path options, for example:
Inbound path1: C:\IM\SECURE\
Inbound path2: C:\IM\FILES\
If your front end mailer only supports one inbound
directory, the "Inbound path1" option should be specified.
You may then leave the "Inbound path2" option field blank.
Inbound path2:
In order to support some of the more advanced features of
the front end mailers, this field is also shared with its
counterpart of "Inbound path1". FrontDoor and InterMail
have both secure and non-secure inbound directories. If you
would like to take advantage of this feature, you should
specify the appropriate subdirectories in both of the
inbound path options, for example:
Inbound path1: C:\IM\SECURE\
Inbound path2: C:\IM\FILES\
If your front end mailer only supports one inbound
directory, the "Inbound path1" option should be specified.
You may then leave the "Inbound path2" option field blank.
For additional information, please refer to the "Inbound
path1" option.
Outbound path:
This option is used by WILDMAIL! to know what subdirectory
to place the outbound mail that has been processed for both
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 23
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
your downlink and uplink systems. The path specified here
must not be the same as either your inbound or netmail
directories otherwise unpredictable results could occur.
Shown below are typical path definitions:
FrontDoor C:\FD\PACKET\
InterMail C:\IM\PACKET-1\
D'Bridge C:\DB\QUEUE\
Binkley C:\BINK\OUTBOUND\
NOTE:
For those systems that are using D'Bridge, you should take
special care in defining this subdirectory. This is because
D'Bridge uses its own internal queue to manage its tasks and
in order for it to work properly, you must specify the
defined temporary queue directory as the outbound directory.
If you don't, chances are D'Bridge will see files that don't
belong in its outbound directory and simply delete them
thereby losing all your downlinks mail in the process.
Netmail path:
This option allows you to specify where WILDMAIL! should
look to find the Netmail .MSG files created by both
WILDMAIL! and your front end mailer. This directory is
typically the same as you've defined in your front end
mailers Netmail directory setup.
Shown below are typical path definitions:
FrontDoor C:\FD\NETMAIL\
InterMail C:\IM\NETMAIL\
D'Bridge C:\DB\NETMAIL\
Binkley C:\BINK\NETMAIL\
Care should be taken when defining this subdirectory because
it must not be the same as either your Inbound or Outbound
directories. Otherwise unpredictable results may occur!
WILDMAIL! uses this directory to scan for newly received
AreaRequest messages, and where to place outgoing netmail
messages that will be sent by your front end mailer.
Bad msgs path:
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 24
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
This option allows you to specify the subdirectory where
WILDMAIL! should place newly received messages that your
system has not been configured to process.
Shown below are typical path definitions:
FrontDoor C:\FD\BADMSGS\
InterMail C:\IM\BADMSGS\
D'Bridge C:\DB\BADECHO\
Binkley C:\BINK\BADMSGS\
When encountering these "orphaned" messages, WILDMAIL! will
convert then into the traditional .MSG file format and store
them in the specified directory for processing at a later
time.
Typically these "bad messages" can appear if you receive
mail from satellite systems but only wish to keep some of
the conferences you'll be receiving. If you would like
WILDMAIL! to simply delete these messages, please refer to
the "Kill orphaned messages" option found on the node
definitions screen found under Node Management.
Mailer type:
This option allows you to specify the type of front end
mailer you are using to send and receive the mail bundles.
This is typically a program that runs in front of your BBS
program and intercepts an automated mail transfer.
Selecting the desired Mailer type by tapping the [SPACEBAR]
will cause WILDMAIL! to match the operating characteristics
of the selected mailer for proper handling/processing of
mail. Shown below are the supported mailer types.
FrontDoor
This is a very popular front end mailer. It processes mail
in a more traditional manner requiring no special
configuration.
Intermail
This program is nearly identical to its counterpart of
FrontDoor.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 25
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
D'Bridge
This is a somewhat unique program in that it handles mail
transfers and processing in a non-traditional fashion.
WILDMAIL! has been designed to fully support D'Bridges
internal processing queue. Due to this uniqueness, if you
run D'Bridge as your front end mailer, it's critical that
you specify this mailer type.
LYNXMAIL!
This is a front end mailer currently being developed by
Integrated Solutions. It is scheduled to be released in the
last quarter of 1994.
Binkley
This BBS type is unique from the others because it doesn't
have a mail packing/routing mechanism built into it, so a
third party utility that performs this function must be
used.
If this mailer type is selected, WMCONFIG! allows you to
specify the packing/routing program name and its associated
command line parameters via a special protected field called
Mail router. From there you can define the packer name and
the necessary command line information for proper execution.
Mail router:
This field is currently only available when the Mailer type
has been set to Binkley. This is used to allow you to
specify the packing/routing program that WILDMAIL! should
execute after the tossing process is complete.
Prior to executing this program, WILDMAIL! will swap itself
out of conventional memory and execute the defined program.
When the packing program has finished, WILDMAIL! will swap
itself back into conventional memory and resume any
remaining processes.
Parameters:
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 26
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
This is used to allow you to specify the command line
parameters to use with the Mail router program definition in
order to properly create the outbound mail archives for your
downlink node addresses.
Since this options settings are derived specifically from
the program used for the actual packing process, you should
refer to the appropriate documentation for the command line
parameters to use with that program.
NOTE
If you specify a batch file in the program name to run, you
should refrain from any command line parameters here and
simply put them in the batch file.
HLO/CLO mode:
When creating outbound archives for Binkley systems, a
special text file is created which acts as a special "queue"
type file containing a list of all the outbound archives
destined for a particular node address.
The very first character of each line entry is used to
determine the disposition of the outbound archive after it
has been sent to its destination node.
WILDMAIL! gives you the ability to select which operating
mode is correct for your configuration. Tapping the
[SPACEBAR] toggles through the available choices as listed
below:
None
This setting will not place any "status" character on the
line, only the complete path and filename of the archive.
C:\BINK\OUTBOUND\0000FFF.MO1
Notice there is nothing in front of the drive letter.
(^) Delete
This setting places a carat (^) character in the first
position of each line entry.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 27
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
^C:\BINK\OUTBOUND\0000FFF.MO1
This tells Binkley systems to delete the archive after
transmission.
(#) Truncate
This setting places a pound (#) character in the first
position of each line entry.
#C:\BINK\OUTBOUND\0000FFF.MO1
This tells Binkley systems to truncate the archive to a 0
byte file after transmission causing WILDMAIL! to increment
the archive naming scheme. i.e. MO1, MO2.
Caution should be used with this option because the
truncated 0 byte files will build up on your system and will
require effort on your part to manage them.
Network mode:
This option allows you to define what network mode (if any)
WMCONFIG! and WMUTIL! should operate under. In order to
properly support the various databases used during the
configuration process, these programs need to know what mode
to operate under.
You should note that WILDMAIL! itself will use the network
mode that the BBS has been defined to run under. So making
changes here only affect WMCONFIG! and WMUTIL!'s database
routines.
Tapping the [SPACEBAR] toggles through the available choices
as described below.
Single Line No database locking and unlocking is
performed in this mode.
DOS 3.3 Share DOS based file locking/unlocking is handled
by loading SHARE and letting it properly
handle the databases. This is commonly used
on DESQview, Lantastic and Netware Lite
configurations.
Novell This is typically used by systems running
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 28
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
Novell Netware v2.xx or higher.
Log file options:
This option is used to specify the level of information you
would like placed in the defined activity log file.
Pressing [ENTER] on this field presents you with a pick list
of items to include in the log file. Highlighting the
desired option followed by tapping the [SPACEBAR]
select/deselects the item.
During the course of WILDMAIL!'s execution, it will write
information to the defined log file. This information has
been categorized by placing a special character (referred to
as an ID) at the beginning of the entry. Using this ID
character along with selecting the appropriate logging
option(s) allows you to select which information you wish to
be saved to the log file.
To select a particular option, simply position the highlight
bar on the desired option and press the [SPACEBAR]. A
selection "dot" now appears for that option. If you wish to
deselect the option, press the [SPACEBAR] a second time.
DIAGNOSTIC LOG OPTIONS
Due to the complexities of processing mail, WILDMAIL! has
two very special options that provide a highly detailed
level of logging that can be very useful in determining
certain problems associated with netmail messages. You will
notice they have a "(D)" associated with the log option
name, meaning this option is for diagnostic purposes only.
Sel Logging Option ID
─── ──────────────── ───
( ) .NML Creation (D) /
( ) .MSG Reading (D) \
Due to the nature of these two options, a significant amount
of information is written to the log file for each netmail
message it processes, so either of these two should only be
turned on as needed. We strongly recommend turning these two
diagnostic options off for normal operation.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 29
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
Activity log path:
This option allows you to define the path and file name
WILDMAIL! should use for its activity log file. All
information relative to the processing that WILDMAIL! does
will be written to this file (subject to the log options
defined).
A typical path definition might be:
C:\WM40\WM.LOG
Normal DOS conventions are required when defining the log
file name.
VIEW FUNCTION
Pressing ALT-V when this option it highlighted, brings up
the file in read-only mode. This is handy for taking a
quick look at the log file during the configuration process.
Pressing [ESC] aborts the viewing mode and returns you to
WMCONFIG!
At any point in time after WILDMAIL! has finished its
processing, you may edit/delete this file as desired.
However, if you attempt to view this file (using an external
viewer) while WILDMAIL! is running, errors will be logged to
the ERROR.LOG file.
Min free disk space (Gen):
This option is used to determine at what point WILDMAIL!
will abort processing if the amount of free disk space
becomes less than the value specified here. This setting
can become critical on systems than run very low on disk
space in preventing system crashes due to insufficient disk
space. A typical definition might be:
Min free disp space (Gen): 5000000
This option differs from its counter part "Min free disk
space (Msg)" in that it refers to the amount of free disk
space (in bytes) that the WILDMAIL! home directory
(typically \WM40) resides on.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 30
WILDMAIL! v4 SYSTEM INFORMATION
─────────────────────────────────────────────────────────────────
Typically this setting is higher than its counterpart due to
the additional space required to compress and uncompress the
mail.
If WILDMAIL! does abort due to this minimum being reached,
all information specific to the drive is written to the
defined activity log for later review.
Min free disk space (Msg):
This option is used to determine at what point WILDMAIL!
will abort processing if the amount of free disk space
becomes less than the value specified here. This setting
can become critical on systems than run very low on disk
space in preventing system crashes due to insufficient disk
space. A typical definition might be:
Min free disp space (Msg): 3000000
This option differs from its counter part "Min free disk
space (Gen)" in that it refers to the amount of free disk
space (in bytes) that the currently tossed message resides
on. This becomes important on systems that support multiple
drive definitions and scatter their message bases across
different disk drives.
If WILDMAIL! does abort due to this minimum being reached,
all information specific to the drive is written to the
defined activity log for later review.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 31
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
MISCELLANEOUS INFORMATION
Information defined here dictates the operational characteristics
of WILDMAIL! such as number of duplicates, packet sizes and so
on. Shown below is a complete breakdown of the available options
and their descriptions.
Default archive format:
This field is used to set a default compression and
uncompression format. Tapping the [SPACEBAR] toggles
through the various formats available. Supported archive
formats are:
ARC ARJ PAK LZH ZIP ZOO
This default value is used in several places such as
forwarding PKT files not destined for your system, file
attachments for grunged messages and so on. In other words,
when WILDMAIL! needs to compress files, it will use this
compression method anywhere a compression method is not
already defined.
Create extended area info:
Due to the large number of conferences supported by
WILDMAIL! (some 32,760), not all information for each of the
conferences can be stored in memory. This means that
certain conference information will not be included in the
log file.
However, you can instruct WILDMAIL! to save conference
specific information to a temporary file that will be
processed automatically and added to the log file once the
tossing phase is complete.
Setting this option to Y causes WILDMAIL! to create this
information in the log file, otherwise setting it to N will
disable this option.
NOTE Since much of this information is compiled on a
message by message basis, enabling this option
(temporarily storing this to disk) will tend to
slow down the tossing process slightly.
Verify control info in msgs:
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 32
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
Because of the various interpretations of the specifications
for echo style messages, WILDMAIL! offers you the ability to
decide if you want the SEEN-BY: and PATH: line information
checked in the inbound messages.
With this option set to Y (the default setting), WILDMAIL!
will check for the existence of the SEEN-BY: and PATH: lines
before processing the message. If they exist and are
properly formatted, WILDMAIL! will toss them accordingly.
However, if there is something missing, or they're not
included at all, WILDMAIL! will toss them into the Bad
Messages directory with an extension of .MSG for later
review.
With this option set to N, WILDMAIL! will ignore the missing
information and process them blindly. Caution must be
exercised here because certain systems are very finicky
about the proper formatting of messages. Any outbound
messages that WILDMAIL! creates will ALWAYS contain both the
SEEN-BY: and PATH: control lines.
Del archives before tossing:
During the course of processing newly received mail, a fair
amount of disk space is required to hold copies of both the
newly received mail archive and the uncompressed contents of
that file.
With this option set to N, WILDMAIL! will save the original
mail archive until all the .PKT files contained within it
have been successfully tossed. This is commonly used to
ensure the messages are tossed properly before anything gets
deleted.
With this option set to Y, WILDMAIL! immediately deletes the
original mail archive after uncompressing the contents and
then starts the tossing process. This saves on the amount
of disk space required. It should be noted that there is a
point where both the original archive AND the uncompressed
contents will be on the disk at the same time prior to the
original archive being deleted. This can be an important
consideration when you're running low on disk space.
If disk space is of concern, please refer to the "Min disk
space required (Gen)" option via System Information option
settings for additional information.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 33
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
If for some reason the mail is not successfully tossed, the
next time WILDMAIL! runs, it will attempt to uncompress the
mail archive again and restart the process. Since there
could be .PKT files still left over from the original
uncompression process, you need to make sure the compression
format used has the command line parameter to automatically
overwrite the existing .PKT files. Since they're the same
ones anyway, nothing will be lost.
If this is not done the uncompression utility will hang the
system waiting for you to acknowledge the overwrite. Since
this could tie up your BBS for an extended period of time,
this is a very important consideration. Please refer to the
Main Menu, Mail Archive Definitions, Parameters options for
additional information for each specific format.
Forward PKTs not 'TO' you:
When mail is received on your system, the PKT files are
normally addressed to either your primary or AKA address. If
it's not addressed to your system, it must be handled in
either of two ways.
1) Rename the *.PKT file to *.BAD
2) Forward it on to the system its addressed to
This option allows you to select which method should be used
when this situation occurs.
With this option set to a Y, when WILDMAIL! encounters a
.PKT file destined for an address different than your own,
it will pack up the file using the default packer type.
Then it creates a Netmail message with this file attached
and places it in the outbound file area for transmission by
your front end mailer.
With this option set to N, any incoming .PKT files that are
not intentionally destined for your systems primary address
or any of your AKA addresses will be automatically renamed
to *.BAD and no forwarding or processing will take place at
all.
NOTE: If WILDMAIL! renames these files to *.BAD, it
requires manual intervention on your part to try and
determine the reason for this .PKT's arrival.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 34
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
Delete null/empty messages:
When processing echomail, Netmail messages are created that
contain special information in the SUBJECT: line pertaining
to the attached mail archive (the actual echomail messages).
These Netmail messages are used to send mail from one system
to another by using the addresses located in the TO: and
FROM: fields. They normally contain nothing in the body of
the message except possible control information such as the
INTL kludge, TOPT/FMPT lines etc.
Since these messages are of little value once the attached
mail archives (the actual echomail messages) have been
received, you can use this option to have WILDMAIL!
automatically delete these "null" messages.
By definition, a null message is considered to be a Netmail
message with a TO: and FROM: address and an empty message
body except for possible control lines beginning with a Hex
01 character.
Force INTL kludge line:
INTL kludge line information is used when a Netmail message
(with or without attached echomail) is sent between
different zone addresses. Its a method used to ensure that
mail gets sent to the proper address similar to below.
^AINTL 86:250/110 1:161/123
In the above example, the ^A character always preceeds the
INTL keyword because its used to "hide" the line from normal
viewing. The 86:250/110 address refers to the destination
address while the 1:161/123 represents to the originating
address.
With some of the early mailers, when mail was sent within
the same zone, only the <net/node> information was being
used. Now that a lot more networks exist (different zone
numbers) a method is needed to ensure that a message sent to
86:250/110 didn't end up going to 1:250/110. Notice the
same <net/node> but different <zone> number.
Setting this option to N (the recommended setting) will
instruct WILDMAIL! to only insert the INTL line into body of
Netmail messages destined for zones OUTSIDE of your Primary
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 35
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
Zone. For Netmail messages sent within the same zone,
WILDMAIL! will NOT insert the INTL kludge line.
Setting this option to Y, WILDMAIL! will insert the INTL
kludge line in the message body on EVERY Netmail message
whether it is destined for the same zone or not.
NOTE:
For some systems that don't properly handle control line
information, null Netmail messages may not be properly
detected and thus may not get deleted. WILDMAIL! however,
fully conforms to the specifications established for
creating null messages.
Flag Netmail as Kill/Sent:
Since a Netmail message is generated for every echomail
archive (to transfer it from system to system), these
messages can "pile up" in a hurry. WILDMAIL! makes use of
this option to instruct your front end mailer to delete
these messages automatically.
Setting this option to Y causes WILDMAIL! to activate the
KILL/SENT flag setting (on the message) when it is
extracted. This flag will then be interpreted by the front
end mailer to delete the message after it has been
successfully transmitted to its destination address.
Setting this option to N will leave each message intact in
your front end mailers Netmail message folder for manual
disposal. Remember, with this setting, these messages will
pile up in a hurry! You will then be responsible for doing
the cleanup of these old messages.
Use EMS for database needs:
WILDMAIL! has been designed to take advantage of EMS
(expanded memory) for increased speed when accessing the
various databases. This option is used to specify whether
or not WILDMAIL! should take advantage of this type of
memory (if it is available) for use specifically when
accessing the databases.
If no EMS memory is available and this option is set to Y,
WILDMAIL! automatically detects this and simply carries on
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 36
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
normally.
NOTE:
If you're running on a peer-to-peer style network (LAN) and
encounter memory contention problems, disabling this option
could possibly eliminate these memory related errors. If
you're running under a multi-tasker such as DESQview, be
aware that WILDMAIL! will attempt to grab as much free EMS
as is available (at that moment in time). This could be a
problem if any other program on your system makes use of EMS
memory so that when WILDMAIL! executes, there may not be any
memory left over.
The solution to this is to limit the amount of EMS memory in
the window that WILDMAIL! executes in by editing the desired
window (in DESQview) and selecting advanced options by
pressing [F1]. Then setting the "Maximum Expanded Memory
Size (in K):" option to a value acceptable for the
requirements of your system.
Please bear in mind, the more EMS memory you give WILDMAIL!,
the faster it will run (up to a point).
Use XMS/EMS for swap file:
This option is used to establish whether or not WILDMAIL!
should make use of XMS (extended memory) or EMS (expanded
memory) for swapping out when packing/unpacking of the mail
archives or when it calls other programs such as "Program to
run before packing" etc.
When WILDMAIL! runs, it uses up a fair amount of the PC's
base memory. Generally there is insufficient memory left
over to execute the programs necessary for packing and
unpacking of the mail archives.
WILDMAIL! overcomes this limitation by swapping out the
contents of memory it occupies at that time to a temporary
swap file located either in XMS/EMS or to disk (depending on
what's available) thereby freeing up precious base memory to
execute the compression/uncompression utilities.
When this process is complete, WILDMAIL! will swap itself
back into base memory and resume processing of mail.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 37
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
Save Ctl-A FLAG line:
When WILDMAIL! is executed with the SCAN, NETMAIL or MAILOUT
command line parameter(s) to extract new messages, by
default all lines starting with a special Ctl-A character
will be deleted.
Certain offline mail readers such as WCEdit (by Joe Lemoine)
put ^AFLAG line information in the body of the message to
better facilitate netmail message delivery by the front end
mailer. This option allows you to configure WILDMAIL! to
handle this special case situation.
Setting this option to Y instructs WILDMAIL! to leave the
^AFLAG line in the body of the message while stripping out
all remaining lines starting with a Ctrl-A character.
Setting this option to N tells WILDMAIL! to strip out ALL
Ctl-A lines from the message body when extracting messages
from the message base (default setting).
Prohibit message importation:
This option either enables or disables a so called "twit"
filter. This filter is only applied to messages that are
imported into your system and not to messages that are
passed on to other systems.
Setting this option to Y instructs WILDMAIL! to check the
FROM name on the message being imported to a list that
WILDMAIL! keeps. A maximum of 30 names can be added to this
"twit" list.
Since this causes additional overhead when tossing the mail,
(decreased performance because of the additional checking)
this option is normally set to N and is provided primarily
as a feature and not a normal setting.
List of names to exclude:
Pressing [ENTER] on this field displays a list of user names
that WILDMAIL! will use (if the Prohibit message importation
option has been set to Y) to prevent messages from the names
contained here from being added to your message bases.
Up to 30 user names may be added containing no more than 36
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 38
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
characters each. Shown below is a description of the
available options:
[INS] - Create an Exclude Name
Pressing the [INS] key pops up a window allowing you to
enter up to 36 characters of a user name. The normal
editing keys are active.
When the new name has been entered, pressing [F10] saves the
changes while [ESC] aborts and exits.
[DEL] - Delete an Exclude Name
After selecting the desired user name by positioning the
highlight with the Up/Dn arrow keys and pressing the [DEL]
key, a prompt is displayed confirming your request for
deletion. Pressing Y deletes the entry while [ESC] aborts
the process and returns you to the previous screen.
[ENTER] - Edit an Exclude Name
After selecting the desired user name by positioning the
highlight with the Up/Dn arrow keys and pressing the [ENTER]
key, a window is displayed with the user name available for
modification.
The normal edit keys are available such as [BACKSPACE],
[INS] and [CTRL-Y] to clear the entire entry. When the
desired changes are completed, pressing [F10] saves the
changes while pressing [ESC] aborts and returns you to the
list of user names.
Size of duplicates database:
Due to the way echomail is sent from one system to another,
some form of method must be used to make sure messages
already received by your system are not accidently added a
second time or passed on to other systems more than once.
WILDMAIL! makes use of a special database file with a record
containing special MSGID CRC information for EACH message
that has been processed by the system including those
conferences defined as "passthrough". This information is
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 39
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
stored in a file called WMDUPES.DAT which is located in the
\WM40 directory.
This option is used to define the maximum number of records
this special file will hold. For most systems, we suggest
at least 3-5 days worth of messages. For example, if you
typically receive 5,500 messages a day, you would use a
value of anywhere from 16500 to 27500. (3 x 5,500 = 16,500)
Please note however, the larger you set this number, the
larger the file size will be. If you wish to disable
duplicate message checking all together, simply specify a
value of 0 (zero).
Purge entries after nn days:
WILDMAIL! will maintain the duplicates file by date as well
as by number. In other words, if the entry that is in the
duplicates database is older than the number of days
specified here (from todays date) then WILDMAIL! will delete
the entry in the duplicates database.
The maximum value of this field is 30 days and the minimum
value is 1. An optimum value for this field is 7 days.
Save dupes found as MSG file:
With this option set to Y, when WILDMAIL! encounters a
duplicate message, it will toss it into the path specified
via the "Duplicate message path" option as a standard .MSG
formatted message. This option is handy in case you want to
try and track down why you are receiving duplicate messages
on your system.
With this option set to N, WILDMAIL! will simply delete the
duplicate message if it encounters one.
Temporary swap file path:
This option is used to define the <drive:\directory> path
where WILDMAIL! can create its temporary Swap File when it
swaps out to compress/uncompress the mail archives. This
can be placed on any DOS drive that has at least 385K of
free disk space.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 40
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
The preferred location would be a RAM disk because this
would allow for extremely fast swapping.
This option can be used on systems that are short on disk
space on a given drive and you wish to redirect where this
temporary file will be stored.
Save duplicate messages path:
With the Save duplicate message option set to Y, you would
use this option to specify the complete DOS path to where
the duplicate messages are to be stored.
This directory should be unique and NOT shared with any
other program!
Program to run before packing:
This option allows you to specify the DOS path and program
name (or batch file) WILDMAIL! should execute prior to the
mail packing/compressing process starts.
This could be used to execute some sort of cost accounting
system prior to the messages being tossed into your BBS
system (and/or forwarded to your downlink nodes).
If you are going to be executing more than one program, you
should specify a batch file as the program name. Simply
include all the processes you wish to do in the batch file
making sure you DO NOT execute WILDMAIL! a second time.
The batch file should simply terminate once the desired
programs have been executed. This is because WILDMAIL! will
swap itself out of memory and then execute the specified
program name (or batch file). Once the batch file is
finished, WILDMAIL! restores itself into memory and resumes
the packing process.
Normal DOS naming conventions must be strictly adhered to
when defining the path and program name. If this option is
left blank, WILDMAIL! will simply begin the packing process
effectively bypassing this step.
Program to run after unpacking:
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 41
WILDMAIL! v4 MISCELLANEOUS INFORMATION
─────────────────────────────────────────────────────────────────
This option allows you to specify the DOS path and program
name (or batch file) WILDMAIL! should execute after the mail
unpacking process has completed and before WILDMAIL! starts
the tossing process.
If you are going to be executing more than one program, you
should specify a batch file as the program name. Simply
include all the processes you wish to do in the batch file
making sure you DO NOT execute WILDMAIL! a second time.
The batch file should simply terminate once the desired
programs have been executed. This is because WILDMAIL!
will swap itself out of memory and then execute the
specified program name (or batch file). Once the batch file
is finished, WILDMAIL! restores itself into memory and
resumes the tossing process.
This could be used to execute some form of grunged mail
detector on all the PKT files that WILDMAIL! just
uncompressed or even some form of cost accounting system
prior to the messages being processed.
Normal DOS naming conventions must be strictly adhered to
when defining the path and program name. If the option is
left blank, after all the mail has been unpacked, WILDMAIL!
will simply begin the tossing process effectively bypassing
this step.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 42
WILDMAIL! v4 MAIL ARCHIVE DEFINITIONS
─────────────────────────────────────────────────────────────────
MAIL ARCHIVE DEFINITIONS
This option is used to define the actual programs used to
uncompress the inbound mail archives and compress the outbound
mail for the 6 archival formats supported. In addition, command
line parameters are defined to control the operational
characteristics of each of these individual programs.
InUse Flag
This flag is used to indicate whether or not a node address
has been configured to use this uncompression format as
indicated by the presence of a (Θ). When WMCONFIG is exited
with the Save option, it will check only those formats that
have the InUse flag set for the presence of the specified
uncompression program to ensure it exists before allowing
WILDMAIL! to be executed.
If this option contains an asterisk (*) character, it
indicates this compression/uncompression format has been
selected as your Default archive format (as defined from the
Miscellaneous Information menu).
Type
This column indicates the compression format that the
following compression programs and command line parameters
will be associated with. Presently 6 different formats are
supported.
ARC ARJ LZH PAK ZIP ZOO
These individual types are referenced throughout the
configuration program, so the assignment of the program name
and command line parameters are critical.
The compression format of ARC has several programs written
by different authors causing quite a bit of confusion and
compatibility problems. When defining the ARC format, be
sure and carefully select the proper one that best suits
your needs.
Shown below are several popular ARC format compression
programs.
ARCA.COM - Written by Wayne Chin & Vernon Buerg
PKARC.COM - Written by Phil Katz of PKWARE, Inc
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 43
WILDMAIL! v4 MAIL ARCHIVE DEFINITIONS
─────────────────────────────────────────────────────────────────
PKPAK.COM - Written by Phil Katz of PKWARE, Inc.
Something that should be pointed out here is the fact that
the reference to ARC, ARJ, LZH, PAK, ZIP and ZOO is simply
just that, a reference. Because you have the ability to
assign a specific compression and uncompression program to a
type, you have the ability to create a unique type, but one
that uses one of the predefined type names. This however
only applies to outbound mail, or more specifically mail
that is compressed for outbound transmission.
WILDMAIL! does not use the uncompression format selected and
"expect" that mail for a specific node will be in that
format. Instead, it reads the first few bytes of the mail
archive and automatically determines it. Once determined,
it then uses the assigned uncompression program (for that
type) and proceeds to uncompress the archive.
So you will not be able to completely design a new type.
The limitation is the way WILDMAIL! detects the inbound mail
archive. Presently there are no plans on allowing this
option because of the complexity involved in allowing the
user to design a method by which WILDMAIL! should determine
the compression method used on the inbound archive.
Special Format - NONE
A special type called NONE exists when you don't want
WILDMAIL! to create compressed mail archive(s) of the PKT
files it has created. Instead you want these PKT file(s) to
be placed into a special directory.
This special <drive:\directory> is defined via the PKT Path
field found in the Node Information and allows you to
specify where WILDMAIL! should put them. This is useful for
those folks that are using FredMail to process messages in
and out of the InterNet network.
Method
This column references the appropriate compression or
uncompression method to be used with the associated programs
and its command line parameters.
Program
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 44
WILDMAIL! v4 MAIL ARCHIVE DEFINITIONS
─────────────────────────────────────────────────────────────────
This option allows you to specify the actual DOS program
name you want WILDMAIL! to use for the compression or
uncompression process for the selected Type.
When entering the file name, you must be sure to include the
extension. File names ending with anything other than .EXE
or .COM are not allowed and normal DOS naming conventions
are required. Make sure this program resides in the DOS
path so when WILDMAIL! attempts to execute it, it can easily
be found.
Parameters:
This field is used to specify the command line parameters to
be used with the selected compression or uncompression
utility. Typically the parameters are separated by a space
but must strictly follow the requirements of the individual
compression or uncompression program being used. Please
refer to Appendix A for specific command line parameters for
the individual programs or the appropriate documentation
from the utilities author.
Archival Process
When WILDMAIL! attempts to compress an outgoing mail archive, it
creates a temporary batch file with the compression utility file
name followed by its associated command line parameters and then
the output name of the archive file. This batch file is then
executed in a DOS shell. When the compression process is
completed, the temporary batch file is deleted and WILDMAIL!
resumes any remaining processes.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 45
WILDMAIL! v4 ORIGIN LINE MAINTENANCE
─────────────────────────────────────────────────────────────────
ORIGIN LINE MAINTENANCE
This option is used to create, edit, modify and delete origin
line information and specify which origin line is to be used with
what conference or group of conferences. When WILDMAIL! extracts
newly created messages (from your system) and prepares them for
transmission into the various network(s), the selected origin
line will be automatically added to the bottom of each extracted
message.
As the name implies, it identifies where the message originated
(or came) from and serves several purposes. First it allows the
network administrators to track a message to a specific system in
case of duplicates or other various reasons and second, it gives
you a mechanism with which you can advertise your BBS.
Up to 60 characters containing system information like phone
numbers, cute tag (style) lines, BBS name and such may be
included. The actual line length is limited to your Origin
address for the selected conference plus the associated * Origin:
prefix and the required parentheses and spaces enclosing your
address for a maximum length of 78 characters as shown below.
* Origin: xxxxxxxxxxxxxxxxxxxxxxxxxxxx (zone:net/node.point)
|< By WM >|<-- Your information here ->|<-- Added by WM --->|
|<--------------- Maximum of 78 characters ---------------->|
Since this is checked on a conference by conference basis
(because of possible varying Origin Address lengths) the initial
limit is set to 60 characters here. Ultimately, the length is
checked when adding an Origin line to a specific conference. See
Main Menu selection, Conference Area Management for additional
information.
Entering specific node addresses in the Origin line is NOT
necessary because WMCONFIG! automatically puts this information
in based upon an address you've previously defined as the Origin
Address for the selected conference.
Active Keystrokes
Following is a list of available keys you may use in the
selection process of the existing origin lines.
Up/Dn Arrow Keys
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 46
WILDMAIL! v4 ORIGIN LINE MAINTENANCE
─────────────────────────────────────────────────────────────────
You may use the Up/Dn arrow keys to position the highlight bar on
the desired origin line. If more Origin lines exist than will
fit on the screen, holding down the Down arrow key will scroll
through the entire list.
Entering specific node addresses in the Origin line is NOT
REQUIRED! This is because WILDMAIL! will automatically put this
information in based upon an address you've previously defined as
the Origin Address for the selected conference.
[ENTER] - Edit an existing Origin line
After selecting the desired Origin line by using the Up/Dn arrow
keys, pressing the [ENTER] brings up this Origin line in edit
mode. The Left/Right arrow keys and [BACKSPACE] keys are active
for any editing changes. Pressing [ESC] aborts any changes made
while pressing [F10] saves the information.
[DEL] - Delete an Origin Line
After selecting the desired Origin line(s), pressing this key
initiates the deletion process for the selected Origin line(s) by
popping up a window confirming your request. Answering Y to the
prompt (confirming the deletion request) means that WMCONFIG!
will delete the entry from its database.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 47
WILDMAIL! v4 ORIGIN LINE MAINTENANCE
─────────────────────────────────────────────────────────────────
What is an Origin/Tear line combination?
When WILDMAIL! extracts messages from the message base, it
performs several operations the least of which is adding what's
called a "Tear line" and a "Origin line" at the bottom of each
extracted message.
The tear line is identified by the three leading dash marks "---"
and typically indicates the tosser used along with its version
and serial number.
The Origin line is identified by the leading "* Origin:" and
contains a brief description of the system it originated from, a
BBS name and possibly a phone number. This line also contains
the nodes network address enclosed in parentheses, but this
information is usually added automatically as is done by
WILDMAIL!.
Shown below is a sample Tear line/Origin line combination
automatically added to the bottom of an extracted message.
--- WILDMAIL!/WC v4.00
* Origin: WILDMAIL! Support BBS (909) 683-0916 (1:161/123.0)
Please note, since the tear line is automatically inserted by
WILDMAIL!, it's simply shown here for reference only.
What are Tag lines?
Tag lines are entirely different from an Origin line or Tear
line. These are special line(s) added to the bottom of a message
(before WILDMAIL! adds the Origin/Tear line combination) by
callers using special message editors called Offline Mail
Readers.
These offline mail readers permit the callers to download a QWK
style mail packet from your system and read and reply to messages
offline saving online time thus making your BBS more accessable
to the other callers on your board.
These tag lines usual display the offline readers name and serial
number combination and normally contain some form of cute phrase.
They serve no necessary purpose in echo style mail and are merely
additional "baggage" added to the message.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 48
WILDMAIL! v4 2D/3D ADDRESS MANAGEMENT
─────────────────────────────────────────────────────────────────
2D/3D ADDRESS MANAGEMENT
In order to offer a degree of compatibility with some of the
older mailer/tosser configurations still in use today, the Assign
Zone to Net/Node Address option is used to define methods to
"fill in" certain missing information. This situation arises
when mail is received from a 2 dimensional address <net/node> and
processed in todays commonly used 3/4 dimensional formats.
Additionally, the Outbound Zone/AKA Matching section compensates
for certain addressing problems with the BBS netmail package
you're currently using.
Assign Zone to Net/Node Address
This option allows you to specify a certain <zone> number to use
in place of the missing zone number from a 2 dimensional
<net/node> address. This process becomes important when you
receive mail in 2 dimensional format and must forward it on to
other systems using the more traditional 3/4 dimensional
addressing schemes.
This missing <zone> number is what usually distinguishes the
network of which the net/node address is from. So if the zone
information is missing, messages may not be delivered reliably.
Shown below are the available keystrokes.
[INS] - Create a definition
Pressing the [INS] key pops up a window allowing you to enter the
resulting <zone:net/node.point> address. So lets say you want to
map zone 100 to an address of 400/53, you would specify the
definition as follows:
<zone> 100
<net> 400
<node> 53
<point> 0
The resulting address address would now be 100:400/53.0. Normal
editing keys are active and when the definition is complete,
pressing [F10] saves the settings while [ESC] aborts and exits.
[DEL] - Delete a definition
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 49
WILDMAIL! v4 2D/3D ADDRESS MANAGEMENT
─────────────────────────────────────────────────────────────────
After selecting the desired definition by positioning the
highlight with the Up/Dn arrow keys and pressing the [DEL] key, a
prompt is displayed confirming your request for deletion.
Pressing Y deletes the entry while [ESC] aborts the process and
returns you to the previous screen.
[ENTER] - Edit a definition
After selecting the desired definition by positioning the
highlight with the Up/Dn arrow keys and pressing the [ENTER] key,
a window is displayed with the definition available for
modification.
When the desired changes are completed, pressing [F10] saves them
while pressing [ESC] aborts and returns you to the previous
screen.
Outbound Zone/AKA Matching
This option allows you to specify which one of your AKA addresses
should be used as the from address when netmail messages created
on your system are extracted and sent on their way.
The operation of this option works like this, on the AKA's you
wish you use, you would associate up to 10 different destination
<zone> number(s). When WILDMAIL! extracts a newly entered
netmail message from the message base, it will check the messages
destination <zone> number, match it to the Outbound Zone/AKA
Matching definition for that <zone> and use that AKA address as
the "from" address of the message.
NOTE: When using this option, you should note that your
primary address is not available for mapping. This is
because by default your primary address will always be
used in case a Zone Mapping definition is not found.
As previously mentioned, you may specify up to 10 different
<zone> numbers for each of your AKA addresses and you may not
duplicate any of <zone> definitions within the same AKA address
or with any of the other AKA addresses.
If you don't have any AKA addresses defined, the displayed screen
will reflect this and your primary address will be used as the
from address on all the outbound netmail messages.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 50
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
BBS SPECIFIC OPTIONS
When setting up WILDMAIL!, you'll need to configure specific
information relative to your BBS type. The following fields in
this section are used to define items like Netmail conference
number/name, DOS paths and so on.
Netmail conference number:
This option is used to specify the conference number defined
in your BBS configuration program that will be your NETMAIL
conference. For WILDCAT! systems, normally this conference
has been flagged with a Mail type of "Netmail".
This number is used so WILDMAIL! will know what conference
to toss messages into that have special
<zone:net/node.point> addressing information in them
(netmail messages).
NOTE for WILDCAT! systems:
Presently, only one conference in WILDCAT! may be configured
as a Netmail conference. This conference is unique in that
when you enter a message in a conference flagged as Netmail,
you are asked what node address this message is to be sent
to prior to asking for the persons name to address it to.
The "Netmail" flag differs from the standard "Normal" type
in that it uses a special node addressing scheme for proper
transmission on to the destination system. The remainder of
the echomail style conferences as well as your local message
areas must be set to "Normal".
Pressing [F2] on this option brings up a complete list of
conferences defined within WILDCAT!. You may view the
status of this flag by positioning the highlight bar upon
the desired conference and pressing [ENTER]. This will
extract the same information as configured when running
MAKEWILD with the only difference being you may not modify
any of these fields.
Do NOT use 0 as the Netmail conference because some BBS's
may use this conference for system generated messages such
as Password Failure, Phone Number verification failure and
so on.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 51
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
Pre-process echomail:
With this option set to Y, you to instruct WILDMAIL! to go
into what's called "Forward-Only" mode. This process means
all mail destined for your systems message bases will be put
into PKT files and placed into the "Pre-processing path"
directory. Nothing goes into your message bases at this
point.
Then at a more convenient time, you could execute WILDMAIL!
a second time with just the PRETOSS command line parameter
and only mail from the "Pre-processing" directory will be
tossed into your BBS's message bases.
This is an extremely powerful option for those systems that
hub mail for downlink nodes. With this option enabled,
WILDMAIL! will process mail at an incredibly fast rate
thereby significantly reducing mail processing time due to
avoiding the message bases entirely and ultimately making
your BBS more available to your callers.
With this option set to N, the "Pre-processing path" field
becomes unavailable. Also, the PRETOSS command line
parameter no longer has any meaning and is simply ignored by
WILDMAIL!. All mail will be processed normally, meaning mail
will be tossed into your BBS system message bases and to
your downlink node addresses simultaneously.
Note about command line parameters
With this option set to Y, in order to get mail into your
BBS's message bases, you must execute WILDMAIL! a minimum of
two different times. Once to forward the mail and again to
toss into your message bases.
Since this is the case, your first execution would normally
be something similar to:
WM SCAN TOSS NETMAIL AREAMGR
All functions associated with the individual command line
parameters would be handled normally with the exception of
TOSS. This parameter would then mean all messages normally
destined for your message bases would handled differently
(see above). This is important because setting the "Pre-
process echomail" option Y only effects the TOSS parameters
execution.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 52
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
Why use the Pre-processing option?
For some reason, mail always seems to come during prime time
calling hours. Since you normally don't want your system
tied up (for too long) processing mail during this busy
period, you could set up your system to execute WILDMAIL!
with just the TOSS parameter. Then, later on when your
system is not very busy (maybe in the early morning hours),
you can run WILDMAIL with the PRETOSS parameter. This has
the effect of reducing offline time while mail is being
tossed thereby making more of your system available during
peak calling times.
It should be pointed out though, that since you will be
processing the same mail twice, overall, it might take more
time to toss the entire amount of mail. But the advantage
is that this extra time can be scheduled when your system is
not very busy.
Update quick statistics:
This option allows you to configure WILDMAIL! to update the
Quick Stats found on the "Waiting for Calls" screen.
With this option set to Y, when WILDMAIL! completes adding
messages to the WILDCAT! message bases(s), the number of new
messages added will be reflected in the Quick Stats on the
Waiting for Calls screen.
Setting this option to N, (the default) no update will be
performed.
NOTE:
Every effort has been taken to ensure accuracy of this
number, but there is a situation where the number of "new"
messages may not always match up to what was added to the
"Total Messages" on your system.
This situation centers around the fact that if the
maximumnumber of messages per conference is exceeded
(forcing WILDMAIL! to purge a message before adding a new
one - if so configured) the value here will be "off" by each
purged message.
Little can be done to correct this situation because the
number added to the Quick Statistics reflects the actual
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 53
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
number of "new" messages WILDMAIL! tossed to the message
base(s).
Notify user of new Netmail:
Your BBS offers callers to your system the feature of being
notified that mail is waiting for them when they first
logon. WILDMAIL! can maintain this feature by reading the
TO: field of each message tossed and check the user database
to see if that person exists and if so, sets a flag in their
user record. The next time they logon, your BBS will inform
them they have new mail waiting in the netmail conference.
Because of the additional searching of the user database for
each new message tossed, this option can add a slight amount
of processing time to the mail tossing process. Normally
though, this is insignificant as the databases within your
BBS are extremely fast.
Force netmail to private:
This option allows you to control the setting of the Private
flag on inbound Netmail messages.
Setting this option Y will cause all inbound Netmail
messages to be forced to Private regardless of its previous
setting.
With this option set to N, WILDMAIL! will use the current
setting of the private flag on the actual Netmail message
when determining whether or not the message will be flagged
as Private in the message base.
Maintain message levels:
NOTE: THIS OPTION ONLY APPLIES TO WILDCAT! v3+ SYSTEMS.
WILDCAT! v4+ SYSTEMS DO *NOT* USE THIS OPTION. IT
HAS NO BEARING ON WILDCAT! v4+ SYSTEMS.
Within MAKEWILD, you normally define the maximum number of
messages allowed per conference to prohibit your message
bases from growing too large. This option is used to tell
WILDMAIL! whether or not to maintain these maximums as
specified.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 54
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
With this option set to Y, WILDMAIL! will purge the oldest
message to make room for the one about to be added if the
number of messages in that conference was already at its
defined limit. This is a "one for one" message purge/toss.
This can increase the amount of time to process each message
if the conference is already at its established maximum but
it does offer automatic message count management.
With this option set to N, messages will be added to the
message bases without maintaining the limits and WILL cause
the database file sizes to continue to grow. You must then
use the command line parameter PURGE when executing
WILDMAIL! (possibly in an event) to properly maintain the
message levels.
When this option is set to N, the primary disadvantage is
that if the conference is at its limit of say 750, then when
WILDMAIL! tosses 200 new messages, the database size now
grows to 950 messages. When the command line parameter
PURGE is used with WILDMAIL!, it will purge the 200 oldest
messages in the conference leaving 200 blank slots while
still occupying 200 blank message slots worth of valuable
disk space.
The only way to effectively reduce the message base back
down to its true file size is to run WCREPAIR. On systems
carrying a large amount of conferences, care must be taken
when disabling this option, otherwise you can end up wasting
a SIGNIFICANT amount of disk space.
Send status msgs to SysOp:
This option determines whether or not WILDMAIL! should
create a message to the SysOp if it encounters any problems
tossing mail. Error messages might be caused by
difficulties accessing the various databases or by corrupted
message conferences and so on.
Status messages are actually NETMAIL messages that will be
created and sent to the SysOp using the primary address that
you have configured in the System Information screen as both
the FROM and TO addresses of the message.
With this option set to N, no status messages will be
generated and error messages will simply be placed in the
WM.LOG/ERROR.LOG file(s).
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 55
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
Netmail message flags:
When WILDMAIL! extracts a Netmail message, you can specify
what flags should be used via this option.
Displayed are the currently selected flags. Pressing
[ENTER] on this field pops up a screen where you can toggle
the appropriate flags to use.
The most commonly used flags are:
LOCAL KILL/SENT PRIVATE
Because some of these flags dictate the transmission urgency
of this message, you should be careful in selecting flags
such as CRASH and IMMEDIATE.
Honor crash flag on msg:
This option is used to tell WILDMAIL! whether or not to
allow Netmail messages entered within your BBS and flagged
as CRASH to in fact go out as CRASH mail.
The term CRASH (or CRASH MAIL) is used to indicate that the
associated message needs to be transmitted immediately
regardless of the time of day or night. This is important
to understand because prime time calling charges may be
incurred depending on the time of day the message is
extracted.
If this option is set to Y, the "Valid CRASHMAIL users:"
option is made available and is used to specify which user
names are allowed to send CRASH mail.
If this option is set to N, the "Valid CRASHMAIL users:"
option is not allowed and any Netmail messages entered in
your BBS flagged as CRASH will automatically have their
status changed to NORMAL. This could be used to prevent
ANYONE from sending out a Netmail message (including the
SysOp) flagged as CRASH from within your BBS.
Valid crash mail users:
The information presented here is a list of user names (read
from your BBS user database) that are allowed to send
NETMAIL messages from your system to another flagged as
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 56
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
CRASH. Selected user names are indicated by a (Θ) to the
left of their name.
In your BBS, when a user enters in a new message or sends a
reply in the Netmail conference, WILDCAT! prompts them with
a message similar to:
Crash mail? [Y]
If they answer Y to this, WILDMAIL! will only accept the
CRASH flag if the FROM: user name on the message has been
previously selected via this option.
If the user name has not been tagged, WILDMAIL!
automatically resets the CRASH flag back to NORMAL. Your
system will then send this message out with the regular mail
instead of immediately. This option offers you a degree of
control as to who has access to using CRASH status for
netmail messages.
Selecting the desired user name by positioning the highlight
bar with the Up/Dn arrow keys and tapping the [SPACEBAR]
will automatically update the user database within your BBS.
Extract Netmail sent TO: an AKA:
This option allows you to override the default setting where
on a scan of the netmail conference (using either a MAILOUT
or NETMAIL parameter) WILDMAIL! will not extract any Netmail
messages addressed to either your Primary address or any of
your AKA addresses. Normally this would prevent WILDMAIL!
from extracting a message from your system just to turn
around and try and send it back to your system.
However, certain third party gating programs when they
process gated Netmail messages to the Internet, (they are
typically addressed to UUCP) require the FROM address to be
one of your primary or AKA addresses.
Setting this option to N (the default) will instruct
WILDMAIL! to ignore any messages addressed to any of your
system addresses and not extract them.
Setting this option to Y instructs WILDMAIL! to not verify
the FROM address of the Netmail message and extract it
anyway. For obvious reasons, caution should be taken when
using this setting.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 57
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
Delete netmail after scan:
This option is used to have WILDMAIL! automatically flag
each Netmail message extracted as deleted (indicated by a
flashing (D) next to the message number). Because of the
way your BBS manages deleted messages, they will remain on
your system until the SysOp uses the [P]urge option found on
the SysOp Menu.
This option could be useful in preventing Netmail messages
from building up on your system. However, caution must be
used here to prevent important messages you wish to keep
from being automatically deleted.
Normally, this option is set to N.
Allow netmail file attaches:
If there is a file attached to a netmail message and this
option is set to a Y, then WILDMAIL! will create a netmail
file attach message with the full path and filename of the
attached file. The file will be copied from the BBS file
attach path to the file attach path specified in the option
"File attach path".
If this option is set to N, then WILDMAIL! will not honor
any file attachments meaning any netmail messages that have
files attached to them will only have the message contents
sent out and not the attached file.
Import netmail as .MSG:
When a Netmail message is received, WILDMAIL! by default
creates a Netmail message (in the .MSG format) and places it
in the defined Netmail directory of your front end mailer.
It also creates another one and places it in your BBS
Netmail conference.
By setting this option to N, when a Netmail message is
received, WILDMAIL! will toss the Netmail message into the
BBS Netmail conference ONLY! This is often used to avoid
having two sets of the same Netmail message (one in your BBS
and one in your front end mailers Netmail message folder).
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 58
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
If you use any third party utilities on your system that
requires Netmail messages to be found in the mailers Netmail
directory, then this option must be set to Y.
NOTE
If you use the AreaRequest option in WILDMAIL!, then this
option MUST be set to Y.
Due to the fact that WILDMAIL! scans the netmail directory
looking for messages that are addressed specially for
AreaRequest functions, if you do not enable this option then
these messages will never be found, thus never processed.
Database lock count:
WILDMAIL! has been designed to work in a true multi-user
environment sharing databases with other users/processes
simultaneously. When a message is added to a conference,
the database file needs to be locked for that brief moment
it is being saved. Once the message has been saved, the
lock is immediately removed making the database fully
accessible again.
Because the locking and unlocking of the message database
causes an incredible amount of overhead (thereby increasing
the time required to toss mail), this option is used to lock
the database for a specified number of messages before
unlocking it again. This has the desirable effect of
reducing overhead and causing a significant speed increase.
Allowable numbers can range from 1 through 255 with a
default value being 100. With a value of 1, this means the
database will be locked and then unlocked for each and every
message added. This is by far the slowest way to execute
WILDMAIL! and is not recommended except in very rare
circumstances.
A value of 100 tells WILDMAIL! to keep the database locked
until the conference being tossed into changes or the
maximum 100 message limit has been reached. A value of 5
indicates the database will be locked for the next 5
messages (if they were all to go into the same conference
database) and then unlocked.
Caution must be exercised when using this option especially
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 59
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
on slower PC's because in a multi-line environment, your BBS
will attempt to save information to a database for a period
of 60 seconds before a fatal error will occur. This process
is indicated by the "Lock Retry ##" being displayed in the
upper RH corner of the screen. The slower the PC, the
longer it can take to save messages and thereby possibly
exceeding your BBS's 60 second limit.
On faster machines, a value of 255 is normally sufficient,
but this is on a case by case basis and warrants close
monitoring to ensure the time limits on locking the database
files aren't exceeded. If a fatal error does occur, it
indicates the number specified should be lowered (maybe 100
or so) and executed/monitored again. Remember the higher
the number, the longer the database will be locked and the
faster messages can be tossed.
It should be pointed out that the BBS's "Lock Retry ##"
displayed in the upper RH corner of the screen on a node (or
task in DESQview) is a simple indication that a database is
temporarily locked by another node or another utility while
information is being saved to the file. This is not an
error and can occur from time to time in a multi-line
environment.
The real error occurs when the file can't be accessed in the
allotted amount of time. If this does occur, it will be
necessary to recheck your settings here.
WILDCAT! home path:
When WILDMAIL! executes, it needs to read the contents of
the WILDCAT! configuration files and depending on the
configuration, it makes use of certain information like
maximum lines per message. Because WILDMAIL! uses these
files, it needs to know the exact <drive:\directory> where
they are located. A typical path might be:
C:\WC40
This directory is commonly referred to as the WILDCAT! home
directory.
Pre-processing path:
WILDMAIL! supports the ability to toss mail destined for
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 60
WILDMAIL! v4 BBS SPECIFIC OPTIONS
─────────────────────────────────────────────────────────────────
your system into a temporary packet(s) instead of your BBS
database for fast processing of mail to your downlink node
addresses.
The path specified here is where WILDMAIL! will create these
temporary PKTs should the "Pre-process echomail" field be
toggled to Y. A typical path definition might be:
C:\WM40\PRETOSS
This path MUST be different than your inbound directory for
this function to work properly.
File attach path:
WILDMAIL! now supports your BBSs ability to attach files to
echomail and netmail messages. This option works in
conjunction with the Extract file attaches option for the
appropriate conference area definition.
When WILDMAIL! extracts a message from a conference with an
attached file, it will process that message normally and
make a copy of the attached file and place it into the
<drive:\directory> path specified here. A typical path
might be:
C:\WM40\ATTACH
Normal DOS naming conventions must be strictly adhered to
when defining the drive and subdirectory.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 61
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
NODE MANAGEMENT
This option is used to specify the operating characteristics of
each node address that will be transferring mail with your
system. Parameters like compression method, conference areas,
passwords for various functions and so on are defined here.
[INS] - Add a new Node Address
Pressing the [INS] key presents you with a screen whereby you can
define the necessary parameters for each node on your system.
[DEL] - Delete a Node Address
After selecting the desired Node Address by using the Up/Dn arrow
keys, pressing the [DEL] key presents you with a prompt to
confirm your request to delete the selected Node. Pressing Y
initiates that action while pressing [ESC] cancels and returns
you to the previous screen.
[ENTER] - Edit a Node Address
After selecting the desired Node address by using the PgUp/PgDn
arrow keys, pressing the [ENTER] key brings up this node in edit
mode whereby you can make the necessary changes.
[ALT-F] - Finding a Node Address
You can look for a specific node address by pressing the [ALT-F]
keys simultaneously. A pop-up window will appear where you will
be able to enter the address of the system you want to search
for.
You can search on <zone> only, you can search on <zone>:<net>, or
you can search on <zone>:<net>/<node>. WMCONFIG! will position
the cursor at the 1st occurence that meets your search criteria.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 62
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
NODE SPECIFIC SETTINGS
Following is a complete breakdown of the available fields and
their uses when configuring the node addresses for your system.
All available keystrokes for a given field are displayed on the
status bar located at the bottom of the screen. Depending on a
previous fields value, certain options may or may not be
available. This is due to the configuration needs/rules for each
option.
Node address:
The address defined here is a complete <zone:net/node.point>
address of the currently selected node. Pressing [ENTER] on
this field pops up another window allowing you to modify the
current values.
Pressing [F10] saves the changes and returns you to the Edit
Node Definition window and resumes edit mode.
Net membership:
This option allows you to define what networks this node
address will have access to. In order for a node to gain
access to a particular conference, it must be a member of
that conferences network.
You will notice a value in parentheses next to this field.
This is the number of networks that this node belongs to.
If this value is (0) then this node does not have any
network affiliations and must join a network before any
conferences may be selected.
Pressing [ENTER] on this field will bring up a list of the
network memberships this node currently belongs to. From
there you can select/deselect networks as necessary.
Active node:
This option controls the active status of this node
definition.
Setting this option Y informs WILDMAIL! that it should
forward mail to and receive mail from this node address.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 63
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
Likewise, setting this option to N will temporarily
interrupt mail delivery to this node so the next time
WILDMAIL! processes mail, it will NOT forward it on to them.
It should be noted that while the N option is handy, mail is
not "stored up" for this node address, so for the duration
this flag is set to N, all mail (for all the selected
conferences) destined for this node will be lost.
Selected confs:
This option allows you to specify all the conferences that
this node should be receiving. This setting is crucial in
ensuring that your downlink (and uplink) nodes get their
mail.
The total number of conferences that have been selected for
this node are displayed in parentheses to the right of this
field. A value of (0) means that there are no conferences
selected.
Pressing [ENTER] on this field will bring up a list of all
the conferences that you have defined on your system.
Conferences can then be selected/de-selected from this list
as needed.
CRITICAL SETTING
This option is one of the most commonly overlooked settings
and is by far the most crucial in your initial setup.
The reason this option is so crucial is that since nodes
must know what conferences they should get and conferences
should know what nodes to forward mail to, there must be
some form of association/link between the two which
indicates what each other should be connected to.
For example, a conference may have 3 node addresses selected
for it. That means that under each one of those node
definitions there should be a selection dot next to that
conference name. The opposite is true as well. When
displaying the conference definition under "Selected nodes",
those same three nodes should have selection dots next to
them.
This selection is used when WILDMAIL! performs the actual
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 64
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
forwarding process and is used to build whats called a
"forward to list" of nodes that should receive a copy of
messages from a particular conference. If there is no
selection dot, then there is no association and
consequently, no mail will be forwarded to that node for
that conference.
UNIVERSAL SELECTION METHOD
WMCONFIG! has been designed to allow you to select either
nodes or conferences from each others (nodes/conferences)
configuration screen. For example, if you wanted to select
the downlink nodes for a given conference, you would use the
option (on the Conference Definitions screen) "Selected
nodes" and place a selection dot next to the appropriate
one.
If you wanted to select conferences for a given node, when
editing that nodes definition, you would use the "Selected
Confs" option and place a selection dot next to the
appropriate one.
Since the selection process is universal, there no need to
select both "sides" of the association. In earlier versions
of WILDMAIL!, you could only select conferences from a nodes
definition and not the other way around. This restriction
has now been removed.
SysOp name:
This field is used to store the name of the SysOp that the
node definition reflects. The name used here shows up in
many different locations within WMCONFIG! and is useful when
identifying a particular system.
Simply enter in the name of the SysOp (up to 36 characters)
in First Name, Last Name format for this node address.
BBS Name:
This field is used to store the name of the BBS that is
associated with the node address.
This name is purely for informational purposes but it helps
to identify the node address and SysOp name.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 65
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
Voice #:
This field is used to store the voice phone number of the
SysOp.
It's purely for informational purposes and is provided here
so that the number would be handy in case you need to call
him/her.
BBS #:
This field is used to store the BBS phone number of the
SysOp and Node number.
It is used purely for informational purposes and is not used
by WILDMAIL!.
Maximum messages PKT:
When WILDMAIL! processes outbound mail, it creates special
data files containing messages for other systems with the
extension of .PKT. These files are the temporary storage
medium used when mail is sent from system to system.
This option is used to define a limit on how many messages
are added to a .PKT file before WILDMAIL! stops and creates
a new one. You should try and keep this number to a
reasonable value because if for whatever reason a mail
packet (.PKT file) becomes corrupted, mail will be lost.
The larger the packet, the larger the loss.
Since the average size of a message is somewhere between
1,100 to 1,600 bytes in size, typical values ranging from
200 to 300 messages are appropriate here.
Maximum uncompress bytes:
When WILDMAIL! compresses mail for your downlink systems, it
will build a list of PKT files for each node and proceeds to
build an outbound "archive" file. This file is then
attached to a netmail message addressed to that system.
Instead of having one "huge" archive file for the downlink
node to uncompress at one time, this option allows you to
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 66
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
specify how many combined PKT "bytes" should be considered
the maximum allowed before forcing WILDMAIL! to create an
additional archive file. In other words, lets say there are
10 PKT files and each of them is 500K in size. Combined,
thats a total size of 5Mb (10 x 500k).
If you set this value to 5000000 (5Mb), then only 1 archive
will be created. However if you set this option to 3000000
(3Mb), then WILDMAIL! will divide up PKT files and create
two archives. The first one containing 6 PKT files and the
second containing the remaining 4.
This option is most often useful for your downlink nodes
that are running low on disk space. The most common problem
is if you create one huge archive for them, their system
will need to have the size of the original archive PLUS the
uncompressed size of the enclosed PKT files in free disk
space. If they don't, their system will run out of disk
space causing serious problems.
Setting this value to 0 will instruct WILDMAIL! to ignore
any size restrictions.
PKT file format:
This option is used to select which format WILDMAIL! should
use when creating mail for this node address.
Within FidoNet style networks, there are presently three
specific formats of .PKT files (the data files that contain
the echomail messages) that can be created by the various
mail tossers. All 3 formats are available for outbound
mail.
The recommended setting for this option is Type 2.2. This
setting allows full <zone> and <point> support. If the node
address is a point then you must select either the Type 2.2
or Type 2 Plus options.
Pressing the [SPACEBAR] toggles these different .PKT file
formats. Shown below is a breakdown of the individual
settings.
Type 2
This format relies on 3 dimensional addressing scheme in the
<zone:net/node> format. WMCONFIG! will not allow you to
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 67
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
select this format if a <point> number was entered in the
address definition. You must select a Type 2.2 or Type 2
Plus format for a point.
Type 2.2
This format is by far the most commonly used and makes use
of the 4 dimensional addressing format of
<zone:net/node.point>.
Type 2 Plus
This is also a widely used format and fully supports 5
dimensional addressing format of
<zone:net/node.point@domain> format.
NOTE
On inbound mail, WILDMAIL! automatically detects the
presence of all three formats.
Inbound PKT password:
All three types of the PKT file formats that WILDMAIL! has
been designed to support the ability to store passwords in
the header portion of the PKT file.
This option allows you to specify what password should be
"expected" when you receive PKT files from this particular
node address. Up to 8 characters are allowed, upper and
lower case characters are insignificant.
Passwords are not a required item, but are provided here
should your configuration needs dictate.
NOTE
Something that should be noted here is that WILDMAIL! will
always read the PKT password and uses it to match the nodes
PKT password definition. Even if you have nothing defined
for the nodes PKT password, if there is some form of garbage
in the PKT headers password, then password failure will
occur.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 68
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
PASSWORD ERRORS
When WILDMAIL! encounters a password on a PKT file that
doesn't match, an entry into the log file, the PKT file gets
renamed using the ".BAD" extension and the file is left in
your inbound directory for later review.
The password that is read from the PKT file is also stored
in the log file, so in order to resolve this problem, you
should check the log file and then the appropriate node
definition and make the necessary changes.
SESSION PASSWORDS
There is a known situation that can occur and centers around
Netmail messages generated by certain versions of FrontDoor
and InterMail front end mailers.
Apparently when those mailers generate the .PKT file for
Netmail messages, they will force the use of the "session
level" password as the password on the PKT file.
When this happens, if you have specified a different Inbound
PKT password to use than the session level password between
your two systems, (which is normally the case) a PKT
password failure will occur when processing these PKT files.
However, the normal echomail PKT files will be processed
properly.
You should note, this problem is centered ENTIRELY around
the front end mailers and there inability to define a PKT
password!
Consequently, there is only ONE solution to this, you MUST
change your Inbound PKT password to the same as your front
end mailers session level password for that nodes address.
In essence, this defeats the purpose of PKT passwords, but
until this situation gets resolved, there little else you
can do.
Outbound PKT password:
All three types of the PKT file formats that WILDMAIL! has
been designed to support the ability to store passwords in
the header portion of the PKT file.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 69
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
This option allows you to specify what password should be
put into outbound PKT files for this particular node
address. Up to 8 characters are allowed.
Before specifing a password here, you should ask your
downlink node what password he/she has set their system up
to use, otherwise they could potentially end up losing mail
until the password issue has been resolved.
Flags on netmail msg:
When WILDMAIL! compresses the outbound mail for this node,
it creates a Netmail message that will have the echomail
"attached" to it. This option allows you to specify the
flags that should be used when generating this Netmail
message.
Displayed are the currently selected flags. Pressing
[ENTER] on this field pops up a screen whereby you can
toggle the appropriate flags to use.
The most commonly used flags are:
LOCAL KILL/SENT PRIVATE
Because some of these flags dictate the transmission urgency
of this message, you should be careful in selecting flags
such as CRASH and IMMEDIATE.
Uncompressed PKT path:
This option is only available if the option "Compression
format" has been set to NONE, meaning that the outbound mail
is in uncompressed format. This option is used to specify
where WILDMAIL! should copy these files to. For WILDUUCP!
systems this might be:
C:\WILDUUCP\GATE\
For non-WILDUUCP! systems, you should specify the directory
where your gating software expects to find new mail. If you
are really creative here, in unique configurations, this
could be the inbound directory of a "reserved" node address.
Normal DOS naming conventions must be strictly adhered to
when specifing the path.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 70
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
Use standard naming:
When processing outbound mail, WILDMAIL! uses the selected
compression format for that node to packup the outbound mail
archives. The naming of these archives is important to
maintain proper processing sequence so mail tossing will be
done on a first in, first out basis.
Typically, the first 8 characters of the file name indicates
the address difference in hexidecimal between the source and
destination systems while the file name extension is used to
indicate the day the mail archive was created on.
Standard naming conventions for these file extensions are as
follows:
Mon = .MOx Wed = .WEx Fri = .FRx Sun = .SUx
Tue = .TUx Thu = .THx Sat = .SAx
In the above example, x is used to indicate the sequential
number of the archive. This value can range from 0 to Z for
a total of 36 possible archives in your outbound directory
at any one time.
This value is automatically determined when checks are made
on the outbound directory for the highest numbered archive
for that address. WILDMAIL! does not maintain a "running"
daily total of archives created. If it did so, on very busy
systems you could very easily exceed 36 archives.
Setting this option to Y uses this archive naming scheme and
is the preferred method.
When this option is set to N, all outbound mail archives for
this node will have the file extension of .MO0. This means
all new mail for that node will be added to that single
existing archive file without creating any new archives.
With a setting of N, this could make for a rather large
single mail archive should that node not pick up their mail
for a day or two. This could be used for any international
nodes that you feed mail to. Rather than transferring a
bunch of archives you would only transfer one thus speeding
up transmission time.
NOTE
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 71
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
With this option set to N on multi-line systems, you should
be aware that if a node is picking up mail that WILDMAIL! is
attempting to add a PKT file to, either of the two processes
will in all likelihood fail.
Compression format:
Since echomail messages are commonly compressed prior to
transmission, this option is used to define the compression
format to be used for this node. Pressing the [SPACEBAR]
toggles through the available compression formats.
Available formats are:
ARC ARJ LZH PAK ZIP ZOO NONE
This option works in conjunction with the Main Menu option,
Mail Archive Definitions where you define the program names
and command line parameters used for the various compression
formats. Once the format has been selected, pressing
[ENTER], PgUp/Dn or Cursor Up/Dn accepts the value and
allows you to continue editing.
Fredmail and Mail Gating via WILDUUCP!
If the selected mail archive type is set to NONE, outbound
mail is created but not compressed. Because this option is
primarily designed for those systems that gate mail from one
system type to another such as Fredmail or our own gating
product called WILDUUCP!, a path needs to be specified to
tell WILDMAIL! where these uncompressed PKT files should be
placed.
Because the mail type of NONE has special conditions
associated with it, if this type is selected, the PKT Path
option will be available.
Kill orphaned messages:
This option allows you to specify whether or not WILDMAIL!
should delete messages received from this node if there
isn't an conference defined in your configuration.
The most common use for this option is for those nodes pick
up their mail from satellite delivery systems. You receive
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 72
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
the entire feed, but only wish to process a selected group
of conferences.
If this option is set to Y, any messages that come from this
node address and there isn't a corresponding conference
definition, the messages will simply be deleted. This
prevents the "orphaned" messages from building up in your
bad echo directory.
If this option is set to N, any messages that come from this
node that don't have a conference definition will be saved
in the bad messages directory as a .MSG file.
Use tiny SEEN-BY: lines:
╓───────────────────────────────────────────╖
║ PLEASE READ THE FOLLOWING VERY CAREFULLY! ║
╙───────────────────────────────────────────╜
This option is used to have WILDMAIL! automatically strip
ALL the SEEN-BY: lines from all the mail destined for this
node address and replace it with only your systems address
and the node address you are editing. Because of the danger
of creating duplicate messages within a network, this option
would normally be set to N.
In an extremely rare situation of sending mail between
zones, it is possible for two nodes to have identical
addresses with the only difference being the zone number.
Because zone numbers are not used in SEEN-BY: lines, one of
these node addresses would receive the mail and the other
wouldn't. This option would be used to ensure that the node
address you're editing would receive its mail regardless if
its address was already in the SEEN-BY: lines.
If this option is set to Y, all the SEEN-BY: lines from each
message is removed and is replaced with the defined AKA from
your system and the node address you are editing. In other
words, if your systems node address was 86:250/100 and this
node's address was 86:250/120, the contents of the SEEN-BY:
line would read as follows:
SEEN-BY: 250/100 250/120
All previous SEEN-BY: information for each and every message
WILL BE LOST! If this option is set to Y, the end result
will mean that the nodes address you're editing MUST NOT
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 73
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
FORWARD ANY MAIL RECEIVED FROM YOUR SYSTEM to any other
address or duplicate messages will be introduced into the
network!
The use of this option requires a complete understanding of
how echomail works because if this option is set to Y and
without proper implementation, the possibility of creating
message duplication loops is dangerously high! Caution is
advised.
If you don't fully understand the PATH:/SEEN-BY: lines or
don't know what to do, simply set this option to N.
Node activation date:
This field has been provided for your use exclusively.
Presently, WILDMAIL! does not use this field.
Typically you would use this date field to reflect the date
on which the node had become active on your system. When
making changes, you should use the 'mm/dd/yy' format.
Set inactive upon expiration:
This option is very handy for those systems that process a
large volume of mail for their downlink systems. You would
normally use this mechanism to keep track of nodes that have
paid their echomail "dues" by manually updating the nodes
expiration date. You may also record the payment date and
amount in the appropriate fields.
By specifing an expiration date, WILDMAIL! will check
against the current date and if the current date is greater,
then WILDMAIL! will automatically deactivate the node by
toggling the "Active" flag to N.
As part of the deactivation process, WILDMAIL! will send a
deactivation message to the downlink node as well as create
a message to the SysOp informing him/her of the
deactivation.
You may also specify an "notification" interval where
WILDMAIL! will send off a message to the downlink node
informing them that they will be deactivated if the
expiration date is not updated accordingly.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 74
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
Setting this option to Y unprotects the remaining fields
that are associated with this option and enables it
accordingly. Setting this option to N disables the ability
to have WILDMAIL! automatically deactivate nodes.
Expiration date:
This option allows you to specify the date on which
WILDMAIL! will deactivate the node by toggling the "Active"
field to N. Using the format of 'mm/dd/yy', you would
normally use a date of some point time in the future.
For example, if your downlink node pays you on a monthly
basis, you would typically take the date of their payment
and add 30 days to it. Then if you haven't received
payment, or specifically, if the expiration date has not
been updated and it's greater than the date WILDMAIL! runs,
the node will be automatically deactivated.
Send expiration message:
During the course of checking expiration dates, WILDMAIL!
has the ability to send a message to the downlink node
informing him/her that their node will be deactivated if the
expiration date of their account is not updated properly.
Setting this option to N means WILDMAIL! will not send any
messages at all. Setting this option to Y means that
WILDMAIL! will send a message at the appropriate interval as
dictated by the selection dots on the associated period via
the "Message frequency" option, i.e.:
(Θ) 3 days
( ) 7 days
(Θ) 15 days
In the above example, a message would be sent out 3 days
prior to deactivation as well as 15 days prior to. The
selectable frequency of these messages may be 3, 7, 15, 30,
45 and 60 days prior to expiration.
Message frequency:
Presented here is a list of intervals that you would like
WILDMAIL! to send off a status message to the node informing
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 75
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
them of the upcoming expiration date.
Currently there are 6 possible periods you can choose from
(3, 7, 15, 30, 45 and 60 day periods) and you may toggle any
combination thereof. To select or deselect, position the
highlight bar on the desired interval and tap the
[SPACEBAR].
You may also edit an interval's information by highlighting
it followed by pressing the [ENTER] key.
Message sent:
This field is used by WILDMAIL! when determining if the
message for this interval has already been sent.
A setting of Y means that WILDMAIL! has already sent
the message, while a setting of N indicates that
WILDMAIL! will send it when interval period dictates.
Date sent:
This field reflects the date on which the message had
been sent. You may modify this using the 'mm/dd/yy'
format.
Send status message to SysOp:
Whenever WILDMAIL! generates an account status message to
your downlink nodes, you may also have a copy of it sent to
you at the same time.
Setting this option to Y tells WILDMAIL! to send you (the
name defined via System Information - SysOp Name) while
setting this option to N disables this ability.
There is one exception to this option, whenever WILDMAIL!
actually "deactivates" a node, a message will always be sent
to SysOp (you) informing of the deactivation.
Last payment recvd:
Presently, this field is available for your use exclusively.
WILDMAIL! does not use this field for any reason.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 76
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
Normally you would use this to keep track of the last date
you received some form of payment from this node.
Payment amount:
Presently, this field is available for your use exclusively.
WILDMAIL! does not use this field for any reason.
Normally you would use this to keep track of the last
payment amount received from this node.
Allow AreaRequest functions:
This option dictates whether WILDMAIL! will act upon receipt
of specially formatted Netmail message(s) that arrive on
your system from this node definition.
Toggling this option to N will instruct WILDMAIL! to ignore
these specially formatted Netmail messages and it will also
prohibit any access to the remainder of the fields on this
screen.
With this field set to Y, all the remaining fields on the
screen will be made available for your configuration
requirements and instructs WILDMAIL! to process those
specially formatted Netmail messages.
Allow conference querying (-Q):
Conference querying is a function within AreaRequest whereby
a node may place the -Q parameter on the subject line of a
specially formatted Netmail message (following their
password) and receive a response message informing them of
all the conferences they currently have selected.
Setting this option to Y enables this ability while setting
it to N disables it. This is useful often times for the
downlink node(s) who wish to verify the conferences they are
currently receiving from your system.
Exclude during notifications:
WILDMAIL! has the ability to automatically generate Netmail
messages to your downlink/uplink node addresses containing a
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 77
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
list of all the conferences they're currently receiving from
your system.
This option allows you to specify whether or not this node
address should be excluded from this "mass mailing" when
WILDMAIL! is executed with the NOTIFY command line
parameter.
Normally you would toggle your uplinks address to a Y to
exclude them from receiving these notification messages.
Auto-add for new conferences:
WILDMAIL! has the ability to turn on conferences for your
node addresses that would like to have new conferences added
automatically to their system whenever a new conference is
added automatically to the conferences database.
For example, if node 1:161/123 sends a request to turn on a
conference called FOR-SALE and it doesn't exist in your
configuration but does exist in the Master List database,
WILDMAIL! would add the area to the conferences database
(retrieving information from the Master List database) and
send a request off to your uplink requesting this conference
be turned on.
WILDMAIL! would then go through the nodes database and check
each nodes setting for this "auto-add" option and if the
node is a member of the associated network from which the
area came from and this option is set to Y, the new
conference will automatically be activated (selected) for
them.
If this option is set to N, this functionality is disabled.
Send help on bad request:
If one of your nodes sends an AreaRequest message that
contains a command that WILDMAIL! does not recognize or is
invalid, this option is used to toggle whether or not the
node receives the help file that outlines the proper usage
of AreaRequest.
If this field is set to Y and if an invalid request or bad
command was received, WILDMAIL! will send a copy of the file
that was specified in the AreaRequest General Settings -
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 78
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
"AreaRequest help file" option.
With this option set to N, no help file is sent.
With either setting, a response message will always be sent
back to the node detailing what was invalid about the
request.
Send text message on notify:
When WILDMAIL! is executed with a command line parameter
called NOTIFY, it produces a report to each node indicating
all the conferences they currently have selected and various
other information.
This option allows you to define on a node by node basis
whether or not the contents of the NOTIFY.TXT file defined
via the Main Menu option, AreaRequest General Settings
should be included into the NOTIFY netmail message.
Setting this option to Y instructs WILDMAIL! to copy the
contents of the defined notify file into the body of the
netmail messages that get generated.
Setting this option to N, disables this ability.
Response message origin address:
When AreaRequest generates a response message to this node,
this option allows you to specify what the origin address
should be.
Pressing [ENTER] on this field presents you with a list of
your AKA addresses. You may select the desired address by
positioning the highlight bar on the desired address
followed by pressing [ENTER].
If you wish you use your primary address instead, after
pressing [ENTER], simply press the [F10] key.
Flags on response message:
When a node sends an AreaRequest message to turn on/off
conferences, get status etc, WILDMAIL! will always generate
a response informing them of the activity that took place
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 79
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
for that request. This option allows you to define what
Netmail message flags should be used with the response
message that gets sent back to them.
Displayed on the screen are the currently selected flags.
Pressing [ENTER] on this field pops up a screen where you
can toggle the appropriate flags to use.
The most commonly used flags are:
LOCAL KILL/SENT PRIVATE
Because some of these flags dictate the transmission urgency
of this message, you should be careful in selecting flags
such as CRASH and IMMEDIATE.
AreaRequest password:
AreaRequest has been designed to automate a requesting nodes
activation and de-activation of conference areas by using
specially formatted Netmail messages.
In order to limit access to this very powerful feature, a
password may be assigned to the node address you're editing
so anytime this node requests a conference change, the
correct password must be required before any changes can
take place.
Up to 8 character passwords can be defined. To maintain
proper security, make sure no one has access to this
password except the SysOp of this node address.
There is however a limitation to this options capability
within your BBS. Conferences can be activated/de-activated
by downstream nodes, but a new conference can not be
automatically created within your BBS (on your system).
This must be done manually by using your BBS configuration
software. WILDMAIL! will automatically add all new areas as
"passthru", so if you want any of these new areas to be
picked up by your BBS then you will need to define the
conference in your BBS manually and then change the area
configuration within WMCONFIG! to reflect the fact that the
area is now not a "passthru" and tosses directly into your
BBS.
The reasoning behind this is two-fold. First of all, your
entire BBS system must be brought down to make configuration
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 80
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
changes and two, there would have to be some sort of method
to automatically place it somewhere on the system disk and
then allow users access to this new conference. Since this
just doesn't exist, there is no way to automatically create
conferences within your BBS at this time.
Please don't confuse an AreaRequest style request for a new
conference with trying to create a brand new conference
within your BBS software. These are two distinct and very
different options.
AreaRequest security:
AreaRequest has been designed to automate a requesting nodes
activation and de-activation of conference areas by using
specially formatted Netmail messages.
In order to use this, each Node must be assigned a security
access level and, if necessary, any additional sub-levels of
access via the AreaRequest Flags option. This value (and
corresponding flags) is used to match up the requesting
nodes security level to that of the conference(s) they are
trying to activate.
If their security level is equal to or greater than the
conferences security level and any corresponding flags
match, they may activate/de-activate it. So, let's say
you're carrying adult echos with a security level set to
200. In order for a node picking up mail from you to have
the ability to activate/de-activate them, their security
level must be equal to or greater than the level of the
conference desired.
For example:
Conf Conference Description Sec Level
──── ─────────────────────────── ─────────
10 Adult Fantasies 200
11 Adult Parties 200
12 Adult Romances 200
20 General Messages 100
21 Technical Support 150
In the above list of conferences, if a node was assigned a
AreaRequest security level of 100, they would only have the
ability to activate/de-activate conference 20. Let's say
another node has been defined with a security level of 150,
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 81
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
it would only have access to conferences 20 and 21 but not
conferences 10, 11 and 12.
For a node to have access to conferences 10, 11 and 12, they
must have a security level of 200 or greater in order to
activate/de-activate them. Remember, the corresponding
AreaRequest security level is defined for each conference
via the Main Menu option, Conference Area Management after
selecting the desired conference.
When establishing a security level here, a little
forethought is required because you must already know what
each of your conference security levels are set to and who
should have access to what. Once the desired level is
known, simply enter the value in the highlighted field.
AreaRequest flags:
AreaRequest flags are used as a secondary level security
protection mechanism designed to limit which node addresses
have access to the various different conferences carried on
your system.
Pressing [ENTER] brings up another screen allowing you to
select which flags this node should have associated with it.
It should be pointed out here that you won't be able to
"create" flags with this option (that's done from the Main
Menu option, AreaRequest General Settings) but rather select
any of the previously defined flags.
Extended % commands:
Besides the regular AreaRequest command set, there are
additional AreaRequest commands called the extended set.
These commands are easily distinguished by the percent sign
at the beginning of the command name as indicated below.
%COMPRESSION %PASSWORD %ACTIVE
%PASSIVE %-ALL %HELP
%RESCAN %LIST %QUERY
%UNLINKED %PKTPSWDIN %PKTPSWDOUT
%PKTFORMAT %UNCOMPBYTES %MSGSPERPKT
These commands are completely configurable allowing you to
specify which commands will be available on a node by node
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 82
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
basis.
[SPACEBAR] - Select/Deselect
After highlighting the desired option by using the Up/Dn
arrow keys, tapping the [SPACEBAR] will either toggle an
option active or inactive.
If an option is active then a (Θ) will appear next to the
option. An inactive option has a ( ) next to it. You can
select all options by hitting [CTRL-ENTER].
[F10] - Save
Press the [F10] function key to save your selections and to
return to the Node definition screen. If you press [ESC]
instead of the [F10] key, you will be prompted to abort your
changes if any had been made. From there you can either hit
the Y key to abort the changes or hit the [ESC] key to
return to the options and press [F10] to save from there.
Each of the extended commands is described below.
%COMPRESSION This command will change the compression
format for the node.
%PASSWORD This command will change the AreaRequest
password for the node.
%ACTIVE This command will make the node active if it
was previously toggled as inactive.
%PASSIVE This command will make the node passive or
inactive thereby disabling the node from
receiving any conferences.
%-ALL This command will disconnect the node from
all conferences that it was receiving.
%HELP This command will allow the node to request
the help file.
%RESCAN This command will allow the node to rescan
the area that is specified on the same line
as the %RESCAN command.
%LIST This command will allow the node to obtain a
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 83
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
list of all conferences and networks that the
node has access to.
%QUERY This command will allow the node to query
what conferences and networks that node is
connected to.
%UNLINKED This command will allow the node to request a
list of all conferences and networks they
have access to which are not currently
selected.
%PKTPSWDIN This command will allow the node to change
the "Inbound PKT password" field.
%PKTPSWDOUT This command will allow the node to change
the "Outbound PKT password" field.
%PKTFORMAT This command will allow the node to change
the setting of the "PKT file format" option
determining the PKT format of mail sent to
their system.
%UNCOMPBYTES This command will allow the node to change
the value of the "Maximum uncompress bytes"
field.
%MSGSPERPKT This command will allow the node to change
the value of the "Maximum messages PKT"
field.
Mailing Addr:
This field is used to store the 1st line of the address for
the node defined. This is purely an informational field and
is not used at this time.
Comments:
This field is used as a "scratch pad" to possibly leave
yourself a note about this node address. There are 2 lines
making up the comment field.
Up to 35 characters may be entered on each line.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 84
WILDMAIL! v4 NODE MANAGEMENT
─────────────────────────────────────────────────────────────────
City:
This field is used to store the city of the node address.
It is currently used for informational purposes.
State:
This field is used to store the state code of the node
address. It is currently used for informational purposes.
Zip:
This field is used to store the zip code of the node
address. It is currently used for informational purposes.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 85
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
CONFERENCE AREA MANAGEMENT
This option allows you to define what message area goes with each
conference on your system by allowing you to add, edit and delete
message conference areas. Each conference area must be defined
before a node address may obtain access to it.
[INS] - Add a new Conference
Pressing the [INS] key presents you with a template of settings
available. Further down in the documentation are detailed
explanations the use of each field.
[DEL] - Delete a Conference
After selecting the desired Conference by using the Up/Dn arrow
keys, pressing the [DEL] key presents you with a prompt to
confirm your request to delete the selected Node. Pressing Y
initiates that action. Pressing [ESC] cancels and returns you to
the previous screen.
[ENTER] - Edit a Conference
After selecting the desired Conference by using the Up/Dn arrow
keys, pressing the [ENTER] key brings up this Conference
definition in edit mode.
[F9] - Filter Networks
Pressing the [F9] key displays a list of all the networks that
are currently defined on your system. You can filter the display
of conferences by selecting only the network you want displayed
followed by pressing the [ENTER] key. The display will now only
reflect those conferences that are associated with that network.
To remove/disable the network filtering, simply press the [F9]
key followed by pressing the [ESC] key and all of the conferences
from all of the networks will be displayed.
[F5] - Sort Conferences
By default, the conferences are always sorted by Area Name. You
may toggle this sort order (Area Name/Conference Number) by
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 86
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
pressing the [F5] key.
[ALT-F] - Find Conference Area/Conference Number
Depending on what the current sort order is (see above), this
option allows you to specify a search criteria to locate a
particular conference within the database.
Pressing the [ALT-F] key presents you with a screen whereby you
may define the appropriate search specification (Area Name or
Conference Number). Once the search parameters have been
defined, you may start the search by pressing the [ENTER] key.
The highlight bar will then be positioned on either the exact
match or closest match of the appropriate conference.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 87
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
CONFERENCE SPECIFIC SETTINGS
Following is a complete breakdown of the available fields and
their uses when configuring the conferences for your system. All
available keystrokes for a given field are displayed on the
status bar located at the bottom of the screen. Depending on a
previous fields value, certain options may or may not be
available. This is due to the configuration needs/rules for each
option.
FTSC Area name:
This option is used to specify what area name (hidden within
each message) is to be matched up with a specific conference
message base on your BBS. Pressing [ENTER] brings up the
Master List database of defined areas along with their
associated networks.
You may select the desired conference by positioning the
highlight bar on the desired name and pressing [ENTER] to
select it. WMCONFIG! then copies the area name, long
description and network name into the appropriate fields and
returns you back in edit mode.
WHAT IS AN AREA NAME?
When you receive Fidonet style mail, messages from various
different conferences are usually bundled together. In
order to organize which message goes to what conference,
there is a special keyword located within the header of each
message called "AREA:". The name immediately following this
definition is the actual conference area name this message
belongs in.
For example, if you use a file viewer utility (such as Vern
Buergs LIST program) to view the header portion of a message
and see the definition:
AREA:WILDCAT
In this case, the above indicates the message came from the
WILDCAT conference and would be tossed into a conference
with an area name definition of WILDCAT.
When WILDMAIL! performs its tossing process, it extracts the
area information from each message and then searches the
conferences database in WMCONFIG! to find a match. This
conference definition then points to the appropriate
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 88
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
conference (message base) in the BBS and WILDMAIL! will then
proceed to add the message to that particular message base.
Active conference:
This option allows you to control the active status of the
conference.
Setting this option to N will effectively tell WILDMAIL!
that this conference doesn't exist while setting this option
to Y activates its use. This option is useful in
controlling mail flow on a global basis for this particular
area.
It should be noted that while this option is handy, mail is
not "stored up" for this area, unless you have the "Kill
orphan messages" flag set to N for the node address that you
receive this conference from. If this is the case then
these messages will get tossed to the bad messages
directory.
Selected nodes:
This option allows you to specify all the node addresses
that should be receiving this conference. This setting is
crucial in ensuring that your downlink (and uplink) nodes
get their mail.
The total number of nodes that currently receive this
conference is displayed in parentheses to the right of this
field. A value of (0) means that there are no nodes
attached to this conference.
Pressing [ENTER] on this field will bring up a list of all
the node addresses that you have defined on your system.
Nodes can then be selected/de-selected from this list as
needed.
CRITICAL SETTING
This option is one of the most commonly overlooked settings
and is by far the most crucial in your initial setup.
The reason this option is so crucial is that since nodes
must know what conferences they should get and conferences
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 89
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
should know what nodes to forward mail to, there must be
some form of association/link between the two which
indicates what each other should be connected to.
For example, a conference may have 3 node addresses selected
for it. That means that under each one of those node
definitions there should be a selection dot next to that
conference name. The opposite is true as well. When
displaying the conference definition under "Selected nodes",
those same three nodes should have selection dots next to
them.
This selection is used when WILDMAIL! performs the actual
forwarding process and is used to build whats called a
"forward to list" of nodes that should receive a copy of
messages from a particular conference. If there is no
selection dot, then there is no association and
consequently, no mail will be forwarded to that node for
that conference.
UNIVERSAL SELECTION METHOD
WMCONFIG! has been designed to allow you to select either
nodes or conferences from each others configuration screen.
For example, if you wanted to select the downlink nodes for
a given conference, you would use the option (on the
Conference Definitions screen) "Selected nodes" and place a
selection dot next to the appropriate one.
If you wanted to select conferences for a given node, when
editing that nodes definition, you would use the "Selected
Confs" option and place a selection dot next to the
appropriate one.
Since the selection process is universal, there is no need
to select both "sides" of the association. In earlier
versions of WILDMAIL!, you could only select conferences
from a nodes definition and not the other way around. This
restriction has now been removed.
Passthrough area:
A conference is considered to be "passthrough" when none of
the messages for the conference are to be added to your own
BBS systems message base(s). This means that all mail will
be forwarded for this conference onto your downlink/uplink
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 90
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
node address(es) without tossing them into your system.
If you want messages from this conference to be tossed into
your systems message base, then you should answer N to this
option. Otherwise toggling this option to Y will instruct
WILDMAIL! not to look for a corresponding message base (on
your BBS system) and to simply forward this mail onto the
designated downlink/uplink node address(es).
BBS conference:
This option allows you to choose which conference in your
BBS configuration these messages will be tossed in to and
scanned out of your BBS.
Pressing [F2] on this field will pop up another screen which
will show all the conference numbers and their respective
descriptions and then you will be able to scroll through
this list and choose which conference these messages are to
be tossed in to.
If the "Passthrough area" option is set to Y, then this
field is darkened out and no value is set. WILDMAIL! will
ignore this field if this is a passthrough area.
Ctrl line processing:
This option allows you to toggle whether the control line
information that is normally in the body of all netmail and
echomail messages is hidden, shown or deleted when the
messages are added to your BBS message files.
Pressing the [SPACEBAR] will toggle through the three
options, which are:
HIDDEN DISPLAY DELETE
The suggested setting is HIDDEN. If you need to debug an
area for some reason you can set this to DISPLAY which would
allow you to see the SEEN-BY and PATH lines which would
normally be hidden. This would allow you to track down
problems such as dupe loops. If you do not care about these
control lines and are an end node then you can set this
option to DELETE which would save over 50% of message line
space (on small messages, the bulk of the message body is
taken up by these control lines).
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 91
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
Restrict importation:
This option allows you to control mail received on your
system and prevents node addresses that are not "selected"
to process mail to/from this conference from importing this
conferences mail into your system.
Setting this option to Y instructs WILDMAIL! to check the
actual address on the PKT file that this conferences mail
came from before tossing the messages into your message
bases as well as forwarding it on to your downlink nodes.
If mail is received from a node that is NOT selected for
this conference and this option is set to Y, then an entry
is made in the log file stating this is a SECURE AREA and
that the message will not be processed.
Normally this option is set to N, but in cases where other
systems may "dump" mail into your system, this is a
protection mechanism that is designed to prevent WILDMAIL!
from forwarding on this "dumped" mail.
COMMON CONFIGURATION PROBLEM
In situations where you "know" the node should be sending
and receiving mail for a given conference is correct, by far
the most common mistake made here is when you've enabled
this option, the node you're receiving the mail from is
sending you replies (or new mail) back using a different
address. Chances are this is just one of their AKA addresses
and can easily be fixed.
To solve this problem, all you need to do is check the log
file and find out what "FROM" address the PKT file came from
and check the node address that you "should" be receiving
mail from and you can make the determination of which
address is incorrect.
Usually its a simply fix on your downlink nodes system, or
you can change your definition for that node in the nodes
database. Either way, this will in all likelihood solve
this problem.
Use domain in MSGID:
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 92
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
This option is used to extend duplicate message detection by
appending the specified domain name for this conferences
network to the end of the origin address within the MSGID
line. This MSGID line is automatically added to each new
message extracted (generated) from your system.
With this option set to Y, this networks domain name is
appended to the end of the "from" address by a leading @
character on the MSGID line similar to:
^AMSGID 1:161/123.0@fidonet.org 65284011
In the above example, the domain name from this conferences
network is "fidonet.org".
Setting this option to N instructs WILDMAIL! to use a line
similar to below:
^AMSGID 1:161/123.0 65284011
If you compare the two lines, you'll notice the
"@fidonet.org" portion has been omitted.
Origin address:
WILDMAIL! allows you to carry message conferences from
different networks on your system so there needs to be a
method by which you can define an origin address for each
conference on your system. This address will be appended to
the bottom of all the new messages created on your system
that get sent out into the network.
Normally you are assigned a unique node address for each
network you are in, so you should use this option to specify
your node address for the network this conference is in.
For example, if your network address for MagNet is
100:910/13 and the conference you are editing is from
MagNet, you would use the address of 100:910/13 as your
Origin address.
Pressing [ENTER] on this option presents you with a list of
predefined AKA Addresses you entered via the Main Menu
option System Information. Using the Up/Dn arrow keys, you
can select which address you want to be used for this
conferences origin address.
If the desired address doesn't appear in this window, you
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 93
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
must return to the Main Menu, select System Information,
option AKA Addresses and enter in the desired network
address. Then you may return here and select/use the new
AKA Address.
Origin line:
This option is used to select which Origin line is to be
used with this conference. Pressing [ENTER] on this option
will present you with a list of origin lines to choose from.
Simply use the Up/Dn arrow keys to highlight the desired
Origin line and press [F10] to accept it.
From this screen, you may also add/edit and delete origin
lines before selecting the desired one by pressing any of
the keys listed below.
[ENTER] - Edit an origin line
[INS] - Add a new Origin line
[DEL] - Delete a new Origin line
When you're done editing/adding an Origin line, you may
complete the process by pressing [F10].
Extract private messages:
This option is used to specify whether or not PRIVATE
messages entered on your system are to be extracted and
forwarded on into the network.
If you select N, any messages entered into this conference
which were flagged as PRIVATE (by the individual entering
the message) will NOT be extracted and thus will never leave
your system. Caution should be exercised here.
Please note, some networks DO NOT permit PRIVATE echomail
messages, so you should be careful when selecting which
conferences in which network(s) allow such a option. If you
have any questions, you should contact the node you're
picking up mail from and ask them.
Extract file attaches:
With this option toggled to Y, when WILDMAIL! performs a
scan of the conference and encounters an attached file, it
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 94
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
will automatically extract it and create a Netmail message
with the attached file to all the downlink nodes assigned to
this conference.
The extracted file will be placed in a separate directory
defined from the Main Menu, System Information, BBS Specific
Option, File attach path.
Notify users of new mail:
Your BBS offers callers to your system the feature of being
notified that mail is waiting for them when they first
logon. WILDMAIL! can maintain this feature by reading the
TO: field of each message tossed and check the user database
to see if that person exists and if so, sets a flag in their
user record. The next time they logon, your BBS will inform
them they have new mail waiting in the selected conference.
Because of the additional searching of the user database for
each new message tossed, this option can add a slight amount
of processing time to the mail tossing process. Normally
though, this is insignificant as the databases within your
BBS are extremely fast.
For those conferences that are flagged as ALIAS, WILDMAIL!
also checks the users Alias name and flags that individuals
user record accordingly.
Add nodes to SEEN-BY:'s:
Outside of the Origin Address specified for this conference,
this option is used to select which additional address(es)
you wish to have WILDMAIL! add to the existing SEEN-BY:
lines of the messages leaving this conference.
Pressing [ENTER] on this field displays a screen whereby you
can define these additional addresses to be automatically
added. Displayed is a list of addresses that have been
defined to be added to the SEEN-BY: lines (if any). The
following keys are available:
[INS] - Add a New Address
[DEL] - Delete an Existing Address
[ENTER] - Edit an Address
Once the address has been defined, you may press [F10] to
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 95
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
save the definition.
NOTE
This option is rarely ever used. Only in cases where
duplicates are being introduced into a network should this
option be considered. And then only for as long as it takes
to find the source of the problem.
Grunged message processing:
This option allows you to determine the disposition of
messages that are not fully compliant with the
specifications for FTSC type mail. This non-compliance is
commonly referred to as a "grunged" message and typically
occurs due to improperly configured mail tossers,
transmission errors, etc.
Due to various degrees of interpretation of the FTSC
specifications, WILDMAIL! will only flag messages as grunged
when the degree of corruption/non-compliance is so great
that something needs to be done. Consequently this is only
a minimal grunge detection system designed to primarily
protect WILDMAIL!'s own reliability.
The messages flagged by WILDMAIL! as grunged are only done
so after some rather detailed checking is done on so called
"non-disputable" areas of compliance. In other words,
failure can only result when a exact specification has been
defined for this area of non-compliance.
BOUNCING GRUNGED MESSAGES
This capability is an extremely powerful one because it
allows you to compress up a copy of the grunged message
using the defined "Default packer" method and send it back
to wherever it came from along with another message
explaining the problem with the grunged message.
This is a completely automatic process saving you precious
time and effort thereby reducing the likelihood of receiving
more grunged messages from that system. While this option
may not always be welcome in certain situations, it does
provide you with a mechanism to manage the grunged messages
received on your system.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 96
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
Depending on the way you have this configured, the netmail
messages generated by WILDMAIL! (along with the attached
grunged message) could be transmitted at your expense so
careful understanding of this option will prove benefical.
FILE ATTACH VERSES MESSAGE COPY
As previously mentioned, WILDMAIL! will compress a copy of
the grunged message and attach it to a netmail message and
send it on to its defined destination. A number of people
have suggested using a "copy only" method of sending the
contents of the grunged message in the body of the return
Netmail message because most systems will route mail of this
type. This routing prevents systems from incurring costs
from returning grunged messages.
In an effort to minimize subjective interpretation of FTSC
specifications and to provide conclusive proof of the
message actually being grunged, an exact copy of the
original provides the conclusive evidence. Presently there
isn't a facility to use the "copy in the netmail message
body" method. If enough systems request this option, it
could be added in a future release.
ADDRESS DETERMINATION
WILDMAIL! has several ways of determining the originating
address of the grunged message. Listed below are these
processes along with the order in which they will be
performed.
1) Attempt to find a MSGID: control line in the
message and use the address found there. <100%
reliable>
2) Attempt to read the address from the "* Origin:"
line of the grunged message. <50% reliable>
3) If steps #1 and #2 fail, use the address specified
in WMCONFIG! under Alternate To: address.
Depending on the degree of corruption in the message, steps
#1 and #2 may not always find a valid address. If one is
found, an entry is made in the log file indicating the
validity, otherwise, a different entry is made in the log
using the alternative address.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 97
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
This alternate address provides a place to always send
messages to and typically reflects the node where you pick
up your mail from (where you got the message from in the
first place). It's up to you to decide what this
alternative address should be.
SELECTION METHOD
WILDMAIL! gives you you several choices on how to handle
these grunged messages. Tapping the [SPACEBAR] on this
option toggles through the available choices as shown below.
Delete Message
This setting is the most commonly one used and instructs
WILDMAIL! to simply ignore the message, make an entry into
the log file and continue on to the next message without
saving the current one. No bouncing of messages will be
performed.
Save Message
This option will create a file using a incrementing
numbering system as the file name along with the .GMD
extention and will place this file into your defined "Bad
Echo/Messages" directory.
The message is actual in what's referred to as a .MSG format
and thus can be read by various third party utilities by
simply renaming the file name. These messages may build up
if you don't monitor them from time to time. No bouncing of
messages will be performed.
Bounce-Save Message
This option allows you to send a copy of the grunged message
back to its origin (see above for address explanation) and
to save a copy of that message in the Bad Echo directory.
Bounce-Kill Message
This option is identical to "Bounce-Save Message" with the
only exception being that the grunged message is deleted
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 98
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
from your system.
Determine To: address from msg:
In determining the address where WILDMAIL! should send this
message back to, this option allows you to define whether or
not WILDMAIL! should search the message body for the address
or force it to use the Alternate To: address definition.
Again, this is used in determining where to send this
grunged message back to.
Setting this option to Y instructs WILDMAIL! to look in the
message for the To: address while setting this option to N
tells WILDMAIL! to simply use the defined Alternate To:
address instead.
Alternate To: address:
This option allows you to define where WILDMAIL! should send
grunged messages back to. The exact use of this option is
determined by the "Determine To: address from msg" option.
Pressing [ENTER] on this field pops up a window where you
can define the appropriate portions of the address.
Origin address on message:
This option allows you to specify the AKA address to use as
the From: address of the netmail message. Normally you
would use your AKA address appropriate for this conferences
network.
Pressing [ENTER] on this field pops up a list of your
previously defined AKAs allowing you to select the
appropriate one.
Flags on message:
When WILDMAIL! creates a Netmail message that has the
grunged message attached, this option allows you to define
which flags should be used.
Displayed are flags currently selected. Pressing [ENTER] on
this field pops up a screen where you can toggle the
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 99
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
appropriate flags to use.
The most commonly used flags are:
LOCAL KILL/SENT PRIVATE
Because some of these flags dictate the transmission urgency
of this message, you should be careful in selecting flags
such as CRASH and IMMEDIATE.
Originating node:
This option indicates whether or not your system is the main
point where mail (for this network) originates from. This
means if you're the originating node, then you don't pickup
mail for this conference from anyone. Shown below is such an
example.
(your address) -> Originating Node
/ | \
Node#1 Node#2 Node#3
In this case, you would set this option to Y. In the above
example, this means that since there are only a total of 4
people in this network, you are considered the main
distribution point or the Originating Node and thus don't
forward mail to anyone on your uplink side.
If you're not the originating node, then you must be picking
up the mail for this conference from another node. Shown
below is such an example.
Originating Node
|
(your hub) Uplink/Feed Address
/ | \
Node#1 Node#2 Node#3
In this case, you might be one of the Node#'s specified
above.
Source differs from Network:
There are times when certain conferences within a network do
not originate at the same place. For instance, if you
receive a local network and there are 3 areas in the
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 100
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
network, and the area names are AREA1, AREA2 and AREA3.
AREA1 and AREA2 both originate from one node and AREA3
originates from a different node. This option gives you the
ability to distinguish which area(s) differ and to put in
their correct destination addresses so that when you need to
turn the area off, the AreaRequest message goes to the
correct address.
If this option is set to a Y then the field following this
becomes enterable and you need to enter the correct address
where deactivation requests are sent to.
Setting this field to N darkens the "Deactivation address"
and all deactivation requests will default to the address as
it is defined in the Destination address" field on the
Network Management screen.
Deactivation address:
If the "Source differs from Network" option is set to Y,
this field becomes active and you need to set the correct
deactivation address for this conference.
Pressing [ENTER] on this field will pop up a screen which
will show all the active node addresses that you have
defined in your system. Position the highlight bar using
the Up/Dn arrow keys or the PgUp/PgDn keys on the correct
deactivation address and press [ENTER] to accept the
address.
AreaRequest security:
AreaRequest has been designed to automate a requesting nodes
activation and de-activation of conference areas by using
specially formatted Netmail messages.
In order to use this, each Node must be assigned a security
access level and if necessary any additional sub-levels of
access via the AreaRequest Flags option. This value (and
corresponding flags) is used to match up the requesting
nodes security level to that of the conference they are
trying to activate.
If their security level is equal to or greater than this
conferences security level and any corresponding flags
match, they may activate/de-activate it. So, let's say
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 101
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
you're carrying adult echos with a security level set to
200, in order for a node picking up mail from you to have
the ability to activate/de-activate them, their security
level must be equal to or greater than the level of the
conference desired.
For example:
Conf Conference Description Sec Level
──── ─────────────────────────── ─────────
10 Adult Fantasies 20
11 Adult Parties 200
12 Adult Romances 200
20 General Messages 100
21 Technical Support 150
In the above list of conferences, if a node was assigned a
AreaRequest security level of 100, they would only have the
ability to activate/de-activate conference 20. Let's say
another node has been defined with a security level of 150,
it would only have access to conferences 20 and 21 but not
conferences 10, 11 and 12.
For a node to have access to conferences 10, 11 and 12, they
must have a security level of 200 or greater in order to
activate/de-activate them. Remember, the corresponding
AreaRequest security level is defined for each conference
via the Main Menu option, Conference Area Management after
selecting the desired conference.
When establishing a security level here, a little
forethought is required because you must already know what
each of your conferences security levels are set to and who
should have access to what. Once the desired level is
known, simply enter the value in the highlighted field.
AreaRequest flags:
This option allows you to select flags that should be
"attached" to this nodes definition. These flags are used
when implementing security with regards to conferences.
Flags are not a necessary requirement, but are provided
should your needs dictate their usage.
Basically the usage is quite simple, in order for a "pass"
condition to occur, when a node sends a AreaRequest to
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 102
WILDMAIL! v4 CONFERENCE AREA MANAGEMENT
─────────────────────────────────────────────────────────────────
activate a conference, if there is a flag defined on that
conference, the requested node must have that exact same
flag before it can be turned on. If there are multiple
flags, then the node must also have "at least" those very
same flags before gaining access.
Pressing [ENTER] on this field pops up a window whereby you
can select the appropriate flags.
NOTE
There is an additional security "level" test before a final
"pass" condition can occur, but it's being excluded here for
example purposes only.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 103
WILDMAIL! v4 AREAREQUEST MANAGER
─────────────────────────────────────────────────────────────────
AREAREQUEST MANAGER
This feature is used to allow automatic activation and
deactivation of conferences by your downlink nodes without any
need for intervention on your part. This is extremely useful
because it frees you up from having to manually add/delete these
conference requests.
If your system carries sensitive conferences, for example adult
related material you want to restrict access to anyone under 18
years old, or you would just like to restrict the automation of
certain conferences, WILDMAIL! allows you to specify 2 different
levels of security access. These access levels are described
below.
SECURITY LEVELS
Security levels are exactly what the name implies, levels. This
is used with both conferences and node addresses to form a
mechanism by which a node must meet a certain requirement before
it can obtain the desired conference(s).
Basically it works like this. A node address may have access to
any conference on your system that has a security level assigned
to it EQUAL TO or LESS THAN its assigned security level. If the
value of the requesting nodes security level is LESS THAN the
desired conference, WILDMAIL! will disallow the request.
So let's say you're carrying adult echos with a security level
set to 200, in order for a node picking up mail from you to them,
their security level must be equal to or greater than the level
of the conference desired. For example:
Conf Conference Description Sec Level
──── ─────────────────────────── ─────────
10 Adult Fantasies 200
11 Adult Parties 200
12 Adult Romances 200
20 General Messages 100
21 Technical Support 150
In the above list of conferences, if a node was assigned a
AreaRequest security level of 100, they would only have the
ability to activate/de-activate conference 20. Let's say another
node has been defined with a security level of 150, it would only
have access to conferences 20 and 21 but not conferences 10, 11
and 12. For a node to have access to conferences 10, 11 and 12,
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 104
WILDMAIL! v4 AREAREQUEST MANAGER
─────────────────────────────────────────────────────────────────
they must have a security level of 200 or greater in order to
activate/de-activate them.
The individual AreaRequest security levels are defined for each
node and conference via the Main Menu options, Node Address
Management or Conference Area Management after selecting the
desired node/conference.
While the security level approach works well in most situations,
it offers somewhat limited protection of certain conferences that
you would like to restrict on a more complex level. This is
where you can combine the security level approach with individual
AreaRequest Flags.
AREAREQUEST FLAGS
AreaRequest flags are commonly used as a secondary level security
protection mechanism coupled with the value of the assigned
Security Level which is designed to limit node address access to
the various different conferences carried on/through your system.
If a flag is assigned to a conference, the requesting node must
also have that flag before it can gain access to it.
It should be pointed out that all flags created are on a equal
basis whereby no one flag has a higher priority level than
another. These are simple flag toggles that can be assigned to a
conference and then its respective downlink nodes who are to have
access to that conference.
Please bear in mind flags are a secondary level protection
mechanism. If a requesting node desires a specific conference
and his AreaRequest security level permits him access and no
flags are attached to the conference requested, that system may
gain access to it.
If this same node sends a request for a conference where his
normal AreaRequest security level is sufficient and a Conference
AreaRequest flag is attached to the conference his system is
requesting, his node address must also have this same Node
AreaRequest flag in order to gain access to that conference.
Combining the AreaRequest Security level and the AreaRequest
flags together provides two levels of security that a system must
pass before gaining access to that conference.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 105
WILDMAIL! v4 AREAREQUEST MANAGER
─────────────────────────────────────────────────────────────────
AREAREQUEST SPECIFIC SETTINGS
Following is a complete breakdown of the available fields and
their uses when configuring the AreaRequest settings for your
system. All available keystrokes for a given field are displayed
on the status bar located at the bottom of the screen. Depending
on a previous fields value, certain options may or may not be
available. This is due to the configuration needs/rules for each
option.
AreaRequest help file:
When your downlink nodes use AreaRequest to turn on or off
conferences, they may not be familiar with all of its
capabilities. To overcome this problem, you can specify an
ASCII text file which contains a description of all of the
functions along with their proper usage.
The contents of this file may be obtained in either of two
ways:
1) Using the %HELP command
2) Bad/Invalid AreaRequest command
If the downlink node already knows how to use the %HELP
command, they can specify it in their AreaRequest message.
Now if you've configured the node to automatically be sent
the contents of the help file upon receipt of a "bad"
AreaRequest command via the:
Send help on bad request: Y
option, then WILDMAIL! will automatically send the contents
of this ASCII text file to them when it responds to their
bad/invalid AreaRequest commands. A bad or invalid
AreaRequest command simply means either the formatting of
the command line was incorrect or it was simply an unknown
command.
Since this is an ASCII text file, you may customize it in
any manner you desire or simply leave it in its original
form. Shown below is a typical definition.
C:\WM40\AREAREQ\AREAREQ.HLP
Normal DOS naming conventions must be strictly adhered to
when defining the drive and subdirectory.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 106
WILDMAIL! v4 AREAREQUEST MANAGER
─────────────────────────────────────────────────────────────────
[ALT-V] - View File
Pressing [ALT-V] on this option allows you to view the
contents of this file (if it exists).
Notify msg text file:
When WILDMAIL! is executed with the NOTIFY command line
parameter, it will generate a report to each of your
downlink nodes informing them of the conferences they
receive on a network by network basis.
During this notification process, if desired, you can tell
WILDMAIL! to import the contents of a ASCII text file into
the beginning of the notification message. This is done by
specifying the complete DOS path/name of the file here along
with toggling the appropriate option on the nodes
definition.
Shown below is a sample definition.
C:\WM40\AREAREQ\NOTIFY.TXT
Normal DOS naming conventions must be strictly adhered to
when defining the drive and subdirectory.
[ALT-V] - View File
Pressing [ALT-V] on this option allows you to view the
contents of this file (if it exists).
Activity log file:
WILDMAIL! maintains a log file of all activity regarding the
processing of area requests that come into your system.
This information is useful for monitoring WILDMAIL!s
activity with regard to processing of area requests.
This option defines the <drive:\directory> and <filename> of
the log file where all activity regarding mail processing is
to be kept. A typical entry would be:
C:\WM40\AREAREQ\AREAREQ.LOG
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 107
WILDMAIL! v4 AREAREQUEST MANAGER
─────────────────────────────────────────────────────────────────
Normal DOS conventions are required when defining the log
file name.
[ALT-V] - View File
Pressing [ALT-V] on this option allows you to view the
contents of this file (if it exists).
Flag definitions:
AreaRequest flags are used as a secondary level security
mechanism designed to limit which node addresses have access
to the various different conferences carried on your system.
Pressing [ENTER] brings up another screen allowing you to
create up to 32 individual flags. When naming these flags,
you may use any character combination using up to 15
characters.
Shown below are the available options.
[INS] - Add a Flag
Pressing the [INS] key allows you to add a new flag
definition. A screen is displayed allowing you to enter up
to 15 characters for the flag name. Once the flag name is
complete, you may save the definition by pressing the [F10]
key or abort the changes by pressing the [ESC] key.
[DEL] - Delete a Flag
After positioning the highlight bar on the desired flag name
followed by pressing the [DEL] key brings up a prompt
confirming your wish to delete the flag.
Answering Y to the prompt causes WMCONFIG! to not only
delete the flag definition, but also go through the
Networks, Nodes and Conferences databases and remove the
flag from the respective databases as well.
[ENTER] - Edit a Flag
After positioning the highlight bar on the desired flag name
followed by pressing the [ENTER] key, the flag name will
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 108
WILDMAIL! v4 AREAREQUEST MANAGER
─────────────────────────────────────────────────────────────────
appear in edit mode. From here you can make the necessary
modifications. Once the changes are complete, you may press
the [F10] key to save or [ESC] to abort the changes.
TIP
It should be pointed out that all flags created are on a
equal basis whereby no one flag has a higher priority level
than another. These are simple flag toggles that are
initially assigned to a conference (if desired) and then its
respective downlink nodes that are to have access to the
selected conference.
These flags have no meaning outside of their intended
AreaRequest usage.
Delete processed msgs:
With this option set to Y, WILDMAIL! will flag the processed
AreaRequest messages as KILL/SENT so your front end mailer
will automatically delete them after transmission.
If this option is set to N, WILDMAIL! will flag the
processed area request messages as RECEIVED so they will
remain in your Netmail directory. With this setting, these
old (already processed) AreaRequest messages can quickly
pile up in your Netmail directory so caution is advised.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 109
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
USING AREAREQUEST
AreaRequest makes use of Netmail messages that have been
specially formatted and they control what AreaRequest should do.
When defining this message there are two distinct sections to
configure, the message header (to/from addressing etc) and the
message body.
The message body is considered optional because if your downlink
nodes use the -Q option (conference query), then nothing needs to
be in the message body. However if your downlink nodes wanted to
turn on/off conferences, change passwords and so on, then these
commands must be specified in the message body.
When your downlink nodes define the message header, the 5 basic
sections are described below.
TO: ADDRESS The netmail message should be addressed to your
address or any one of your AKAs (alternate
addresses) as needed.
TO: NAME The most common name to use would be AREAFIX, but
since these names are configurable (see Network
Management - AreaRequest Alias names), you should
notify your downlink nodes what name to put here.
FROM: ADDRESS The FROM: address of the message should be your
downlinks address that has access to the related
functions this request is being configured for.
In other words, they should use their correct AKA
address relative to the network they're requesting
conferences for. You wouldn't want them to use
their Fido address for conferences within OCRNET,
instead they would use their OCRNET address.
FROM: NAME Normally your downlink nodes would use their
regular name here. This field is not used by
AreaRequest.
SUBJECT LINE This is one of the most crucial definitions
because here is where your downlink nodes specify
their password which could optionally be followed
by a -Q. The most important part here is that the
password MUST BE THE FIRST WORD ON THE LINE. All
the remaining parameters (if used) must be
separated by a space.
Example Usage: PASSWORD
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 110
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
Upper/lowercase characters are insignificant.
The -Q option is functionally equivalent to the
%QUERY command except that it is placed on the
subject line instead of in the body of the
message. For additional information, please refer
to the %QUERY definition.
MESSAGE BODY
The message body portion of the Netmail message can be used for
various different purposes. The activation/deactivation of
conferences, using the extended command set and for specifying
which conferences are to be rescanned, requesting help and so
one.
When AreaRequest processes these messages, it will read each line
as a single command along with any "parameters" and execute it
accordingly. So each command is read on a line by line basis,
interpreted and then executed. Blank lines are ignored,
upper/lowercase characters are insignificant and commands may not
extend past a single line.
Any commands which are read that AreaRequest can't understand or
an attempt to execute options their node address doesn't have
access to, as part of the response message thats sent back to
their system, it will contain information relative to the
inability to execute that command.
Shown below is a description of the available commands.
Area Activation/De-activation
By specifying the area name of the conference, your downlink
nodes may activate it by either of 2 methods as shown below:
Example Usage: +WILDCAT
or
WILDCAT
Notice here that they may include the + character in front of the
area name if desired. It's not a requirement, but is used either
with or without the plus sign. Only one area name may be
specified per line of the message.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 111
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
NOTE:
If the requested conference is not configured on your system,
then AreaRequest will look it up in the Master List database and
add it to your conferences database and then forward a request to
your uplinks main feed address (the node that you get your mail
from) requesting the conference(s). The request uses the
AreaRequest message parameters defined via the appropriate
network definition.
Once mail for the requested conference(s) starts flowing to your
address, then those messages will automatically be forwarded on
to your downlinks system at the same time. Now, to de-activate
the conference, they would use:
Example Usage: -WILDCAT
This is exactly the same as with the activation option only now
you MUST specify the - (minus) character in front of the area to
be deactivated (WILDCAT is the area name that will be turned
off/deactivated).
EXTENDED COMMAND SET
The extended commands are easily distinguished by the percent
sign at the beginning of the command name. Since each of these
commands are configurable by you on a node by node basis, you may
or may not allow all of the ones listed below. If your downlink
nodes attempt to use one they don't have access to its use, they
will be notified accordingly.
As previously mentioned, each of these commands are interpreted
and executed on a line by line basis so if your downlink nodes
wish to execute a command more than once, they'll need to make
additional lines accordingly.
Shown below is a description of the available commands
%COMPRESSION <format>
Allows a node to change the compression method that they
currently have. The <format> must be a valid compression scheme
supported by WM such as ARC, ARJ, PAK, LZH, ZIP and ZOO.
Example Usage: %COMPRESSION ZIP
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 112
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
%PASSWORD <name>
Allows a node to change the value of the AreaRequest password
that they currently use. The <name> must be not be larger than 8
characters. If it is larger, WM will only use the first 8
characters.
Example Usage: %PASSWORD JoeM
%ACTIVE
This command has no parameters and allows your downlink nodes to
reactivate their address that has been previously toggled
inactive via the use of the %PASSIVE command or possibly by you
manually in WMCONFIG!.
Example Usage: %ACTIVE
%PASSIVE
This command has no parameters and allows your downlink nodes to
temporarily toggle all mail flow "off" for their address. For
example, if they were going away on vacation for awhile, using
the %PASSIVE command would temporarily halt mail flow and then
when they return from vacation, using the %ACTIVE command would
re-enable their mail flow.
Example Usage: %PASSIVE
You should note that this option does not toggle their
conferences on or off, rather it toggles their entire node
definition to inactive leaving their configuration completely
intact. Then using the %ACTIVE restores their node definition.
%-ALL
This single option command allows your downlink nodes to toggle
all of the conferences that they're currently receiving from your
system to off. This command is very powerful so your downlink
nodes should be careful when using it.
Example Usage: %-ALL
Normally this command is only used when they will no longer be
picking mail up from your system.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 113
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
%HELP
This single option command will send your downlink nodes the
contents of the defined information file. It will be compressed
using their selected compression format, attached to a netmail
message and then sent off to their address.
Example Usage: %HELP
Depending on your configuration, this file may also be sent to
their system automatically if they attempt to execute a command
that is invalid or use an improper format with a valid command.
%RESCAN <areaname> [<value or ALL>]
This command allows your downlink nodes to extract messages from
a particular conference that your system has message bases for
and have them resent to their system. This is very handy when
your downlink nodes first activate a conference and would like
get their system "caught up" on the messages for a particular
conference.
You should note, if the conference is configured on your system
as a "passthough" conference, they will be unable to extract any
messages because their isn't a message base to extract from.
This option must have at least one parameter specified, with that
being the area name. If they don't specify the area name,
nothing will be rescanned. The second parameter is the number of
messages "backward" that will be counted and then extracted out.
Such as:
Example Usage: %RESCAN WILDCAT 100
or
%RESCAN WILDCAT ALL
In the above example, the area name is WILDCAT and the last 100
messages will be extracted. The second definition means take ALL
of the messages that are in your message base for the WILDCAT
conference, extract them and send them to requesting downlink
node. Since this second parameter is optional, leaving this off
will be interpreted exactly the same as using the ALL parameter.
All of the downlink nodes usual definitions are maintained such
as maximum messages per PKT file as well as maximum archive size
will be properly maintained when using the %RESCAN command.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 114
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
NOTE:
Unlike other systems, your downlink nodes will need to create
multiple definitions for each of the different conferences they'd
like to rescan such as:
%RESCAN WILDCAT 100
%RESCAN FOR-SALE 50
CONTROL LINE INFORMATION
When performing a %RESCAN, certain control line information such
as SEEN-BY: and PATH: lines are properly maintained. This means
that during a rescan, an Origin line will be added (if the
message originated on your system, all the nodes that your system
forwards this conference to will be added to the SEEN-BY: lines
and a new PATH:line will be created containing just their
address.
Caution is advised here because your downlink nodes should make
sure they don't forward ANY of these rescanned messages on to
systems that refeed your uplinks address.
The rescanning messages may be forwarded to their downlink
systems, just make sure they don't get somehow refed to your
uplinks address.
While adding this control info to each "rescanned" message is not
a complete "cure-all" for preventing duplicate messages, it does
provide an extra measure of safety.
%LIST
This command will create a paginated report based upon your
downlink nodes security setup, listing all of the conferences
their node address has access to. It doesn't matter whether the
conferences are selected or not, whether your address has their
system configured for them or not, this is a complete list that
will be generated for all conferences in all the networks your
downlink nodes have sufficient access to.
Example Usage: %LIST
This paginated report is then compressed using their configured
compression format and then attached to a Netmail message and
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 115
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
sent to their address. This information is handy when trying to
determine what conferences are available to them based upon their
security level.
%QUERY
This command allow your downlink nodes to instruct AreaRequest to
generate a listing of all the conferences that their system is
currently receiving on a network by network basis from your
address.
Example Usage: %QUERY
This information is handy when they want to find out what
conferences they are currently receiving.
%UNLINKED
This command will create a list of all conferences that your
downlink nodes have access to which your system already has
configured. In other words, these are the conferences that your
system is already receiving mail for in order to either add to
your message bases or forward on to other downlink systems.
Example Usage: %UNLINKED
This option differs from the %LIST command in that it will only
list those conferences based upon their security setup that they
have access to which your system is "already" carrying (not
something they "could" request).
%PKTPSWDIN <name>
This command allows your downlink nodes to change their outbound
PKT level password. This password is the same password their
system puts on its "outbound" mail PKTs destined for your system.
Example Usage: %PKTPSWDIN NewPswd
If your downlink nodes wish to remove the password entirely, just
use the %PKTPSWDIN without a replacement password.
%PKTPSWDOUT <name>
This command allows your downlink nodes to change their inbound
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 116
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
PKT level password. This password is the same password that your
system puts on its "outbound" mail PKTs destined for their
address. (These are PKT files that appear in their inbound
directory)
Example Usage: %PKTPSWDOUT NewPswd
If they wish to remove the password entirely, just use the
%PKTPSWDOUT without a replacement password.
%PKTFORMAT <format>
This command allows your downlink nodes to change the PKT file
format that your system creates mail destined for their address
in. Currently there are three different types to choose from.
TYPE2 - Type 2 PKT format
TYPE22 - Type 2.2 PKT format
TYPE2PLUS - Type 2Plus PKT format
There is a limitation here. If they are a point off of your
system, then they will be unable to select TYPE2 as their new PKT
format because TYPE2 PKTs don't support point addressing.
Example Usage: %PKTFORMAT TYPE22
By far the most commonly used format is TYPE2PLUS.
%UNCOMPBYTES <size in bytes>
When your creates mail destined for your downlink systems, it
places the messages into PKT files and then compresses those PKT
files into archives for transmission to their system. This
option allows you to specify the maximum bytes the archive should
uncompress "to" when their system uncompresses the mail.
Basically the option works like this, when your system packs up
mail for your downlink node, it will keep a running total of all
PKT sizes and when this maximum is reached, a new archive will be
created for the downlink node.
Example Usage: %UNCOMPBYTES 3000000
This option is extremely handy when their system is low on disk
space and they need to prevent uncompressing a huge archive that
will use more free space than their system has. It should be
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 117
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
pointed out that this is a "best guess" setting because the check
is done on a PKT basis, so the PKT totals at the point which
exceed the value specified here will trigger an archive creation.
%MSGSPERPKT <count>
This command allows your downlink nodes to specify the maximum
number of messages per PKT file that your system should add to a
PKT before creating a new one for them.
Example Usage: %MSGSPERPKT 300
Typical values are 200 to 300. If they specify a large value
here, if mail somehow gets corrupted, they could potentially lose
a larger amount than if the PKT file was smaller.
SIGNALING THE END OF COMMANDS
A special group of characters called a tear line should be placed
after the last command to signal AreaRequest that it has reached
the end of the message and to ignore any remaining text.
This tear line consists of three dashes (---) together starting
on column 1 of a blank line. Although the tear line is not
required, it should be there as a matter of course. So if your
downlink nodes would like to include text to the SysOp (you) in
the same AreaRequest message, they may do so after the tear line
as it will simply be ignored.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 118
WILDMAIL! v4 USING AREAREQUEST
─────────────────────────────────────────────────────────────────
SAMPLE AREAREQUEST MESSAGE
As previously mentioned, this is a standard Netmail type message
which may be created by your downlink node by using either your
front end mailers editor or the one built into their BBS.
Shown below is a sample message.
[1] 15 Jun 94 19:24:32 Cost: 0
By: Joe Martin, The Power Station BBS (1:161/123)
To: AREAFIX, (1:161/55)
Re: Password
St: Kill Del/sent Local
───────────────────────────────────────────────────────────────
+FOR-SALE
-WILDCAT
%RESCAN FOR-SALE 50
%RESCAN GAMING ALL
%RESCAN WOODWORKING 100
%QUERY
%UNCOMPBYTES 2000000
%COMPRESSION ARJ
---
Any text below this line will be ignored by AreaRequest and
signals the end of the commands.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 119
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
NETWORK MANAGEMENT
Presented here is a list of network definitions. Shown below is
a description of the available options.
[INS] - Defining a Network
Pressing the [INS] key will take you to a screen where you will
be able to define the network. All relevant fields must be
filled out and then when you are satisfied with the entry, press
[F10] to save the newly defined network and you will be returned
to this screen.
[DEL] - Delete a Network
Position the highlight bar using the Up/Dn arrow keys or the
PgUp/PgDn keys on the item you wish to delete and press the [DEL]
key. A prompt will ask you if you are sure you want to delete
the selected items. Press the Y key if you want to delete the
item or press the N key or the [ESC] key to return back to the
main screen.
[ENTER] - Edit a Network
Pressing the [ENTER] key will take you to a screen where you will
be able to edit the network definition. Make your changes and
then when you are satisfied with the entry, press the [F10] key
to save the changed network definition. You will be returned to
this screen
WHAT IS A NETWORK?
For use within WILDMAIL!, a network is defined as a group of
conferences that correspond to a particular network name along
with all of its operating characteristics. These being the
location of where the mail comes from, various AreaRequest
options along with the origination of the network.
All of this information forms a network "definition" in
WMCONFIG!. If you were to delete a definition, you would delete
all the conferences and information associated with that network.
The reverse also hold true. Before any conferences may be defined
in WMCONFIG!, the network (or source of those areas) must be
defined first. Once the network is defined, you may then add
conferences to the Master List database and "associate" the
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 120
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
network name with the area name and long description. Then any
future reference to a particular area name will "know" that the
area comes from that particular network.
While this might sound a little confusing at first, the idea here
is to group conferences together in an effort to better manage
all the different area names along with all the "automated"
features such as AreaRequest and so on.
This grouping also gives us some very powerful sorting and
filtering capabilities whereby you can get a better understanding
and ultimately more operational control of mail flow through your
system.
Specifically, when adding conferences to your system, you could
enable the network filter and you would only see those
conferences for that network instead of having to sort through
10,000 conferences just to find a particular one.
NETWORK DEFINITIONS
For every network that you define here you would normally have a
corresponding list of all the area names that are associated with
the network.
For example, Fidonet has two "echolists" (ASCII text files with
all the area names of conferences for Fidonet) that are
associated with it:
FIDONET.NA A list of all areas that are on the Fidonet
backbone and are listed in the echolist published
by the Zone Echo Coordinator on a regular basis.
FIDONET.NO A list of all areas that are on the Fidonet
backbone but are not in the echolist which is
published by the ZEC.
In this case you would need to define both echo lists as separate
networks in WMCONFIG! (1 echolist per network). A common network
naming convention would be to call them:
FIDONET_NA and FIDONET_NO
These "echolist" files are then imported into whats called the
Master List database. (For more info on this import process,
refer to Echolist Management from the Main Menu)
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 121
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
The Master List database contains all the areas for all of the
network definitions you have created which serves several
important functions.
1) It automatically associates a given conference (area
name) to a particular network. This is important for
managing AreaRequest conference queries, etc.
2) Provides a simple and easy to use "master list" of all
the conference names that you can choose from when
adding a conference to your configuration. Especially
useful on "Globally Adding" conferences.
Something that should be pointed out here is that the Master List
database is just that, a "Master List". Just because a
conference (area name) is there doesn't mean your system is
configured for it.
Quite the contrary, in order to add a conference to your
configuration, it must be deleted from the Master List database.
NODE MEMBERSHIPS
Normally, each network has its own addressing scheme used to
identify itself, ie: unique Zone number. However there are
several "alias" networks that share a common address (typically a
Fidonet address) with their own addressing.
Because of this, that particular node must be a "member" of both
the Fidonet network as well as the other "alias" network (such as
WILDNET, ADULTNET, etc.) in order to have access to conferences
in both networks. Up to 10 different network memberships may be
used for the same address.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 122
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
NETWORK SPECIFIC SETTINGS
Network name:
This option allows you to specify the name that will be used
throughout WMCONFIG! to identify this network. You may
enter up to 20 characters but there must NOT be any spaces
in the name.
Normally you would use a name that easily identifies the
network such as FIDONET_NA, FIDONET_NO and so on.
NOTE
Once this name has been defined, you will not be able to
modify it because conferences could be associated with it as
well as node memberships could have been assigned.
In order to modify a network, it must be deleted and then
recreated. Caution should be advised here because when you
delete a network, you delete all conferences and node
memberships at the same time.
Description:
This field contains a verbose description of the network
that you are defining. Up to 60 characters can be entered.
Try and be as descriptive as possible so that you can get a
good idea of the network by reading the description.
Domain name:
This option allows you to specify the domain name associated
with this network. For those that are familiar with the
Internet, this is used to identify a particular network
(system) on the Internet.
If configured, this domain information is used for
additional duplicate checking. Specifically, on the MSGID
lines it is appended to the end of the "from" address by a
leading @ character. These lines are automatically added to
new messages entered on your system similar to:
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 123
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
^AMSGID 1:161/123.0@fidonet.org 65284011
In the above example, the specified domain name here was
"fidonet.org".
It should be noted here that not all FTSC type networks have
defined Internet domain names. If you are unsure of the
appropriate domain name, you should leave this field blank
and ask your uplink address (where you pick up your mail
from).
Originating node:
This option is used to manage AreaRequests from your
downlink nodes that activate conferences you don't carry on
your system. For example:
(your address) -> Originating Node
/ | \
Node#1 Node#2 Node#3
In the above example, this means that since there are only a
total of 4 people in this network, you are considered the
main distribution point or the Originating Node. This means
if Nodes 1 through 3 request a conference you do not carry,
it simply doesn't exist for this network and thus generates
an invalid conference request from WILDMAIL!.
Just the opposite now, if you're NOT the originating node,
then you must be picking up the mail for this network from
another node. Shown below is such an example.
Uplink/Feed Address
|
Your Address
/ | \
Node#1 Node#2 Node#3
In the above example, when one of your downlink nodes (#1
#3) request a conference on your system that you don't
carry, WILDMAIL! will send a request message to the
"Uplink/Feed Address" to activate that conference for them.
Specifically, the request will be forwarded on to the
address specified in the "Destination address" field under
Area Activation Message Definition for this network.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 124
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
Valid AreaRequest 'To:' names:
When WILDMAIL! scans the Netmail directory looking for
AreaRequest messages, one of the things it's searching for
is the name of the person the message is addressed to. This
option is used to specify what TO: names should be
recognized as AreaRequest messages.
The remaining 2 requirements are that, first, the message is
addressed to either your primary address or any of your
other AKA addresses and, secondly, that the RECEIVED flag
has not been set.
Pressing [ENTER] on this field will pop up another screen
which will allow you to specify up to 5 valid AreaRequest
names.
This screen allows you to add, change or delete valid
AreaRequest Alias names that WILDMAIL! will accept. A
maximum of 5 names can be entered on this screen which each
name being up to 36 characters long.
[INS] - Add an Alias
Pressing the [INS] key will pop up a screen which will allow
you to enter a name that your system will recognize as a
valid AreaRequest name. Up to 36 characters may be enter
and spaces are allowed between words.
When you are satisfied with the entry, press the [F10] key
to save your entry. If you want to abort the entry, press
the [ESC] key and you'll be prompted as to whether you want
to abort the process. If you do want to abort the entry,
press the Y key and you'll be returned to AreaRequest Alias
Names screen.
[DEL] - Delete an Alias
Pressing the [DEL] key will pop up a screen which will ask
you if you are sure you want to delete this entry. If you
are sure then press the Y key and the entry will be deleted.
If you are not sure then press the [ESC] key or the N key
and you'll be returned back to the AreaRequest Alias Names
screen.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 125
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
[ENTER] - Edit an Alias
Pressing the [ENTER] key will pop up a screen which will
allow you to edit the name that your system will recognize
as a valid AreaRequest name. Up to 36 characters may be
entered and spaces are allowed between words.
When you are satisfied with the entry, press the [F10]
function key to save your entry. If you want to abort the
entry, press the [ESC] key and you'll be prompted as to
whether you want to abort the process. If you do want to
abort the entry, press the Y key and you'll be returned to
AreaRequest Alias Names screen.
Required AreaRequest flags:
AreaRequest flags are used as a secondary level security
mechanism designed to limit which node address has access to
the various different conferences carried on or through your
system.
Pressing [ENTER] brings up another screen allowing you to
toggle up to 32 individual flags that will be available for
this network definition.
It should be pointed out that all flags created are on an
equal basis where no one flag has a higher priority level
than another. These are simple flag toggles that are
initially assigned to a conference (if desired) and then its
respective downlink nodes that are to have access to the
selected conference.
Please bear in mind, these flags are a secondary level
security mechanism. This means if a requesting node desires
a specific conference and his AreaRequest security level
permits him access and no flags are attached to the
conference requested, that system may gain access to it.
Now if this same node sends a request for a conference where
his normal AreaRequest security level is sufficient and a
"Conference AreaRequest flag" is attached to the conference
his system is requesting, his node address must also have
this same "Node AreaRequest flag" in order to gain access to
that conference.
So combining the AreaRequest Security level and the
AreaRequest flags together would be two levels of security
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 126
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
his system must pass before gaining access to that
conference.
Required security level:
This option allows you to specify what the lowest security
level of a node requesting conferences from this network
should have in order to gain access to those conferences.
For example, if a requesting node has a security level of 50
and you specified a value here of 100, the node will be
denied access to conferences from this network. If the
value specified here was 50 (or below) this node would then
be able to access the conferences.
A little forethought should go into specifying this value
because all of your node/conference values will be based
upon it.
NOTE
When a conference is "auto-added" by a node requesting its
activation, the security level value specified here will
become the value that is used when the area is added to your
conferences database.
The security level option is only "part" of the overall
security checking process. In the above examples the flags
requirement has been left out in order to clarify the
option. In reality, if flags have been assigned, they too
must also be checked and passed before the conference can be
activated.
Purge abandoned areas:
During the course of normal AreaRequest operation, areas
will be turned on and off by your downlink nodes. In
situations where none of your downlink nodes are picking up
mail from conferences that your system is still receiving
from your uplink address, it makes little sense to keep
receiving mail for those conferences when no one is "using"
it.
This option gives you the ability to instruct WILDMAIL! to
automatically send off an AreaRequest message to your uplink
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 127
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
address to turn those respective conferences off providing
they are configured as "passthough".
When WILDMAIL! processes an AreaRequest message, it will
scan through the conferences database and if it finds a
conference that only your uplink address is selected for,
it's configured as passthough and this option for the
associated network is toggled to Y, then an AreaRequest
message will be sent to the address defined via the
"Destination Address" on the Network definitions screen to
deactivate the conference.
Setting this option to N will disable this capability.
Auto-Add origin address:
This option allows you to specify the origin address that
will be used on conferences that are automatically added
from the Master List database by downlink nodes "turning on"
conferences you don't have active on your system.
Typically this situation occurs when someone requests a
conference you don't have in your configuration but is found
in the Master List database. After a special notification
message is sent to "turn on" the conference at your hub
(where you get your mail for this network) this address will
be added to any future messages that originate on your
system from this conference.
Pressing [ENTER] on this field pops up a list of all your
AKA addresses. Simply position the highlight bar on the
desired address and press the [ENTER] key. If you desire to
have your primary address used, simply press the [F10] key.
Auto-Add origin line:
This option allows you to specify the origin line that will
be used on conferences that are automatically added from the
Master List database by downlink nodes "turning on"
conferences you don't have active on your system.
Typically this situation occurs when someone requests a
conference you don't have in your configuration but is found
in the Master List database. After a special notification
message is sent to "turn on" the conference at your hub
(where you get your mail for this network) this origin line
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 128
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
will be added to any future messages that originate on your
system from this conference.
Pressing [ENTER] on this field pops up a list of all your
previously defined origin lines whereby you can select the
appropriate one by positioning the highlight bar followed by
pressing [F10].
Allow remote operation:
This option is an extremely powerful option because it
allows one of your down/uplink nodes to become a remote
operator of your WILDMAIL! data files. The default value of
this field is N.
If you choose to allow remote operation of your WILDMAIL!
data files then enter a Y in this field. By entering a Y
here the fields "Security level for remote" and Remote
access password" open up for entry. Make sure that you
fully understand this remote process before you enable this
option as it is extremely powerful!
Security level for remote:
For remote operation to work correctly you must establish a
security level here. Make sure that this security level is
a value that only the remote node is matched to.
There is an additional security check performed on the
remote access password. Both of these must be satisfied
before remote access is given to the node requesting it.
Remote access password:
To ensure that remote operation is secure you should define
a password in this field. It can be up to 8 characters in
length. For remote operation to take place both the
security level and password fields must be matched.
This means that the security level will be checked first and
if that condition is met then the password will be checked.
If they both are satisfied then the node will be given
access to do remote operation of your WILDMAIL! data files.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 129
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
'To:' name on request msg:
When WILDMAIL! creates a Netmail message to your uplink
address (defined via the Destination address field) to turn
on/off conferences, it must be addressed "to" a particular
name that your uplink address can recognize.
Since not all systems understand the traditional "AREAFIX"
name, this option gives you the ability to specify whatever
name is required by your uplink address.
In order for the AreaRequest message to be interpreted
properly, you should specify the appropriate name to use.
If you are unsure, use the name "AREAFIX" (less the quotes)
and if the requests are not being processed by your uplink
address, you should contact them to verify the correct name
to use.
Destination address:
When downlink nodes turn on/off conferences and a
AreaRequest message is generated on your side to be sent to
your uplink address, this option is used to specify what
address should be considered your uplink address for this
network.
This address is therefore considered the "source" for all
the conferences that you have configured for this network.
Pressing [ENTER] on this field will pop up a list of all the
nodes that you have configured in your nodes database. You
should position the highlight bar on the node you want as
the destination address by using the Up/Dn arrow keys and
then press [ENTER] to select it.
'Fm:' name on request msg:
When WILDMAIL! generates an AreaRequest message to your
uplink address, this option allows you to specify what name
should appear in the FROM: field.
If this field is left blank then the SysOp Name field from
the System Information screen will be used in the message.
Up to 36 characters can be entered in this field.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 130
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
Origination address:
When WILDMAIL! generates an AreaRequest message to your
uplink address, this field is used to specify the origin
address to use.
Pressing [ENTER] on this field will pop up a list of all of
your AKA addresses. If you would like to use one of the
addresses listed, position the highlight bar on the address
desired (by using the Up/Dn arrow keys) and press [ENTER].
If you would like to use your primary address instead of one
of your AKA addresses, press the [F10] key.
Netmail message flags:
When WILDMAIL! creates an AreaRequest message to your uplink
address, this option allows you to specify what flags on the
outgoing Netmail message should be used.
Displayed are the currently selected flags. Pressing
[ENTER] on this field pops up a screen whereby you can
toggle the appropriate flags to use.
The most commonly used flags are:
LOCAL KILL/SENT PRIVATE
Because some of these flags dictate the transmission urgency
of this message, you should be careful in selecting flags
such as CRASH and IMMEDIATE.
Subject line of msg:
When WILDMAIL! creates an AreaRequest message to your uplink
address, this option allows you to specify the contents of
the SUBJECT: line.
In the most common of forms, this line normally only
contains your AreaRequest password for your uplinks system.
Since not all systems support the traditional AREAFIX
format, this option allows you to customize this line to
suit your individual needs for your uplinks system.
As previously mentioned, this line usually contains the
AreaRequest password (for your uplinks system), so you
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 131
WILDMAIL! v4 NETWORK MANAGEMENT
─────────────────────────────────────────────────────────────────
should make sure that at least that information is
specified. If you encounter difficulties, contact your
uplink address and verify the correct information to use
here.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 132
WILDMAIL! v4 GLOBAL MODIFICATIONS
─────────────────────────────────────────────────────────────────
GLOBAL MODIFY OPTIONS
From the Main Menu of WMCONFIG!, selecting this option presents
you with a list of available types of data to modify. Items such
as conferences and nodes for modification as well as globally
deletion. The following keystrokes are available to better
facilitate the modification process.
[F9] - Filter Networks
Pressing the [F9] key displays a list of all the networks that
are currently defined on your system. You can filter the display
of conferences by selecting only the network you want displayed
followed by pressing the [ENTER] key. The display will now only
reflect those conferences that are associated with that network.
To remove/disable the network filtering, simply press the [F9]
key followed by pressing the [ESC] key and all of the conferences
from all of the networks will now be displayed.
[F5] - Sort Conferences
By default, conferences are always sorted by Area Name. You may
toggle this sort order (Area Name/Conference Number) by simply
pressing the [F5] key.
[ALT-F] - Find Conference Area/Conference Number
Depending on what the current sort order is (see above), this
option allows you to specify a search criteria and locate a
particular conference within the database.
Pressing the [ALT-F] key presents you with a screen where you may
define the appropriate search specification (Area Name/Conference
Number). Once the search parameters have been defined, you may
start the search by pressing the [ENTER] key. The highlight bar
will then be positioned on the exact or closest match of the
appropriate conference.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 133
WILDMAIL! v4 GLOBAL MODIFICATIONS
─────────────────────────────────────────────────────────────────
GLOBAL ADD CONFERENCES
Presented here is a list of all the conference(s) which may be
toggled for addition onto your configuration. You can tag
individual conferences by positioning the highlight bar on the
desired conference using the Up/Dn arrow keys and then by tapping
the [SPACEBAR], you can select/deselect it as indicated by the
(Θ) selection dot.
You may also select/deselect all of the conferences by pressing
the [CTRL-ENTER] key.
[F10] - Start Global Add
After selecting the desired conference(s) by using the Up/Dn
arrow keys, pressing the [F10] key presents you with a prompt to
confirm your request to add the selected conferences. Pressing Y
initiates that action while pressing [ESC] cancels and returns
you to the previous screen.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 134
WILDMAIL! v4 GLOBAL MODIFICATIONS
─────────────────────────────────────────────────────────────────
GLOBAL DELETE NODES/CONFERENCES
This option allows you to tag the conference(s) you wish to be
deleted and by pressing the [DEL] key, they will be automatically
removed from the configuration along with all of their respective
nodes being deselected.
Presented here is a list of all the conference(s) which may be
toggled for deletion. You can tag individual conferences by
positioning the highlight bar on the desired conference using the
Up/Dn arrow keys and then by tapping the [SPACEBAR], you can
select/deselect it as indicated by the (^G) selection dot.
May also select/deselect all of the conferences by pressing the
[CTRL-ENTER] key.
Shown below is a list of the available commands.
[DEL] - Start the Global Delete
After selecting the desired conference(s), pressing the [DEL] key
presents you with a prompt to confirm the global delete. Pressing
Y initiates the process or pressing N returns you to the previous
screen.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 135
WILDMAIL! v4 GLOBAL MODIFICATIONS
─────────────────────────────────────────────────────────────────
GLOBAL MODIFY NODES/CONFERENCES
This is an extremely powerful option allowing you to make
sweeping changes to selected conferences by selecting and
modifying options and then pressing [F10].
Selecting the desired conferences may be accomplished by
positioning the highlight bar over the "Select Conf(s) to Modify"
field and pressing [ENTER]. Then position the highlight bar on
the desired conference(s) and press the [SPACEBAR] to place a
(^G) next to the conference name indicating its selection.
You may also select (or deselect) all of the conferences by
pressing the [CTRL-ENTER] key.
Once the desired conferences have been selected, pressing [ESC]
confirms the selection and returns you to the Global Edit screen.
To select a specific field to be changed, position the highlight
bar over the desired field and press [ENTER]. You may now change
the value to the desired setting. Once the value has been
defined, simply press the [ENTER] key and you will now notice the
field has been selected indicated by the presence of the (^G)
selection dot.
Selection value information for each of the fields is available
by pressing the [F1] key on the desired field.
The AreaRequest Flags option is unique in that there is a set of
additional options allowing you to define the method by which to
handle the individual flags.
After selecting this option, you are presented with a list of
previously defined flags from which you may select any of three
methods of handling the changes. Pressing the [SPACEBAR] on the
highlighted flag toggles these choices as explained below.
Select
This indicates that all conferences processed, regardless of the
flags current setting, will be toggled to on (or selected). This
means if the flag was previously set, it will remain set. If it
was off, it will now become selected.
Deselect
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 136
WILDMAIL! v4 GLOBAL MODIFICATIONS
─────────────────────────────────────────────────────────────────
This function is identical to select except in reverse. If the
flag was previously selected, it is now toggled off. If it was
previously toggled off, it will remain that way.
Ignore
You can use this option on those flags that you wish to leave
alone. This means if this option is selected, no changes will be
made whatsoever to this flags current setting in the individual
conferences to be processed.
Once the settings have been defined, pressing the [ESC] key
returns you to the main Global Edit screen and places a (^G) next
to the AreaRequest flag field indicating you wish changes to be
made.
Prior to starting the actual global change process, you may
deselect a specific field (prevent WMCONFIG! from making any
changes to this option) by simply highlighting the desired option
and pressing the [SPACEBAR]. The selection dot now is removed
and no action will be taken on that option.
If you wish to completely abort the global change process, you
may at any time (prior to pressing the [F10] key) by pressing the
[ESC] key. You will be returned to the previous screen.
Now, when you're ready to instruct WMCONFIG! to make the changes,
simply press the [F10] key. Once the update process is complete,
pressing the [ESC] key returns you to the previous screen and you
can then go back and verify the changes.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 137
WILDMAIL! v4 MASTER CONFERENCE LIST
─────────────────────────────────────────────────────────────────
MASTER CONFERENCE LIST
Presented is a complete list of all the available conferences
previously defined within WMCONFIG! and the networks that these
conferences belong to. This screen allows one to change the area
names, long descriptions and network affiliations for any
conference.
You may use the PgUp/PgDn and UpDn arrow keys to move about the
displayed list. Shown below is a description of the available
commands while using this option.
[F9] - Filter Networks
Pressing the [F9] key displays a list of all the networks that
are currently defined on your system. You can filter the display
of conferences by selecting only the network you want displayed
followed by pressing the [ENTER] key. The display will now only
reflect those conferences that are associated with that network.
To remove/disable the network filtering, simply press the [F9]
key followed by pressing the [ESC] key and all of the conferences
from all of the networks will be displayed.
[ALT-F] - Find Conference Area
Pressing the [ALT-F] key presents you with screen whereby you may
define the appropriate search specification. Once the search
parameters have been defined, you may start the search by
pressing the [ENTER] key. The highlight bar will then be
positioned on the exact or closest match of the appropriate
conference.
[DEL] - Delete a Conference
After selecting the desired Conference(s) by using the Up/Dn
arrow keys, pressing the [DEL] key presents you with a prompt to
confirm your request to delete the selected conferences. Pressing
Y initiates the action. Pressing [ESC] cancels the delete
function and returns you to the previous screen.
[INS] - Add a Conference
Pressing the [INS] key presents you with another screen which
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 138
WILDMAIL! v4 MASTER CONFERENCE LIST
─────────────────────────────────────────────────────────────────
will enable you to enter the area name, long description and
network name. When you are satisfied with your entry press the
[F10] key to save the entry.
[ENTER] - Edit a Conference
After selecting the desired Conference(s) by using the Up/Dn
arrow keys, pressing the [ENTER] key presents you with another
screen whereby you can change the area name, long description and
network affiliation. When satisfied with your entry, pressing
the [F10] will save the entry and return you back to the main
screen.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 139
WILDMAIL! v4 MASTER CONFERENCE LIST
─────────────────────────────────────────────────────────────────
MASTER CONFERENCE SPECIFIC SETTINGS
Area name:
This is the FTSC area name that you want to add. Up to 35
characters may be added and no spaces must be present
between words.
You must specify a unique area name. If a duplicate is
found, you will be unable to save the definition.
Description:
This is the long description of the FTSC area name. Up to
60 characters can be entered in this field.
Network:
This is the network name that you want this area to belong
to. Pressing [ENTER] on this field will present you with
another screen which will allow you to choose a network by
positioning the highlight bar on the desired network and
pressing [ENTER].
If no networks have been defined, you will need to return to
the Main Menu and select Network Management and create a
network definition before proceeding.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 140
WILDMAIL! v4 ECHOLIST MANAGEMENT
─────────────────────────────────────────────────────────────────
ECHOLIST MANAGEMENT
In WMCONFIG! there is a database of all the different networks
area names called the Master List database. This database is
referenced in various places, such as when adding conferences to
your configuration, when your downlink nodes request a given
conference (via AreaRequest), Global Adding of conferences and so
on.
In order for those area names to "get into" the Master List
database, there are two methods available:
1) Manual Entry
2) Automatic Importation
The manual method is fairly self explanatory. You must enter
each area name one at a time and associate a particular network
during the process.
However, the preferred manner is the automatic method by use of
what's called "echolist" ASCII text files. These lists contain
the area name followed by the long description. This line by
line list (1 area per line) is then imported into the Master List
database either manually via WMCONFIG! (F4 - Import) or via
WMUTIL! by using command line parameters.
Since each echolist file is based upon a given network (ie:
FIDONET, WILDNET, FAMILYNET etc.) each of your network
definitions should have their own echolist definition as well.
Unfortunately not all networks maintain a list of the conferences
that are available. If this is the case, then that particular
network will not have a corresponding echolist definition. So in
order to get the area names for that network into the Master List
database, you will have to manually enter them.
Shown below is a list of the available options from this screen.
[INS] - Add a Definition
Pressing the [INS] key will pop up a screen which will allow you
to define an echo list definition. Once the definition is
complete, you can press [F10] to save it or [ESC] to abort.
[DEL] - Delete a Definition
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 141
WILDMAIL! v4 ECHOLIST MANAGEMENT
─────────────────────────────────────────────────────────────────
After positioning the highlight bar on the desired definition
followed by pressing the [DEL] key, a screen will pop up asking
you to confirm the deletion of the echolist definition.
[ENTER] - Edit a Definition
Positioning the highlight bar on the desired echolist definition
followed by pressing the [ENTER] key brings up the echolist
definition in edit mode where you may make the necessary changes.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 142
WILDMAIL! v4 ECHOLIST MANAGEMENT
─────────────────────────────────────────────────────────────────
ECHOLIST SPECIFIC SETTINGS
Network name:
This option allows you to specify the network name an echo
list definition should be created for.
Pressing [ENTER] on this field brings up a list of
previously defined networks where you may position the
highlight bar on the desired network and select it by
pressing the [ENTER] key.
If no network names are present, you will need to return to
the Main Menu to create a new network definition under
Network Management.
Update changed descriptions:
This option instructs the importation process to update the
contents of the description field for each of the
conferences that get added to the Master List database when
you've instructed either WMCONFIG! or WMUTIL! to perform an
"import" of conferences from the defined echolist text file.
Setting this option to Y will update the descriptions where
setting this to N leaves them alone.
Purge entries not in import file:
This option allows you to define whether or not the
conferences for this particular network should be deleted
from the Master List database prior to the importation
process.
Setting this option to Y will delete all conferences from
the Master List database (for this echolist's network) and
then proceed to import the conference names and descriptions
from the defined echolist text file.
Setting this option to N will simply update the database
with any new areas that it finds.
Create differential report:
This option allows you to specify whether a special text
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 143
WILDMAIL! v4 ECHOLIST MANAGEMENT
─────────────────────────────────────────────────────────────────
file should be created detailing the events of the
importation process.
Setting this option to Y opens up a field called
"Differential report name" where you can define the text
file this information should be appended to.
Setting this option to N disables this ability.
Differential report name:
This is the complete DOS <drive:\directory> and <filename>
that should be used when creating a differential report.
C:\WM40\ECHOLIST\CONFDIFF.RPT
You should use normal DOS naming conventions when specifying
this file name.
[ALT-V] - View File
Pressing [ALT-V] on this option allows you to view the
contents of this file (if it exists).
Import ASCII text file name:
This option allows you to specify the ASCII text file that
will contain a list of all the conferences along with their
descriptions for this particular network. A typical
definition might be:
C:\WM40\ECHOLIST\FIDONET.NA
For those familar with the Fidonet network, this is the text
file of all the conferences for Fidonet.
For those systems that receive their "weekly" .NA file, you
should copy the new file into the specified directory and
use WMUTIL with the /U command line parameter (followed by
the network name) to import the new file.
[ALT-V] - View File
Pressing [ALT-V] on this option allows you to view the
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 144
WILDMAIL! v4 ECHOLIST MANAGEMENT
─────────────────────────────────────────────────────────────────
contents of this file (if it exists).
Export ASCII text file name:
This option allows you to specify the ASCII text file that
the results of an [F5] - Export will be outputted to. This
option is the exact opposite of an [F4] - Import in that it
will take the contents of all the conferences defined for
this network and export them into an ASCII text file.
A typical definition might be:
C:\WM40\ECHOLIST\EXPORT.LST
Depending on the setting used in "Export text file format"
determines the actual output format. You should use normal
DOS naming conventions when specifying this file name.
[ALT-V] - View File
Pressing [ALT-V] on this option allows you to view the
contents of this file (if it exists).
Export text file format:
This option allows you to specify the output format used on
the defined Export ASCII text file when performing an [F5] -
Export. Tapping the [SPACEBAR] toggles through the choices
listed below.
Paginated
This setting creates a complete file containing all the
conferences for this network paginated to the number of
lines per page defined via the "Page length" option. This
includes special formatting using hardcoded headers and
footers.
Line by Line
This setting produces a standard "echolist" file format
whereby the files are created on a line by line basis with
each line containing the area followed by spaces and then
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 145
WILDMAIL! v4 ECHOLIST MANAGEMENT
─────────────────────────────────────────────────────────────────
the areas' description.
Page length:
This option allows you to define the number of lines per
page that should be used when exporting an ASCII text file
of all the conferences for this particular network.
The default setting here is 55 lines.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 146
WILDMAIL! v4 WHAT ARE POINT ADDRESSES
─────────────────────────────────────────────────────────────────
WHAT ARE POINT ADDRESSES?
Points are BBS systems that send and receive mail in a specific
network but can only be addressed through the node address they
transfer mail with. In other words, if you address mail to a
<point> it doesn't go directly to their system but rather to the
system they pickup their mail from.
To be considered a full node (not a point) typically requires
that their BBS must be up and running 24 hours/day especially for
mail delivery during what's called Zone Mail Hour. Because
certain BBS's were not always operational 24 hours/day, there
needed to be a way to make echomail available to them. This is
where points came into being.
A common comparison would be a <point> is to a node address what
a caller using QWK mail and an offline reader is to a regular
BBS. Mail is transferred on a regular basis, but only when the
caller uploads his/her QWK mail REP packet. Thus the caller can
only be addressed through the system they upload their replies to
and not directly.
The problem was how to address them as a <point>. Only 3D
addressing was available at the time and there were hundreds of
systems using this 3D addressing scheme. Couple that with the
original design limitations of the mail packets and mailer
software and it made it difficult to implement a satisfactory
change. To solve this problem, a specially translated addressing
scheme was devised.
This required those systems to call a node address who was always
available and pick up their mail using their specially translated
address. In the remaining portion of this section, we'll discuss
the terminology and the "how and whys" of the implementation.
BOSS NODE
BOSS node is the name given to the node address that has point
addresses attached to their system which it feeds mail to.
Whenever mail is addressed to a <point>, the BOSS node is where
the mail actually gets sent to and then the <point> picks it up
from them (the BOSS node).
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 147
WILDMAIL! v4 WHAT ARE POINT ADDRESSES
─────────────────────────────────────────────────────────────────
ADDRESSING SCHEMES
Within the realm of Fidonet style mail, there are two distinctive
methods of addressing called
3D or Three dimensional
4D or Four dimensional
The term dimensional refers to the number of segments in the node
address where:
3D uses: <zone:net/node> or 1:161/123
4D uses: <zone:net/node.point> or 1:161/123.1
Notice that 4D uses an additional parameter at the end of the
address indicated by the '.1'. This is called the <point> and
where the 4D address gets its 4th dimension.
POINT DESCRIPTIONS
Because of the difference between the two methods of point
addressing, the following section discusses the unique
characteristics of each of them.
3D POINT ADDRESSES
This section on translated addressing is a little confusing, so
you might have to reread this a couple of times to get a good
grasp of it, so hang in there. As was mentioned above, the BOSS
node is where the <point> addresses go to get their mail from, in
this case where those systems who weren't available 24 hours/day
would go to pick up their mail.
From a fundamental level, 3D addressing dictates that <node>
addresses get their mail from a their HUB address. A collection
of HUB's usually form a network or the <net> portion of the
addressing scheme. And then of course a collection of networks
is called a <zone>.
So for those systems that weren't available 24 hours/day, they
could use the <zone> number from the BOSS nodes address, use a
"fake" <net> address created by the BOSS node and then the <node>
portion of the 3D addressing scheme (1st point, 2nd point etc) to
form a complete 3D <zone:net/node> address. Consequently, this
is where the term FakeNet address came from. After all this was
a fake address! Here's how it works.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 148
WILDMAIL! v4 WHAT ARE POINT ADDRESSES
─────────────────────────────────────────────────────────────────
DESIGN CHANGE
As you can see, the 3D method is both cumbersome and awkward to
say the least. In order to overcome this special addressing, a
design change was in order which required a structure change in
not only the way mail was transferred from one system to another,
but in the way the addressing information within the mail packets
(PKT files) was stored. Because of the magnitude of systems
already in use, backwards compatibility was a must!
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 149
WILDMAIL! v4 WHAT ARE POINT ADDRESSES
─────────────────────────────────────────────────────────────────
So a new mail packet type was created and was called an enhanced
TYPE 2 packet (TYPE 2.2). It now uses the old 3D format for
compatibility and simply appends the <point> information to the
end of it. This not only removes the requirement of the FakeNet
method, but also adds in a few other options/features we won't go
into here.
4D ADDRESSING
With this new mail packet type, node addressing now uses the full
4 dimensional <zone:net/node.point> information. No longer was
any translation process required and the associated headaches of
creating FakeNet ID's and so on was also removed. Unfortunately,
pointlists (special nodelist of points) are still required by the
BOSS node and the point, but at least addressing the points was a
bit more efficient now.
In order for systems to make use of this new format, they MUST be
configured to use a TYPE 2.2 mail packet. Remember, the mail
packet type (PKT file) is the format that WILDMAIL! will create
their outbound mail in.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 150
WILDMAIL! v4 USING 4D ADDRESSING FOR POINTS
─────────────────────────────────────────────────────────────────
POINT CONFIGURATIONS
This section defines how to configure your system as either a
BOSS node or as point using 4D addressing. This is by far the
simplest method and the easiest to understand.
IF YOU'RE A BOSS NODE
This is very simple. From the Node Management Screen simply:
1) Define each point that will be picking up mail from you
using their 4D address in <zone:net/node.point> format.
So if your address is 1:161/123, then your:
First point 1:161/123.1
Second point 1:161/123.2 <etc>
2) Set Active Node to Y.
3) Set Mail Type to TYPE 2.2.
4) Set the remaining options for each node accordingly.
As part of the requirements of being a BOSS node, you will now
need to create a POINTLIST of all the addresses that will be
points off of your system. This will need to be compiled with
your front end mailers main nodelist for proper mail transfers.
Please refer to the appropriate section in your mailers
documentation for specifics on incorporating pointlists in with
your primary nodelist.
IF YOU'RE A 4D POINT
From the System Information Screen your should:
1) You should define your Primary Address as your BOSS
nodes address plus your point number. So if your BOSS
nodes address was 1:161/123 and you're the third point
off of their system, then your address would be
1:161/123.3.
2) AKA addresses need not be specified unless you have
another address for a different network. In other
words, no special definition is required.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 151
WILDMAIL! v4 USING 4D ADDRESSING FOR POINTS
─────────────────────────────────────────────────────────────────
From the Node Address Management Screen you should:
1) Define your BOSS nodes address.
2) Set Active Node to Y.
3) Set Mail Type to TYPE 2.2.
4) Set the remaining options accordingly.
From the Conference Management Screen you should define all the
conferences you'll be getting from your BOSS node as follows:
1) Set Active Area to Y.
2) Set the Origin Address to your <zone:net/node.point>
address. (In the previous example this would be
1:161/123.3)
3) Uplink/Feed address should be set to your BOSS nodes
address.
4) Set the remaining options accordingly.
As you can see, setting up points in 4D format is very simple to
do.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 152
WILDMAIL! v4 TROUBLESHOOTING
─────────────────────────────────────────────────────────────────
TROUBLESHOOTING
This section will try an address the most common problems
encountered when running WILDMAIL!. Because of the diversity of
configurations, it's difficult to be precise, but we'll attempt
to cover as much as possible.
COMMON QUESTIONS/PROBLEMS
Question: I am unable to update any information within
WMCONFIG!, why?
Answer: When WMCONFIG! is first executed, it comes up in
Protected Mode. This prevents you from accidently
changing anything. If you wish to make changes,
you must press [F8] to toggle into Edit Mode.
Question: I can not position the cursor to the desired
field, it just skips over it, why?
Answer: Depending on previous options settings, certain
fields may become "protected". This indicates the
field is no longer needed in the current
configuration. Because this is affected by other
settings, you should press [F1] for additional
help information on the options presented to
determine why the field is not needed.
Question: I get an Unable to open Users Database. Status =
9903 error when accessing the Crash Users list,
why?
Answer: The Home directory/path under the WILDCAT!
specific options doesn't contain the necessary
WILDCAT! configuration files for WMCONFIG! to find
the users database. Make sure this path correctly
points to the WILDCAT! home directory.
Question: I get a "CONFDESC.DAT Not Found" message when
pressing [F2] on the WILDCAT! conference option in
Conference Management. Why?
Answer: The path defined for the WILDCAT! Home directory
path option in WILDCAT! specific option doesn't
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 153
WILDMAIL! v4 TROUBLESHOOTING
─────────────────────────────────────────────────────────────────
correctly point to the WILDCAT! home directory.
Consequently, WMCONFIG! can't pull up the
conference information from WILDCAT!. Change this
setting to reflect the correct directory and the
error will go away.
Question: You encounter a message stating "Error closing
Areas database - 10445" when running WMCONFIG!.
Answer: This can occur when WILDMAIL! is already running
and you attempt to run WMCONFIG!. You may not run
WMCONFIG! while WILDMAIL! is running.
Question: I am unable to delete the Origin line with the
asterisk enclosed in parentheses, why?
Answer: This is considered the default Origin line and
WMCONFIG! forces you to always have one. If you
want to change the default (or even delete it) you
will need to create a new one first, make that one
the default and then go back and delete the old
one.
Question: I have a node address defined in the Nodes
database with selected conferences but WILDMAIL!
doesn't create any outbound mail for it, why?
Answer: Check the status flag for that node. If it's
toggled to N, then WILDMAIL! will not forward mail
to it because it's considered inactive.
Question: When WILDMAIL! tosses mail, certain messages end
up in the BADECHO directory, why?
Answer: There are several reasons why this can happen.
First off, if the area name found in the message
doesn't match up to any of the conference areas
defined in the Areas Database, WILDMAIL! will
place it here. Secondly, if you've enabled SEENBY
line checking and certain information is incorrect
or missing, WILDMAIL! will copy them here for your
review.
If the area name wasn't found in the database, you
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 154
WILDMAIL! v4 TROUBLESHOOTING
─────────────────────────────────────────────────────────────────
can always add it as a new area and the next you
execute WILDMAIL! with the TOSS parameter, it will
toss those "bad messages" into its corresponding
conference preventing mail from being lost.
Question: I enter a new message into a conference and the
next time I run WILDMAIL! with the scan option,
the message isn't extracted. Why?
Answer: Within each conference database file, there is a
reserved portion that contains information like
the low and high message numbers, the total number
of messages. In addition, there is field that
contains the number of the message that was last
extracted by WILDMAIL!. For some reason, this
number is higher than the highest message number
in the conference, consequently, WILDMAIL! won't
extract it.
This is easily resolved by executing WILDMAIL!
with the -T command line parameter along with the
necessary conference number, last extract value
etc. For specifics, refer to the section on
command line parameters.
Question: Echomail messages seem to toss and extract
properly, but Netmail messages only appear in my
FrontDoor/InterMail Netmail directory, why?
Answer: If FrontDoor or InterMail is not executed with the
command line parameter -NOUNPACK, then it will
intercept the Netmail messages and toss them.
Once they're tossed there's no way for WILDMAIL!
to know they even existed. To prevent this from
happening, make sure you execute FD or IM with a
minimum of the following command line:
FD -NOUNPACK
or
IM -NOUNPACK
You may have additional parameters, but you must
place the -NOUNPACK parameter if you want the
received Netmail messages to go into WILDCAT!.
Question: When I attempt to enter a message into the Netmail
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 155
WILDMAIL! v4 TROUBLESHOOTING
─────────────────────────────────────────────────────────────────
conference I receive the message:
"Netmail services are currently unavailable"
Why?
Answer: When you configure a conference within MAKEWILD
and use the mail type of NETMAIL, when a message
is entered into that conference WILDCAT! attempts
to use specially created files for looking up the
network address of the person you wish to send the
message to. If these files can't be found, the
message is displayed.
You need to get a copy of the nodelist compiler
for WILDCAT! called WILDNODE. This file is
available for download from the WILDMAIL! support
BBS and is free. Simply follow the installation
instructions for the program and you'll be set.
Question: Because information is stored in the WILDCAT!
message bases regarding High, Low and Last
Extracted message numbers, what happens if I run a
WCRENUM on the message base?
Answer: This question can be answered two ways depending
on the version of WCRENUM you're running.
Pre v3.60 of WILDCAT!
If you haven't upgraded to at least v3.60 of
WILDCAT!, after renumbering the message base, you
must reset the last extract count via the -T
command line parameter. Or you could use our fast
and simple RESETWC program to do this for you.
Resetting the last extract value is a REQUIREMENT
otherwise newly entered messages will not be
extracted.
v3.60 or later of WILDCAT!
Nothing special needs to be done. The version of
WCRENUM that came with WILDCAT! v3.60 or greater
correctly updates this last extract value
requiring no intervention on your part.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 156
WILDMAIL! v4 TROUBLESHOOTING
─────────────────────────────────────────────────────────────────
Question: I'm getting reports from nodes I transfer mail
with that messages originating from my system have
the Origin line truncated. Why?
Answer: If you've recently used the [F4] Global change
option in WMCONFIG! to replace origin lines or
have modified an existing Origin line in the
Origin line database (and let WMCONFIG!
automatically update the conferences that used
it), chances are the one you selected/modified for
the conference in question exceeded the allowable
78 character limitation. If that was the case,
then WMCONFIG! will truncate the Origin
information enough to add in the Origin address
and its required parentheses. To resolve this,
you should go back to the failing conference(s)
and reselect a new Origin line, or edit the
existing one and reduce its length.
Question: When WILDMAIL! is busy tossing mail on my WILDCAT!
system, every once in a while, it displays the
message:
"Unable to add message - Database full"
It then deletes the message and carries on
processing. Why?
Answer: On WILDCAT! systems, each conferences database has
a numerical limitation on the maximum message
number allowed. To be specific, 65,535. This
should not be confused with the actual number of
messages in the database.
To resolve this, you should look at the contents
of your WM.LOG file and see what conference number
this happened on. From there you should run
WCRENUM on that conference and WILDMAIL! will now
toss messages into it properly.
Question: When running WMCONFIG! or WMUTIL! I get an error
message stating the databases are in use.
WILDMAIL! is not running and no other program is
accessing the WILDMAIL! databases. Why?
Answer: For some reason the databases have been left in
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 157
WILDMAIL! v4 TROUBLESHOOTING
─────────────────────────────────────────────────────────────────
use. To clear this, you should execute WMUTIL!
with the /I parameter from the WILDMAIL! directory
and it will reset the inuse flag.
If WILDMAIL! is in use and you use this setting,
unpredictable results can occur and you run the
risk of corrupting information in the databases.
Question: Whenever I execute WILDMAIL!, all my mail is
processed normally, but the netmail messages get
tossed into the BADECHO directory. Why?
Answer: If you don't execute WILDMAIL! with either the
MAILIN or NETMAIL command line parameters, when a
Netmail message is found, it needs to be placed
somewhere, so it's put into the BADECHO directory
until the MAILIN or NETMAIL command line
parameters are used.
Question: All mail both in and out of my system is running
fine, but for some reason AreaRequest is not
processing any of the AreaFix style messages, why?
Answer: First off, for AreaRequest to operate, you must
have previously enabled the option in WMCONFIG!.
Secondly, you should make sure that you are using
the AREAMGR command line parameter when executing
WILDMAIL! as this invokes that function. Finally,
WILDMAIL! will only process those messages that do
not have the RECEIVED flag set. Make sure the
messages have not been received and try again.
Question: My Uplink address is complaining that the <zone>
number is missing from the packet header when
their system receives it. In other words, my
address of 1:161/123 is received as 161/123.
Because of this, his system informs him of a
security violation. Why?
Answer: Because WILDMAIL! supports multiple PKT formats,
you should make sure you are sending mail to their
system using the TYPE 2.2 format. TYPE 2 PKTs do
not support the <zone> information, but are
provided as a method of remaining compatible with
some of the older mail processors in use today.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 158
WILDMAIL! v4 TROUBLESHOOTING
─────────────────────────────────────────────────────────────────
This information is contained in the Node
Management section, for the selected node under
Mail Type.
LOGGING INFORMATION
Depending on how you've defined the level of logging via the
System Information, Log file options setting dictates the amount
of information WILDMAIL! will place into the log file it
generates.
Whenever you encounter any problems, you should always view the
contents of this file because this will typically indicate the
error as WILDMAIL! saw it stating specific information about the
problem and often times can give you a method to resolve it as
well. The higher level of logging, the more likely you'll
understand the problem.
WILDCAT! ERROR.LOG FILE
Because WILDMAIL! tosses directly into the WILDCAT! message
bases, it must observe the rules of the configuration
requirements of WILDCAT!. If there is a problem within WILDCAT!,
WILDMAIL! may too experience the same problem.
Any time you encounter a problem in WILDMAIL!, you should make a
habit of checking the ERROR.LOG file found in the WILDCAT! home
directory and see if any information has been logged there.
Together with that file and the WILDMAIL! log file, you should be
able to put together a reason for the programs acting the way
they did. Then you can resolve the problem with a bit more
insight than just a trial and error method of fixing things.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 159
WILDMAIL! v4 LICENSING AND DISTRIBUTION AGREEMENT
─────────────────────────────────────────────────────────────────
LICENSING AND DISTRIBUTION AGREEMENT
Copyright (C) 1991, 1994 by Integrated Solutions. ALL RIGHTS
RESERVED. COMMERCIAL DISTRIBUTION AND/OR USE PROHIBITED WITHOUT
WRITTEN PERMISSION FROM Integrated Solutions.
Non-Commercial distribution and/or use is permitted under the
following terms:
1) You may copy and distribute copies of WILDMAIL!
executable code as you receive it, in any medium,
provided that you do so in a lawful, friendly manner
and that you conspicuously and appropriately publish on
each copy of each file that is a part of the
distribution package a valid copyright notice:
"Copyright (C) 1991, 1994 by Integrated Solutions. Any
copies that you distribute must be distributed free of
charge to the recipient of the copy. WILDMAIL! may not
be sold and you may not rent or lease it to any other
person."
2) You must keep this License Agreement intact and give
any other recipients of the WILDMAIL! program a copy of
this License Agreement along with the program.
3) You must distribute WILDMAIL! in unmodified form. You
may not add an advertisement for your Bulletin Board
System, User Group, or anything else either as a file
in the distribution packet or as a header in any
archive. You may not add, modify or delete any of the
files in the WILDMAIL! distribution archive.
4) WILDMAIL! must be distributed for free. You may not
charge a distribution fee for the physical act of
transferring a copy of this program. You may not place
this program in any file area of a Bulletin Board
System where a fee is required for download.
5) You may not modify your copy or copies of WILDMAIL! or
any portion of it and you can not copy and distribute
any modifications. WILDMAIL! is distributed in ZIP
format and you may not distribute it in any other form.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 160
WILDMAIL! v4 LICENSING AND DISTRIBUTION AGREEMENT
─────────────────────────────────────────────────────────────────
6) You may not copy, sublicense, distribute or transfer
WILDMAIL! except as expressly provided under this
License Agreement. Any attempt otherwise to copy,
sublicense, distribute or transfer WILDMAIL! is void
and your rights to use the program under this License
agreement shall be automatically terminated.
7) You may not incorporate parts of WILDMAIL! into other
programs without the written permission of Integrated
Solutions. Permission may or may not be granted based
upon a determination of what your intended use is.
8) For the purposes of this document, "COMMERCIAL USE" is
defined as concurrent operation of the software on
three or more computers or data lines owned by the same
for-profit organization. Any organization may operate
this software under the terms of this Non-Commercial
Agreement if operation is limited to two or less
computers or data lines.
9) You may use the software only after understanding and
agreeing upon the above terms.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 161
WILDMAIL! v4 LICENSING AND DISTRIBUTION AGREEMENT
─────────────────────────────────────────────────────────────────
NO WARRANTY
WILDMAIL! v4 IS DISTRIBUTED AS AN EVALUATION COPY ONLY! THIS
PROGRAM REQUIRES THE USE OF A SPECIAL 30 EVALUATION KEY
OBTAINABLE FROM THE WILDMAIL! SUPPORT BBS AT (909) 695-6676. IF,
AT THE END OF THE 30 DAY PERIOD, YOU HAVE NOT REGISTERED THE
PRODUCT, WILDMAIL! WILL SIMPLY CEASE TO RUN. REACTIVATION
REQUIRES THE PLACEMENT OF THE REGISTERED VERSION INTO THE
WILDMAIL! DIRECTORY.
THIS PROGRAM IS GUARANTEED TO DO ABSOLUTELY NOTHING EXCEPT TAKE
UP DISK SPACE. USE IT AT YOUR OWN RISK. NEITHER INTEGRATED
SOLUTIONS NOR ANY OTHER PERSON INVOLVED IN ITS DISTRIBUTION IS
RESPONSIBLE IN ANY WAY, FOR ANY DAMAGES RESULTING FROM ITS USE OR
MISUSE, DIRECTLY OR INDIRECTLY.
THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF WILDMAIL! IS
ENTIRELY WITH YOU. SHOULD WILDMAIL! PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR OTHER DAMAGES TO
YOUR EQUIPMENT, SOFTWARE, OR OTHER PROPERTY.
INTEGRATED SOLUTIONS IS NOT RESPONSIBLE TO YOU FOR DAMAGES,
INCLUDING BUT NOT LIMITED TO, ANY LOST PROFITS, LOST MONIES, OR
OTHER SPECIAL, GENERAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OR INABILITY TO USE (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
LOSSES SUSTAINED BY THIRD PARTIES OR A FAILURE OF THE PROGRAM TO
OPERATE WITH ANY OTHER PROGRAMS) OR ANY OTHER LOSS EVEN IF YOU
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR FOR ANY
CLAIM BY ANY OTHER PARTY.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 162
WILDMAIL! v4 LICENSING AND DISTRIBUTION AGREEMENT
─────────────────────────────────────────────────────────────────
TECHNICAL SUPPORT
You may contact Integrated Solutionsr by logging on to the BBS
for technical support. We can also be reached in the WILDCAT!
conference on Fidonet.
Business hours are 9am-5pm Monday through Fridays PST and our
voice number is (909) 695-6677.
30 DAY EVALUATION COPY
WILDMAIL! v4 is a fully functional, full featured mail processor
for WILDCAT! v4.xx. This program is not disabled in any way but
does require the use of a special 30 day evaluation key. This key
is obtainable by dialing the WILDMAIL! support BBS at the number
listed above.
This temporary key will allow WILDMAIL! to run for 30 DAYS
without registration, after which, the program will simply cease
to run. This should be sufficient time to properly evaluate the
program for fitness prior to its actual registration.
After you register the program, you will receive the registered
version which no longer requires a key file.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 163
WILDMAIL! v4 TECHNICAL SPECIFICATIONS
─────────────────────────────────────────────────────────────────
TECHNICAL SPECIFICATIONS
Because of the complex nature of tossing mail, this section has
been devoted to the requirements and assumptions that WILDMAIL!
v4 operates under.
Memory Requirements
WILDMAIL!'s requires approximately 385K of BASE 640K memory.
It also will use XMS or EMS memory if it's found. For
swapping into XMS/EMS, approximately 385K is required
otherwise swapping will occur to disk.
For database accesses, only EMS memory can be used and
WILDMAIL! uses up everything that it finds. Caution must be
exercised here because in a multitasking environment, this
could be disastrous. To eliminate this problem, in DESQview
you should limit the amount of EMS the window that WILDMAIL!
executes in.
Conference Areas Supported
Because the conference information is stored in a database,
fundamentally there is no limit to the number of conferences
WILDMAIL! can process. The only limitation being the
available disk space.
There is however a limit on the number of conferences
contained within WILDCAT! which is carefully observed.
Node Addresses
As with the conferences, fundamentally there is no limit to
the number of node addresses that may be defined. The only
limiting factor is available disk space.
Downlink Nodes per Conference
WILDMAIL! supports up to 92 node addresses that may be
attached to a specific conference. This means that although
you can easily have more than 92 nodes in the nodes
database, only 92 may be attached to a single conference.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 164
WILDMAIL! v4 TECHNICAL SPECIFICATIONS
─────────────────────────────────────────────────────────────────
Tossing Mail in Date/Time Order
Mail bundles are tossed in date/time order, no matter what
order they are received in, beginning with .SU0, .MO0, etc.
.PKT files are tossed in date/time order also.
Large Messages
Messages that exceed the maximum line limit defined in
MAKEWILD for its respective conference are automatically
split into smaller ones in order to maintain the integrity
of the original message.
In other words, if the incoming message contains 250 lines
and the destination conference is set to 150, the first 146
lines are added to the initial message in WILDCAT! along
with a 4 line prompt indicating the split. WILDMAIL! then
creates a new message using the same TO:, FROM: and SUBJECT:
information and inserts a 4 line prompt (indicating the
message continuation) and then adds the remaining 104 lines.
WILDMAIL! will automatically add as many new messages as
required to toss the original message into the WILDCAT!
conference. It should be noted that the split is only done
with the mail going into your WILDCAT! message conferences.
Any messages (exceeding the conference length limit)
forwarded to your downlink nodes will not be split and thus
left completely intact.
No Content/Null Messages
A NO CONTENT message (null message) is defined as any
message not having any text body. WILDMAIL! creates these
as Netmail messages used to transmit the outbound echomail
archives.
Some systems may not be able to support "null messages" that
contain the INTL kludge line information in the body of the
Netmail message, but WILDMAIL! generates fully compatible
null Netmail messages.
Maximum AKA Addresses . . . . . . . . . . . . . . . . . . . . 20
Maximum Forward Lists . . . . . . . . . . . . . . . . . . . . 20
Maximum Zone Assignments . . . . . . . . . . . . . . . . . . 20
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 165
WILDMAIL! v4 APPENDIX A - ARCA/ARCE
─────────────────────────────────────────────────────────────────
APPENDIX A - PACKER/UNPACKER PARAMETERS
The following is a reference section devoted to assisting you in
deciding which command line parameters are necessary when
defining your packer types. It is recommended to always use the
overwrite feature of the unpacker. This prevents system hangs
due to the prompt waiting to confirm an overwrite.
ARCA v1.28
10/4/87. ALL RIGHTS RESERVED
Copyright (c) Wayne Chin and Vernon Buerg 1986-87
===================================================
Usage: ARCA [d:][\path]ArchiveName[.ARC]
[d:][\path]FileName[.Ext] [/D]
Use /D to delete files after adding to archive
Filenames may contain * and ? wildcards
ARCE v3.1b
Extract ARC files 9/16/87. ALL RIGHTS RESERVED.
Copyright (c) 1986-87 by Wayne Chin & Vernon D. Buerg
======================================================
Usage: ARCE d:path\filename.ext [filespecs..]
[d:\outpath][/R][/P][/Q][/T] [/Gpswd]
d: = drive and path are optional
ext = defaults to .ARC
/R = specifies reuse existing files
/P = extracts files to standard output
/Q = suppresses beeps and bells
/T = test archive integrity only
/G = supplies encryption password, e.g. /Gpswd
NOTE: The /R parameter is highly recommended to
overwrite existing files in case WILDMAIL!
encounters tossing difficulties. See above for
additional details.
System Enhancement Associates
21 New Street, Wayne NJ 07470
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 166
WILDMAIL! v4 APPENDIX A - PKARC/PKXARC
─────────────────────────────────────────────────────────────────
PKARC v3.5
Archive Create/Update Utility 04-27-87
Copyright (c) 1986,1987 PKWARE Inc. All Rights Reserved.
========================================================
Usage: PKARC [-oct,-nct] options[g<passwrd>] archive
[filename...]
Options are:
-a = add files to archive
-d = delete files from archive
-f = freshen files in archive
-m = move files to archive
-u = update files in archive
-v = verbose listing of archive
-l = display software license
-c = add/update file comments
-x = add archive comment
-oct,nct = old/new compatibility
-g = encrypt w/password
-c = compression,
-t = timestamping
PKXARC v3.5
Archive Create/Update Utility 04-27-87
Copyright (c) 1986,1987 PKWARE Inc. All Rights Reserved.
========================================================
Usage: PKXARC [options] archive [d:path\] [file...]
Options are:
-r = replace existing files
-v = verbose listing of archive(s)
-c = extract file(s) to screen
-p = extract file(s) to printer
-t = test archive integrity
-l = display software license
-e,-x = extract file(s)
-g<password> = extract garbled file w/password
NOTE: The -r parameter is highly recommended to overwrite
existing files in case WILDMAIL! encounters tossing
difficulties. See above for additional details.
PKWARE, Inc.
9025 N. Deerwood Drive
Brown Dear, WI 53223
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 167
WILDMAIL! v4 APPENDIX A - PKPAK
─────────────────────────────────────────────────────────────────
PKPAK Version 3.61
Archive Create/Update Utility 08-02-88
Copyright (c) 1986-1988 PKWARE Inc. All Rights Reserved.
=========================================================
Usage: PKPAK [-b[path]] [-o,-n] options[g<passwrd>]
archive [files...]
<Options>
-a = add files to archive
-b = create tmp archive on alternate drive
-c = add/update file comments
-d = delete files from archive
-f = freshen files in archive
-g = encrypt with password
-i = add changed files to archive
-l = display software license
-u = update files to archive
-x = add archive comment
-v[m][c] = verbose listing of archive [with more]
[with file comments]
-m[a,f,u] = move [with add/freshen/update] files to
archive
-o[c][t],
-n[c][t] = old/new compatibility,
[compression][timestamping]
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 168
WILDMAIL! v4 APPENDIX A - PKUNPAK
─────────────────────────────────────────────────────────────────
PKUNPAK Version 3.61
Archive Create/Update Utility 08-02-88
Copyright (c) 1986-1988 PKWARE Inc. All Rights Reserved.
=========================================================
Usage: PKUNPAK [options] archive [d:path\] [file...]
<option>
-c[m] = extract to screen [with more]
-e,-x = extract file(s) (default)
-g<password> = decrypt with password
-l = display software license
-n = extract only newer files
-p[a,b] = extract file(s) to printer [ascii mode,
binary mode]
-r = replace existing files
-t = test archive integrity
-v[v] = verbose list of archive(s) [made by]
NOTE: The -r parameter is highly recommended to
overwrite existing files in case WILDMAIL!
encounters tossing difficulties. See above for
additional details.
PKWARE, Inc.
9025 N. Deerwood Drive
Brown Dear, WI 53223
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 169
WILDMAIL! v4 APPENDIX A - ARJ
─────────────────────────────────────────────────────────────────
ARJ 2.30
Copyright (c) 1990-92 Robert K Jung. Jan 19 1992
All Rights Reserved. ARJ file compression archiver utility.
===========================================================
Usage: ARJ <command> [-<sw> [-<sw>...]] <archive_name>
[<file_names>...]
List of frequently used commands and switches.
<Commands>
a = Add files to archive
m = Move files to archive
d = Delete files from archive
t = Test integrity of archive
e = Extract files from archive
u = Update files to archive
f = Freshen files in archive
v = Verbosely list contents of archive
l = List contents of archive
x = Extract files with full pathname
<Switches>
-c = skip time-stamp Check
-n = only New files (not exist)
-d = with Delete (move)
-r = Recurse subdirectories
-e = Exclude paths from names
-u = Update files (new and newer)
-f = Freshen existing files
-v = enable multiple Volumes
-g = Garble with password
-w = assign Work directory
-i = with no progress Indicator
-x = Exclude selected files
-m = with Method 0, 1, 2, 3, 4
-y = assume Yes on all queries
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 170
WILDMAIL! v4 APPENDIX A - LHARC
─────────────────────────────────────────────────────────────────
LHARC v1.13c
Copyright (c) Haruyasu Yoshizaki, 1988-89
High-Performance File-Compression Program - 05/31/89
====================================================
Usage: LHARC [<command>] [{{/|-}{<switch>[-|+|2|<option>]}}]
<archive_name> [{<drive_name>:}|
{<home_directory_name>\}] [<path_name> ...]
<command>
a = Add files to archive
u = Update files to archive
f = Freshen files in archive
m = Move new files into archive
d = Delete files from archive
e,x = Extract files from archive
p = disPlay files in archive
l,v = View List of files in archive
s = make a Self-extracting archive
t = Test integrity of archive
<switch>
-r = Recursively collect files
-w = assign Work directory
-x = allow Extended file names
-m = no Message for query
-p = distinguish full Path names
-c = skip time-stamp Check
-a = allow any Attributes of files
-v = View files by another utility
-n = display No indicator
-k = Key word for AUTOLARC.BAT
-t = archive's Time-stamp option
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 171
WILDMAIL! v4 APPENDIX A - LHA
─────────────────────────────────────────────────────────────────
LHA version 2.13
Copyright (c) Haruyasu Yoshizaki, 1988-91
A High-Performance File-Compression Program - 07/20/91
======================================================
Usage: LHA <command> [/option[-+012|WDIR]]
<archive[.LZH]>
[DIR\] [filenames]
<command>
a = Add files u = Update files
m = Move files f = Freshen files
d = Delete files p = disPlay files
e = Extract files l = List of files
x = Extract files with pathnames
v = View listing of files with pathnames
s = make a Self-extracting archive
t = Test the integrity of an archive
<option>
/r = Recursively collect files
/w = assign Work directory
/x = allow Extended file names
/m = no Message for query
/p = distinguish full Path names
/c = skip time-stamp Check
/a = allow any Attributes of files
/z = Zero compression (only store)
/t = archive's Time-stamp option
/h = select Header level (default = 1)
/o = use Old compatible method
/n = display No indicator a/o pathname
/i = not Ignore lower case
/l = display Long name with indicator
/s = Skip by time is not reported
/- = '@' and/or '-' as usual letters
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 172
WILDMAIL! v4 APPENDIX A - PAK
─────────────────────────────────────────────────────────────────
Usage: PAK <command> [/opt] [/opt..] <archive name>
[file]
<command>
A = Add files to archive
M = Move files to archive
U = Update archive files
F = Update duplicate files
E = Extract files from archive
X = Move files from archive
D = Delete files
L = List files
V = List files
P = Display files
T = Test files
C = Convert files
R = Revise remarks
<option>
/C = use Crunching compression
/S = use Squashing compression
/G = Garble with password
/M = Move files
/D = Duplicate files only
/R = with Remarks
/P = Pack archives
/ON = Sort by Name
/OT = Sort by time
/OS = Sort by Size
/OE = Sort by extension
/O- = no sort
/WA = Write over Always
/WP = Prompt Write over
/WO = Write over Older
/WN = Never Write over
/T = set Temporary path
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 173
WILDMAIL! v4 APPENDIX A - PKZIP
─────────────────────────────────────────────────────────────────
PKZIP (R) v1.10
Copr. 1989-1990 PKWARE Inc. All Rights Reserved.
Reg. U.S. Pat. and Tm. Off. Create/Update Utility 03-15-90
==========================================================
Usage: PKZIP [-b[path]] [options] zipfile [files...]
<options>
-d = delete files -l = display license info
-a = add files -c = add/edit file comments
-k = keep same ZIP date -q = enable ANSI comments
-r = recurse subdirs -z = add zipfile comment
-i = add changed files -f = freshen files
-u = update files
-b = create temp zipfile on alternate drive
-C = add comments to new files only
-o = set ZIP date to latest file
-m[u,f] = move files
-s<pwd> = Scramble files with password
-$[drive] = save volume label
-t[mmddyy] = Compress files on or after specified date
(default=today)
-e[x,i,s] = use maximal compression/Implode only/Shrink
only
-<p|P> = store pathnames | p=recursed into |
P=specified & recursed into
-<w|W><H,S> = | w=include | W=don't include | Hidden &
System files
-<j|J><H,S,R> = | j=mask | J=don't mask | Hidden/System &
Readonly attributes
PKWARE, Inc.
9025 N. Deerwood Drive
Brown Dear, WI 53223
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 174
WILDMAIL! v4 APPENDIX A - UNPKZIP
─────────────────────────────────────────────────────────────────
PKUNZIP (R) v1.10
Copr. 1989-1990 PKWARE Inc. All Rights Reserved.
Reg. U.S. Pat. and Tm. Off. Create/Update Utility 03-15-90
==========================================================
Usage: PKUNZIP [options] zipfile [d:outpath\] [file...]
<options>
-c[m] = extract to screen [with more]
-t = test zipfile integrity
-d = create directories stored in ZIP
-l = display software license
-n = extract only newer files
-o = overwrite existing files
-q = enable ANSI in comments
-s<pwd> = unscramble with password
-f = extract only newer & existing files
-$ = extract volume label if in ZIP
-p[a,b,c][1,2,3] = extract to printer [Asc mode,Bin
mode,Com port] [port #]
-<j|J><H,S,R> = | j=mask | J=don't mask | Hidden,
System/Readonly attributes
-e[c,d,e,n,p,s] = extract files in CRC/Date/Ext/Name &
Percentage/Size order
NOTE: The -o parameter is highly recommended to overwrite
existing files in case WILDMAIL! encounters tossing
difficulties. See above for additional details.
PKWARE, Inc.
9025 N. Deerwood Drive
Brown Dear, WI 53223
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 175
WILDMAIL! v4 APPENDIX A - ZOO
─────────────────────────────────────────────────────────────────
ZOO archiver v2.00
(1988/02/06 21:24:14)
(C) Copyright 1988 Rahul Dhesi Noncommercial use permitted
===========================================================
Novice usage: ZOO <-cmd> archive[.zoo] file...
Where <-cmd> = -add -extract -move -test -print -delete
-list -update -freshen -comment
Usage: ZOO <command> [option] archive
<command>
a = add files P = pack archive
c = update comments T = fix archive datestamp
D = delete stored files u = add only newer files
e,x = extract files U = undelete stored files
l,L,v,V = list filename g = adj. gen. limit/count
<options>
-a = show archive name(s) in listing
-A = apply g or c to archive
-c = add/list comments
-d = extract/list deleted files too
-dd = extract/list only deleted files
-E = erase backup after packing
-f = fast add (no compression) or list
-M = move when adding (erase original)
-n = add only files not already in archive
-N = send extracted data to Neverland
-O = don't ask "Overwrite?"
-q = be quiet
-p = pipe extracted data to standard output
-: = don't store dir names
-/,// = extract full pathnames
-. = pack to current dir
-I = add filenames read from stdin
-C = show file CRC value
-+/- = enable/disable generations
-S = overwrite newer files
-g = list generation limits
-P = pack after adding
-@n = start extract/list at position n
NOTE: The -O parameter is highly recommended to overwrite
existing files in case WILDMAIL! encounters tossing
difficulties. See above for additional details.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 176
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
This section is offered as a reference when using WILDMAIL! with
the front end mailer called FrontDoor. This is a very popular
mailer and can be downloaded from just about any BBS under the
name of FD202.ARJ. The current version as of this writing is
v2.02.
This section is devoted to the associated batch files and NOT the
actual setup of FrontDoor via the FDSETUP program. For specific
information on FDSETUP, refer to its author for technical
support.
Again, the information presented here is for reference only! We
can not offer support on FrontDoor, but we have included this
section due to its popularity.
ASSOCIATED BATCH FILES
FrontDoor can be run standalone, but for use with WILDMAIL! it
MUST be run from a batch file. This file for our example
purposes will be called CAT.BAT.
When using FrontDoor/WILDMAIL!/WILDCAT!, there are three batch
files involved in this process. These files all exist in the \FD
directory. Shown below is a brief description of these files.
CAT.BAT - This is the main batch file used when running
FrontDoor. After this file has been
executed, FrontDoor will be ready to receive
calls and if a human caller is detected, it
will then pass control to DOBBS.BAT via the
DOS CALL command.
DOBBS.BAT - When a human caller is detected, FrontDoor
will create this file in the \FD directory
overwriting the previous DOBBS.BAT file and
exit with a errorlevel 100. This is a one
line batch file that executes EXEBBS.BAT and
contains information that will be passed to
WILDCAT! for proper operation.
EXEBBS.BAT - This is the main batch file used to execute
WILDCAT! This file will test the contents of
DOBBS.BAT for specific character strings for
use in determining whether or not this is a
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 177
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
reliable connection. This information is
then passed onto WILDCAT! to enable/disable
the error correcting type protocols.
SYSTEM FLOW
The basic flow of these batch files when a human caller connects
to FrontDoor is as follows.
CAT.BAT -> DOBBS.BAT -> EXEBBS.BAT (then return to CAT.BAT).
When CAT.BAT is executed, FrontDoor will be brought up and will
be waiting for calls. When a human caller connects and FrontDoor
displays the "Press Escape twice for WILDCAT!" message and after
pressing escape twice, FrontDoor will drop with a errorlevel 100
and create a batch file called DOBBS.BAT in the \FD directory.
This batch file contains information on the connect speed, com
port, time remaining until FrontDoor's next event and a possible
reliable connect mode string if the modem returned one.
In the CAT.BAT file, after dropping with a errorlevel 100, the
batch file will instruct it to use the CALL command when
executing DOBBS.BAT. This will ensure that when DOBBS.BAT is
finished executing, it will return program execution to CAT.BAT.
DOBBS.BAT then executes a batch file called EXEBBS.BAT which in
turn tests for various reliable connect strings and then executes
the appropriate command line to bring up WILDCAT!
When the caller logs off the BBS, WILDCAT! will terminate and
program flow will return to EXEBBS.BAT. This file basically just
"ends" and returns to the batch file that executed it called
DOBBS.BAT and since there was only one line to that batch file,
it will then return to the CAT.BAT file and continue to the NEXT
line AFTER executing the CALL command and continue on. The
program flow will return to the main loop and bring FrontDoor
back up waiting for calls.
If a mail call happens, the basic flow will remain in CAT.BAT and
execute WILDMAIL! for processing and then return to FrontDoor.
For additional information on this process, refer to the section
regarding the CAT.BAT file.
This may sound a little complicated, but in the following
examples, we will try and make more sense out of this.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 178
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
Below is a sample batch file used to run FrontDoor as a front end
mailer for WILDCAT! v3.x. Throughout the example batch files,
line numbers are shown to the immediate left with the > symbols.
ie. 23> refers to line 23. They DO NOT EXIST in the actual batch
file.
1> @echo off
2> cls
3> SET FD=c:\fd
4> SET WCNODEID=1
5> SET WCMDM=USRHST
6> :START
7> c:
8> cd\fd
9> fd -NOUNPACK
10> IF ERRORLEVEL 100 goto RUN-BBS
11> IF ERRORLEVEL 90 goto SCAN-TOSS
12> IF ERRORLEVEL 80 goto LOCAL-BBS
13> IF ERRORLEVEL 1 goto EXIT
14> IF ERRORLEVEL 0 goto EXIT
15> goto START
16> :RUN-BBS
17> call DOBBS.BAT
18> goto START
19> :SCAN-TOSS
20> cls
21> c:
22> cd\wildmail
23> wm toss scan netmail
24> goto START
25> :LOCAL-BBS
26> c:
27> cd\wc30
28> wildcat /B LOCAL
29> goto START
30> :EXIT
The following descriptions of this batch files assumes some
understanding of how to create and use batch files. The batch
files used in these examples make use of 2 important DOS
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 179
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
commands, the IF ERRORLEVEL/GOTO and the LABEL commands. Please
refer to the appropriate DOS manual for specifics if necessary.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 180
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
CAT.BAT FILE
Line #1 - Simply turns off all display for each command that's
executed from this file.
Line #2 - This clears the screen.
Line #3 - Sets environment variable FD equal to the path where
all the FrontDoor system files are located and is
required by FrontDoor.
Line #4 - Lines #4 and #5 are used for WILDCAT! to set the Node
ID and the appropriate modem definition file (.MDM) to
use for operation when WILDCAT! is executed.
Line #6 - This is the MAIN PROGRAM LOOP label.
Line #7 - Changes to the appropriate drive letter. You will need
to specify here which one is required for your system.
Line #8 - Change directories to the location of the FrontDoor
program files.
Line #9 - This line actually executes FrontDoor. Notice the
command line parameter, -NOUNPACK. This command is
used to make sure netmail messages are properly tossed
into WILDCAT! If this parameter is NOT used, FrontDoor
will grab these messages and toss it into its own
internal message base and delete them before WILDMAIL!
can properly process them.
Line 10 - This line tests to see of the errorlevel returned by
FrontDoor when it exited equals the value of 100. If
it does, then it will 'goto' the label called RUN-BBS
in line #16. This will start the process of bringing
up the BBS. This is desired when a caller connects and
presses the Escape key twice.
Line 11 - This functions exactly the same was as line #10 does,
except it will 'goto' a label called SCAN-TOSS on line
#19. This is used with the active events 'behavior'
option when preparing to process the incoming mail.
Normally, after mail has been received, FrontDoor will
drop with this errorlevel (any number can be specified,
but must be defined in FDSETUP) and then jump to line
#19 to start execution of WILDMAIL!
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 181
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
Line 12 - Same as line #10 except tests for an errorlevel of 80
and if so, jumps to the label called LOCAL-BBS on line
#25. This is a user defined errorlevel used to bring
up the BBS in local mode. This value is defined in
FDSETUP, under Mailer, Function Keys and is normally
the F1 key to remain consistent with WILDCAT!'s SysOp
logon. This option is presented here as a convenience
and is not required for proper operation.
Line 13 - Lines #13 and #14 are used to test for abnormal/normal
shutting down (Alt-Q) of FrontDoor. These lines will
jump to the label called EXIT on line #30 and will
return you to the DOS prompt. This is a normal exit
routine.
Line 15 - This line is a simple safety valve used to restart
FrontDoor in case one of the errorlevels didn't match
the ones that were included here. Typically, this is
some sort of abnormal exit from FrontDoor, and instead
of ending up at the DOS prompt, this will attempt to
restart FrontDoor.
Line 16 - Lines #16, #17 and #18 are used when a human caller is
detected and will used to bring up the BBS. This line
contains the label for the MAIN LOOP when FrontDoor
drops with an errorlevel 100 from line #10.
Line 17 - This line executes the DOBBS.BAT batch file created
when FrontDoor exited with a errorlevel 100. The CALL
command is used here to ensure that when DOBBS.BAT is
finished executing, it will RETURN TO LINE #18 of this
file. Without the CALL command, when DOBBS.BAT was
finished executing, it would simply drop to the DOS
prompt. NOT GOOD!
Line 18 - After DOBBS.BAT is finished executing, it will return
to this line and then 'goto' the label called START on
line #6. This will complete the process of the caller
logging off the BBS and preparing to restart FrontDoor
and be ready to take additional calls.
Line 19 - This is the main WILDMAIL! program loop for processing
mail.
Line 20 - Clears the screen.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 182
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
Line 21 - Changes to the drive where the WILDMAIL! subdirectory
is located.
Line 22 - Changes to the WILDMAIL! subdirectory where all the
configuration and executable files are located.
Line 23 - Executes WILDMAIL! with the TOSS SCAN command line
parameters. This will start the actual processing of
mail.
Line 24 - This terminates the mail processing loop and restarts
FrontDoor by jumping to a label called START in line
#6.
Line 25 - The is the main LOCAL LOGON loop's label. This
'subroutine' is executed when FrontDoor drops with a
errorlevel 80 from line #12. This is used to allow
local logons to the BBS when the appropriate function
key has been pressed while FrontDoor is up and waiting
for calls.
Line 26 - Changes to the drive where WILDCAT! is located.
Line 27 - Changes to the subdirectory containing all the WILDCAT!
files.
Line 28 - Executes WILDCAT! using the options set in line #4 with
the /B LOCAL command parameters for allowing local
logons.
Line 29 - After normal logoff, FrontDoor is brought back up by
returning to line #6.
Line 30 - This is the label used when FrontDoor is brought down
via lines #13 or #14. This is the last line in the
batch file and thus will return you to the DOS prompt.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 183
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
DOBBS.BAT FILE
FrontDoor MUST BE configured to drop with a errorlevel 100 on ALL
POSSIBLE CONNECT SPEEDS and create the .BAT file. This
information is found in FDSETUP under Mailer, Errorlevels.
This is a one line batch file created by FrontDoor and will
change from caller to caller. Shown below is a sample of this
file.
EXEBBS 9600 1 897 /ARQ/V32/LAPM/V42BIS
^^^^^^ ^^^^ ^ ^^^ ^^^^^^^^^^^^^^^^^^^^
%0 %1 %2 %3 %4 <----- DOS Variables
Below is a breakdown of the above command line.
%0 = Command that DOS will execute
%1 = Connect speed determined by FrontDoor
%2 = Communications port
%3 = Minutes remaining until next event
%4 = Reliable mode connect string (if applicable)
This line will execute a file called EXEBBS.BAT in the \FD
directory passing the speed as 9600 (%1), com port 1 (%2), 897
minutes (%3) until the next FrontDoor event and the connect
string of /ARQ/V32/LAPM/V42BIS (%4). The contents of EXEBBS.BAT
will then take this information and properly evaluate it and then
execute it for proper operation in WILDCAT!
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 184
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
EXEBBS.BAT FILE
This batch file is used primarily to bring up WILDCAT! with the
parameters passed from the calling batch file called DOBBS.BAT.
The information contained in DOBBS.BAT is used to 'set up'
WILDCAT! for the proper speed, time remaining before any
FrontDoor events and whether or not this is a reliable
connection.
Sample EXEBBS.BAT file for use with FrontDoor.
1> @echo off
2> cls
3> SET comspec=c:\command.com
4> SET connect=
5> if %4 == /ARQ SET connect=/MNP
6> if %4 == /ARQ/HST SET connect=/MNP
7> if %4 == /ARQ/V32 SET connect=/MNP
8> if %4 == /ARQ/LAPM SET connect=/MNP
9> if %4 == /ARQ/MNP SET connect=/MNP
10> if %4 == /ARQ/HST/HST SET connect=/MNP
11> if %4 == /ARQ/LAPM/V42BIS SET connect=/MNP
12> if %4 == /ARQ/MNP/MNP5 SET connect=/MNP
13> if %4 == /ARQ/HST/HST/MNP5 SET connect=/MNP
14> if %4 == /ARQ/HST/HST/V42BIS SET connect=/MNP
15> if %4 == /ARQ/V32/LAPM/V42BIS SET connect=/MNP
16> if %4 == /ARQ/V32/MNP SET connect=/MNP
17> if %4 == /ARQ/V32/LAPM/MNP/MNP5 SET connect=/MNP
18> :START
19> c:
20> cd\wc30
21> ctty con
22> wildcat /B %1%connect% %3
InterMail Systems
In the above example you should note that all of the connect
strings are in upper case. Since InterMail operates
virtually identically to FrontDoor, it has this little quirk
in this it only uppercases the first character of the
connect string. Since the batch == command is case
sensitive, it's imperative that you understand theses
differences.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 185
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
EXEBBS.BAT FILE
Line #1 - Simply turns off all display for each command that's
executed from this file.
Line #2 - This clears the screen.
Line #3 - This is safety measure to make sure DOS knows where to
look for COMMAND.COM.
Line #4 - This is a very important DOS environment variable.
This is used to pass the /MNP flag associated with the
current connection to WILDCAT! to indicate whether or
not this is a reliable connect. If this flag is set,
WILDCAT! will make the Ymodem/G and 1K-Xmodem/G
protocols available to the caller. For now, we are
turning the flag off (actually removing the variable
entirely) because we will test the connect string for a
reliable connect in lines #5 through #17.
Line #5 - Lines #5 through #17 are used to test the connect
string information passed to us from the DOBBS.BAT
file. If you refer to the section on the DOBBS.BAT
file, note that this is DOS environment variable %4.
Here we test for a exact match of the string supplied,
if there is a match, we will turn on the flag used in
line #4 (connect=) via the SET command, to now equal
/MNP. If no match is found, the environment variable
'connect' will be untouched.
The strings in these lines are ones outputted by your
modem. You will need to review each possible
combination for your EXACT modem type. The ones shown
here are for the older USR Dual Standards without
v.32bis. The strings you enter must be the ones that
are a EXACT MATCH and indicate a reliable connect.
Some modems use a simple /REL and others may be more
complex.
Line 18 - The MAIN PROGRAM LOOP for bringing up WILDCAT!
Line 19 - Changes to the drive where WILDCAT! is located.
Line 20 - Changes to the subdirectory containing all the WILDCAT!
files.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 186
WILDMAIL! v4 APPENDIX B - FRONTDOOR/INTERMAIL SYSTEMS
─────────────────────────────────────────────────────────────────
Line 21 - Redirects output to the CONsole. This is a safety
valve to make sure there are not conflicts as to where
data is to be outputted to. This line is not normally
needed, but is here in case a DOOR program goes nuts on
you.
Line 22 - This is the main command line that executes WILDCAT!
The /B parameter is required and indicates that a front
end mailer is used with this configuration and to look
for additional command line information that is passed.
If you recall in the DOBBS.BAT file, the DOS
environment variable %1 indicated connect speed. The
'%connect%' parameter is the reliable connect flag used
in lines #4 through #17 and %3 is the time remaining
until the next FrontDoor event.
To help understand this, we will use the contents of
the example DOBBS.BAT file The command on line #22;
wildcat /B %1%connect% %3
will be replaced with the parameters passed in
DOBBS.BAT and will now look like:
wildcat /B 9600/MNP 897
This indicates a reliable connection at 9600 baud with
897 minutes left until the next FrontDoor event. A
match was found on line #15 so the DOS environment
variable 'connect' now equals /MNP. If there wasn't a
match in lines #5 through #17, the command line would
read:
wildcat /B 9600 897
You will notice the /MNP parameter is now missing and
WILDCAT! will not allow the Ymodem/G and 1K-Xmodem/G
protocols.
When the caller logs off the BBS, either normally, or by dropping
carrier, WILDCAT! will exit and return to the EXEBBS.BAT file.
Since there are no remaining lines in this batch file to execute,
the program flow will return to DOBBS.BAT, and since there are no
more lines to execute in the DOBBS.BAT file, it will return to
the CAT.BAT file, line #18. This will then 'goto' line #6 and
restart FrontDoor completing our 'human caller loop'.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 187
WILDMAIL! v4 APPENDIX C - WHAT IS NETMAIL/ECHOMAIL?
─────────────────────────────────────────────────────────────────
APPENDIX C - WHAT IS NETMAIL/ECHOMAIL?
There is a lot confusion and misunderstanding of these two
distinctly different types of mail especially by newcomers to the
BBS arena. This section will attempt to clarify these two terms
into something a bit more palatable than just saying Netmail
means direct and Echomail means going from system to system
before reaching its destination.
System Addressing
Within the original designs of Fidonet style mail transfers, a
method was needed to differentiate one system from another. This
was done in the form of system addressing meaning that each PC in
the network would be assigned a unique number (or address)
different from any other PC in the network. Today, this is
typically done in the standard <zone:net/node.point> or 4
dimensional addressing method.
Now that each PC had a address, a message could be sent to that
address in a manner similar to the way the post office can
forward letters from across town or out of state to our home
address based upon the address on the letter. This manner proved
very effective and as long as systems were running 24 hours a
day, a message could be sent literally any time of the day or
night.
File Attachments
This is where Netmail originally started. You could create a
message on your system and address it to a person and send it
directly to the destination system. Because this method proved
so effective, people were not content with just sending a message
anymore, they wanted to be able to send a file along with the
message. So special information was added to the Netmail message
to inform the front end mailer that when it would send the
Netmail message, it should also send the file that was "attached"
to it.
Sharing Message Bases
Things were really starting to cook with this new technology!
Well, as things would have it, someone came up with the bright
idea that wouldn't it be nice to have the same message base on
one system (let's call it System #1) as on another (or System
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 188
WILDMAIL! v4 APPENDIX C - WHAT IS NETMAIL/ECHOMAIL?
─────────────────────────────────────────────────────────────────
#2). This means more people could have access to the same
information on System #2 without having to call System #1 that
the messages originated from.
Since we could already attach files to a Netmail message
addressed to a specific system, why don't we just bundle up the
entire message base and send it to the other system. Sure! It
would be real easy to do, but what if people wanted to reply to
those messages? They would have to call the system the messages
originated from (System #1) and leave the replies there. That
was nice but people being lazy as they are, a better plan was
needed. So the first thought was that System #2 could just send
back the entire message database the following day. But that
wouldn't work because if System #1 had any new messages entered
in its message base, they would be lost.
Then the bright idea come to light. Lets just send any "new"
messages entered and not the entire message database. This just
might work! All they had to do was take all the new messages,
bundle them up into a special file, attach it to a Netmail
message and send it to the other system. Now they were cooking!
So System #2 could send out any new messages to System #1 and
System #2 could send any new messages to System #1. Now both
systems would have identical message databases. This was great!
To say the idea caught on would be a understatement to say the
least. Now two entirely different PC's could share the same
message database.
Once the word got out about this new technology, more and more
BBS's wanted to join in. All they had to do was schedule a time
when they could send the new messages created on their system
back to the originating system and pick up any new messages
created on that system. With all this new technology, new
problems started to crop up, like how to control duplicate
messages and who could participate in this and so on.
Another major problem was with all these other systems
participating, the message traffic really started to grow.
That's when the idea came about of having special message
"sections" or conferences that pertained to specific topics of
interest thereby focusing the conversations. Well this solved
one problem, but because more and more people wanted to join in,
the originating system was now spending more time transferring
mail to other systems and none was left over for the regular
callers on the BBS. Still yet another problem was all these
other systems were having to call long distance just to pick up
the new messages!
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 189
WILDMAIL! v4 APPENDIX C - WHAT IS NETMAIL/ECHOMAIL?
─────────────────────────────────────────────────────────────────
Hub Creation
It was decided that since systems were usually grouped close to
each other, they could send mail to all the members of that group
and then someone from that group would be responsible for sending
the new messages back to the originating system and picking up
any new one created from the other systems. This would free up
the originating system from all the individual BBS's calling and
transferring mail and limit its use only to those BBS's that
would feed a group of other systems. Thus the birth of Echomail.
These BBS's that would "feed" the group of systems in their area
were called Hubs and the individual systems within the group were
called Nodes. This idea took off like wild fire. After all,
instead of calling long distance, they could place a local call
and pick up the same new messages as if they called the
originating system. This was ideal!
Well, as life would have it, another major problem cropped up.
With so many Hubs trying to get mail for their Nodes, it was
becoming increasingly difficult for the Hubs to transfer mail
with the originating system. So networks were created. These
were groups of Hubs that would get their mail (for their Nodes)
from one central place that would then call the originating
system for mail. This effectively reduced the number of Hubs
calling the originating system and now only the networks or Area
coordinators (as they were called) would call the originating
system. The Hubs would then call the Area coordinators to get
their mail to feed their Node addresses.
Now, bringing us up the current mail technology, the principals
are the same only with a few more "layers" of mail travels, but
the basic method is still the same, one system calls another and
"echoes" the mail to a group of downlink systems which then in
turn forward it onto other systems. Eventually, it makes it into
the hands of the callers of the BBS's for their usage.
Something that's been intentionally left out in this discussion
is the groups of message areas or conferences. As was mentioned
earlier, these were conference areas devoted to a specific topic
of discussion, so if you wanted to discuss automotive repair, you
wouldn't want to leave a message in the gardening conference.
Not all the systems in the network would want to carry all the
conferences as this could easily exceed the available disk space
on the smaller systems. So most BBS don't carry all the
available conferences, but rather only the ones that pertain to
the main "focus" of the BBS itself.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 190
WILDMAIL! v4 APPENDIX C - WHAT IS NETMAIL/ECHOMAIL?
─────────────────────────────────────────────────────────────────
Netmail Definition
So lets do a recap on what we've learned already. Netmail is a
method by which a special message originating on one system could
be sent to another system directly. In other words there would
be an Originating Address and a Destination Address on each
message generated (not to mention the TO: and FROM: names of the
message itself).
The Destination address of the message is what's used to send it
on its way to its destination system. Netmail messages also have
the ability to have special file attachments so when the Netmail
message is sent to the destination system, the attached file is
also transmitted at the same time.
Typically, when a file is attached to a Netmail message, the body
of the actual Netmail message itself is usually blank, but may
also contain text for the person it's addressed to at the
destination system. In other words, the Netmail message itself
may or may not contain text. If it doesn't contain text, then
usually the message is addressed to the actual BBS and not a
specific person. These were typically referred to as "null"
messages.
Echomail Definition
As was previously mentioned, echomail was the actual "contents"
of the message bases of the systems participating in the network
of BBS's sending and receiving mail. This included all the
individual conferences (or message topics) as well. These
messages were usually bundled up and compressed into a file and
attached to a Netmail message to be sent to the various systems
within the network.
Echomail messages therefore have no specific means designed into
them to indicate they should go to a specific network address.
They relied ENTIRELY on the use of Netmail messages to send them
on their way. Remember, these were the message bases that were
being echoed from system to system to update the nodes message
databases.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 191
WILDMAIL! v4 APPENDIX C - WHAT IS NETMAIL/ECHOMAIL?
─────────────────────────────────────────────────────────────────
Summary
So it can be summarized that echomail messages are bundled up
into special file(s) called mail archive(s) that are attached to
Netmail message(s). These Netmail message(s) then sends this
attached mail archive onto the different systems into the network
for inclusion into the individual message bases of the nodes in
the network.
Once the Netmail message has been received at its destination, it
is usually deleted because normally it doesn't contain any text
in the body of it. It was only used to send the attached
echomail archive bundle.
Obviously, todays technology permits a lot more capability with
the use of Netmail messages, but the intent here was to describe
the differences between to the terms. We hope we've succeeded!
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 192
WILDMAIL! v4 APPENDIX D - OBTAINING A NODE NUMBER
─────────────────────────────────────────────────────────────────
APPENDIX D - OBTAINING A NODE NUMBER
In the course of WILDMAIL!'s product support, one of the commonly
asked questions is where do I go to get a node number? Because
of the frequency of this question, we've decided to include a
very general approach to this process.
Which Network to Join
Today, there are literally hundreds of different networks
that support a multitude of mail transfers. Some in QWK
format, some in Novell's MHS, others in Fido style etc.
Because of this diversity, we'll limit the discussion to
Fido style networks. These are the networks that use a
front end mailer such as D'Bridge, FrontDoor, InterMail
BinkleyTerm and several others.
First off, you should probably select one that is reasonably
close to you because you're bound to have a number of
questions and long distance phone bills can quickly add up.
So you go about calling a BBS that is currently passing mail
to and from a given network. Once you find the one you'd
like to join, you should obtain a Nodelist.
What's a Nodelist
A Nodelist is a ASCII based text file that contains all the
nodes (different BBS's) in that network. This is akin to a
phone book for a given city. Peoples phone numbers are
listed as well as their "addresses".
Nodelists are used by your front end mailer (the software
program that actually does all the dialing and file
transfers during mail sessions) to look up a specific node
address and obtain the phone number to dial when mail needs
to be sent to that address. Since these files are text
based, you can use your favorite file viewer utility to
display the contents of them.
Obtaining a Nodelist
Normally the BBS you called when searching for a network to
join has one of these Nodelist files available for download.
If you can't find it on their system, you should leave a
message to the SysOp and ask them to make it available to
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 193
WILDMAIL! v4 APPENDIX D - OBTAINING A NODE NUMBER
─────────────────────────────────────────────────────────────────
you for download.
Locating the Closest Hub
Once you download the file, you should use your file viewer
utility to display it and if you look closely, you will
notice there is a definite pattern to how it's laid out.
What you want to do to use the "search" capability of your
file viewer and search for all the nodes that exist within
your city. If none exist, you should search for cities that
are close to yours. Normally, you'll find these cities
closely bunched together because they are usually all within
a special sub-network or group that all share the mail.
Once you've located this group of nodes, you should look for
the for the word "Hub" which is normally located as the
first word on a line. On this line you will find the name
of the BBS, the SysOps name and his BBS's phone number.
Immediately following the phone number is the highest modem
speed his system supports for mail transfers.
This person is where all the nodes listed under him/her
(until the next occurrence of a Hub statement) get their
mail from and is the person you need to contact.
Contacting the Hub SysOp
Once you've located the Hub, you should logon to their
system as a new user (if you've never called before) and
leave a message to the SysOp requesting a node number. You
should leave a detailed message about your BBS regarding the
following items:
* Complete BBS name
* City and state your calling from
* Phone number of your front end mailer
* Modem type and maximum baud rate
* Any error correction methods your modem supports
* Will your system accept mail 24hrs/day
Once you've left the message, you should check back in with
this system and see if you've received a reply. Normally
this is sufficient to start the ball rolling.
Netmail Transfer Capability
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 194
WILDMAIL! v4 APPENDIX D - OBTAINING A NODE NUMBER
─────────────────────────────────────────────────────────────────
As part of the qualification requirements for obtaining for
a node number, most systems require you to prove that you
have your mailer setup and at least semi operational. This
usually involves having your system send their system a
Netmail message and then you being able to receive one back
from them. Normally, they will assign you a temporary node
number to be used for the testing process until your actual
address gets assigned to you.
Because this is the fundamental requirement of mail
transfers, it's very important to be able to do. If you
haven't already gotten a fairly good grasp on this process,
you should spend a bit of time with the documentation that
came with your mailers software and brush up on it.
If you're already some form of another network, this
"approval process" may require you to show that you can
handle multi-network mail transfers. This usually involves
making sure your system correctly identifies itself for each
network you're participating. This isn't very hard to do,
but does require you to understand the requirements and
needs for this capability. Again, there is no substitute
for reading the mailers documentation!
Receiving Your Node Address
Once all the above steps have been accomplished, the time
required to actually be assigned a node number can vary
greatly. This is due to the work schedules of the people
administering the network. If they're very busy, it could
take up to 3-4 weeks, or possibly as quick as 7 days.
Unfortunately, there is no way to say for sure, but if you
haven't heard anything in a couple of weeks, you might want
to send them a message reminding them of your "application".
Best thing to is not get in a hurry and try to be patient.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 195
WILDMAIL! v4 APPENDIX E - PERFORMANCE TUNING
─────────────────────────────────────────────────────────────────
APPENDIX E - PERFORMANCE TUNING
Because of the inherent complexity and disk intensive nature of
processing mail, many systems find that mail processing time can
be excessive at times. This section discusses ways by which you
can increase the efficiency of your entire system thereby
reducing the amount of time required for WILDMAIL! to process
your echomail needs.
Disk Caching Software
These are third party program(s) that execute in background
while your PC goes about its normal duties running your BBS
and associated utility programs. Basically it's a method by
which portions of your hard disk are "mirrored" in some form
of memory reducing the amount of mechanical action required
to retrieve information for the disk drive(s). This memory
can be of several different types like EMS, XMS and less
likely, base 640K memory.
Because of the disk intensive nature of running a BBS
especially in a multiline environment, disk caching software
is a must. Add to that the increased demands of tossing
mail and it can significantly reduce the effectiveness of
your BBS causing very noticeable delays and slow response
times.
There are many different disk caching software packages out
in both the shareware and commercial markets and it's not
our intent here to recommend one package over another. But
rather inform you ahead of time that DISK CACHING of some
form IS REQUIRED! If you don't already use one, after
installing it, you will see a DRAMATIC speed increase in
your systems performance. Of course as a byproduct,
WILDMAIL! will also enjoy a speed increase.
As a side note, DOS has its own pseudo disk caching ability
via the BUFFERS= command found in the CONFIG.SYS file. The
larger the number, the more space in memory that's
allocated. The problem is that if the number is higher than
30, it actually takes longer to search memory than it would
to go to the disk drive and read the information directly.
If this command is omitted from the CONFIG.SYS file, DOS
will assign a default value of 8.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 196
WILDMAIL! v4 APPENDIX E - PERFORMANCE TUNING
─────────────────────────────────────────────────────────────────
Because disk caches are designed to replace the
functionality of this command, you normally must reduce the
value of this command to something like BUFFERS=3. This
minimizes DOS's internal searching ability and lets the disk
caching software take over. With this setting to anything
higher than 3, it reduces the effectiveness of your disk
caching software because it's now wasting time searching the
internal buffers and not the disk caches more advanced
searching algorithms.
A value of anything lower than 3 will not be of any value
and will only hinder the bootup time of your PC prior to the
disk caching software being loaded. A value of 0 is invalid
and will produce unpredictable results on your PC, the
minimum being that it may not always allow your PC to boot
up properly.
DOS File Count Limitation
Since DOS v3.0 or higher is required to run WILDMAIL!, there
is an inherent limitation to the number of files contained
within a subdirectory before DOS starts to become EXTREMELY
inefficient in locating a specific file. As a general rule
of thumb, it's usually safe to limit the number of files
contained within a single subdirectory to 200.
WILDCAT! allows you to specify a DOS directory where you
want a specific conferences message database files to reside
via a configuration program called MAKEWILD. A common
mistake is to group each networks conference into its own
subdirectory allowing for better organization.
While this in itself is not a problem, if you have more than
50 conferences from that network then you can easily exceed
200 files within that subdirectory. Here's why.
WILDCAT! v3.x stores each conference into its own unique
database format separate from the other conferences. This
allows an incredible amount of flexibility and protection
against a single message destroying the entire mail for the
BBS.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 197
WILDMAIL! v4 APPENDIX E - PERFORMANCE TUNING
─────────────────────────────────────────────────────────────────
Because each conference database is separate, it can have up
to 4 files associated with it. You may have noticed this
already. Shown below are those files.
MSGxxx.DAT - Actual message content/information.
MSGxxx.IX - Index file containing 6 keys for each
message used for high speed searching
from the above .DAT file.
MSGxxx.DIA - This is a special, extremely small
dialog file that used in multiline
systems to manage record/file locking.
MSGxxx.CRC - This file is generated by the TomCat!
QWK mail door for its own internal
management of the users information.
The 'xxx' represents a numeric value associated with the
conferences number padded by leading zeros. For example, if
the conference number is 39, the file names would be:
MSG039.DAT, MSG039.IX, MSG039.DIA and MSG039.CRC
Because the above 4 files are associated with each
conference, you can easily exceed the recommended limit of
200 files in a subdirectory if you have more than 50
conferences in the same location.
Because more and more systems are involved in different
networks, a consistent subdirectory naming convention is
preferred for ease of reference. You may not realize it,
but DOS allows you to utilize the standard naming convention
of files for subdirectories. This means you can add an
extension to a directory name if you want.
Following that thinking, you could use the first 5
characters to indicate the network name followed by the
starting conference number. Then as the extension, you
could use the ending conference number.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 198
WILDMAIL! v4 APPENDIX E - PERFORMANCE TUNING
─────────────────────────────────────────────────────────────────
For example, let's say you have 150 different conferences in
Fidonet starting from conference #100 and ending with
conference #249.
Now in FamilyNet you have 100 conferences ranging from
conferences #300 through #399.
You could use the subdirectory naming scheme as follows:
FIDO100.149 - Conferences 100 through 149
FIDO150.199 - Conferences 150 through 199
FIDO200.249 - Conferences 200 through 249
FAMLY300.349 - Conferences 300 through 349
FAMLY350.399 - Conferences 350 through 399
As you can see, this method not only solves the files per
subdirectory limitation but also gives you a distinct visual
indication of what conferences database files are in each
subdirectory.
If you have grouped all your conferences together and this
idea appeals to you, you must do several things.
1) Create the subdirectories desired.
2) Manually move the conferences database files into
the correct directory keeping each conferences
associated .IX, .DIA, and .CRC files with it.
3) Run MAKEWILD and change each conferences message
database paths to the new subdirectory. MAKEWILD
has a very handy function called Global Change via
the [F4] key that can significantly speed up this
process.
Once the changes are complete, before logging onto the BBS,
you should manually verify all the changes first, then once
you're satisfied, logon and make sure the message bases are
available and intact.
Database Safety Mode
For those systems that are running WILDCAT! BBS software, it
has a special option called Database File Safety Mode. This
can be found via MAKEWILD (the configuration program for
WILDCAT!) from the Main Menu, General Definition Part 2,
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 199
WILDMAIL! v4 APPENDIX E - PERFORMANCE TUNING
─────────────────────────────────────────────────────────────────
option #2.
This option allows you the ability to have WILDCAT!
automatically maintain duplicate information or additional
verification for each of the databases it manages. This
means the Users, File and Message databases can be protected
in the event of power failures, user errors and so on.
The disadvantage to this is that it can add a significant
"load" to the overhead WILDCAT! must go through to execute
your BBS depending on the upon setting. Currently there are
three different settings that this checking can be set to.
NONE - No checking is done outside of the normal
error trapping routines that WILDCAT! uses.
PARTIAL - This setting performs verification that data
was successfully written to disk.
FULL - With this setting, WILDCAT! makes use of the
.DIA file (dialog file) to store portions of
the data to be saved to the database in this
file prior to writing it to the actual
database file. If it is saved properly, it
will then be flushed to disk.
This allows protection by making a duplicate
copy of the information should an unexpected
shutdown occur. This permits WCREPAIR to
easily reconstruct the potentially lost data.
WILDCAT! by default uses the PARTIAL setting. As is
mentioned in the WILDCAT! documentation, WCREPAIR (database
repair utility) will repair just about any error that your
system encounters just short of an erased database file. So
the need for this option setting to be anything but NONE is
normally of little use on the vast majority of the systems
in use today.
To give you an idea as to the impact of this option, with
this setting set to FULL, by simply changing this option to
NONE, you can expect to see a 400% increase in speed. The
PARTIAL setting being reset to NONE would have approximately
a 200% speed increase. Now considering your mail processing
takes an hour to toss, you could easily cut this in half or
greater just by making sure this option is set to NONE.
Please bear in mind, each system is unique because of
hardware and software differences, but the fact remains that
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 200
WILDMAIL! v4 APPENDIX E - PERFORMANCE TUNING
─────────────────────────────────────────────────────────────────
while the PARTIAL and FULL options can offer you additional
peace of mind, but they come at a cost. That cost being
performance. By personal experience from our own 10 line
BBS system, we use the NONE setting and rarely (if ever)
have to run WCREPAIR on the message bases. We currently
maintain over 200,000 messages at any one point in time in
500 or so conferences, so we speak with a considerable
amount of confidence in this area.
Preprocessing Mail Deliveries
Preprocessing mail is by far the fastest method to toss
mail. This is due mainly because WILDMAIL! will simply
forward all mail to both your downlink nodes and to your
system (into the defined PRETOSS directory). This bypasses
tossing mail directly into the WILDCAT! message databases
and thereby processes the mail incredibly fast!
This pretossing capability was primarily designed for those
systems that hub mail for downlink systems which move a lot
of mail. Because the WILDCAT! databases are not used in
this process, you may want to consider using this option if
you move a lot of mail. For those systems that are simply
nodes and don't forward any mail, this option will be of
little use to you.
The advantage of this option is that you can schedule when
WILDMAIL! will take the mail that has been preprocessed for
your system and toss it into your WILDCAT! message bases.
This means all your downlink nodes will get their mail
faster and your system won't be tied up as long on the
initial tossing session. Then when your system is not as
busy, say in the early morning hours, you could execute
WILDMAIL! with the PRETOSS command line parameter to process
your systems mail.
For specific information on using/setting up this option,
please refer to the Main Menu option - System Information,
BBS specific options - Pre-process echomail.
Summary
As you are probably aware, each system running a BBS is
configured differently with rarely any two systems running
exactly the same way. Because of this, there is simply no way to
accurately predict the outcome of performance tuning changes made
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 201
WILDMAIL! v4 APPENDIX E - PERFORMANCE TUNING
─────────────────────────────────────────────────────────────────
to your system. Unfortunately, this is strictly a trial and
error basis with you being the judge of the effects.
A lot of factors come into play when operating a BBS especially
in a multiline environment. Obviously the faster the components
that make up your BBS, the more potential it has for performance
gains. Things to consider are:
o Available horsepower - 286/386/486 etc.
o Disk drives capacity and its average seek time.
o Available memory and how it's being utilized.
o Multitasking software and its configuration.
o Number of lines running on a single machine.
o Modem speeds.
While we have tried to give examples of the most significant
causes for performance slowdowns, we can't go into each area
fully and thus can only offer this bit of additional advice.
Take your time troubleshooting and performance tuning. A very
methodical and accurate effect analysis technique will yield the
highest results. Unfortunately this requires a bit of patience
on your part but it will be well worth it. Please bear in mind,
any performance tuning you do, you should always have a good
backup before you start, especially when you start changing your
disk caching software settings! Otherwise, you run the risk of
losing a lot of your hard work and effort.
As a last note, this section has been devoted entirely to
speeding up your PC, not WILDMAIL!. Once your PC has been
thoroughly tuned, only then will your callers and WILDMAIL! reap
its full benefits.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 202
WILDMAIL! v4 APPENDIX F - ERRORS UNCOMPRESSING MAIL
─────────────────────────────────────────────────────────────────
APPENDIX F - ERRORS UNCOMPRESSING MAIL
In the past when mail was uncompressed, no checking was done with
regards to the outcome of the actual process. If an error
occurred, WILDMAIL! would process whatever PKT files were found
and then cleanup after itself by deleting the mail archive.
During the unarchival process, certain situations could occur
like running out of disk space or even running up against a
partially corrupted mail archive. If an error did occur, the
outcome was often less than desirable, typically with the loss of
mail.
Errorlevel Checking
WILDMAIL! now checks for an errorlevel returned by the
uncompression program. If something other than an
errorlevel of zero is returned, WILDMAIL! will leave the
mail archive intact as well as any PKT files that were
successfully uncompressed.
Logfile Entries
An entry is then placed in the WM.LOG file (or whatever you
have named log file) of the errorlevel along with a brief
description of the problem. Since all the PKT files that
were successfully uncompressed remain intact, WILDMAIL!
proceeds to toss them as usual.
The next time WILDMAIL! executes, it will attempt to
uncompress the archive and the process will start all over
again. If the same PKT files are uncompressed, when
WILDMAIL! starts to toss them, it will find the messages as
duplicates and simply ignore them. Bear in mind, each time
WILDMAIL! encounters an error, it makes an entry in the log
file.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 203
WILDMAIL! v4 APPENDIX G - PATH AND SEENBY LINES
─────────────────────────────────────────────────────────────────
APPENDIX G - PATH: AND SEEN-BY: LINES
In Appendix C we talked about sending echomail messages from one
system to another so that all BBS's could share a common message
base. A very important aspect of transferring mail between
systems like this is how to prevent duplicate messages from being
re-introduced in the network.
This is handled in a rather ingenious way by adding information
to the end of each message indicating all the systems that have
processed this message. So every time a new system would receive
the message, its node address would be added to this special list
of nodes. So the more systems that have "Seen" the message, the
more node addresses would be appended to the end of the message.
This is where the term SEEN-BY: lines comes from.
FORMAT
These SEEN-BY: lines only contain the <net/node> portion of the
node addresses. Notice that the <zone> information is NOT
contained within them, thus limiting the duplicate checking to
only nodes within the same <zone>.
The keyword "SEEN-BY:" must start at position 1 on a new line
following the origin line information (unless it's preceded by
special characters which hide it). The node addresses follow it
separated by a single space and can inherit the <net> portion of
the previous address on the line. For example, if you have a
SEEN-BY line such as:
SEEN-BY: 161/123 504
It's assumed that node address 504 is actually 161/504. Normally
these lines are sorted by the mail processor each time a new node
address is added with each line limited to approximately 78
characters (total) in length before a new line is created.
HIDDEN INFORMATION
Because SEEN-BY lines are only used by the mail processors which
handle the forwarding and tossing of the mail, this information
is of little use to the actual message recipient so special
control characters can be added to the SEEN-BY: lines. Normally
this is a Hex 01 or commonly referred to as a Control A. This is
typically used by the message viewers to prevent the information
from being displayed thereby reducing the "clutter" on the
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 204
WILDMAIL! v4 APPENDIX G - PATH AND SEENBY LINES
─────────────────────────────────────────────────────────────────
screen.
WILDMAIL! v3.00 has the ability to remove the Hex 01 (Control A)
characters from the AREA:, SEEN-BY: and PATH: lines allowing you
to display the entire message information should some form of
duplication occur. This is handled on a conference by conference
basis. Please refer to the section on Conference Management,
SEEN-BY: line processing for additional information.
Normally however, you wouldn't want to leave this option enabled
because it will clutter up the messages with information and your
callers will start to complain. But it is handy for isolating
certain problems!
PATH: LINES
PATH: lines follow the SEEN-BY: lines in the message and operate
almost identically to them except these lines indicate the route
(or path) the message has taken to get to your system. Unlike
the SEEN-BY: lines, the PATH: lines are not sorted because they
indicate from left to right the originating system and the
systems the message encountered before arriving at your system.
The same <net> inheritance from the previous node address applies
as well.
VIEWPKT
For those of you interested, we have developed a program called
ViewPKT! that will display the messages in your Netmail directory
(or any directory you desire) and allow you to select a Netmail
message. You can then highlight the desired echomail bundle
"attachment" and uncompress the contents and permit you to
display the contents of the actual PKT files.
This will show in great detail the specifics of each message in
the PKT file along with specific information about the program
that created it. For those that process a lot of mail, this is
essential for ensuring that mail is created and addressed
properly!
For more information, you can download the latest copy from the
WILDMAIL! support BBS and try it yourself.
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 205
WILDMAIL! v4 MASTER INDEX LISTING
─────────────────────────────────────────────────────────────────
MASTER INDEX LISTING
Following is a listing of selected words found throughout the
documentation and their associated page number(s).
Activation date . . . . . . . . . . . . . . . . . . . . . . . 74
Active area . . . . . . . . . . . . . . . . . . . . . . . . . 152
AKA . 22, 34, 49, 50, 57, 73, 79, 92-94, 99, 110, 125, 128, 131,
151, 165
ALIAS . . . . . . . . . . . . . . . . . . 95, 110, 122, 125, 126
Area name . . . 86-88, 111, 112, 114, 121, 122, 133, 139-141, 154
AreaRequest . . . 1, 4, 13, 14, 24, 59, 77-83, 101, 102, 104-106,
108-113, 116, 118, 119-122, 125-128, 130, 131, 136,
137, 141, 158
AreaRequest Flags . . . . . 81, 82, 101, 102, 105, 108, 126, 136
AreaRequest security . . . . 4, 81, 82, 101, 102, 104, 105, 126
BBS type . . . . . . . . . . . . . . . . . . . . . . . . 26, 51
BinkleyTerm . . . . . . . . . . . . . . . . . . . . . 1, 13, 193
Compression format . . . . . . . . . 34, 43, 70-72, 83, 114, 115
Conference number . . . . . . 14, 51, 86, 87, 133, 155, 157, 198
CRASH . . . . . . . . . . . . . 18, 56, 57, 70, 80, 100, 131, 153
D'Bridge . . . . . . . . . . . . . . . . . . . 1, 4, 23-26, 193
Default address . . . . . . . . . . . . . . . . . . . . . . . 21
DESQview . . . . . . . . . . . . . . . . . . . . 28, 37, 60, 164
Disk space 5, 13, 30, 31, 33, 40, 55, 67, 117, 162, 164, 190, 203
Distribution . . . . . . . . . . . . 5, 7, 8, 100, 124, 160, 162
Downlink nodes . . . 1, 41, 52, 65, 67, 76, 90, 92, 95, 104-107,
109-118, 124, 126, 127, 128, 130, 141, 164, 165, 201
Duplicates . . . . . . . . . . . 7, 15, 32, 39, 40, 46, 96, 203
Duplication loops . . . . . . . . . . . . . . . . . . . . . . 74
Echo List . . . . . . . . . . . . . . . . . . . . . . . 141, 143
Evaluation . . . . . . . . . . . . . . . . . . . . . 5, 162, 163
Expired . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Fakenet ID . . . . . . . . . . . . . . . . . . . . . . . . . 150
FIDO . . . . . . . . . . . . . . . . . . . . . . . . . 110, 193
Fidonet . . 1, 67, 88, 93, 121-124, 141, 144, 148, 163, 188, 199
File attach . . . . . . . . . . . . . . . . . 12, 58, 61, 95, 97
File attaches . . . . . . . . . . . . . . . . . . . . 58, 61, 94
Filter . . . . . . . . . . . . . . . . . . 38, 86, 121, 133, 138
Flags . . 4, 56, 70, 79-82, 95, 99-103, 105, 108, 109, 126, 127,
131, 136, 137
Four dimensional . . . . . . . . . . . . . . . . . . . . 4, 148
FROM: name . . . . . . . . . . . . . . . . . . . . . . . . . 110
FrontDoor . 1, 10, 12, 23-25, 69, 155, 177-179, 181-185, 187, 193
Global Edit . . . . . . . . . . . . . . . . . . . . . . 136, 137
Hold . . . . . . . . . . . . . . . . . . . . . . 6, 33, 40, 120
Home directory . . . . . . . . . . . . . . 30, 60, 153, 154, 159
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 206
WILDMAIL! v4 MASTER INDEX LISTING
─────────────────────────────────────────────────────────────────
Inbound directory . . . . . . . . 5, 11, 22, 23, 61, 69, 70, 117
INTL . . . . . . . . . . . . . . . . . . . . . . . . 35, 36, 165
INTL kludge . . . . . . . . . . . . . . . . . . . . . 35, 36, 165
InUse flag . . . . . . . . . . . . . . . . . . . . . . . 43, 158
KILL/SENT . . . . . . . . . . . . . 36, 56, 70, 80, 100, 109, 131
Lock Retry . . . . . . . . . . . . . . . . . . . . . . . . . 60
LYNXMAIL! . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Mail archive . . . . . . . 1, 11, 33-35, 43-45, 71, 72, 192, 203
Mail archives . . . . . . . . . . . . 14, 27, 35, 37, 40, 43, 71
Mailer 1, 12-14, 21-26, 34, 36, 38, 49, 58, 109, 147, 177, 179,
182, 184, 187, 188, 193-195
Mailer type . . . . . . . . . . . . . . . . . . . . . 13, 25, 26
MAKEWILD . . . . . . . . . . 11, 13, 51, 54, 156, 165, 197, 199
Memory . . . . . . . . 17, 26, 32, 36, 37, 41, 42, 164, 196, 202
Message count . . . . . . . . . . . . . . . . . . . . 13, 14, 55
MSG . . 1, 11, 14, 24, 25, 29-31, 33, 40, 56, 58, 70, 73, 98, 99,
107, 130, 131
MSGID . . . . . . . . . . . . . . . . . . . . 39, 92, 93, 97, 123
Net . 21, 22, 35, 46, 49, 51, 62, 63, 67, 68, 148, 150-152, 188,
204, 205
Node 1, 2, 4, 5, 12-14, 18, 19, 21, 22, 25, 27, 35, 43, 44, 46,
47, 49, 51, 52, 60-86, 89-94, 98, 100-106, 108,
111-115, 117, 119, 122, 123, 124, 126, 127, 129, 130,
147, 148, 150-152, 154, 159, 164, 181, 188, 190,
193-195, 204, 205
Node addresses 1, 2, 27, 46, 47, 52, 61, 63, 64, 73, 77, 78, 82,
89, 90, 92, 101, 104, 108, 164, 190, 204
Notify . . . . . . . . . . . . . . 14, 54, 78, 79, 95, 107, 110
Null messages . . . . . . . . . . . . . . . . . . . . . . 36, 165
Offline . . . . . . . . . . . . . . . . . . . . . 38, 48, 53, 147
Origin address 4, 21, 46, 47, 79, 93, 95, 99, 128, 131, 152, 157
Origin line . . 3, 4, 19, 21, 46-48, 94, 115, 128, 154, 157, 204
Outbound mail . 1, 5, 10, 13, 21, 23, 27, 43, 44, 66, 67, 70-72,
150, 154
Packet . . . . . . . . . 24, 32, 48, 61, 66, 147, 150, 158, 160
Passthru . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Password . 4, 51, 68-70, 77, 80, 82-84, 110, 113, 116, 117, 119,
129, 131, 166, 167-170, 173-175
PATH 4, 5, 12, 22-25, 27, 30, 33, 40-42, 44, 45, 52, 58, 60, 61,
70, 72, 74, 91, 95, 107, 115, 153, 166, 167, 169,
171-173, 181, 204, 205
Path definition . . . . . . . . . . . . . . . . . . . . 4, 30, 61
Peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . 37
PKT . 1, 4, 5, 12, 22, 32-34, 42, 44, 52, 66-70, 72, 84, 92, 114,
116, 117, 118, 149, 150, 158, 165, 203, 205
PKT password . . . . . . . . . . . . . . . . . . . . 68, 69, 84
Point . 7, 9, 21, 22, 30, 31, 33, 37, 46, 49, 51, 52, 63, 67, 68,
75, 100, 117, 118, 124, 147, 148, 150-152, 154, 188, 201
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 207
WILDMAIL! v4 MASTER INDEX LISTING
─────────────────────────────────────────────────────────────────
Pre-processing . . . . . . . . . . . . . . . . . 22, 52, 53, 60
Primary address 9, 21, 22, 34, 50, 55, 57, 79, 125, 128, 131, 151
PURGE . . . . . . . . . . . . . . . 11, 13, 40, 53, 55, 127, 143
Rescan . . . . . . . . . . . . . . . . . . 82, 83, 114, 115, 119
Restrict import . . . . . . . . . . . . . . . . . . . . . . . . 4
Scheduled . . . . . . . . . . . . . . . . . . . . . . 13, 26, 53
SEENBY . . . . . . . . . . . . . . . . . . . . . . . . . 4, 154
Selected conferences . . . . . . . . . . 64, 134, 136, 138, 154
Standard naming convention . . . . . . . . . . . . . . . . . 198
SUBJECT: . . . . . . . . . . . . . . . . . . . . . 35, 131, 165
Swap file . . . . . . . . . . . . . . . . . . . . . . . 4, 37, 40
Tear line . . . . . . . . . . . . . . . . . . . . . . . . 48, 118
TO: field . . . . . . . . . . . . . . . . . . . . . . . . 54, 95
Type 2 . . . . . . . . . . . . . . 4, 67, 68, 117, 150-152, 158
Type 2.2 . . . . . . . . . . . . . . . 67, 68, 117, 150-152, 158
Uplink 1, 2, 4, 9, 11, 24, 64, 77, 78, 89-91, 100, 124, 127-132,
152, 158
WILDCAT! conference . . . . . . . . . . . . . . . . 153, 163, 165
XMS/EMS . . . . . . . . . . . . . . . . . . . . . . . . . 37, 164
Zone 4, 21, 22, 35, 36, 46, 49-51, 62, 63, 67, 68, 73, 121, 122,
147, 148, 150-152, 158, 165, 188, 204
Zone matching . . . . . . . . . . . . . . . . . . . . . . . . . 4
─────────────────────────────────────────────────────────────────
Revised: 11/30/94 Page 208