(Continued from previous message)
 
PASSTHROUGH TIC AREAS
---------------------
 
A note about Passthru TIC areas. The files are temporarily stored on your
computer until all of the systems have received the file. The files are
located in the DB\DATA\PASSTHRU directory.
 
When D'Bridge performs a QueueScan, it first scans the Queue entries on
disk to ensure no systems have the Passthru file waiting to be sent or
moved. If D'Bridge cannot find any occurance in the Queue entries, it will
erase the file out of the Passthru directory.
 
 
HATCHING/POSTING FILES
----------------------
 
There are three ways to do this. Using the UTILITIES menu, DBUTIL HATCH or
an automated ACTION that performs the hatching.
 
FILENAME: The complete path and filename to be hatched/posted.
 
FILEECHO: The name of the fileecho where this file will be "posted" to.
 
ORIGINAL: Use if this is an "original" file so it is not erased when sent.
 
    DESC: The description of the file (limited to 10 lines). Note that if
          the file contains a "BBS description" file like FILE_ID.DIZ, then
          most systems would use that description instead of what you type
          here; depending how that system is configured.
 
   MAGIC: If this file should have a "magic" keyword as per the TIC
          specification, then specify that here.
 
 REPLACE: If this file replaces another, then specify the name here.
 
 
 
READ/WRITE ACCESS CONTROL SYSTEM
--------------------------------
 
NOTE: It is extremely important for both newcomers and experienced D'Bridge
      administrators to understand this new feature. Incorrect settings can
      cause "problems".
 
D'Bridge 3.7 now has the ability to control read/write Echomail and TIC
fileecho access. And its as easy as one letter on your keyboard.
 
In the ECHOMAIL AREAS screen in the FORWARD TO section, you define the
Echomail links as usual. You already know that you can override priority
for a system, ie. 1:229/426,N to make sure that 426 has Normal priority.
Now by adding one more letter AFTER the priority, you can control that
system's access:
 
  R means READ ONLY access. W is WRITE ONLY. The letter B (OR NOTHING AT
  ALL - THE DEFAULT SETTING) means both read/write access.
 
1:229/426,NR    Means that 1:229/426 has Normal priority and READ ONLY access
                to the Echomail area. Messages are relayed to that system
                but any postings are rejected (with no acknowledgement).
                
1:229/426,CW    Means that 1:229/426 has Crash priority and WRITE ONLY access
                to the area. No messages will be relayed to this system.
 
1:229/426,IB    Means that 1:229/426 has Immediate priority and read/write
or 1:229/426,I  acesss - the default behavior (or when R/W/B is blank)
 
REDIRECT TO     If a violation occurs with READ ACCESS, as in, the system
                attempts to post a message forbidden by their restriction,
                you may specify an Echomail area to have those postings
                redirected to. The default setting is the BADECHO area.
 
You MUST specify a priority first before the read/write. In other words, do
not use syntax like 1:229/426,R.
 
For TIC/Fileechoes, the same rule/syntax applies except that the context
is different. So READ access means that the system will receive the file
but cannot hatch (post) files in the Fileecho area... useful for Fileecho
areas such as the Fidonet NODEDIFF:
 
Example: 1:229/426,N 619,R 728,R  Means that the NODEDIFF will be received
by 426 and relayed to 619 and 728 but both 619 and 728 cannot send NODEDIFF
files in return.
 
 
OTHER FIXES AND CORRECTIONS
---------------------------
 
This major release of D'Bridge has numerous corrections and revisions.
 
Careful attention to detail and rigorous testing was done to make sure
that 3.7 is the most reliable, stable D'Bridge yet.
 
- The commands ALT+N (New Echo Link) and ALT+R (Request Echo Link) have
  been slightly revised for the fileecho/TIC support. Now, a question
  asks you if the request is for Echomail (default) or TIC files.
 
  At the last minute, I added the ability to specify the "name" of the
  automated management system for fileecho/TIC files (ie. FILEFIX). So if
  a system does not respond to "FileFix", you may specify ALLFIX or FILEMGR
  (or whatever you want) as the manager name. The name is also saved for
  future usage.
 
- When using ALT+N or ALT+R to do an Echomail Areafix request, that
  specific request must be processed first before doing another ALT+N or
  ALT+R for a Filefix request. (This will be revised/corrected later)
 
- The ALT+N and ALT+R commands in the internal editor only function for
  Echomail requests and links. TIC functionality is not integrated (yet)
  into the internal editor.
 
- The ALT+N and ALT+R commands now properly use the alias-address provided
  that the address/zone matching is properly defined in Config - BASIC. The
  correct INTL, FMPT and TOPT kludges are injected into ALT+N/ALT+R
  generated packets before processing.
 
- At the last minute, I added support for FILES.BBS to D'Bridge. This means
  that whenever TIC's are processed and you are storing a copy of the file
  in a directory, D'Bridge can update any FILES.BBS present with the
  filename and description. A lot of BBS software supports FILES.BBS to save
  work involved in keeping your BBS filebases updated.
 
  There are two types of FILES.BBS formats supported by D'Bridge. Standard
  and Extended. Standard means the filename, a space, then a one-line
  description. Extended means that any description more than one line will
  be added to the next line in the file with a plus-sign (+) character.
 
  Example: TORWEATH.ZIP Latest weather reports for Toronto, Ontario.
           +This archive contains the latest weather survey data
           +for the city of Toronto, Ontario Canada.
 
- Also added was the ability for D'Bridge to import descriptions from
  FILE_ID.DIZ and DESC.SDI files if the above FILES.BBS is set to Extended.
 
- It is no longer possible to specify the directories for PSTN dialup
  "scripts" or FileBase files. They should be stored in the DATA directory
  from now on.
 
  This is not because they are being phased out. This was done to free up
  memory usage in the code; because scripts and Filebase files are nowadays
  a very seldom-used portion of the mailer. So the decision was made to
  remove the code that stores scripts and Filebase info in different places.
 
- You may now send file-requests (FREQ) to a remote BinkD system. Whether
  the remote system honors the request depends on how the remote operator
  has set it up. At this time, D'Bridge does not process incoming file-
  requests from BinkD sessions; only on dialup.
 
  This is due to the fundimental way that BinkD was designed; and its
  reliance on what is known as a "SRIF" (Standard Request Information
  File) to act as the go-between. The way that D'Bridge handles FREQ's was
  programmed in a way to make integrating a method like SRIF extremely
  difficult to do.
 
  This is not a D'Bridge-specific problem; it is difficult to get file-
  requests working even in a minimal BinkD system, without the use of
  scripting, other software, etc.
 
  I have chosen not to implement SRIF since in a later release I plan to
  address these (minor) shortcomings with a much more integrated solution.
 
- DBUTIL also now supports "moving" FREQ's out of the Queue as well.
  Whether or not the remote system will honour the FREQ depends on how the
  remote system has file request support configured.
 
- The NETmail filter/tracker system has been completely redesigned and
  reprogrammed from scratch. It is 100% integrated with the internal message
  tosser and uses much less code to process/filter NETmail messages.
 
- The NETmail filter/tracker also has been greatly simplified. It will only
  filter NETmail messages that are addressed to unlisted systems. By default
  the system is shut off. It is enabled by going to PACKET/MAIL CONTROL.
 
- All procedures that send automated NETmail responses to remote systems
  have been checked to prevent certain behavior if a D'Bridge operator
  does not correctly set up routing on a new installation.
 
  Note that D'Bridge by default only routes "In-transit" Netmail to systems
  destined within the same "Net". If your uplink or other systems do not
  reside in your "net" segment, you will need to specify correct routing.
 
- Corrected a problem where in certain conditions, D'Bridge appears dead
  for up to a minute before processing large volumes of mail with many
  Queue entries waiting to be sent out or many packets waiting to be
  compressed (XMAIL) (this is possibly a regression problem from prior
  versions)
 
(Continued in next message)

--- D'Bridge 3.7