PC Online 1999 November

home *** CD-ROM | disk | FTP | other *** search

/ PC Online 1999 November / PCONLINE_11_99.ISO / filesbbs / OS2 / BBTO230.ZIP / BBTOSS.DOC < prev next >

Wrap

Text File | 1999-05-31 | 172.1 KB | 3,951 lines

▒███████ ▒███████ ▒████████ ▒███████ ▒███████ ▒███████ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒████████ ▒████████ ▒███ ▒██ ▒██ ▒██ ▒███████ ▒███████ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒██ ▒████████ ▒████████ v 2.30 ▒██ ▒███████ ▒███████ ▒███████ FTS Echomail/Netmailprozessor Shareware ***************************** * DOS DPMI (Protected Mode) * * OS/2 * ***************************** -= written by Burkhard Buelte, BBSoft (c)1994..99 =- ┌─────────────────────────────┐ │ Benutzerhandbuch - Manual │ └─────────────────────────────┘ Einleitung ─────────────────────────────────────────────────────────────────────── BBTOSS ist ein Echomail und Netmailprozessor für Hudson, JAM, Squish Fido-Msg, Ezycom und HTML Messagebase-Formate, hat eingebaute Areafix- Funktionen, Unterstützung für die gebräuchlichsten Kompressions- programme und integrierte Netmail Routingfunktionen. Weitere Features beinhalten: - Unterstützt Frontdoor- und Binkley-Style ARCMail-Handling - Unterstützt Hudson/JAM/Squish/Ezycom/*.Msg/HTML/Passthrough Areaformate - Installationshilfe bei Umstieg von FMail, FastEcho, IMail, GEcho, - Setup menügeführt - Setup-Export für Remote Access 2.0x/2.50, Ezycom 1.10/1.20/1.48, Proboard 2.00/2.10/2.12, Maximus 3.0, Concord - Aka's unbegrenzt[+] (unreg=40), 32000 Areas, 32000 Links, 32000 Downlinks pro Area - 62 Message-Gruppen möglich (0-9, A-Z, a-z, *) - 2-Phasen Toss Option für optimale Multiline-Unterstützung, d.h. Tossen an Downlinks und in die lokale MsgBase können getrennt werden - Tossen während dem Poll für Multilinesysteme - Integriertes Binkley-Style Netmailhandling (für Crash, Direct, F'attach Mails) - Echoarea Schreib/Lese-Level, Read-Only- und Pflichtareas - Autocreate von neuen Echoareas - Autoconnect von Links an neue Areas und Newarea Info an Links - Lokale Netmailarea (in Mailbox) in beliebigem Areaformat, mit automatischem Absender AKA-matching, dadurch schreiben auch User mit der richtigen Absender AKA - Voreingestelltes Netmailrouting an Downlinks incl. Points u. Hostroute - Netmailrouting Angaben mit Ersatzzeichen * und ? - Bouncen von nicht routebaren Netmails - Uplinkmanager zum automatischen Weiterleiten von Areabestellungen - Versenden von Startmsg (AreaRulefile) bei Areabestellung - Pro Downlink definierbare Packet-Absender-Aka, interessant für Host/Hub-Systeme mit mehreren Akas pro Netz - Multiparameter Aufrufe z.B. toss mgr pack scan mit einem Aufruf - Zeitliches Begrenzen des einzelnen Tossvorgangs möglich - Temporäres Beenden des Tossvorgangs durch Tastendruck - Herausfischen von Msgs an Aliasnamen, auch aus Passthrough Areas {+} und kopieren in beliebiges Area - Fehlerbenachrichtung von Downlinks per Netmail in verschiedenen Situationen z.B. - falsche Aka in Echomails verwendet - Routingfehler bei Netmails - Dupes empfangen - Automatisches Informieren von Downlinks beim Löschen von Echomailareas - 3 kombinierbare Dupe Check Methoden - Posten von Textfiles in beliebige Areas (BBTPOST.EXE) (Group-Mail) - Import von AREAS.BBS Dateien inklusive der Downlinks pro Area, dadurch sehr flexibel bei der Umstellung von anderen Tossern sowie sortiertes Exportieren einer AREAS.BBS - Node/Linkeinstellungen und Areas aus FMail 1.00g, Fastecho 1.41/1.45 GEcho 1.10 und Ezycom 1.10/1.20/1.48 importierbar - Vielseitige Exportfunktionen von AREAS.BBS bis Passwort-Liste und Null-Traffic bzw. Null-Link Echos - Autom. Echoareastatistik auch von Passthrough Areas - Löschen und Abbestellen von Areas ohne Traffic oder ohne Downlinks - Erstellen von TimEd/GoldEd/Squish Area-CFG - Aufräumen (Packen, Reindex, Renumber) von Hudson, Jam und Squish Messagebases - Support Echoarea im Fido BBTOSS.GER INHALTSVERZEICHNIS ─────────────────────────────────────────────────────────────────────── Einschränkungen in der unregistrierten Version sind mit [+] gekennzeichnet 1. Einführung und Vorwort 1.1 Programme (Übersicht) 1.2 Konfigurationsdateien (Übersicht) 1.3 BBT/BBTCFG Aufrufparameter 2. Installation 2.1 Installation BBT.EXE 2.2 Umsteigen von FMail auf BBToss 2.3 Umsteigen von FastEcho auf BBToss 2.4 Umsteigen von Ezycom auf BBToss 2.6 Besonderheit unter NW-Dos 7.0 2.6.1 Entpacken mit ARJ unter NWDos + NWLite 3. Das Setup (BBTCFG.EXE) 3.1 Setup-Menü 3.1.1 Aka-Setup (Adressen-Setup) 3.1.2 Verzeichnis Setup 3.1.3 Outbound / Inbound Setup 3.1.4 Gruppen Setup 3.1.5 Packer Optionen 3.1.6 Alias Namen 3.1.7 Tosser Flags 3.1.7.1 lösche 0-Byte Netmails 3.1.7.2 gesendete Netmail löschen 3.1.7.3 Dupes löschen 3.1.7.4 Badmails löschen 3.1.7.5 Areamgr Antworten löschen 3.1.7.6 bounce unzustellbare Netmail 3.1.7.7 strikter Inbound AKA Check 3.1.7.8 konvertiere File attach (binkleystyle) 3.1.7.9 verwende Echomail.BBS (bei SCAN) 3.1.7.10 2-Phasen Toss 3.1.7.11 Multiline/Multitasker-Mode 3.1.7.12 Path-Line Dupecheck 3.1.7.13 CRC DupeCheck 3.1.7.14 SEEN-BY DupeCheck 3.1.7.15 copy Echo-Msg an Alias 3.1.7.16 Keine Info Msg an Sysop 3.1.7.17 Error Netmails an Links sofort senden 3.1.7.18 Return Receipt Request Antwort Messages 3.1.7.19 Autoexport Area.BBS 3.1.7.20 Autoexport TimEd Area Config 3.1.7.21 Autoexport GoldEd Area Config 3.1.7.22 Autoexport Squish Area Config 3.1.7.23 Copy Sent Netmail to .... 3.1.8 Limits 3.1.8.1 Dupe-Check Message Alter 3.1.8.2 Dupe-Check Save max Msg pro Area 3.1.8.3 Dupe-Check Save Msg-Alter 3.1.8.4 Maximale Toss Zeit 3.1.8.5 Maximale nicht gepollt Zeit 3.1.8.6 Maximale Packet Größe 3.1.8.7 Maximale ARCMail Größe 3.1.8.8 Minimaler Disk Free Platz 3.1.8.9 Max. Files Open 3.2 LinkDaten-Menü 3.2.1 Link Edit 3.2.1.1 Link Daten im Einzelnen 3.2.1.2 Link Flags 3.2.1.3 Link Arealiste 3.2.2 Global Linkedit 3.2.3 Link Vorgaben 3.2.4 Uplink-Manager 3.3 AreaDaten-Menü 3.3.1 Area-Manager Extramenü 3.3.1.1 Hinzufügen/Anklemmen eines Links 3.3.1.2 Re-Nummerieren der Areas 3.3.2 Area Editor 3.3.2.1 Loesche SeenBy 3.3.2.2 Loesche Path 3.3.2.3 Reset Scan Aka 3.3.2.4 Prüfe Msg-Aka 3.3.2.5 Passiv 3.3.2.6 Import SeenBy 3.3.2.7 Import Path 3.3.2.8 Nicht in BBS export 3.3.2.9 Pflichtarea 3.3.2.10 Read Only Area 3.3.3 Routing 3.3.4 Globales Area Edit 3.3.5 Traffic 0 Areas abmelden 3.3.6 Link 0 Areas löschen 3.3.7 Reset Areastatistik 3.3.8 Relink Areas 3.4 Export Menü 3.4.1 AutoExport 3.4.2 Areas.BBS 3.4.3 Bestell-List 3.4.4 Export Areas to Mailbox 3.4.4.1 Export nach Remote Access 3.4.4.2 Export nach Proboard 3.4.4.3 Export nach Ezycom 3.4.4.4 Export nach Maximus 3.4.5 Export TimeED Area Config 3.4.6 Export Passwort Liste 3.4.7 Export Rulefile Liste 3.5 Import Menü 3.5.1 Import AREAS.BBS 3.5.2 Import Squish.cfg 3.5.3 Import Ezycom Areanummern 3.5.4 Import Area-Beschreibungen 3.5.5 Import Area-Rulefileliste 3.6 BBTCFG Aufrufparameter 3.6.1 Environment Variabel 4. Die Tosser-Funktionen, Befehle/Parameter und ihre Wirkung 4.1 Der TOSS Befehl 4.1.1 Umbenannte PKT-Files 4.1.2 TwoPassToss und TOSSII 4.1.3 Tossen von Fileattach Netmails 4.2 Der SCAN Befehl 4.3 Der PACK Befehl 4.4 Der IMPORT Befehl 4.5 Der MGR Befehl 4.5.1 Befehle in einer Areamgr-Netmail 4.6 Der NOTIFY Befehl 4.7 Der RELINK Befehl 4.8 Der AUTO Befehl 4.9 Der CLEAN Befehl 4.10 Der SAYERR Befehl 4.11 Der ZIP und UNZIP Befehl 4.12 Der BAD Befehl 4.13 Der COMPILE Befehl 4.14 BBT Errorlevel 5. Die einzelnen Config-Dateien 5.1 Tossereinstellung (BBTOSS.INI) 5.2 Packereinstellung (BBTZIP.INI) 5.4 Areas (BBTAREA.INI / BBTAREA.BBT) 5.5 Links (BBTLINK.INI / BBTLINK.BBT) 5.6 Gruppen (BBTGROUP.INI) 5.7 Routing (BBTROUTE.CFG) 5.8 Uplinkmanager (BBTUPLNK.INI) 5.8.1 Uplinkmanager Arealistdatei 5.9 Aliasnamen (BBTALIAS.CFG) 5.10 Lock Semaphore (BBTOSS.BSY) 6. Zusatzprogramme und Utilities 6.1 BBTCLEAN Messagebase aufräumen 6.1.1 BBToss und das Squishformat 7. Referenz: Mailer-Unterstützung 8. Was BBToss nebenbei erledigt 9. Nutzungsbedingungen 9.1 Registrierung 9.2 Open Beta Politik 10. Autor 11. Bisher bekannte Probleme Anhang A Fehlermeldungen Anhang B Message Kludges die BBToss unterstützt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- 1.1 Programme ─────────────────────────────────────────────────────────────────────── BBTINST.EXE Installationsprogramm um für die 1. Installation Daten und Einstellungen aus anderen Programmen zu übernehmen BBT.EXE Tosser BBTCFG.EXE Setup-Programm für BBTOSS BBTCLEAN.EXE Messagebase-Utility, aufräumen der Messagebase BBTPOST.EXE Programm zum posten von Textfiles in Echoareas und als Netmail AREAMGR.HLP Hilfetext für AreaMgr %HELP Anforderung 1.2 Konfigurationsdateien ─────────────────────────────────────────────────────────────────────── BBTLNG.CFG Sprachfile für Meldungen des Tossers (BBTLNG.ENG Sprachfile Englisch) BBTLINK.INI enthält die Downlink-Informationen BBTAREA.INI enthält die Area-Informationen BBTOSS.INI ASCII-File, enthält Pfade und Tossermode-Flags BBTROUTE.CFG ASCII-File, enthält Netmail-Routing für BBToss Pack BBTGROUP.INI ASCII-File, enthält die Namen der Message-Gruppen und Defaults für autom. anzulegende Areas BBTUPLNK.INI ASCII-File, enthält Setup für automaische Areabestellung beim Uplink BBTZIP.INI ASCII-File, enthält Packereinstellungen BBTALIAS.CFG ASCII-File, enthält Aliasnamen des Sysops BBTDUPE.BBT enthält CRC-Daten für Dupecheck Für schnelleren Zugriff compiliert BBToss die Area und Link INI- Dateien in Files mit gleichem Namen jedoch mit Endung *.BBT. Das compilieren wird von BBToss automatisch vorgenommen. Für die Installation maßgebend sind die jeweiligen *.INI und *.CFG Dateien. Die *.BBT Files werden bei Änderungen oder Fehlen auto- matisch erstellt. Dadurch ist sichergestellt, daß bei Versions- wechsel keine manuellen Anpassungen notwendig sind. Das Austauschen der EXE Dateien genügt. 1.3 Aufrufparameter ─────────────────────────────────────────────────────────────────────── BBT.EXE <parameter> Parameter: AUTO Um die Aufrufe fuer den normalen Message Import/Export zu vereinfache. AUTO fuehrt nacheinander alle notwendigen Schritte aus (TOSS/SCAN/MGR/IMPORT/PACK/ZIP) um vorhanden Inbound und Outbound Messages zu verarbeiten. TOSS Tossen der empfangenen Msgpackets, einsortieren in lokale MsgBase abhängig von Schalter "2 pass toss" und verteilen an die Down-/Uplinks. Durch die ESC-Taste kann der Tossvorgang abgebrochen werden. BBToss wird beendet dann sobald als möglich, d.h. das aktuelle Packet wird noch zuende bearteitet. TOSSII im 2 Phasen-Toss-Mode getosste Messages in lokale Messagebase einsortieren PACK Netmails packen unter Berücksichtigung der voreinge- stellten oder angegebenen Routingregeln. SCAN lokale MsgBase nach neuen, zu exportierenden Echomails [/HMB] durchsuchen. Der SCAN Vorgang nimmt einige Zeit in [/JAM] Anspruch, da die gesammte Messagebase nach neuen Messages [/SQUISH] durchsucht wird. Duch den Tosserschalter "benutze [/EZY] ECHOMAIL.BBS" kann der SCAN vorgang beschleunigt werden, [/MSG] wenn der Tosser eine ECHOMAIL.BBS/NETMAIL.BBS (für [/ALL] Hudson), ECHOMAIL.JAM/NETMAIL.JAM (für JAM) oder ECHOTOSS.LOG (für Squish) Datei findet (die vom Mailbox- programm oder vom Editor erzeugt wird). Mit dem Parameter /ALL wird die gesamte Messagebase gescann, egal ob BBToss eine ECHOMAIL.*/ECHOTOSS.* Datei findet oder nicht, was zwar etwas länger dauert, aber todsicher ist. Der Scanvorgang kann durch die ESC-Tast beendet werden. Mit dem optionalen Parameter /HMB wird nur die Hudson Messagebase durchsucht. Mit /JAM nur die Jam-Messagebase. Ein sicherer und guter Kompromiss ist, BBTOSS z.B. Errorlevel (siehe Mailboxdocu) einfach mit SCAN auf- zurufen, wenn neue Messages geschrieben wurden und maximal einmal pro Tag SCAN /ALL aufzurufen um ggf. von neue Msgs zu finden, die mit einem Tool erstellt wurden, welches das ECHOMAIL.BBS Future nicht unter- stützt. MGR Areamgr Netmails bearbeiten RELINK Erstellt AREAMGR Bestell-Messages für alle aktiven Echo-Areas und sendet diese an jeden angeschlossenen Link. NOTIFY Sendet dem angegebenen Link eine Message, genau so als wäre eine Msg an den Areamgr geschickt worden. Aufruf BBT.EXE notify AKA <%areamgr-Befehl> bzw. BBT.EXE notify AKA %<%areamgr-Befehl> Beispiele: bbt notify 2:2471/2400 %List %query %help bbt notify 2:2471/2400 %pause %status bbt notify 49:70/1 %status bbt toss notify 49:70/1 %list pack Nach "notify" muß eine Nodenummer gefolgt von den %Befehlen kommen (4DOS & Windows95 Anwender siehe unten). Beim "notify" Parameter können alle Areamgr-Befehle, die mit "%" beginnen verwendet werden. (wie %LIST, %QUERY, %STATUS, %PAUSE, %RESUME %-ALL) Bei der 2. Aufrufmöglichkeit wird für alle Links, die das Notify-Flag im Linkmanager gesetzt haben eine Statusmsg versendet. Aufruf: BBT.EXE NOTIFY * %STATUS .... bzw. BBT.EXE NOTIFY * %%STATUS Es ist also an Stelle der expliziten Nodenummer ein * einzugeben. 4DOS und Windows 95 Anwender müssen 2 "%" Zeichen bei den Befehlen verwenden z.B BBT.Exe notify * %%STATUS %%LIST IMPORT importiert Netmails in die Messagebase der Box (erst aufrufen wenn alle anderen auf Netmails reagierenden Programme das Netmailfolder des Mailers gescannt haben, z.B. Filemgr, Votemgr usw.) BAD Re-tosst Messages aus dem BadArea und fügt die Messages in die Messagebase ein ZIP nur BBT: ruft intern BBPACK auf um vorhandene *.PKT Files im Outbound an Downlinks zu packen, wird in der Regel nicht benötigt CLEAN nur BBT: löscht die bereits gesendeten (0 Byte Packets) von den Vortagen COMPILE Compiliert (falls notwendig) die aktuellen Text- Configs (*.INI und *.CFG Files). ? Hilfebildschirm anzeigen Es können mehrere Parameter gleichzeitig angegeben werden, die der Reihenfolge nach abgearbeitet werden (dies erspart das mehrfache einlesen der Config-Files) Beispiel: BBTOSS toss mgr pack --> erst tossen, dann Areabestellungen bearbeiten, dann Netmails packen 2. Installation ─────────────────────────────────────────────────────────────────────── Die globale ConfigDatei BBTOSS.INI. Alle hier enthaltenen Einstellungen können mit BBTCFG.EXE menügeführt verändert werden. Selbstverständlich kann man aber auch mit einem Texteditor diese Datei manuell bearbeiten. !!!! WICHTIG !!!! ~~~~~~~~~~~~~~~~~ Nach dem Entpacken der Files müssen auf jeden Fall die Packerein- stellungen im Menü "Zip Optionen" oder im File BBTZIP.INI ange- passt werden. 2.1 Installation BBT.EXE ─────────────────────────────────────────────────────────────────────── Sollte auf ihrem Rechner standardmäßig keine DPMI-Schnittstelle (z.B. durch EMM386 oder HIMEM) installiert sein, müßen sie nur darauf achten, das die mitgelieferten Dateien DPMI16BI.OVL und RTM.EXE im aktuellen Verzeichnis, oder in einem Verzeichnis welches in der PATH Zeile ihrer AUTOEXEC.BAT steht. Einfacherhaltshalber entpacken sie die beiden Dateien in das BBTOSS Verzeichnis und ergänzen die PATH Zeile in der AUTOEXEC.BAT z.B. vorher PATH c:\DOS;c:\WINDOWS nachher PATH c:\DOS;C:\WINDOWS;c:\BBT Wenn die Datei RTM.EXE und DPMI16BL.OVL im Verzeichnis c:\BBT liegt. Weitere Einstellungen bezüglich DPMI-Schnittstelle sind normalerweise nicht notwendig. Einzelheiten zur Beeinflussung der Speicherbelegung durch den DPMI-Loader siehe DOSDPMI.DOC. 2.2 Umsteigen von FMail auf BBToss ─────────────────────────────────────────────────────────────────────── - Erstellen eines Verzeichnisses für BBToss z.B. MD c:\BBT - Erstellen eines Arbeitsverzeichnisses für BBToss z.B. MD c:\BBT\work - Entpacken des Archives im BBT Verzeichnis BBTINST.EXE aufrufen. Die Environmentvariabel FMAIL (SET FMAIL=) muß gesetzt sein und auf das Verzeichnis in denen sich die FMail Daten befinden zeigen. - BBTCFG aufrufen und die Einstellungen ergänzen, z.B. Akas, Routing, Verzeichnisse, Packer, Gruppen usw. 2.3 Umsteigen von Fastecho auf BBToss ─────────────────────────────────────────────────────────────────────── - Erstellen eines Verzeichisses für BBToss - Erstellen eines Arbeitsverzeichnisses für BBToss Umstieg von Fastecho 1.41 / 1.45 / 1.46 - BBTINST.EXE aufrufen. Die Environmentvariable FE (SET FE=) muß gesetzt sein. Die Funktion konvertiert die Area- und Nodeeinstellungen, uebernimmt Verzeichnisse, globale Tosserflags, Gruppen und Routing. Dabei werden ggf. vorhandene BBToss CFG Dateien überschrieben. ~~~~~~~~~~~~~~ - BBTCFG aufrufen und die Einstellungen ergänzen, z.B. Akas, Routing, Verzeichnisse, Packer, Gruppen usw. Ganz wichtig, die Packereinstellungen, da diese nicht übernommen werden und BBToss (aus Sicherheitsgründen) ausschliesslich mit absoluten Pfaden zu den Packern arbeitet. 2.4 Umsteigen von Ezycom auf BBToss ─────────────────────────────────────────────────────────────────────── - Erstellen eines Verzeichisses für BBToss - Erstellen eines Arbeitsverzeichnisses für BBToss - Aufrufen von BBTINST.EXE. Die Environmentvariable EZY (SET EZY=) muß gesetzt sein. - Aufruf von BBTCFG und die importierten Daten kontrollieren 2.6 Besonderheit unter NW-Dos 7.0 ─────────────────────────────────────────────────────────────────────── Der DPMI-Laufzeitmanager von NW-Dos 7.0 ist nicht 100% kompatibel zu dem von BBToss verwendetem. Daher sollte der mitgelieferte verwendet werden (RTM.EXE, DPMI16BI.OVL). Dazu ist darauf zu achten das der Speichermanager EMM386.EXE mit Parameter DPMI=OFF in der Config.sys aufgerufen wird, z.B. DEVICE=C:\NWDOS\EMM386.EXE DPMI=OFF FRAME=AUTO /W Ist die DPMI-Schnittstelle des EMM386.EXE aktiv tritt z.B. folgende Symphtom auf: Bei packen der erstellten Mailpackets (*.PKT) zu einem ARCMail Bundle wird nur für einen Link ein ARCMail Bundle erstellt, obwohl noch weitere *.PKT Files für andere Links im Outbound/TmpOutbound liegen. 2.6.1 Entpacken mit ARJ unter NWDos + NWLite ─────────────────────────────────────────────────────────────────────── Unter NWDos 7.0 in Verbindung mit NWLite 1.1 ist es nicht möglich ARJ Archive auf einem Netzlaufwerk zu entpacken. Dies betrifft in der Regel nur Multiline-Systeme, die BBToss nicht von dem Rechner aus aufrufen, auf dem die empfangenen ARCMail Files liegen. In diesem Fall wird empfohlen ein anderes Packprogramm zu verwenden. 3 Das Setup-Programm (BBTCFG.EXE) ─────────────────────────────────────────────────────────────────────── 3.1 Das Setup-Menü ─────────────────────────────────────────────────────────────────────── 3.1.1 Aka Setup ─────────────────────────────────────────────────────────────────────── Aka ist die Abkürzung für "also known as" was man mit "auch bekannt unter" übersetzen kann. Es ist also nichts anderes gemeint, als eine oder mehrere Adressen (Nodenummern) unter denen man das System (den Sysop) erreichen kann. Im Aka-Setup kann man nun seine Nodenummern, auf die BBToss reagieren soll eintragen. Die 1. Adresse wird von BBToss intern als Hauptadresse betrachtet (Main-AKA) und wird z.B. verwendet, wenn BBToss eine Nachricht an den Sysop schreibt. Bei der Eingabe muß eine vollständige Nodenummer eingegeben werden, also Zone:Netz/Node (z.B. 2:246/2480 oder 49:70/1). Die Eingaben werden in der ASCII-Datein BBTOSS.INI gespeichert, in der registrierten Version ist die Anzahl der Adressen unbegrenzt [+] [d.h. es können bis zu 32000 eigene Adressen eingetragen werden :-) ], in der unregistrierten Version sind maximal 40 AKA's möglich. Für Anwender von binkleystyle-Mailern (z.B. Binkley, Xenia, McMail...) ist es wichtig als 1. Aka (also die Mainaka) die gleiche wie im Mailer zu verwenden, da dieses Einfluß auf die Outbound-Verzeichnis-Namen hat. 3.1.2 Verzeichnisse Setup ─────────────────────────────────────────────────────────────────────── Die Eingaben werden in der ASCII-Datei BBTOSS.INI gespeichert. Alle Directory-Eingaben müssen mit einem \ enden. - Netmail-Folder-Typ Area Base-Typ des globalen Netmailfolders auf welches ggf. auch der Mailer zugreift Die meisten Mailer setzen ein Fido *.MSG Format voraus (N). BBToss erlaubt hier aber auch jedes andere Format (ausser HTML). - Netmail-Folder Pfad zum globalen Netmail-Folder-Area indem zunächst jede empfangene und zu sendende Netmail zwischengespeichert wird. - Netmail-Folder-DefaultZone Ueblicherweise enthalten Netmails eine MsgId aus der BBT die DefaultZone autom. ermittelt. Bei Links, die ein Gateway oder aeltere Fido-Editoren betreiben kann diese Information in den Netmails fehlen (oder im 2D Format ohne Zoneangabe vorliegen). Im Fido *.MSG Format (Standardformat des Netmailfolders) werden keine Information ueber Zone gespeichert, die hier angegebene Zonenr. wird bei allen Msgs ohne Zone-Angabe als Default-Zone angenommen (DefaultZone fuer Europa ist 2 ). DefaultZone ist daher insbesondere bei Netmail-Folders im *.MSG Format bei Connects zu Gateway-Systemen nützlich. - Copy sent Netmails to Area Name (nicht das Verzeichnis) des Areas in das lokale Netmails kopiert werden, bevor Sie geloescht werden. Um das Kopieren zu aktivieren ist Tosser-Flag "Copy Sent Netmail" einzuschalten. Das Area muss im Areamanager eingetragen sein/werden. BBToss kopiert lokal erstelle Netmails aus dem globalen Netmailfolder direkt vor dem loeschen in dieses Area. Netmails werden nach dem versenden/packen von BBToss geloescht, wenn sie das Flag Kill-After-Sent tragen, welches in der Regel gesetzt wird, wenn Flag "kill sent Netmail" eingeschaltet ist. (Da zu exportierende Netmails aus Box-Netmail Areas (SCAN) zunaechst im globalen Netmailfolder zwischen gespeichert werden, werden auch diese Netmails erfasst). - Work-Directory In dieses Verzeichnis speichert BBToss die entpackten *.PKT aus ARCMail Packeten zwischen und verwendet es für andere temporäre Dateien. Dieses Verzeichnis sollt NICHT mit anderen Programmen geteilt werden, die *.PKT Files erstellen oder bearbeiten. Am sichersten ist es wenn für BBToss ein eigenen Verzeichnis angelegt wird. Die Verwendung von einer RAM-Disk kann NICHT emfpohlen werden, da bei großen Echomailpackets die nicht auf die RAM-Disk passen Fehler auftreten können. - Hudson-Msg-Base Pfad zur Hudson-Message-Base - Logdatei Dir Verzeichnis in dem die Logdatei erstellt wird 3.1.3 Outbound / Inbound Setup ─────────────────────────────────────────────────────────────────────── - Secure Inbound-Directory Pfad zum Verzeichnis des Mailers, in dem eingehende Mailpackete gespeichert werden, von Nodes mit Sessionpassword - UnSecure Inbound-Directory Pfad zum Verzeichnis des Mailers, in dem eingehende Mailpackete gespeichert werden von Nodes ohne Sessionpassword (unbekannte Nodes) - Local-Inbound-Dir Packets im Local-Inbound-Dir werden ohne jegliche Prüfung getosst. Dieses Verzeichnis wird in der Regel verwendet um lokale *.PKT Files (z.B. von anderen Programmen erstellt, wie z.B. Filetosser) zu bearbeiten, da hierbei weder Aka noch Passwort überprüft werden. - Outbound-Directory In diesem Verzeichnis werden die ausgehenden Mailarchive von BBToss erstellt. Für binkleystyle Mailer ist dies der Basisname der Outbounds in dem die *.FLO und *.OUT Files geschrieben werden (also das Outbound des Mailers). BBToss unterstützt automatisch die Zone-Outbound-Dirctorynamen, also z.B. c:\BT\OUTBOUND wird für die Mainaka unverändert verwendet, z.B. Mainaka Zone 49, dann wird für Zone 2 das Verzeichnis auf c:\BT\OUTBOUND.002 erweitert. Domain-Outboundnamen werden von BBToss in der jetzigen Version nicht unterstützt. 3.1.4 Gruppen Setup ─────────────────────────────────────────────────────────────────────── Die Eingaben werden in der ASCII-Datei BBTGROUP.INI gespeichert. Die Gruppen werden durch ein Zeichen gekennzeichnet. Zulässig sind Zeichen von "0" - "9", von "A" - "Z" und von "a" - "z". Das heißt BBToss unterscheidet bei den Gruppen zwischen Groß- und Kleinschreibung (case sensitiv), Gruppe a ist nicht das Selbe wie Gruppe A. Für automatisch erstellte Areas (siehe Uplinkmanager) können hier erweiterte Angaben eingetragen werden, wenn ein selb- ständig erstelltes Area auch gleich physisch angelegt werden soll. Dazu ist eine StartAreanummer anzugeben. BBToss sucht ab dieser Areanummer nach einer noch nicht belegten Nummer und trägt diese beim erhalt der 1. Message eines durch den Uplinkmanager erstellten Areas ein (bei Startnummer 0 ist diese Funktion abgeschaltet). Weiter notwendige Angaben für das erstellen der Area ist ein Messagebase-Typ (also J=JAM, S=Squish usw.) und ein Messagebase- verzeichnis (beachte, hier nur ein Verzeichnis eintragen, der eigentliche Dateiname [bei Jam und Squish] wird von BBToss beim erstellen der Areas selbständig generiert). Im Feld Ruleverzeichnis kann ein Verzeichnis angegeben werden in dem BBToss die Rule-Textdateien für diese Gruppe findet. Der Rule-Dateiname selbst wird im Area-Editor angegeben (bzw. im Importmenü eingelesen). Das Feld "Statistik Area" dient der automatischen Erstellung einer Gruppen-Tagesstatistik (in der registrierten Version) Wird hier der Name (Echotag) eines Areas angegeben erstellt BBToss eine Echostatistik Mail für diese Gruppe und tosst sie in das Area. Die Ausgabe in das Area erfolgt im automatischem Tagesevent (1. Aufruf von BBToss an diesem Tag). Ausgegeben wird eine Tagesstatistik mit der Anzahl der verarbeiteten Messages jedes Area dieser Gruppe. 3.1.5 Packer Optionen ─────────────────────────────────────────────────────────────────────── Bei den Eintragungen der Packer ist darauf zu achten, daß IMMER der absolute Pfad zum Packprogramm angegeben werden muß (dies ist ein entscheidender Sicherheitsaspekt). Z.B c:\packer\pkzip.exe Der Pfad kann nur entfallen, wenn das/die Packer im angegebenen Default-Packer-Pfad zu finden sind. Da bei der Erstinstallation noch keine absoluten Pfade einge- tragen sind müssen die Packereinstellungen entsprechend ergänzt (und nicht vorhandene Packer gelöscht) werden. Beim packen/entpacken mit PKZIP/PKUNZIP kann es zu Problemen mit der DPMI Option von PKZIP/PKUNZIP kommen, daher sollte PKZIP/PKUNZIP mit dem Parameter "-)" aufgerufen werden, der den Zugriff von PKZIP/PKUNZIP auf die DPMI-Laufzeitbibliothek verhindert. Beispiel für den Eintrag in BBTZIP.INI [ZIP] Compress=c:\bin\pkzip.exe %a %f Extract=c:\bin\pkunzip.exe -e -- -+ -) %a %f %p ListSign=@ Wer bisher eine globale Packerschell verwendet, kann bei den einzelenen Packern (die unterstützt werden sollen) auch die Packerschell eintragen. Dabei ist zu berücksichtigen, wie BBToss den Pack- Unpackbefehl erweitert. Im Pack- bzw. Entpackaufruf sind 3 verschiedene %-Parameter zulässig, die beim Aufruf wie folgt ersetzt werden %a Name des zu (ent-)packenden Archives %f Name der zu packenden Datei, bzw. der Name einer von BBToss erstellten ASCII-Datei, aus der der Packer die Namen der zu packenden Dateien liest. Wird eine Listdatei verwendet setzt BBToss vor den Parameter das/die Zeichen (maximal 3) die unter LISTSIGN angegeben sind. %p Der Pfad in den das Archiv entpackt werden soll Für den Aufruf zum entpacken ist %a, %f und %p anzugeben, damit BBT Archivname und Entpack-Zielverzeichnis eintragen kann. Beim Aufruf zum packen ist %a und %f anzugeben, damit BBT Archiv- name und zu packendes File (Fileliste) einsetzen kann. Z.B. Extract=pkunzip.exe -e %a %f %p wird erweitert von BBT erweitert zu: pkunzip.exe -e \inbound\0000ffff.mo1 \bbt\work Compress=pkzip.exe -a %a %f wird von BBT erweitert zu: pkzip.exe -a \outbound\ffff0000.mo1 \bbt\tmpout\12345678.pkt oder pkzip.exe -a \outbound\ffff0000.mo1 @\bbt\packlist.bbt Da die OS/2-Packer teilweise abweichende Parameter erwarten, als ihre Dos-Versionen bietet BBToss die Möglichkeit die Einstellungen für Dos und OS/2 gleichzeitig in der BBTZIP.INI aufzunehmen. Dies ist auch vorteilhaft, wenn die Dos und OS/2 Version von BBToss gemischt betrieben wird/werden soll. Für die OS/2 Einstellung ist ein weiterer INI-Datei Eintrag anzufügen, bei dem ein OS2_ dem Packerkurznamen vorangestellt wird, also z.B. [ZIP] für die Doseinstellungen und [OS2_ZIP] für die OS/2 Einstel- lungen. Beispiel: [ZIP] Extract=c:\dos_pack\pkunzip.exe -e -- -+ -) %a %f %p Add=c:\dos_pack\pkzip.exe -) %a %f ListSign=@ [OS2_ZIP] Extract=c:\os2_pack\unzip.exe -s -j -o -L -qq %a %f -d %p Add=c:\os2_pack\zip.exe %a %f ListSign=-@< 3.1.6 Alias Setup ─────────────────────────────────────────────────────────────────────── Hier können bis zu 100 Namen eingegeben werden. Verarbeitet BBToss eine Message, die an einen dieser Namen gerichtet ist, wird die entsprechende Message herauskopiert und als Netmail an den Sysop gespeichert. Die Originalmessage wird dabei nicht verändert und ganz normal verarbeitet. Groß-/Kleinschreibung wird bei den Namen nicht unterschieden. Soll die Message nicht in das Netmailverzeichnis des Mailers kopiert werden, so kann hinter dem Aliasnamen (durch Komma getrennt) ein anderes Area angegeben werden (AREANAME) in das die Mail kopiert wird (z.B. Sysop,MYMAIL). Diese Area muß dann aber in BBToss bereits eingerichtet sein. 3.1.7 Die Tosser Flags ─────────────────────────────────────────────────────────────────────── 3.1.7.1 lösche 0-Byte Netmails ─────────────────────────────────────────────────────────────────────── Netmails ohne Text (z.B. von Echomailpacketen oder Ticfiles) werden sofort gelöscht. 3.1.7.2 gesendete Netmail löschen ─────────────────────────────────────────────────────────────────────── Beim PACK Befehl werden gepackte/gesendete Netmail aus dem Netmail- folder gelöscht (also Netmails die den sent-Status haben). Voreinstellung: Netmail als "sent" markieren. 3.1.7.3 Dupes löschen ─────────────────────────────────────────────────────────────────────── Dupemsgs werden sofort gelöscht (nicht in ein Dupearea geschrieben) 3.1.7.4 Badmails löschen ─────────────────────────────────────────────────────────────────────── Badmsgs werden sofort gelöscht (nicht in ein Badarea geschrieben) 3.1.7.5 Areamgr Antworten löschen ─────────────────────────────────────────────────────────────────────── Antworten vom Areamgr werden nach dem senden/packen gelöscht, wenn Schalter aus ist, als "sent" markiert. Eine Kopie an den Sysop wir auf jeden Fall geschrieben. 3.1.7.6 bounce unzustellbare Netmail ─────────────────────────────────────────────────────────────────────── Netmails für die vom Tosser kein Empfänger ermittelt werden kann, also kein Link vorhanden ist an den er die Netmail senden kann und sie auch nicht an eine eigene Aka gerichtet ist, werden mit diesem Schalten an den Absender zurückgeschickt. Der Empfänger kann nicht ermittelt werden, wenn per voreingestelltem HOST/Node/Point-Routing und auch durch keine Zeile im BBTROUTE.CFG eine Nodenummer ermittelt werden kann. Weiterhin, wenn bei einem Link ein Routingfehler auftritt und die Netmail mehrmals vom eigenen BBToss verarbeitet wurde. (Dies kann auch auftreten wenn man selber eine Routinganweisung ver- gessen hat, z.B. es existiert ein Link 49:70/703, der bei 49:70/701 pollt, und keine Routinganweisung "49:70/701 49:70/703" eingetragen wurde, sondern nur die globale 49:70/0 49:*, dann schickt der eigene BBToss die Netmail an 49:70/0 zurück). Und zum letzten, wenn der Link an den die Netmail gerichtet ist, oder das System über die die Netmail geroutet wird, nicht aktiv ist (-> Link-Editor "aktiv Flag"). In diesem Fall wird dies in der zurückgeschickten (gebouncten) Netmail als Ursache angegeben. 3.1.7.7 strikter Inbound AKA Check ─────────────────────────────────────────────────────────────────────── Durch setzen dieses Flags werden im Inboundverzeichnis keine Packets verarbeitet, deren Absender dem Tosser nicht bekannt ist. Normalerweise wird das Inbound-Verzeichnis auf das Verzeichnis des Mailers gelegt, in dem dieser die Packets von Links mit einem Sessionpasswort ablegt (Packets von unbekannten Links werden im UnSecureInbound erwartet). Wenn der Mailer diese Unterscheidung unterstützt, sollte diese zusätzliche Sicherheitsschranke ver- wendet werden (da BBToss von unbekannten Links z.B. keine Echo- mail tosst und Netmails von unbekannten Links nicht routet). Bei Connects mit Links die z.B. Frontdoor oder Intermail Multi- line Boxen fahren kann es vorkommen, daß bei Anruf auf einer anderen Line die Packets nicht mit der erwarteten Hauptaka des Systems übertragen werden. In diesem Fall kann man dieses Flag ausschalten, wodurch Packets im Inbound von nicht bekannten Nodenummern wie Packets im UnSecureInbound behandelt werden. Gleiches gilt für Mailer, die Überhaupt kein UnSecureInbound (oder etwas analoges) kennen. 3.1.7.8 konvertiere Fattach (binkleystyle) ─────────────────────────────────────────────────────────────────────── Bei Mailern mit binkley Style Outbound (wie Binkley, McMail, Xenia) werden Netmails (mit oder ohne Fileattach) nicht als *.MSG Files verarbeitet, sondern in *.OUT Files im Outbound erwartet. Daher ist für das behandeln von Netmails bei solchen Mailern üblicher Weise ein zusätzliches Tool erforderlich. BBToss erledigt dieses umwandeln/konvertieren mit. Bei Fileattach Msgs wird zusätzlich zu dem *.OUT ein *.FLO erstellt um die angehängte Datei zu übertragen. Mit diesem Flag wird festgelegt, daß BBToss auch Fileattach Msgs bearbeitet und ein entsprechendes *.OUT und *.FLO anlegt. Ist dieses Flag nicht aktiv, werden bei binkley Style Mailern Fileattach Msgs von BBToss UEBERHAUPT NICHT bearbeitet (siehe auch LinkEditor->Flags->Fileattach erlaubt) 3.1.7.9 verwende Echomail.BBS (bei SCAN) ─────────────────────────────────────────────────────────────────────── Beschleunigt den Scanvorgang, da anhand der Echomail.BBS (muß vom Editor oder Boxprogramm erstellt werden) sofort die neuen Messages getosst werden, ohne das die gesamte Area abzusuchen. Beim Scannen der Hudson Messagebase verwendet BBToss die Datei Echomail.BBS und Netmail.BBS um herauszufinden, in welchem Area neue Messages enthalten sind. Hierdurch wird der Scanvorgang erheblich beschleunigt. die Dateien Echomail.BBS und Netmail.BBS müssen von dem Programm erzeugt werden mit dem die Message geschrieben wurde, ist also nicht Aufgabe von BBToss. Lesen sie in der Docu ihres Boxprogramms nach oder schreiben sie einfach eine Message und schauen nach, ob im Hudson Directory die Dateien erstellt wurden. Die Dateien ECHOMAIL.BBS und/oder NETMAIL.BBS werden von BBToss im gleichen Verzeichnis erwartet in dem die restlichen Hudson Message- base Dateien vorhanden sind (also im Verzeichnis welches in BBToss als Pfad für die Hudson Base angegeben wurde). Für JAM-Areas verwendet BBTOSS die Datei ECHOMAIL.JAM , die in dem Directory gesucht wird, welches als HudsonMsgDir im Setup angegeben wurde. Für Squish wird analog die ECHOTOSS.LOG Datei im eingestelltem Ver- zeichnis verwendet. In BBTCFG muß dazu Pfad und Dateiname angegeben werden. Anmerkung: Mit Parameter SCAN /ALL kann erzwungen werden, das BBToss die gesammte Messagebase nach neuen Messages durchsucht. 3.1.7.10 2-Phasen Toss ─────────────────────────────────────────────────────────────────────── 2 geteilter Tossvorgang siehe TOSSII Beim Aufruf von TOSS werden die aktuellen Packets an die Links verteilt und gleichzeitig ein lokales Packet (LOCALPKT.0) erzeugt, die zu einem späteren Zeitpunkt mit TOSSII in die Messagebase einsortiert werden können. 3.1.7.11 Multiline/Multitasker-Mode ─────────────────────────────────────────────────────────────────────── Schaltet die Verwendung von Semaphoren ein, in diesem Modus muß SHARE geladen sein. 3.1.7.12 Path-Line Dupecheck ─────────────────────────────────────────────────────────────────────── Verwenden der Msg-Path Zeile für DupeCheck. Kommt eine eigene Aka in der Path Zeile vor, wird die Msg als Dupe erkannt. Unabhängig davon, welche Aka im Area als für das Area zu verwendende Nodenummer eingetragen ist, prüft BBToss die Pathzeile gegen alle eigenen Akas. Der Path-Line Dupecheck sollte auf jeden Fall verwendet werden, da hiermit der größte Teil der Dupes erkannt wird und dies unabhängig von der Laufzeit der Nachricht (was z.B. bei Dupes von Pointsystemen die selten pollen sicherer ist als ein reiner CRC-Dupecheck). Insiderinfo: Da in der Path-Zeile keine Pointnummern enthalten sind, aber Point- systeme existieren, die selber die Nodenummer des Bossnodes an die Path-Zeile anfügen schlägt die Dupeerkennung von BBToss bei Messages aus Packets von eigenen Points erst an, wenn eine eigene Aka 2x in der Path-Zeile vorkommt. 3.1.7.13 CRC DupeCheck ─────────────────────────────────────────────────────────────────────── Errechnet und speichert einen CRC-Wert aus der MsgId (so vorhanden) Absender und Subject jeder Message welcher zur Dupeerkennung beim tossen verwendet wird. Der check wird für jedes Area getrennt durch- geführt, so daß Crosspostings (besser gesagt Crosscopying, der selben Msg in verschiedenen Areas) nicht als Dupe angesehen wird. 3.1.7.14 SEEN-BY DupeCheck ─────────────────────────────────────────────────────────────────────── Bezieht die SEEN-BY Zeilen in Echomails für die Dupeerkennung mit ein. Das bedeutet, das bei aktivem Schalter die Msg an keinen Downlink weitergesendet wird, der im Seen-By enthalten ist. Ausgenommen davon sind eigene Points, da diese ja die gleiche Grund- nodenummer wie man selber trägt und die somit in jedem Fall im Seen-By enthalten ist. Diese Dupecheck Methode ist mit Vorsicht zu genießen. Es vermeidet zwar Duperinge ermöglicht aber auch fremden Systemen (in der Up- link Kette) durch hinzufügen von Seen-By's das tossen an einen Down- link zu verhindern. 3.1.7.15 Copy Echo-Msg an Alias ─────────────────────────────────────────────────────────────────────── Schaltet die Alias-copy Funktion ein, die jede Echomail an die im Aliasconfig eingegebenen Namen als Netmail herauskopiert ein. In der aktuellen Version sind maximal 100 Aliasnamen zulässig. 3.1.7.16 Keine Info Msg an Sysop ────────────────────────────────────────────────────────────────────── BBToss schreibt in verschiedenen Fehlersituationen lokale Info Nachrichten (Netmails) an den Sysop. Ist dieses Flag aktiv, werden KEINE Info/Fehler Nachrichten geschrieben. 3.1.7.17 Error Netmails an Links sofort senden ────────────────────────────────────────────────────────────────────── Wenn gesetzt erstellt BBT die Fehler-Netmails sofort (während des tossens), wenn nicht gesetzt werden die Fehlermeldungen erst erstellt/gesendet wenn BBT SAYERR aufgerufen wird. 3.1.7.18 Return Receipt Request Antwort Messages ────────────────────────────────────────────────────────────────────── Wenn gesetzt erstellt BBT beim tossen von Netmails an das eigene System, die das Flag ReturnReceiptRequest enthalten eine Antwortmessage, dass die Message erhalten wurde und sendet diese an den Absender der Message. 3.1.7.19 Autoexport Area.BBS ────────────────────────────────────────────────────────────────────── Wenn markiert wird bei Aenderungen der Area Konfiguration (z.B. neues Area waerend tossen erstellt) automatisch eine AREAS.BBS Datei neu exportiert, welche von anderen Programmen (z.B. Mailbox Editor usw.) verwendet werden kann. Der Name der Datei kann im Menue Autoexport definiert werden. 3.1.7.20 Autoexport TimEd Area Config ────────────────────────────────────────────────────────────────────── Wenn markiert wird bei Aenderungen der Area Konfiguration (z.B. neues Area waerend tossen erstellt) automatisch eine Timed Config Datei neu exportiert. Der Name der Datei kann im Menue Autoexport definiert werden. 3.1.7.21 Autoexport GoldEd Area Config ────────────────────────────────────────────────────────────────────── Wenn markiert wird bei Aenderungen der Area Konfiguration (z.B. neues Area waerend tossen erstellt) automatisch eine GoldEd Config Datei neu exportiert. Der Name der Datei kann im Menue Autoexport definiert werden. 3.1.7.22 Autoexport Squish Area Config ────────────────────────────────────────────────────────────────────── Wenn markiert wird bei Aenderungen der Area Konfiguration (z.B. neues Area waerend tossen erstellt) automatisch eine Squish Config Datei neu exportiert. Der Name der Datei kann im Menue Autoexport definiert werden. 3.1.7.23 Kopiere gesendete Netmails ────────────────────────────────────────────────────────────────────── Wenn markiert werden lokale Netmails vor dem loeschen/senden in das bei "Copy sent Netmail to" eingestellte Area kopiert. (siehe Netmailfolder Setup, Setup->Verzeichnisse). 3.1.8 Limits ────────────────────────────────────────────────────────────────────── 3.1.8.1 Dupecheck: Message Alter ────────────────────────────────────────────────────────────────────── Maximal zulässiges Alter einer Message in Tagen Mit diesem Wert kann eingestellt werden, nach welchem Alter eine Message grundsätzlich als Dupe bzw. Badmail erkannt wird. Wird hier z.B. 200 Tage eingestellt, so wird JEDE Msg, die empfangen wird, aber älter als 200 Tage ist automatisch als Dupe erkannt UND NICHT WEITERGELEITET. 0 schaltet diesen Dupecheck ab. Der kleinste einstellbare Wert ist 15 Tage. 3.1.8.2 Dupe-Check Save max Msg pro Area ────────────────────────────────────────────────────────────────────── Hier kann angegeben werden wieviele CRC Daten maximal für den CRC-Dupecheck pro Area gespeichert werden. 0 = kein Limit (jedoch maximal 1.000.000), Beachte, je größer dieser Wert, je mehr CRC Daten müssen verwaltet werden, was a) Speicher kostet und b) Zeit um jede Message mit den vorhandenen CRC Daten zu vergleichen, was die Ausführungsgeschwindigkeit beim tossen ERHEBLICH verringern kann. Es wird dringend empfohlen hier ein Limit zu setzen. 3.1.8.3 Dupe-Check Save Msg-Alter ────────────────────────────────────────────────────────────────────── Die Dupecheck CRC Daten von verarbeiteten Messages werden maximal für die hier angegebene Anzahl von Tagen gehalten/gespeichert. 0 = kein Limit (jedoch maximal 1000 Tage) Beachte, je größer dieser Wert, je mehr CRC Daten müssen verwaltet werden, was a) Speicher kostet und b) Zeit um jede Message mit den vorhandenen CRC Daten zu vergleichen, was die Ausführungsgeschwindigkeit beim tossen ERHEBLICH verringern kann. Es wird empfohlen hier ein Limit einzutragen. 3.1.8.4 Maximale Toss Zeit ────────────────────────────────────────────────────────────────────── Zeitliche Begrenzung eines Tossvorgangs in Minuten. Z.B. MaxTime=15 beendet das Tossen nach ca. 15 Minuten, auch wenn noch nicht alle Packets vertosst sind. Dadurch besteht die Möglichkeit den Tosser so einzustellen, das der nächste Mailer-Event auf jedenfall eingehalten wird. Die noch nicht bearbeiteten Packets werden dann beim nächsten Aufruf getosst. Der kleinste einstellbare Wert ist 5 Minuten. 3.1.8.5 Maximale nicht gepollt Zeit ────────────────────────────────────────────────────────────────────── Wird beim Tossen bei einem Link ein Mailarchiv festgestellt, welches älter als die hier angegebene Anzahl von Tagen ist, wird der Link automatisch auf HOLD gesetzt. Dadurch werden keine weiteren Echomails für den Link erstellt, bis er manuell (in BBTCFG) oder per Areamgr Request (Befehl %RESUME oder %ACTIV) wieder aktiv geschaltet wird. Dadurch wird ein ansammeln von Echomails, wenn ein Link z.B. bei längerem Urlaub vergessen hat ein %PAUSE Areamgr Request zu schicken vermieden. HoldDays=0 schaltet diese Funktion ab. 3.1.8.6 Maximale Packet Größe ────────────────────────────────────────────────────────────────────── Default maximale Größe eines Msg-PKT-Files in Byte. Voreingestellt sind 1000000 Byte (1 MB). Überschreitet das aktuelle *.PKT File diese Größe, werden nachfolgende Messages in ein neues File geschrieben. Minimal einstellbare Größe ist 100.000 Byte. Der hier eingestellte Wert wirkt global, im Linkmanager kann dieser Wert fuer jeden Link individuell eingestellt werden. 3.1.8.7 Maximale ARCMail Größe ────────────────────────────────────────────────────────────────────── Maximale Größe eines Msg-ARCMail-Archivs. Voreingestellt sind 1000000 Byte (1MB). Übersteigt das Archiv diese Größe, wird beim _nächsten_ Tossvorgang ein neues Archiv erstellt. Minimale einstellbare Größe ist 64000. Der hier eingestellte Wert wirkt global, im Linkmanager kann dieser Wert fuer jeden Link individuell eingestellt werden. 3.1.8.8 Minimaler Disk Free Platz ────────────────────────────────────────────────────────────────────── Minimaler freier Platz auf der Festplatte. Vor und waehrend dem Tossen prueft BBToss ob genuegend freier Speicherplatz auf der Festplatte vorhanden ist. Ist weniger Platz als hier angegeben vorhanden, werden keine weiteren Messages an die Downlinks verteilt. Der freie Plattenplatz wird beim TOSS und UNZIP Befehl überprüft. TOSS prueft die den freien Platz im Outbound/Temp.Outbound, vor dem Entpacken wird Inbound/Temp.Inbound geprueft. BBTOSS PACK, ZIP usw. werden weiterhin ausgeführt. Der größte einstellbare wert ist 200000000 (200MB). 3.1.8.9 Max. Files Open ────────────────────────────────────────────────────────────────────── Anzahl der Files, die BBToss gleichzeitig öffnen darf. Dieser Wert hängt von der jeweiligen Dos-Einstellung ab und muß immer kleiner sein, wie der Wert von FILES= in der CONFIG.SYS. Standardwert ist MaxFilesOpen=20 Da BBToss während des Tossens für jeden Downlink an den in diesem Tossvorgang Messages gesendet werden 1 File öffnen möchte ohne dieses Files sofort wieder schließen zu müssen, ist ein hoher Wert erwünscht. Ein Wert von MaxFilesOpen kleiner 10 sollte auf jedenfall vermieden werden. BBTCfg prueft die tatsaechlich moegliche Anzahl gleichzeitig offener Dateien wenn die Einstellung hier geaender wird und gibt an ob der neue Wert zulaessig ist. 3.2 Link-Daten Menü ─────────────────────────────────────────────────────────────────────── In diesem Menü sind alle Einstellungen die sich auf Linkdaten beziehen zusammengefaßt. 3.2.1 Link-Edit ─────────────────────────────────────────────────────────────────────── Es erscheint eine Liste aller in BBToss eingerichteten Links. Durch betätigen der Schalter am unteren Rand kann die Liste am Bildschirm nach verschiedenen Kritereien sortiert dargestellt werden (Schalter mit Maus anklicken oder ALT-Taste + hervorge- hobenen Buchstaben). Mit der RETURN-Taste kann man den Link auf dem der Laufbalken steht editieren. Sowie per Maus-Doppelklick. Mit der EINFÜGEN-Taste wird ein neuer Link hinzugefügt, mit der ENTFERNE-Taste gelöscht. Wurde ein Link hinzugefügt, wird nach dem eingeben der Daten danach gefragt, ob der Link an alle Areas der Gruppe angeschlossen werden sollt. Wird dies mit YES beantwortet, so wird der Link an alle Areas aus allen Gruppen die beim Link eingetragen wurden angeklemmt, wenn der beim Link eingetragene Level größer oder gleich dem Readlevel des Areas ist. Es wird also der gleiche Zustand hergestellt, als wenn der Link eine Message an den AREAMGR mit dem Befehl %ALL geschickt hätte. Mit dem "Copy"-Knopf wird ein neuer Link durch kopieren des aktuellen Links angelegt. Dies ist eine schnelle Möglichkeit einen Link anzulegen, bei dem nur wenige Daten eines bestehenden Links geändert werden müssen. Die Nodenummer muß immer geändert werden, da es in BBToss nicht zulässig ist 2 Links mit gleicher Nodenummer einzutragen (ggf. wird eine entsprechende Fehler- meldung angezeigt). 3.2.1.1 Link-Daten im Einzelnen ─────────────────────────────────────────────────────────────────────── Sysop Name des Sysops oder des Systems NodeNr Die Nodenummer oder Pointnummer der Links UseAka Die eigene Nodenummer, die in den Mail-Packets als Absendernodenummer verwendet wird PktPwd Das Mail-Packet Passwort MgrPwd Das Passwort fuer den Areamanager Level Level, der mit dem Lese- und Schreiblevel der Areas verglichen wird Group Area-Gruppen, denen der Link angehört und aus denen er Areas bestellen kann. Es sind maximal 15 Gruppen pro Link vorgesehen. Wird * eingegeben gehört der Link zu jeder Gruppe Packer Das Packprogramm, mit dem die Mail-Packets für den Link gepackt werden. Es wird jeweils nur ein Buchstabe als Kennzeichen eingegeben. Mit der Pfeiltaste runter erhält man eine Liste der möglichen Eingaben. Z=ZIP J=ARJ L=LHA A=ARC S=SQZ O=ZOO Max. Pkt Maximale Groesse eines Packet-Files (*.PKT) fuer diesen Size Link. Dies ueberschreibt die Vorgabe in Setup->Limits. Max. Maximale Groess eines Arcmail Archives (*.MO1 usw.) fuer Archive diesen Link. Diese Angabe ueberschreibt die Vorgabe in Size Setup->Limits Arcmailstatus Auswahlfeld des Mail-Status mit dem das Mailarchiv erstellt wird. - ohne [X] bei einem Connect wird das Archiv versendet - hold nur wenn der Link anruft wird das Archiv gesendet - direct nur direkt versenden, ggf. vorhandene File-Routingregeln des Mailers bleiben wirkungslos. In der Regel werden Files (eben das Mailarchiv) vom Mailer automatisch nur direkt versendet - crash der Mailer ruft den Link an und sendet das Mailpacket sofort (wenn der Mailer im aktuellen Event Crash-Mails verarbeitet) Mailstatus Auswahlfeld des Mail-Status mit dem Netmails für den erstellt werden. - ohne [X] bei einem Connect wird die Netmail versendet - hold nur wenn der Link anruft wird die Netmail gesendet - direct nur direkt versenden, ggf. vorhandene Mail-Routingregeln des Mailers bleiben wirkungslos. - crash der Mailer ruft den Link an und sendet die Netmail sofort (wenn der Mailer im aktuellen Event Crash-Mails verarbeitet) 3.2.1.2 Link Flags ─────────────────────────────────────────────────────────────────────── Aktiv ───────────────── nur wenn dieser Schalter gesetzt ist, werden Echo Messages an diesen Link getosst. Der Schalter kann manuell oder vom Link selber per Message/Request an den AREAMGR verändert werden (z.B. weil der Link in Urlaub geht usw.). Oder auch automatisch von BBToss wenn Limit "max. Tage nicht gepollt" (BBTCFG->Setup->Limits) gesetzt ist. Checkpktpwd ───────────────── Von dem Link werden nur die Mail-Packets bearbeitet in denen das korrekte Packet-Passwort enthalten ist. Ist kein Passwort oder ein falsches im Packet ent- halten wird das entsprechende Packet in *.PWD umbe- nannt und nicht bearbeitet. Sayerror ───────────────── Bei Fehlern wird eine entsprechende Fehlermessage gesendet. Ist Tosser Flag "Fehlermeldungen an Link sofort senden" AN werden die Netmails während des tossens erstell, ohne dieses Flag erst bei Aufruf von BBT.EXE SAYERR) versendet. Autocreate ───────────────── Schickt der Link Messeages für ein lokal nicht vor- handenen Areas, wird das Area automatisch in BBToss als passthru angelegt (soll aufgrund einer Msg das Area physisch angelegt werden ist der Link im Up- linkmgr einzutragen). Forwardmgr ───────────────── Bestellt der Link ein nicht vorhandenes Area schreibt BBToss automatisch eine Bestellmessage an den AREAMGR eines im Uplinkmanager eingetragenen Uplinks. PackNetmail ───────────────── Netmails fuer diesen Link werden mit dem eingestelltem Packprogramm zu einem Mailarchiv zusammengepackt (sollte eingestellt werden). Pack hold Netmail ───────────────── Auch Netmails mit Status HOLD werden für diesen Link gepackt. ARCmail auffüllen ───────────────── Ist dieses Flag an, wird für den Link KEIN tägliches ARCmail Archiv erstellt, sondern ein vorhandenes Archiv immer bis zur bei "ARCMail Packetgröße" ange- gebenem Wert aufgefüllt. Dies ist insbesondere für Links, die nicht täglich pollen und bei denen pro Tag nur wenig Traffic zusammenkommt interessant. Da per voreinstellung täglich ein neues Archiv erstellt wird, auch wenn die angegebene Größe noch nicht er- reicht ist. Diese Option mach in erster Linie bei dynamischen Mailern (wie Frontdoor, Intermail) Sinn, da die Anzahl der ARCmail Netmails verringert wird. Bei binkleystyle Mailern bringt es keinen echten Vorteil. Autoconnect ───────────────── Der Link wird automatisch an neue Areas, die von anderen über den Uplinkmanager bestellt wurden angemeldet, wenn der Link zur entsprechenden Gruppe (siehe Uplinkmgr) und sein Level größer oder gleich dem beim Uplink ange- gebenem READLEVEL ist. Notify ───────────────── Links bei denen dieses Flag gesetzt ist, erhalten beim Aufruf von "BBT notify" (ohne weitere Parameter) eine Status-Message zu Ihren Einstellungen Fileattach erlaubt ────────────────── BBToss setzt im Normalfall empfangenen Netmails mit an- hängenden Files auf HOLD (d.h. sie werden nicht auf eigene Kosten versendet, sondern müssen vom Empfänger abgeholt werden). Hat ein Link diese Flag gesetzt werden Netmails mit an- hängenden Files (fileattached Msgs) von diesem Link normal geroutet, was je nach Empfänger und dessen Einstellungen (Uplink/pollendes System) möglicherweise auch auf eigene Kosten übertragen wird. D.h. durch dieses Flag wird bei der Message nicht das Holdflag gesetzt. Mgr: PWD ändern ok ────────────────── Hiermit wird festgelegt, ob der Link das Packetpasswort und Areamgr-Passwort per Areamgr Befehl %PWD und %PKTPWD ändern darf. New Area Info ────────────────── Wurde ein neues Area automatisch angelegt (Autocreate) und konnte dem (autom.) Area ein Uplink zugeordnet werden erhält jeder Link, der diese Flag gesetzt hat eine Info Message, daß ein neues Area verfügbar ist. Der Link muß natürlich der selben Gruppe angehören und sein User- level muß größer oder gleich dem Readlevel des neuen Areas sein. Mit Areamgr Befehl %NEWAREAINFO+ bzw. %NEWAREAINFO- kann der Link dieses Flag selber verändern. Arcmail 0.60 ────────────────── Die Arcmail Packete werden entsprechend dem Standard vergeben. Der Name setzt sich wie folgt zusammen hex(ORIGNET-DESTNET) hex(ORIGNODE-DESTNODE) Bei Point wird anstelle von ORIGNODE-DESTNODE die Pointnummer ver- wendet. Daraus folgt, daß für einen Link immer der gleiche Dateiname ver- wendet wird. Default ist eine abweichende Methode zur Ermittlung des Arcmail Dateinamens, der sicherstellt, daß kein Konflikt mit gleichem Dateinamen für unterschiedliche Links entsteht. Insbesondere bei Frontdoor-Style Mailern ist zu empfehlen diese Flag nicht zu setzen, da hier alle Mailarchive in einem Verzeichnis gespeichert werden und ein häufiger Namenskonflikt zu erwarten ist. Read Only ────────────────── Das Read Only Flag erlaub dem Link fuer alle Areas nur lesenden Zugriff mit Ausnahme wenn dieser Link in einem Area als Uplink angegeben ist. 3.2.1.3 Link Arealiste ─────────────────────────────────────────────────────────────────────── Mit dem AreaList Knopf im Linkeditor wird eine Liste der bestellten Areas des Links angezeit. In der Arealiste können mit der Einfg-Taste (Insert) weitere Areas für den Link manuell angemeldet werden. Nach drücken der Einfg-Taste erscheint eine Liste mit allen vorhandene Areas. Hier sind einfach die Areas zu markieren (mit Leertaste) die für den Link angemeldet werden sollen. Durch drücken der Entf-Taste (Delete) wird der Link von dem Area ge- trennt. Sollen mehrere Areas für diesen Link abgemeldet werden, können diese zuvor mit der Leertaste markiert werden und dann alle markierten Areas mit der Entf-Taste aus der Liste entfernt werden. In beiden Situationen (Area für den Link manuell hinzufügen oder löschen) ist die Area TAG-Funktion aktiv (Taste ALT-T) mit der mehrere Areas anhand verschiedener Daten markiert werden können (z.B. Gruppe usw.). 3.2.3 Vorgaben Link-Daten ─────────────────────────────────────────────────────────────────────── Hier können die Voreinstellungen/Grundeinstellungen, die beim hinzufügen von neuen Links vorgegeben werden eingestellt werden. Die Daten werden in der Datei BBTLNK00.BBT gespeichert. Es wird der übliche Linkeditor verwendet, so daß alle Daten verändert und vorgegeben werden. Jedoch verlangt der Editor die Eingabe einer Absendernodenummer, wobei selbstständig die Main- Aka eingesetzt wird. Diese Nodenummer ist dann beim hinzufügen eines Links selbstverständlich entsprechend zu überschreiben. 3.2.4 Uplink-Manager ─────────────────────────────────────────────────────────────────────── Bestellt ein Downlink ein nicht vorhandenes Area und hat das Uplinkflag gesetzt, wird automatisch eine Bestellmessage an den eigenen Uplink geschickt. Hier werden die für die korrekte Bestellung notwendigen Daten festgelegt. In der Liste mit Taste Einfügen einen neuen Uplink erstellen, oder mit Taste Entfernen einen Uplink löschen oder mit Leertaste eine vorhandenen Uplink Editieren. Im Uplinkeditor müssen folgende Daten angegeben werden Zonenummer Dies ist die Zonenummer der Downlinknodenummern für die bei diesem Uplink Areas bestellt werden Nodenummer Die Nodenummer des Uplinks. Der Uplink selber muß im Linkmanager von BBToss eingetragen sein, aus dem die für die Bestellung notwendigen Daten ermittelt werden (z.B. Passwort) Default-Gruppe Diese Gruppe wird in dem neu erstelltem Area eingetragen, weiterhin muß der anfragende Downlink dieser Gruppe angehören, damit die Bestellung an diesen Uplink raus geht. Dies bietet die Möglichkeit für eine Zonenummer mehrere Uplinks (mit verschiedenen Gruppen) einzurichten, was aber wohl selten vorkommen wird. MgrName Ist der Name des Areamanager Programms des Uplinks. In der Regel wird hir "Areamgr" eingegeben. Manche Tosser reagieren aber auch auf "Areafix" oder einen anderen Namen. Der hier eingetragene Name wird in der Bestellmsg als Empfängername eingetragen. Arealiste <optional> In der hier angegebenen Liste müssen die beim Uplink verfügbaren Areanamen angegeben sein. BBToss sucht vor erstellen der Bestellmessage in dieser Datei. Ist das Area hierin vorhanden, wird die Bestellmessage erstellt. Wird das Area nicht gefunden, wird das Area nicht bestellt. Aufbau der Arealiste: AREANAME AREANAME Beschreibung ... ... Ist eine Beschreibung vorhanden wird diese übernommen. Anmerkung zu Uplinks mit Arealisten: - ist keine Liste angegeben oder fehlt die Datei wird die nimmt BBToss an, das Area sei vorhanden - Gibt es einen Uplink mit mehreren Arealisten, so ist der Uplink bis auf den Listennamen mehrfach einzutragen (oder manuell eine Gesamtliste zu erstellen) - bei mehrfachem Eintrag eines Uplinks ist auf die Reihen- folge zu achten und die Arealiste in der die bestellten Areas wahrscheinlich gefunden werden vor allen weiteren Einträgen zu setzen (bessere Geschwindigkeit) - bei mehrfach eingetragenem Uplink ist bei jedem Eintrag eine Arealiste anzugeben (macht sonst keinen Sinn) - Soll die Reihenfolge der Uplinks geändert werden kann die Datei BBTUPLNK.CFG manuell editiert werden Beispiel: BBTUPLNK.CFG ; BBToss Uplink-Config ; Zone,Uplink-Nodenr,Gruppe,MgrName,Arealistfile ; 2,2:1718/0,F,Areamgr,bb-fido.nat <- nationale Areas 2,2:1718/0,F,areamgr,bb-fido.int <- internationale Areas 7,7:77/777,X,areafix, Hier wurde die nationale Liste vor der internationalen einge- tragen, da Areabestellungen wahrscheinlich in der nationalen Liste eher gefunden werden. Für die Zone 7 wurde keine Liste angegeben, d.h. hier wird ohne Überprüfung jede Bestellung von berechtigten Links (siehe Linkflags) weitergeleitet. ReadLevel Vorgabe des ReadLevel für die Areas, die bei diesem Uplink bestellt werden. Gleichzeitig muß der bestellende Link einen mindestens gleichgrossen Level haben um Areas über diesen Uplink bestellen zu können. Bei Links mit "AutoConnect" Flag wird ebenfalls überprüft, ob mindestens lesender Zugriff zulässig ist. WriteLevel Vorgabe des WriteLevel der Areas, die per Uplinkmanager über diesen Uplink bestellt werden. Der Schalter "Wer Liste" zeigt eine Liste der Links an, die bei diesem Uplink Areas bestellen können. D.h. die das Flag "Ulinkmgr ok" gesetzt haben, deren Zonenummer, Gruppe und Level mit den Einstellungen des Uplinks übereinstimmen und deren Areamgr Bestellungen autom. zu diesem Uplink weitergeleitet werden. Diese Liste ist rein informativ und gibt einen Überblick ob Link und Uplink Einstellungen wie gewünscht zusammen passen. 3.3 AreaDaten Menü ─────────────────────────────────────────────────────────────────────── In diesem Menü sind alle Einstellungen zusammengefaßt, die Einstellungen der Areas betreffen. Es erscheint eine Liste aller in BBToss eingerichteten Areas. Durch betätigen der Schalter am unteren Rand kann die Liste am Bildschirm nach verschiedenen Kritereien sortiert dargestellt werden (Schalter mit Maus anklicken oder ALT-Taste + hervorge- hobenen Buchstaben). Mit der RETURN-Taste kann man das Area, auf dem der Laufbalken steht, editieren. Sowie per Maus-Doppelklick. Mit der EINFÜGEN-Taste wird ein neues Area hinzugefügt, mit der ENTFERNE-Taste gelöscht. Wird ein Area hinzugefügt, wird nach dem eingeben der Daten nachge- fragt ob alle Links der Gruppe an das Area angeschlossen werden sollen. Wird dies mit YES beantwortet, werden alle Links, die zu der Gruppe des Areas gehören und deren Readlevel ausreichend ist an das Area angeklemmt. Wird ein Area gelöscht an dem noch Links angemeldet sind, wird nach- gefragt ob diese Über das Löschen informiert werden sollen. Wird diese Frage mit YES beantwortet wird ein kurze Infomsg an den Link gesendet (wenn Flag "Errormsg senden" AN ist) und auf jeden Fall eine Msg an den Areamgr des Links, der das Area abmeldet. 3.3.1 Area-Manager Extramenü ─────────────────────────────────────────────────────────────────────── Das Extramenü erreicht man mit der F10 Taste in der Arealiste 3.3.1.1 Hinzufügen/Anklemmen eines Links ─────────────────────────────────────────────────────────────────────── Es erscheint eine Link Liste. Mit dem OK-Button wird der gerade markierte Link an das Area angeklemmt. Durch markieren (taggen per Leertase oder Maus) von mehreren Links, werden die markierten Links an das Area angeklemmt. Alternativ dazu kann im Areaeditor einfach die Nodenummer in der Link- liste eingetragen werden. 3.3.1.2 Re-Nummerieren der Areas ─────────────────────────────────────────────────────────────────────── Die Areas werden pro Gruppe, beginnen beim Startarea (Setup->Gruppen) alphabetisch aufsteigend sortiert, fortlaufend nummeriert. Es werden keine Hudson und Ezycom Areas umnummeriert (behalten ihre alte Nummber bei); Es werden nur Areas renumbert, denen bereits eine Areanummer zu- gewiesen wurde. 3.3.2 Area-Editor ─────────────────────────────────────────────────────────────────────── Mögliche Eingaben oder Bedeutung der Felder: Areanummer Nummer des Areas in der Mailboxkonfiguration. ---------- Mögliche Werte 1 - 65535. Areas mit Nummer 0 werden nicht in die Mailbox übernommen. (Bei BaseTyp Hudson muß eine Nummer zwischen 1-200 angegeben werden). MsgBase-Pfad Das Verzeichnis, bzw. der Dateiname des Areas. ------------ Bei Hudson wird hier nichts angegeben. Bei JAM und Squish der Dateiname des Areas ohne Extension. Bei Fido-Msg Areas das Verzeichnis. Bei Ezycom das Basisverzeichnis der Messagebase. Passthrough benötigt grundsätzlich keinen Pfad, ist dennoch einer eingetragen, wird er ignoriert. Message-BaseTyp E = Ezycom --------------- H = Hudson J = JAM L = HTML (output only) N = Fido *.MSG S = Squish P = Passthrough Area-Typ E = Echoarea Area welches an Links gesendet wird -------- L = lokales Area Area welches nur lokal vorhanden ist N = Netmail-Area Area aus dem Netmail gelesen werden B = Badmail-Area hier landen die Badmails D = Dupemail-Area hier landen die Dupes Schreiblevel Diesen Level muß der Link mindestens haben ------------ um in deses Area schreiben zu können, bzw. damit seine Messages verteilt werden. Schickt ein nicht berechtigter Link dennoch Messages werden sie als BadMsg behandelt. Leselevel Nur Links, deren Level größer oder gleich dem hier --------- angebenen ReadLevel ist, können diese Area per AREAMGR Request bestellen. Wird der Link manuell in das Area eingetragen, werden die Msgs auch an ihn gesendet. Dies bietet die Möglichkeit innerhalb einer Gruppe zusätzliche Berechtigungen du erteilen. Häufig werden die Bestellmöglichkeit für Points, Nodes, Hubs und Hosts nicht per Gruppe, sonder per Level gehandhabt. max. Anzahl Msgs Maximale Anzahl der Messages in diesem Area. Wird ---------------- diese Anzahl überschritten werden durch Aufruf von BBTClean Messages gelöscht. 0 schaltet diese Funktion ab. max. Anzahl Msgs Übersteigt die Anzahl der Messages in diesem Area den ---------------- bei "max. Anzahl Messages" eingegebenen Wert, werden durch Aufruf von BBTClean soviele Messages glöscht, bis die hier eingetragene Anzahl erreicht ist. Da BBTClean sehr gründlich arbeitet und das gesamte Area neu schreibt, kann durch diesen eintrag die Bearbeitungsdauer beeinflusst werden damit nicht wegen 1 oder 2 Messages das Area aufgeräumt wird. Beispiel: Max Msgs = 200, Min Msgs = 150 BBTClean bearbeitet das Area, wenn z.B. 201 Msgs vorhanden sind und löscht 51 Msgs, so daß danach noch 150 Msgs vorhanden sind. Da Area wird dann erst wieder bearbeitet, wenn wieder mehr als 200 Msgs vorhanden sind. max. Messagealter Maximales Alter der Messages in Tagen. Jede Message ----------------- die älter als die hier angebebene Anzahl von Tagen ist wird beim Aufruf von BBTClean gelöscht. Dies ist bei der Bearbeitung durch BBTClean etwas zeitaufwendiger, als das reine löschen nach Msg- anzahl. Wird zusätzlich bei MaxMsgs ein Wert einge- tragen werden dennoch alle Messages gelöscht die älter als hier angegeben sind (auch wenn dadurch die Anzahl von max. bzw. min Messages unterschritten wird). eigene Aka Diese Aka wird in die SEEN-BY und PATH Zeile der Msg ----------- eingefügt. Jedem Echo-Area sollte eine eigene Nodenummer zuge- ordnet werden. Beim Dupe-Check anhand dieser Aka er- kannt, ob die Msg auf deinem System bereits bearbeitet wurde, also ein Dupe ist. Weiterhin wird diese Aka dazu benutzt (bei gesetztem Flag Check-Area-Aka) festzustellen ob die Absender- nodenummer einer Message in das Echoarea paßt. Dazu werden die Zonenummern der Absendernodenummer der Msg und der hier eingetragenen Area-Aka verglichen. Sind die Zonenummern ungleich, wird die Message nicht getosst und der Absender erhält eine Netmail mit einer Fehlermeldung (Die Message wird an die Absenderadresse der Message adressiert, wenn man dem Netz nicht angehört, kann die Netmail mit der Fehlermeldung nicht geroutet werden). Uplink Dies ist die Nodenummer des Links von dem das Area ------ bezogen wird. Der Uplink muss in der Linkliste eingetragen sein. Der Eintrag hier legt fest welcher der an das Area angeschlossenen Links der Uplink ist. RuleFile Name einer Textdatei die die Regeln/Gesetze (Rules) -------- des Areas enthält. Dieser Text wird beim Anmelden des Areas von einem Link als Startmessage des Areas an den Besteller gesendet. Ist hier kein vollständiger Dateiname (Pfad+Name) angegeben, wird im aktuellen Verzeichnis gesucht und danach im Defaultverzeichnis der Rules für die Gruppe (siehe Gruppen-Einstellungen). 3.3.2.1 loesche SeenBy ─────────────────────────────────────────────────────────────────────── löscht die SEEN-BY Zeilen der exportierten Messages und erstellt diese nur mit den eigenen Downlinks neu 3.3.2.2 loesche Path ─────────────────────────────────────────────────────────────────────── löscht die Pathzeile in den exportierten Messages und erstellt eine neue verkuerzte PATH Zeile. 3.3.2.3 Reset Scan Aka ─────────────────────────────────────────────────────────────────────── Beim scannen und exportieren von Echomails wird falls nicht bereits durch den Editor gesetzt die Aka aus dem BBToss Areasetup als Absender Aka gesetzt und die MsgId falls notwendig entsprechend angepaßt. Bei Netmail Areas hat dieser Schalter keine Wirkung. Dadurch ist sichergestellt, daß alle exportierten Messages die zum Area passenden Absender Adressen enthalten. 3.3.2.4 prüfe Msg-Aka ─────────────────────────────────────────────────────────────────────── Prüft die Absender-Aka des Absenders ob diese zu der für diese Area eingetragenen Zone paßt (= eigene Aka). Sind die Zonenummern ungleich wird eine Fehlermessage erstellt. 3.3.2.5 passiv ─────────────────────────────────────────────────────────────────────── Das Area ist passiv, d.h. es kann nicht angemeldet werden, erscheint nicht in den Listen und es werden keine Messages exportiert (auch nicht wenn korrekte Msg's empfangen werden). 3.3.2.6 import SeenBy ─────────────────────────────────────────────────────────────────────── Importiert die SEEN-BY Zeilen der Message in die Messagebase 3.3.2.7 import Path ─────────────────────────────────────────────────────────────────────── Importiert die Pathzeile der Message in die Messagebase 3.3.2.8 nicht in BBS export ─────────────────────────────────────────────────────────────────────── Das Area wird NICHT in die Configuration der Mailbox exportiert, selbst wenn alle anderen Daten dieses ermöglichen würden (Areanr. usw.). 3.3.2.9 Pflichtarea ─────────────────────────────────────────────────────────────────────── Area kann vom Link nicht per Msg an den Areamgr abbestellt werden. Es handelt sich also um ein Pflichtarea, welches nach dem anmelden oder aufschalten nur manuell im Setup oder durch löschen der Area abgemeldet werden kann. 3.3.2.10 Read Only Area ─────────────────────────────────────────────────────────────────────── Fuer dieses Area ist (mit Ausnahme des Uplinks) fuer alle Links nur lesender Zugriff gestattet. D.h. Links koennen/duerfen in diesem Area keine Messages senden. Wird dennoch eine Message empfangen, wird diese als Badmail behandelt und nicht weiter verteilt. Dieses Flag wirkt auch wenn der Schreiblevel des Links gross genug waere um eine Msg in das Area zu stellen. Ist kein Uplink eingetragen werden nur lokale Messages an die Links weitergeleitet. 3.3.3 Routing ─────────────────────────────────────────────────────────────────────── Routing nennt man den Weg, den NETMAILS vom Absender zum Empfänger nehmen. Dafür muß auf jedem System korrekt angegeben werden, wohin die Netmails für die verschiedenen Empfängeradressen gesendet werden sollen/müssen. BBToss bietet die Möglichkeit Netmails an den Empfänger zu packen. BBToss arbeitet ohne weitere Angaben mit dem eingebauten Standard- routing. Das unterstütz Point, Direkt-Node und Host-Routing. Damit BBToss die Netmail auch bei anderen Routingwegen an die korrekte Routeadresse packt ist in der Configdatei BBTROUTE.CFG eine entsprechende Routezeile einzugeben. Der Aufbau einer Routezeile in der Datei BBTROUTE.CFG sieht folgender maßen aus: 2:123/8765.0 2:123/8765 2:123/* 2:* ------------ ---------------------- an diesen Node Msg's die an eine dieser wird die Msg Nodenummer gerichtet sind geschickt werden gepackt Ersatzzeichen sind * und ?, wobei * für 0 - 65534 steht und ? genau für eine Zahl 0 - 9. z.B. 2:* meint alle Nodes in Zone 2 2:247/* meint alle Nodes im Netz 247 in Zone 2 2:248/50 meint Node 50 im Netz 248 in Zone 2 incl. seiner Points 2:248/5? meint Node 50 bis 59 im Netz 248 in Zone 2 !!! 2:248/5* ist unzulässig 2:249/5?? meint Nodes 500 bis 599 im Netz 249 in Zone 2 !!! 2:250/?00 meint Node 0 bis node 900 !!! 2:250/1?0 meint Node 100 bis 190 Es ist ebenfalls möglich, das Ersatzzeichen ? in der Netznummer zu verwenden, z.B. 2:24??/* Die Angaben in BBTROUTE.CFG werden von oben nach unten abgearbeitet, nach der 1. Übereinstimmung wird nicht nach weiteren Übereinstimmung gesucht. Also 2:246/1000 2:246/* 2:200/0 2:* sendet alle Netmails mit Empfänger im Netz 246 and 2:246/1000, alle anderen Netmails mit Empfänger in Zone 2 and 2:200/0 !!! und so macht mans verkehrt !!! Aber 2:200/0 2:* 2:246/1000 2:246/* hier werden alle Netmails mit Empfänger in Zone 2 and 2:200/0 ge- sendet, die 2. Zeile wird erst garnicht mehr bearbeitet, da ja bereits alle Netmails mit Zone 2 gepackt sind. BBToss enthält ein voreingestelltes Routing, d.h. wenn nichts anderes in der BBTROUTE.CFG steht, - werden Netmails, die an direkte Up/Down-Links gerichtet sind auch direkt an dies gepackt (incl. für deren Points). - Hat man einen HOST (zone:net/0) als Link, werden Netmails für Nodes im gleichen Net (die nicht bei dir direkt Downlinks sind) an den Host gepackt. - Netmails an Points werden mit in das Packet des Boss-Node gepackt - Netmails an eigene Points werden direkt an diese gepackt BBToss bearbeitet - keine Mails mit "crash" Status - keine Mails mit File "attached" Status - keine Mails, die nicht entweder "local" oder "forward" Status haben - keine Mails mit "received" Status (außer gleichzeitig "forward") - keine Mails die "sent" Status haben (außer ggf. löschen) - Mails mit HOLD Status nur wenn Flag "pack HOLD Netmail" im Linkeditor gesetzt ist. Andersherum gesagt, es werden nur Netmails gepackt, die "local" oder "forward" Status haben. Beim tossen setzt BBToss nur bei den Netmails selber den "forward" Status wenn für den Empfänger ein internes oder explizites Routing bekannt ist. 3.3.4 Globales Area Edit ─────────────────────────────────────────────────────────────────────── Hier kann auf einmal eine ganze Gruppe von Areas verändert werden. In der ersten Zeile wird angegeben welche Areagruppen die Änderungen gelten soll. Wird z.B. ACX eingegenben, so werden alle Areas die zu den Gruppen A , C und X gehören geändert (beachte BBToss unter- scheidet bei den Gruppenkennzeichen zwischen Groß- und Kleinschreibung). Sollen die Flag der Areas verändert werden, so ist zusätzlich in das dafür vorgesehene Feld ein X einzutragen, als Sicherheitsabfrage, da die hier gesetzten Flags die in den betroffenen Areas vorhandenen überschreiben (d.h. die betroffenen Areas haben genau die Flags gesetzt / nicht gesetzt wie hier angegeben. Im Feld "Link hinzufügen" kann eine Link an alle Areas der angegebenen Gruppen angeklemmt werden. "Link entfernen" disconnected den angegebenen Link von allen Areas der betroffenen Gruppen. Das Feld Uplink setzt die Uplinknodenummer für die Areas der aus- gewählten Gruppe. Beachte dass die Uplinknodenummer ein in BBToss vorhandener Link sein muss. Das eintragen der Uplinknodenummer im Area ersetzt NICHT die Einstellungen im ->Uplinkmanager. 3.3.5 Traffic 0 Areas abmelden [+] ─────────────────────────────────────────────────────────────────────── Es werden die Echoareas herausgesucht, in denen seit erstellen oder seit dem letzten EchoStatistik-Reset keine Messages verarbeitet wurden. Diese Areas werden auf Nachfrage gelöscht und bei den noch angeklemmten Links per Areamgr Message abgemeldet, sowie eine kurze Info gesendet. Ist das Flag "Fehlermsgs senden" des Links AUS, wird nur die Areamgr- Msg gesendet (keine Infomsg). Die Messages werden nicht sofort erstellt, sondern durch Aufruf von BBT SAYERR. Bei der Suche werden nur Areas berücksichtigt, die seit mehr als 2 Tagen aktiv sind (also seit mindestens 2 Tagen keine Nachrichten verarbeitet wurden. 3.3.6 Link 0 Areas löschen [+] ─────────────────────────────────────────────────────────────────────── Es werden die Echoareas herausgesucht, die keinen oder nur einen Link haben. Diese werden dann auf Nachfrage gelöscht und (falls vorhanden) beim Link per Areamgr Message abgemeldet sowie eine kurze Info geschickt (letzteres nur wenn Flag "Fehlermsgs senden" für den Link eingeschaltet ist. Die Nachrichten werden nicht sofort erstellt, sondern durch Aufruf von BBT SAYERR. 3.3.7 Reset Areastatistik ─────────────────────────────────────────────────────────────────────── Rücksetzen der Areastatistik auf das heutige Datum und zu Null setzen aller Zähler. Damit wird beim Export der Areastatistik die Anzahl und durchschnitt- lichen Messages pro Tag vom heutigen Datum an gerechnet. Es werden nur solche Areas zurückgesetzt, in denen seit erstellen des Areas bzw. seit dem letzten Statistik-Reset Messages verarbeitet wurden. Dies soll verhindern, das Areas in denen niemals eine Messages verarbeitet wurde vom "Traffic 0 Areas" Befehl nicht erkannt werden. 3.3.8 Relink Areas ─────────────────────────────────────────────────────────────────────── Relinkt alle aktiven Echo-Areas bei den Links. BBTCFG erstellt AREAMGR Bestell Messages fuer die Link um sicherzustellen, dass alle angemeldeten Areas bestellt sind. Es wird abgefragt ob AREAMGR Messages an alle Links, die Areas angemeldet haben gesendet werden sollen (Diese Funktion ist identisch mit dem BBToss Befehl RELINK) oder nur an die Uplinks der Areas. Wird nur an Uplinks gewählt, muss die Uplink Nodenummer im Area- setup eingetragen sein, damit das Area in die Bestell-Msg aufge- nommen wird. 3.4 Export Menü ─────────────────────────────────────────────────────────────────────── 3.4.1 AutoExport ─────────────────────────────────────────────────────────────────────── Wird beim Tossen ein Area neu angelegt oder veraendert kann hier angegeben werden dass eine aktualisierte AREAS.BBS, TimEd Cfg, GoldEd Cfg oder Squish Cfg automatisch exportiert wird. Dazu die entsprechende Zeile markieren und vollen Pfad plus Name der zu exportierenden Cfg Datei angeben. z.B. [X] Auto export Areas.BBS c:\mailbox\areas.bbs 3.4.2 Export AREAS.BBS ─────────────────────────────────────────────────────────────────────── Erstellt eine Areas.BBS datei mit allen Areas. Die AREAS.BBS wird von z.B. von einigen Msg-Editoren verwendet um die vorhandenen Areas zu ermitteln. Die Areas.BBS kann nach verschiedenen Kriterien sortiert erstellt werden. 3.4.3 Export Bestell-List ─────────────────────────────────────────────────────────────────────── Erstellt eine Liste aller von diesem Node bestellten Areas. Die kann zum einen zur Übersicht dienen, zum anderen ist es eine nützliche Hilfe um alle Areas bei seinem eigenen Uplink zu bestellen. Z.B. wenn dieser sich eine neuen Nodenummer zugelegt hat, aber die Areaconfiguration nicht übernommen hat, oder einfach um zwischendurch mal sicher zu stellen, das alle Areas auch noch angemeldet sind. 3.4.4 Export Areas to Mailbox ─────────────────────────────────────────────────────────────────────── Abhängig von dem aktuell eingestelltem Mailboxprogramm werden die Areaeinstellung in die Mailboxkonfiguration exportiert. Es werden nur Areas exportiert, die - eine AreaNummer größer 0, d.h. es MUSS eine AreaNummer eingetragen sein (auch für JAM oder Squish) - nicht das Flag "nicht in Mailbox exportieren" gesetzt haben. BBT richtet sich beim Export rein nach der Areanummer, diese muß also auch bei Areas gesetzt sein, die aus BBT Sicht nicht zwingend ein benötigen (JAM, Squisch, *.MSG Areas). Hudson Areanummern müssen grundsätzlich zwischen 1 - 200 liegen. BBTCFG schreibt nur die aus BBTSetup bekannten Daten in die Area Config der Mailbox, der Rest der Einstellungen bleibt unver- ändert. Das bedeutet, das Read-, WriteLevel, die Flags und Gruppen per Mailox-Config gesetzt werden müssen. BBTCFG überschreibt diese Einstellungen auch bei erneutem Export nicht. Auch bereits in der Box installierte Messageareas werden nur dann über- schrieben, wenn auf dieser Areanummer von BBTCFG ein Area installiert wird. Es ist somit möglich lokale Areas in der Box zu installieren ohne sie in BBToss übernehmen zu müssen. BBTCFG prüft vor überschreiben oder neu einrichten eins Area in der Box ob ein Area gleichen Namens bereits existiert. Ist dies der Fall übernimmt BBTCFG die Daten (Gruppe, Level, Flags usw.) des gefundenen Areas und schreibt es an die neue Position. Das 2. Area mit gleichem Namen wird gelöscht. Dies ist insbesondere vorteilhaft, wenn einem Area in BBTCFG eine neue Areanummer zugeordnet wird. Das Resultat ist dann, das alle Einstellungen erhalten bleiben, das Area also quasi nur verschoben wird. Ist in den Areaeinstellungen der Schalter "nicht in BBS exportieren" gesetzt, wird an dieser Stelle ein Leerrecord von BBTCFG in die Box-Configuration geschrieben, also der entsprechende Areaeintrag auf jeden Fall gelöscht. Ist der Schreib-Userlevel 0 wird er von BBToss auf 32000 gesetzt. Dies soll verhindern, das neue Areas mit Schreiblevel 0 eingerichtet werden. Gleiches gilt für den Sysoplevel. Das exportieren wird nicht automatisch ausgeführt. Sondern man ist selber dafür verantwortlich BBTCFG.EXE dazu aufzurufen. Vor dem Export der Areas erstell BBTCFG eine Kopie der vorhanden Areakonfig-Datei der Mailbox (*.BAK im Mailboxverzeichnis). Tritt während des Exports ein Fehler (I/O-Error) wird diese Kopie (*.BAK) automatisch zurückgespeichert. 3.4.4.1 Export nach Remote Access ─────────────────────────────────────────────────────────────────────── Nach RA werden ausschließliche JAM und Hudson Areas exportiert, da RA keine anderen Messagebaseformate unterstützt. Ist in BBToss eine Areabeschreibung vorhanden, wird diese als Area- name für RA verwendet (ansonsten der Areaname aus BBToss) 3.4.4.2 Export nach Proboard ─────────────────────────────────────────────────────────────────────── Nach Proboard werden ausschließlich Hudson, JAM, Squish und Fido-Msg Areas exportiert 3.4.4.3 Export nach Ezycom ─────────────────────────────────────────────────────────────────────── Nach Ezycom werden ausschließlich Ezycom und Passthru Areas exportiert. Als EchoTag und QWKName wird der BBToss-Areaname verwendet. Der Ezycom Name wird aus der BBToss Areabeschreibung exportiert (wenn vorhanden). BBToss Passthru Areas werden als Passthru exportiert. Ausnahme sind davon sind BBToss Passthru Areas vom Typ "*", die als Waitthru nach Ezycom exportiert werden. Ezycom kennt weiterhin Lokalmail und Allmail Areas. BBToss überschreibt beim Export von BBToss-Lokalareas (Basetyp=L) die vorhandene Einstellung nur, wenn noch nicht eine der beiden Ezycom-Typen konfiguriert ist. In dem Fall exportiert BBToss das Area als Lokalmail-Area. 3.4.4.3 Export nach Maximus ─────────────────────────────────────────────────────────────────────── Nach Maximus werden Squish und Fido-Style-Msgareas exportiert. Da Maximus eine Config-Datei orientierte Mailboxsoftware ist, wurde darauf verzichtet die MAREA.DAT Datei direkt zu manipulieren, da dadurch die exportierten Daten bei jedem Aufruf von SILT.EXE wieder überschrieben würden. Daher erstellt BBToss eine separate Area-Controldatei mit Namen BBTMAREA.CTL im Maximus-Verzeichnis, diese kann in die Box-Config eingebunden werden. Als Areaname wird die Areanummer verwendet. Es ist somit auch für den Maximus-Export dem zu exportierenden Areas ein Nummer zuzu- ordnen. Da z.Zt die ACS Namen (also die Userlevel) nicht aus Maximus ausge- lesen werden, fügt BBToss eine Zeile wie z.B. Acs BBTLevel10 ein. Dabei die die angegebene Zahl der jeweilige Read-Level des Areas. Entweder muß ein entsprechender Userstatus angelegt werden, oder es wird mit einem Editor einfach durch einen anderen Ersetzt. 3.4.5 Export TimeED Area-Config ─────────────────────────────────────────────────────────────────────── Erstellt eine Configdatei für TimeED die an die TimeEd.cfg ange- fügt werden kann um alle Areas mit Namen, Beschreibung und Akamatching im TimED zu konfigurieren. 3.4.6 Export Password-Liste ─────────────────────────────────────────────────────────────────────── Erstellt eine Textdatei mit den Nodenummern und dazugehörigen Pass- wörtern. Eine solche Passwortliste wird von verschiedenen Mailern Mailern und Nodelist-Tools verwendet. Das Format ist frei wählbar, dazu wird eine Ausgabemusterzeile angezeigt, die dem gewünschten Format angepaßt werden kann. In der Musterzeile wird %AKA und %PWD durch die jeweils aktuellen daten der Links ersetzt. Beispiel: PASSWORD %AKA %PWD Erstellt eine Datei mit jeweils einer Zeile pro Link, z.B. wie folgt: PASSWORD 2:244/1720 ABCPWD PASSWORD 17:88/1701 XYZPWD 3.4.7 Export Rulefile Liste ─────────────────────────────────────────────────────────────────────── Exportiert eine Liste mit den bei den Areas eingetragenen Rulefile- namen. Die Liste kann wahlweise mit Areabeschreibungen erstellt werden. ECHOTAG RULEFILE <Beschreibung> 3.5 Import Menü ─────────────────────────────────────────────────────────────────────── Hier können Area und Linkdaten aus verschiedenen anderen Configurationen übernommen werden. Zu beachten ist dabei, das vorhandene Daten dabei überschrieben werden und neue hinzugefügt werden. 3.5.1 Import AREAS.BBS ─────────────────────────────────────────────────────────────────────── Es wird eine AREAS.BBS Datei mit Angabe der Downlinks erwartet, also z.B. 10 TEST.ECHO 2:2471/0 2400 usw.... für ein Hudsonarea Ist das Area vorhanden, werden die Downlinks durch die in der AREAS.BBS ersetzt. Stehen in der Areas.BBS keine Downlinks, werden ggf. vorhandene von dem Areas abgeklemmt. Aus einer Areas.BBS können Hudson, JAM, Squish und Passthru Areas importiert werden. 3.5.2 Import SQUISH.CFG ─────────────────────────────────────────────────────────────────────── Es wird eine Squish.cfg Datei mit Angabe der Downlinks erwartet, also z.B. Echoarea TEST.ECHO c:\areas\test -$ -p2:2471/0 2400 usw.... für ein Squish-Format Area. Ist das Area vorhanden, werden die Downlinks durch die in der Squish.cfg ersetzt. Stehen in der Squish.cfg keine Downlinks, werden ggf. vorhandene von dem Areas abgeklemmt. Aus einer Squish.cfg können *.MSG und Squish Areas importiert als Echoarea oder Netmailareas importiert werden. BBToss berücksichtigt z.Zt. keine INCLUDE .... Anweisungen. Also Keyworte werden Echoarea für Echos und Netmailarea für Netareas erwartet. 3.5.3 Import Ezycom Areanummern ─────────────────────────────────────────────────────────────────────── Die Areanummern werden aus Ezycom neu importiert. Die kann notwendig sein, wenn die Reihenfolge der Areas in Ezycom verändert wurde, z.B. durch EZYUTIL -sortmess. Danach würde die Installation von Ezycom und BBToss sich unterscheiden und die Messages im falschen Area landen. Hiermit werden die Areanummern wieder abgeglichen. Es werden nur die Areanummern von bereits (in BBToss) vorhandenen Areas übernommen also keine neuen Areas in BBToss angelegt oder gelöscht. 3.5.4 Import Areabeschreibungen ─────────────────────────────────────────────────────────────────────── Importiert Areabeschreibungen aus einer Arealist-Datei. Die Arealistdatei muß eine Textdatei sein, wie sie von vielen Netzen verteilt wird, in der pro Zeile ein Area mit Beschreibung aufgeführt ist, die grundsätzlich wie folgt aufgebaut ist: ECHOTAG Description ... ... z.B. BALLADE.GER Ein Area fuer Texten und Diskussionen zu Balladen NET.SYS.DOS Systembeschreibung von Dosnetzwerken Der Importbefehl überschreibt ggf. vorhandene Beschreibungen mit den in der Datei gefundenen. Wollen Sie Ihren Downlinks ebenfalls eine solche Liste der bei Ihnen vorhandenen Areas mit Ihren Beschreibungen zur Verfügungstellen, können Sie unter dem Menüpunkt "Export"->"AreaListe/Beschreibung" eine entsprechende Liste erstellen (wahlweise mit oder ohne Be- schreibungen). 3.5.5 Import Rulefile-Namen ─────────────────────────────────────────────────────────────────────── Importiert aus einer Liste, die als Textfile vorliegen muß die Area- Rulefile Namen. Die Liste muß folgendermaßen aufgebaut sein ECHOTAG RULEFILE .... .... oder RULEFILE ECHOTAG .... .... Entsprechende Listen werden in den Netzen häufig verteilt (z.B. Fido Z2_TAG.*). Für den Import wird abgefragt, für welche Areagruppe Rulefilenamen importiert werden soll, der Name der Listdatei und das Verzeichnis in dem die Rulefiles vorhanden sind sowie in welchem Format die Rulelistdatei vorliegt (YES= zuerst ECHOTAG oder NO= zuerst RULEFILE). BBToss importiert den Ruledateinamen nur, wenn die Ruledatei vor- handen ist. Bereits bestehende Einträge werden überschrieben. 3.6 BBTCFG Aufrufparameter ─────────────────────────────────────────────────────────────────────── Das Setupprogramm (BBTCFG.EXE) kann mit verschiedenen Parametern aufgerufen werden. Dies bewirkt, das die entsprechende Funktion direkt ausgeführt wird, ohne das der jeweilige Menüpunkt manuell aktiviert werden muss. Allgemeine Form der Aufrufe BBTCFG.EXE Befehl /parameter:wert Die Befehle/Aufrufparameter im einzelnen: STAT /GROUP:<gruppen> /FILE:<Dateiname> ─────────────────────────────────────────────────────────────────────── Area-Statistik für angegebene Gruppen in Textdatei <Dateiname> aus- geben Soll die Statistik für alle Gruppen ausgegeben werden ist als Gruppe /GROUP:* anzugeben. Die Ausgabedatei kann ein beliebieger Dateiname mit Pfad sein, es wird kein Standardverzeichnis vorgegeben. Beispiele: BBTCFG STAT /GROUP:Ff /FILE:c:\text\fidostat.txt BBTCFG STAT /GROUP:* /FILE:c:\bbt\echostat.txt LINKSTAT /GROUP:<gruppen> /FILE:<Dateiname> ─────────────────────────────────────────────────────────────────────── Link-Echomail-Statistik für angegebene Gruppe in Textdatei <Dateiname> ausgeben Soll die Statistik für die Links aller Gruppen ausgegeben werden ist als Gruppe /GROUP:* anzugeben. Die Ausgabedatei kann ein beliebieger Dateiname mit Pfad sein, es wird kein Standardverzeichnis vorgegeben. Beispiele: BBTCFG LINKSTAT /GROUP:F /FILE:c:\text\fidolink.txt BBTCFG LINKSTAT /GROUP:* /FILE:c:\bbt\linkstat.txt RESETSTAT ─────────────────────────────────────────────────────────────────────── Rücksetzen der Areastatistik und der Linkstatistik. Alle Messagezähler werden auf 0 gesetzt und das Statistikdatum der Areas auf das aktuelle Datum gesetzt. Bei Areas in denen keine Message seit Area-Erstellung oder letztem RESETSTAT verarbeitet wurden, wird das Datum nicht verändert. Beispiel: BBTCFG RESETSTAT COMPILE ─────────────────────────────────────────────────────────────────────── BBTCFG prüft ob eine der ASCII-Configdateien (*.CFG *.INI) verändert wurde und compiliert (übersetzt) diese in eine *.BBT Datei. Beispiel: BBTCFG COMPILE Diese Prüfung wird automatisch bei jedem Start von BBT.EXE durchge- führt, so daß sich ein explizites compilieren in aller Regel er- übrigt. MAILBOX ─────────────────────────────────────────────────────────────────────── Exportiert die Areadaten in die Mailboxcfg 3.6.1 Environment Variable ─────────────────────────────────────────────────────────────────────── BBToss erwartet alle seine Config- und INI-Dateien in dem Verzeichnis, in dem BBT.EXE und BBTCFG.EXE liegen, also aus dem Verzeichnis aus dem BBToss aufgerufen wird. Wer die *.EXE und Configdateien in getrennten Verzeichnissen haben möchte kann die Environment Variable BBTOSS in der Autoexec.bat oder der Mailerbatch setzen. SET BBTOSS=<Pfad zu den BBToss Configdateien> z.B. c:\BBT\BIN für die *.EXE Dateien (bbt.exe bbtcfg.exe usw.) c:\BBT\CFG für die *.CFG *.INI *.BBT Dateien mit SET BBTOSS=C:\BBT\CFG angeben BBToss erwartet dann alle Konfigurationsdateien in dem mit dem SET Befehl angegebenen Verzeichnis. 4. Die Befehle und ihre Wirkung ─────────────────────────────────────────────────────────────────────── 4.1 Der TOSS Befehl ─────────────────────────────────────────────────────────────────────── Ablauf des Toss-Befehls: BBToss schaut zunächst im INBOUND nach ARCMail Archiven und entpackt diese (wenn konfiguriert in das TMPINBOUND, ansonsten in das Verzeichnis in dem das Archiv liegt). Wenn kein Fehler beim entpacken auftritt, wird das ARCMail-Archiv gelöscht. Wenn vorhanden werden nun ARCMail Archive im lokalem Inbound ent- packt. Danach sucht BBToss in folgenden Verzeichnissen nach *.PKT Files LOCALINBOUND INBOUND TMPINBOUND UNSECINBOUND Werden *.PKT Files gefunden, so werden diese getosst. Dabei werden *.PKT-Daten (wie Passwort oder Absendernodenummer) im LOCALINBOUND nicht überprüft. Das LOCALINBOUND spielt somit eine Sonderrolle und wird in der Regel dazu verwendet Packets von anderen Utility- Programmen zu verarbeiten (z.B. Filetosser, Postutilities usw.) Im INBOUND und TMPINBOUND werden die *.PKT-Daten entsprechend den Einstellungen für Links und Areas geprüft. Aus Packets (*.PKT Files) im UNSECINBOUND werden ausschliesslich Netmails getosst. Enthält ein Packet Echoareas, wird das Packet umbenannt. Jedoch werden die Netmails nur wenn sie an direkte Downlinks gerichtet sind auf "forward" gesetzt, d.h. sie werden auf keinen Fall über ein weiteres System geroutet (soll so eine Netmail trotzdem von BBToss gepackt werden ist das "forward"-Flag manuell zu setzten). Dies dient der Sicherheit, da ja jedes beliebige System Netmails übertragen kann und hiermit sichergestellt ist, das nur für oder von berechtigten Systemen (Stichwort: mit Passwort/ INBOUND) Nachrichten zu Lasten des eigenen Systems ungeprüft übermittelt werden. BBToss beinhaltet bei Packets im UNSECINBOUND einen weiteren Sicherheitsmechanismus. Wie oben erwähnt werden ausschliesslich Netmails aus diesen *.PKT's verarbeitet. Jedoch stellt BBToss nach 25 Netmails in einem (unsecure) Packet den Tossvorgang ein und benennt das Packet um. Die während des tossens erstellten *.PKT Files an die Downlinks werden im OUTBOUND gespeichert. Wurde ein TMPOUTBOUND im Setup angegeben, werden die *.PKT Files im TMPOUTBOUND ge- speichert (also nicht im OUTBOUND). Nach dem tossen der gefundenen eingegangen Packets werden alle *.PKT Files im OUTBOUND und TMPOUTBOUND zu einem ARCMail Archiv für die Links im OUTBOUNDIR gepackt. (bei binkley-style Mailern wird zuvor geprüft ob der Link gerade pollt, ist dies der Fall, wird für den Link das ARCMail-Archiv erst beim nächsten TOSS oder ZIP Befehl gepackt). Bei Frontdoor-style Mailern wird dann eine ARCMail-Netmail erstellt, mit der das erstellte Archiv an den Link geroutet wird. Wurde ein Semaphore-Verzeichnis angegeben, wird ein FDRESCAN.NOW Semaphore erstellt. Bei Binkley-style Mailern wird die *.FLO Datei des Links erstellt oder aktualisiert. Die *.FLO Dateien der Downlinks werden im OUTBOUND (ggf. mit Erweiterung auf Zone-Outbound) erstellt. Bei jedem Toss-Lauf erstellt BBToss eine IMPORT.LOG Datei in der die Areas (Echotags) aufgelistet sind in denen neue Mails einge- tosst wurden. Im 2-Phasen-Tossmode wird die IMPORT.LOG beim Befehl TOSSII erstellt. Bei erneutem Aufruf von BBToss mit TOSS/TOSSII wird die IMPORT.LOG überschrieben. BBToss selber benötigt die IMPORT.LOG Datei nicht, erstellt sie aber um anderen Utilities, die direkt nach BBToss aufgerufen werden anzuzeigen in welchen Areas neue Messages hinzugekommen sind. Default ist <BBTOSSVERZEICHNIS>\IMPORT.LOG 4.1.1 Umbenannte PKT-Files ─────────────────────────────────────────────────────────────────────── Umbenannte PKT-Files und ihre Bedeutung: *.DST Der Packet-Absender oder Packet-Empfänger ist nicht bekannt. Die Packet-Empfäger-Aka muß eine eigene AKA sein. *.PWD Das Packet enthält kein, oder ein falsches Passwort *.XXX Das Packet von einem unbekannten Node enthält Echomails. Die Netmails aus diesem Packet wurden bereits verarbeitet. *.BAD nicht näher spezifizierte Fehler Soll ein solches Packet (nach manueller Prüfung) dennoch verarbeitet werden, so muß es manuell in *.PKT umbenannt werden und falls der Fehler nicht durch berichtigen des Setups behoben wurde ins Lokal- Inbound kopiert werden (Hier werden alle Packets ohne weitere Pruefung verarbeitet). 4.1.2 TwoPassToss und TOSSII ─────────────────────────────────────────────────────────────────────── Bei aktivem TwoPassToss wird während des TOSS Befehls die Messages nicht sofort in die Messagebase geschrieben, sondern in ein lokales Packet (LOCALPKT.0 usw. im WORKDIR). Mit TOSSII werden diese lokalen Packets in die Messagebase einsortiert. (Anmerkung: Netmails werden grundsätzlich sofort in das Netmailver- zeichnis des Mailers geschrieben) Dieser geteilte Tossvorgang hat den Vorteil, daß - TOSS Befehl schneller ist, da in ein LOCALPKT schneller geschrieben wird als in die Messagebase - BBToss mehr offene Files für Downlinks verwenden kann, da für die meisten Messagebaseformate 3 oder mehr Files offen gehalten werden müssen. - BBToss nicht darauf achten muß ob z.B. ein Boxuser online ist, oder ein anderes Tool die Messagebase gesperrt hat. - für TOSSII in den Packets nur noch Areas enthalten sind, die auch in der Messagebase vorhanden sind. BBToss erstellt beim Aufruf per TOSSII eine IMPORT.LOG Datei, in der die Echoareas aufgelistet sind, in die neue Messages importiert wurden. Diese Datei ist dient dazu, anderen Utilities anzuzeigen in welchen Areas neue Mail enthalten ist. BBToss selber verwendet die IMPORT.LOG nicht. Bei jedem Aufruf mit TOSSII wird IMPORT.LOG überschrieben. 4.1.3 Tossen von Fileattach Netmails ─────────────────────────────────────────────────────────────────────── Fileattach Netmails sind Netmails mit denen gleichzeitig ein File übertragen wird. Der Dateiname steht in der Subject Zeile der Netmail. Da die Directory Struktur auf jedem System verschieden ist, ergänzt BBToss den angegebenen Dateinamen mit der aktuellen Pfad zu diesem File. BBToss sucht die Datei im Inboundverzeichnis und im Verzeichnis in dem das gerade getosste *.PKT liegt. Wurde die Datei nicht gefunden (z.B. weil noch nicht vollständig übertragen) ergänzt BBToss das Inboundverzeichnis (Inbound, UnsecInbound). Sind mehrere Dateinamen im Subject enthalten und passen nicht alle mit Pfaden ergänzte Namen (expanded Filenames) ins Subject der Mail, wird die Mail dupliziert. Hat das sendendende System kein "F'attach erlaubt Flag" (siehe Linkeditor) oder ist unbekannt, wird die Msg auf HOLD gesetzt. 4.2 Der SCAN Befehl ─────────────────────────────────────────────────────────────────────── SCAN durchsucht die loake Messagebase nach neuen Messages und verteilt diese an die angeschlossenen Downlinks. Gleichzeitig werden als Netmail Area Configurierte Areas durch- sucht und die dort enthaltenen Messages als Netmail verschickt. Dabei weist BBToss eine Besonderheit auf, das Akamatching für ausgehende Netmails beim tossen. Diese Feature sucht entsprechend der Netmail-Empfänger Adresse die passende lokale Aka heraus und setzt diese als Absender- adresse der Message ein. Dies wird aber nur durchgeführt, wenn dem Area im Setup keine feste EIGENE Aka angegeben wurde. Das Akamatching für ausgehende Netmails hat den Vorteil, das in der Mailbox ein einziges Netmailarea ausreicht um Messages korrekt in alle angeschlossenen Netze zu verschicken (die meisten Mailboxen setzen eine feste Adresse ein und der User muß unter mehreren Netmail Areas auswählen.... dies kann man mit BBToss getrost vergessen). BBToss überschreibt beim AKa matching auch eine ggf. von der MAilbox eingetragenen Absender- adresse. Nur wenn in BBToss für das Area eine Aka eigetragen ist, dann wird diese auch IMMER verwendet. Es empfiehlt sich das Akamatching zu nutzen (also keine Aka für das Netmailarea in der MAilbox anzugeben). 4.3 Der PACK Befehl ─────────────────────────────────────────────────────────────────────── PACK durchsucht das Netmailverzeichnis und packt die Netmails an die entsprechenden Nodes. Dabei werden die Routingregeln beachtet (siehe Abschnitt Routing). Netmails werden nur für die Links gepackt, für die das PackNetmail- Flag eingeschaltet ist. Abhängig vom Schalter "lösche gesendete Netmail" werden die ver- abreiteten Netmails gelöscht oder als gesendet markiert. BBToss bearbeitet während des PACK-Befehls - keine Mails mit "crash" Status - keine Mails mit File "attached" Status - keine Mails, die nicht entweder "local" oder "forward" Status haben - keine Mails mit "received" Status haben - keine Mails die "sent" Status haben - Mails mit HOLD Status nur wenn Flag "pack HOLD Netmail" im Linkeditor gesetzt ist. Andersherum gesagt, es werden nur Netmails gepackt, die "local" oder "forward" Status haben. Beim tossen setzt BBToss nur bei den Netmails selber den "forward" Status wenn für den Empfänger ein internes oder explizites Routing bekannt ist. BBToss hat eine integrierte Routingfehler-Erkennung. Lief eine Netmail mehr als 3x über das System, geht BBToss wohl zurecht davon aus, das das Routing der beteiligten Systeme irgendwo einen Fehler hat. - Es wird eine Fehlermeldung an das System geschickt an welches BBToss die Netmail bisher geroutet hat (und zurück bekam). - Die Netmail wird an den Absender umadressiert und mit einem kleinen Hinweis zurückgeschickt - Die Originalmail wird ins Badarea geschrieben 4.4 Der IMPORT Befehl ─────────────────────────────────────────────────────────────────────── Mit IMPORT werden Netmails an eine eigene Aka in des Netmailarea der Mailbox importiert. Wurde kein Netmailarea in der Messagebase (z.B. Hudson, JAM, Squish) angelegt, verbleiben die Areas im Netmailverzeichnis des Mailers. Dieser Befehl ermöglicht das Mailboxuser Netmails von fremden Systemen erhalten. Der IMPORT Befehl ist notwendig, da User in der Regel keinen Zugriff auf das Netmailverzeichnis des Mailers haben, also nur nach IMPORT an ihre Netmails kommen. IMPORT importiert keine Mails, die den Status "lokal" oder "sent" haben oder an AreaMgr gerichtet sind. Ebenfalls verbleiben Msgs an einen in der Aliasliste aufgeführten Namen im Netmailverzeichnis des Mailers (werden also nicht importiert). Existieren mehr als ein Netmailarea in der Mailbox importiert BBToss die Message in das Area, welches zur Empfängeradresse der Message passt. Um festzustellen in welches lokale/Box Netmailarea die Message zu importieren ist, sucht BBToss zunächst nach einem Area mit genau übereinstimmender MainAka (im Areasetup). Wurde kein entsprechendes Area gefunden wählt BBT das Area mit gleicher Zone und gleicher Net Nummer. Wird kein entsprechendes Area gefunden wird das erste Area mit gleicher Zone Nummer verwendet. Ist auch diese Suche nicht erfolgreich wird das erste verfügbare lokale Netmail Area gewählt. Nach dem Import wird das SENT Flag der Originalmessage im Netmail- folder gesetzt, bzw. wenn der Schalter "lösche gesendete Netmail" die Message gelöscht. 4.5 Der MGR Befehl ─────────────────────────────────────────────────────────────────────── Up- und Downlinks können ihre Einstellungen per Netmail an einen Pseudouser "Areamgr" ansehen und ändern. Insbesondere werden damit Echomail-Areas an- und abgemeldet. BBToss durchsucht beim Mgr Befehl das Netmailverzeichnis des Tossers nach Netmails an Areamgr und bearbeitet die in der Message enthaltenen Befehle (außer auf AREAMGR reagiert BBToss standardmäßig auf die Namen AREAFIX, BBTOSS . Weitere Namen z.B. CONFMGR sind im Languagefile (BBTLNG.CFG) in Zeile mit Nummer 1 eingetragen werden und können bei Bedarf ergänzt werden). Der grundsätzliche Aufbau einer Netmail an Areamgr (oder AreaFix) ist folgender von: Absender Name an: Areamgr 2:2469/1254 (= eingetragene Nodenummer im BBT) subj: Passwort_des_Links ---------------------------------------------- +ABC.Area -XYZ.Area ---------------------------------------------- pro Zeile ein Befehl Nach bearbeiten der Befehle sendet BBToss dem Link eine entsprechende Info oder Bestätigung. Eine Antwortnachricht wird vom Areamgr auf jeden Fall geschrieben, wenn der Link nicht bekannt ist wird dann eben eine entsprechende Fehlermeldung an den Absender geschickt. Da es nach meiner Erfahrung häufiger vorkommt, das ein Link, der mehr als eine AKA hat, mit einer Falschen Nodenummer an den Areamgr schreibt prüft BBToss ob ein Link mit gleichem Namen existiert. Ist dies der Fall wird es in der Fehlermeldung angegeben, mit dem Hinweis eine entsprechende Nodenummer für Areamgr-Messages zu ver- wenden. Es wird eine Fehlermeldung mit folgendem Inhalt erstellt: > Deine Nodenummer ist nicht im Areamgr eingetragen > hier im Nodemanager gibt es "Hans Sauer" mit Nodenr 2:2888/101 > wenn du das bist, dann nimm doch bitte die Aka 4.5.1 Befehle in einer Areamgr-Netmail ─────────────────────────────────────────────────────────────────────── Siehe auch Datei AREAFIX.HLP. Der Inhalt der Datei AREAFIX.HLP im BBToss Hauptverzeichnis wird dem Link beim Befehl %HELP als Hilfestellung geschickt %ALL Meldet alle Areas an, für die die Gruppe des Links paßt und %+ALL der Link einen entsprechenden Leselevel hat %-ALL meldet alle Areas ab +* meldet alle Areas an +ABC* meldet alle Areas, deren Name mit ABC beginnt an. +ABC.GER, R meldet Area an und fuehrt Rescan fuer diese Area durch (siehe auch %RESCAN) %LIST Gibt eine Liste der verfügbaren Areas für den Link an, also alle Areas die zu einer seine Gruppen gehören und für die sein ReadLevel hoch genug ist. %STATUS sendet eine Netmail mit Angaben zu den Einstellungen des Links zurück. Beispiel für eine Antwortmessage ---------------------------------------------- Status: aktiv Packer: ZIP max. Packetgröße........ 292 kB max. ARCmail Archivgröße 976 kB eingestelltes Routing: RouteTo 49:70/105 49:70/106 49:70/107 ---------------------------------------------- Angaben zum Routing werden nur gemacht, wenn in BBTROUTE.CFG ein spezielles Routing eingestellt wurde, ansonsten wird der Hinweis "Standard-Routing" angegeben. %COMPRESS Mit diesem Befehl kann der Link den gewünschten Packer einstellen, z.B %COMPRESS ZIP stellt den Packer auf Zip ein. mit %COMPRESS ? erhält der Link eine Liste der installierten Packer (in BBToss eingetragene). Wird ein nicht verfügbarer Packer angewählt wird ebenfalls eine Liste der Packprogramme zurückgeschickt. %PAUSE setzt den Status des Links auf Pause (Link->aktiv-Flag=no), damit wird an diesen Link keine Echomail weitergeleitet. Der Link kann dies mit dem Befehl %RESUME wieder rück- gängig machen. Der Befehl ist in in erster Linie dazu gedacht, den Bezug von Echomail temporär für eine gewisse Zeit abzubestellen, ohne die jede Area abzumelden. Mit %RESUME sind sofort wieder alle Areas wie vor dem %PAUSE Befehl aufgeschaltet. %QUERY Sendet als Antwort eine Liste der bestellten Areas %AVAIL Sendet als Antwort eine Liste der beim eigenen Uplink verfügbaren Areas. Als Liste der verfügbaren Areas wird die in BBTCFG bei Linkmanager->UplinkManager eingestellte Arealistdatei verwendet und (unverändert) an den Downlink gesendet. Der requestende Downlink muß der Gruppe des Uplinks angehören und einen Level >= dem Readlevel des Uplinks eingestellt haben. Wurde für keinen zutreffenden Uplink eine Arealistdatei gefunden (nicht konfiguriert) schickt BBT automatisch das Ergebnis eines %LIST Befehls zurück. %UNLINKED Sendet eine Liste der NICHT bestellten Areas %RESCAN für alle nach dem Befehl %RESCAN bestellten Areas werden dem Link alle Messages des Areas zusammengestellt. %RESCAN=x für alle nach dem Befehl %RESCAN= bestellten Areas werden dem Link x Messages des Areas zusammengestellt. In beiden Formen des Befehls werden dem Link auch dann die Messages zusammengepackt, wenn er bereits an das entsprechende Area angeschlossen ist, es kann also auch ein Rescan von bereits angemeldeten Areas durchgeführt werden. Beispiel: +A.AREA diese Area wird nur angemeldet %RESCAN +B.AREA dieses Area wird angemeldet und alle Msgs gepackt %RESCAN=10 +C.AREA dieses Area wird angemeldet und die letzten 10 Msgs gepackt --- In rescannten Messages wird eine Kludgezeile ^ARESCANNED <areamainAKA> eingefügt um dem empfangenden System (Tosser) anzuzeigen, das diese Messages nicht exportiert werden brauchen. %RESUME Macht den %PAUSE Befehl rückgängig (Link->activ-Flag=on) und sendet dem Link eine Statusmessage, sowie eine Liste der Areas, die für ihn angemeldet sind. Alternativ kann auch der Befehl %ACTIVE verwendet werden (identisch mit %RESUME). %PWD Ändert das bestehende Areamgr Passwort (das Passwort, daß bei Areabestellungen usw. angegeben werden muß). Es werden nur Paßworte akzeptiert, die mindestens 3 Zeichen und maximal 15 Zeichen lang sind. Beispiel: %PWD=MEINPWD oder %PWD MEINPWD Passworte werden von BBToss automatisch in Großbuchstaben umgewandelt, Groß-/Kleinschreibung macht daher keinen Unterschied. %PKTPWD Ändert das bestehende Packetpasswort (das Passwort, daß in den Messagepackets *.PKT Files verwendet wird). Packetpassworte dürfen maximal 8 Zeichen lang sein. BBToss akzeptiert in diesem Befehl nur Paßworte, die mindestens 3 Zeichen lang sind. Beispiel: %PKTPWD=MEINPWD oder %PKTPWD MEINPWD Passworte werden von BBTOss automatisch in Großbuchstaben umgewandelt, Groß-/Kleinschreibung macht daher keinen Unterschied. %NEWAREAINFO+ %NEWAREAINFO- Ändert das Linkflag "New Area Info". Ist NEWAREAINFO aktiv, erhält der Link eine Info Netmail, wenn ein Area automatisch angelegt wurde und dem Area ein Uplink aus dem Uplinkmanager (autom.) zugeordnet wurde. Gruppe und Level des Links werden dabei berücksichtigt. Er erhält die Infomsg nur, wenn er das Area auch bestellen kann. Alternativ können die Befehle im alten Stil in der Subjectzeile an- gegeben werden. Das 1. Wort der Subjectzeile ist bei Areamgr- Requests das Passwort, danach können die Befehle durch Leerzeichen getrennt angegeben werden. Dabei werden die Befehle dann nicht mit "%" begonnen, sondern mit einem "-" Zeichen und es werden Abkürzungen verwendet. Mögliche Befehle in der Subjectzeile -L entspricht %LIST -Q entspricht %Query -H oder -? entspricht %HELP -U entspricht %UNLINKED -P entspricht %PAUSE -A entspricht %ACTIVE -S entspricht %STATUS Beispiel einer Subjectzeile mit Befehlen: to: Areamgr Subj: passwort -L -H Sendet dem Link eine Antwort mit der Liste der bestellten Areas und den Hilfetext. Entspricht also einer Message to: Areamgr Subj: passwort ----------------- %LIST %HELP --- 4.6 Der NOTIFY Befehl ─────────────────────────────────────────────────────────────────────── Der Befehl NOTIFY sendet eine Informations-/Status Msg an den angegebenen Link oder an alle Links und informiert über die bestellten Areas und andere Einstellungen des Links. Es können alle AreaManager Befehle die mit "%" beginnen im Aufruf verwendet werden. Aufruf BBT.EXE notify AKA <%areamgr-befehl> Beispiele: bbt notify 2:2471/2400 %List %query %help bbt notify 2:2471/2400 %pause %status bbt notify 49:70/1 %status bbt toss notify 49:70/1 %list pack Nach "notify" muß eine Nodenummer gefolgt von den %Befehlen kommen. Beim "notify" Parameter können alle Areamgr-Befehle, die mit "%" beginnen verwendet werden (wie %LIST, %QUERY, %STATUS, %PAUSE, %RESUME %-ALL). Bei der 2. Aufrufmöglichkeit wird für alle Links, die das Notify-Flag im Linkmanager gesetzt haben eine Statusmsg versendet. Aufruf: BBT.EXE NOTIFY * %STATUS .... Es ist also an Stelle der expliziten Nodenummer ein * einzugeben. 4DOS Anwender müssen 2 "%" Zeichen bei den Befehlen verwenden z.B BBT.Exe notify * %%STATUS %%LIST. 4.7 Der RELINK Befehl ─────────────────────────────────────────────────────────────────────── Der RELINK Befehl erstellt AREAMGR Bestell-Messages für alle aktiven Echo-Areas und sendet diese an jeden angeschlossenen Link. 4.8 Der AUTO Befehl ─────────────────────────────────────────────────────────────────────── Der AUTO Befehl fasst die vorgenannten einzelnen Befehle zusammen und erledigt alles automatisch. D.h. es wird SCAN TOSS PACK MGR IMPORT TOSSII intern aufgerufen, wenn es notwendig ist. Der einzigste Befehl, der derzeit darin nicht enthalten ist, ist der SCAN Befehl (mit dem ja die lokale Messagebase nach neu geschriebenen Messages zum exportieren durchsucht wird). 4.9 Der CLEAN Befehl ─────────────────────────────────────────────────────────────────────── Der Befehl CLEAN dient dazu bereits gesendete ARCMail-Archive der vorangegangenen Tage zu löschen. Dies ist notwendig, da die Mailer diese Files nicht löschen, sonder auf 0 Byte setzen um zu vermeiden, das eine Datei am selben Tag mit gleiche Namen gesendet wird. Der CLEAN Befehl brauch daher maximal einmal am Tag aufgerufen werden, da nur ARCMail Dateien entfernt werden, die nicht das heutige Datum haben und 0 Byte groß sind. BBToss erledigt das automatisch beim ersten Aufruf des Tages (Erkennung anhand des Logdateidatums). 4.10 Der SAYERR Befehl ─────────────────────────────────────────────────────────────────────── Die während des Tossvorgangs in der Datei BBSAYERR.BBT festgehaltenen Fehlermeldungen werden mit diesem Befehl per Netmail an die Links gesendet. 4.11 Der ZIP und UNZIP Befehl ─────────────────────────────────────────────────────────────────────── Beide Befehle werden in der Regel nicht benötigt, da beim Tossen und Scannen die Packer automatisch aufgerufen werden. Wer allerdings die eingehenden oder ausgehenden *.PKT Files mit anderen Tools vor- oder nachbearbeiten möchte, welche die ARCMail Archive nicht selbst packen/entpacken können, kann diese Befehle verwenden. UNZIP entpackt die in den Inboundverzeichnissen liegende ARCMail ZIP packt die in den Outboundverzeichnissen liegenden *.PKT Files Sollen die beiden Befehle verwendet werden ist bei TOSS der Parameter /NOZIP zu verwenden, damit TOSS die Packer nicht automatisch aufruft. 4.12 Der BAD Befehl ─────────────────────────────────────────────────────────────────────── Wurde ein BADMAIL Area angelegt, rescannt BBToss dieses Area und tosst alle Messages, die kein SENT Flag haben und in denen ein Echoareaname enthalten ist (Kludge AREA: oder ORIGAREA:) erneut. Wurde eine Message re-tosst, wird das SENT Flag gesetzt, wodurch die gleiche Message bei einem erneuten BAD Aufruf nicht noch ein- mal re-tosst wird. Die re-tossten Msgs werden in ein *.PKT File ins Localinbound ge- schrieben und beim nächsten TOSS Befehl an die Links verteilt, sowie in die eigene Messagebase beschrieben. 4.13 BBT COMPILE ─────────────────────────────────────────────────────────────────────── Für schnelleres Einlesen der Configurationsdaten compiliert BBT die Konfigurations Textdateien (*.INI und *.CFG) in Dateien mit der Endung *.BBT. BBT überprüft beim Start ob eine *.INI oder *.CFG Datei verändert wurde (neueres Dateidatum als die *.BBT Datei) und compiliert bei Bedarf automatisch die entsprechende *.INI/*.CFG Datei. Unter seltenen Bedingungen (z.B. Rückspeichern eines Backups, Ausfall oder stellen der Rechneruhr u.ä.) kann mit dem COMPILE Befehl ein neu compilieren aller *.CFG und *.INI Dateien erzwungen werden. Dieser Aufruf-Parameter ist auch in BBTCFG verfügbar. 4.14 BBT Errorlevel ─────────────────────────────────────────────────────────────────────── BBToss gibt nach Beenden des Programms folgende Errorlevel zurück, die in ein Batchdatei abgefragt werden können. Errorlevel Beschreibung 1 Netmails getosst 2 Echomails in lokale Messagebase getosst 4 Ausgehende Mailarchive erstellt Die Errorlevel wirken additiv, d.h. wurde mehr als eine Aktion ausgeführt addieren sich die Errorlevel. Errorlevel Beschreibung 1 Netmail getosst 2 Echomail getosst 3 (1+2) Netmail und Echomail getosst 4 Mailarchive erstellt 5 (1+4) Netmail getosst und Mailarchive erstellt 6 (2+4) Echomail getosst und Mailarchive erstellt 7 (1+2+4) Netmail und Echomail getosst und Mailarchive erstellt Die Errorlevel können in einer Batch abgefragt werden BBT.EXE <command> if errorlevel 4 goto mailerrescan if errorlevel 2 goto offlinereaderscan if errorlevel 1 goto msgtracker Zu beachten ist, dass die Errorlevel wie maximal Pegel anzusehen sind. D.h. Bedingung ist wahr, wenn Errorlevel gleich oder groesser dem angegebenen Wert ist. Gibt BBT z.B. Errorlevel 4 zurueck, dann sind auch "if errorlevel 1", "if errorlevel 2" und "if errorlevel 3" wahr, jedoch nicht "if errorlevel 5". "if errorlevel 0" ist somit immer wahr. 5. Inhalt der einzelnen Config-Files ─────────────────────────────────────────────────────────────────────── Alle Configurationsdateien sind als Textdateien (ASCII-Dateien) an- gelegt. Sie können per Texteditor oder menügeführt per BBTCFG.EXE gändert werden. Zur schnelleren Ausführung werden die Text-Configdateien von BBToss in *.BBT Dateien compiliert (übersetzt). BBToss startet die Über- setzung automatisch, wenn die entsprechende *.BBT Datei fehlt oder die Text-Configdatei ein jüngeres Dateidatum besitzt. 5.1 Die Tosser Konfiguration (BBTOSS.INI) ─────────────────────────────────────────────────────────────────────── Die globale ConfigDatei BBTOSS.INI. Alle hier enthaltenen Einstellungen können mit BBTCFG.Exe menügeführt verändert werden. Selbstverständlich kann man aber auch mit einem Texteditor diese Datei manuell bearbeiten. Die Datei ist in folgende Abschnitte (Section) aufgeteilt [BBTPATH] Die Verzeichnisse die BBToss verwendet [NETMAILFOLDER] Einstellungen zum globalem Mailfolder des Mailers [MAILER] Einstellungen zum Mailer [MAILBOX] Einstellungen zur Mailbox [BBTFLAGS] BBToss Flags [BBTLIMITS] BBToss Limits Section [MAILER] ∙ MAILER=<Mailer> Bei den Mailereinstellungen ist in erster Linie wichtig, welche Art von Outbounds für die Echomailpackets erstellt werden müßen. Hierbei gibt es 2 grundsätzlich verschiedene, "Frontdoor-Style" und "Binkley-Style", Default bei fehlendem Eintrag ist Frontdoor-Style. Zulässige Angaben für Mailername sind Parameter Bemerkung (Style) FRONTDOOR oder FD Frontdoor-Style INTERMAIL oder IM Frontdoor-Style TMAIL Frontdoor-Style BINKLEY oder BT Binkley-Style MCMAIL Binkley-Style TMAIL_Binkleymode Binkley-Style XENIA oder XEN Binkley-Style Bei Frontdoor-Style kompatibler ARCMail-Behandlung stehen die Namen der Msg-Packets in der Subjectzeile einer Netmail mit Absender ARCMail. Es werden also für ARCMail-Packets "fileattached Netmails" verwendet. Bei Binkley-Style kompatibler ARCMail-Behandlung wird in dem angegebenen Outbounddir (Binkley Zone-Outbound wird unterstützt, also Basis- name mit *.XXX mit XXX=Zonenr in hex z.B. OUTBOUND.002 <- nicht jedoch Domainoutbound mit vollkommen unterschiedlichen Verzeichnisnamen) nach einem *.FLO *.HLO File gesucht, in dem die Namen der Msg-Packets (ARCMail) stehen. Section [MAILBOX] ∙ MAILBOX=<Boxsoftware> Gibt an für welche Mailboxsoftware die Areaeinstellungen exportiert werden sollen. Z.Zt können die Areaeinstellungen in folgende Boxsoft- war exportiert werden. zulässige Angaben für <Boxsoft> REMOTE_ACCESS oder RA für Remote Access 2.0x RA250 für Remote Access 2.50 EZYCOM für Ezycom 1.1/1.2 EZY_120 für Ezycom 1.20 EZY_148 für Ezycom 1.48 PROBOARD für Proboard 2.x PB_212 für Proboard 2.12 PB_215 für Proboard 2.15 MAXIMUS für Maximus 3.0 CONCORD für Concord DMS40 für DMS Section [BBTPATH] ∙ INBOUND=<pfad> gibt das Inbounddirectory des Mailers an in dem Sessionpassword geschützte Mailpackete landen ∙ UNSECINBOUND=<pfad> gibt das Inbounddirectory des Mailers an in dem die Packets von Nodes ohne Sessionpassword landen. Aus diesen Packets werden NUR Netmails verarbeitet. ∙ LOCALINBOUND=<pfad> Das Securityinbound-Directory des Tossers. In diesem diesem Verzeichnis befindliche PKT's werden ohne jegliche überprüfung getosst ∙ OUTBOUND=<pfad> gibt das Outbounddirectory des Tossers an, in dem die ARCMail Packets (Archive mit den Echo- und Netmails) erstellt werden. Bei Binkley kompatibelen Systemen werden Zoneoutbound-Verzeichnisse verwendent. Der Basisnamen wird beim Tossen zum entsprechenden Zone- Outboundnamen erweitert (Ist also das Directory in dem die *.FLO, *.OUT Dateien erstellt werden) Eingabe von c:\bt\outbound\ (für die Mainzonenummer) wird beim tossen auf c:\bt\outbound.002 für Zone 2 erweitert, c:\bt\outbound.031 für Zone 49 usw. und die entsprechenden *.FLO Dateinen in diesen Directories erstellt, sowie die dazugehörigen Mailarchive. ∙ TMPOUTBOUND=<pfad> gibt das temporäre Outbounddirectory des Tossers an, in dem die *.PKT Files an die Links zwischengespeichert werden und von hier aus zu einem ARCMail Packet im OUTBOUND gepackt werden. Das TmpOutbound kann zu Optimierung der Geschwindigkeit genutzt werden, wenn Outbound und TmpOutbound auf verschiedenen physikalischen Platten liegen, reduzieren sich beim packen die Kopfbewegungen der Platten. Oder wenn das Outbound ein Netzlaufwerk ist und das TMPOUTBOUND auf eine lokale Platte gelegt wird. Dieses Verzeichnis KANN, muß aber nicht angegeben werden. ∙ TMPINBOUND=<pfad> In dieses Verzeichnis werden empfangene Mailarchive entpackt. Durch konfigurieren auf eine ander Platte als die Inboundverzeichnisse kann durch weniger Platten seek Operationen der Entpackvorgang beschleunigt werden. Dieses Verzeichnis KANN, muß aber nicht angegeben werden ∙ WORKPATH=<pfad> Arbeitsverzeichnis von BBToss für temporäre Files. Das Verzeichnis sollte nur von BBToss benutzt werden. Es wird dringend empfohlen, ein solches Verzeichnis anzulegen ∙ JAMLOG=<pfad> Verzeichnis in dem die ECHOMAIL.JAM/NETMAIL.JAM Datei für schnelleren SCAN stehen. Die Dateien werden von der Box oder dem Editor nach dem Schreiben von neuen Nachrichten erstellt. ∙ ECHOTOSSLOG=<datei> Pfad und Name zur ECHOTOSS.LOG Datei, die beim SCAN verwendet wird (in der Regel bei Squish-MsgBaseFormat) um nur die Areas mit neuen Messages zu scannen. Die Datei wird vom Boxprogramm oder Editor nach dem Eingeben von neuen Nachrichen erstellt. ∙ IMPORTLOG=<pfad+datei> Pfad und Name zur IMPORT.LOG Datei, die beim TOSS/TOSSII erstellt wird und die Echoareatags der Areas enthält in die Mails geschrieben wurden, um anderen Utilities anzuzeigen in welchen Areas Messages hinzugekommen sind. ∙ LOGPATH=<pfad> Verzeichnis in dem die Logdatei erstellt wird ∙ LOGLEVEL=<zahl> Mit dem Loglevel kann eingestellt werden, was alles in die Logdatei geschrieben werden soll. Je kleiner die Zahl, je mehr Informationen werden in die Logdatei geschrieben. Loglevel 1 : alles (jede Bildschirmeldung wird protokolliert) Loglevel 2 : detailiert Loglevel 3 : normal Loglevel 4 : reduziert (z.Z. identisch mit Loglevel=3) Loglevel 5 : minimal Loglevel 0 wird wie Loglevel 3 behandelt. ∙ HMBDIR=<pfad> Ist der Pfad zur HudsonMessageBase, wie sie z.B. von Remote Access oder Proboard verwendet werden. ∙ EZYMSGBASEDIR=<pfad> Ist der Pfad zur Ezycom-MessageBase Section [NETMAILFOLDER] ----------------------- ∙ BASETYP=<AreaBaseTyp> Der Basetyp des globalen Netmailfolders kann in BBToss frei ge- waehlt werden. Die meisten Mailer und anderen Programme setzen ein Fido *.MSG Basetyp voraus. Es wird daher empfohlen den Basetyp auf N (= Fido *.MSG Format) zu setzen. ∙ PATH=<pfad> Ist der Pfad zum Netmaildirectory des Mailers. Hier sucht BBToss nach empfangenen Netmails und im Frontdoor-Modus nach ARCMail Messages (Netmails mit angehängten Echomailpackets [File attached]) ∙ DefaultZone=<Zonenr> Bei Messages ohne Zone Informationen wird dies Zonenummer als Default Zone gesetzt. ∙ SentArea=<Areatag> Areaname (nicht Path) in das gesendete lokale Netmails vor dem Loeschen kopiert werden. Section [BBTFLAGS] ------------------ ∙ PathDupe Prüft die Path-Zeile in Echomails um die Message als Dupe zu erkennen. ∙ CRCDupe Dupeerkennung anhand von einer beim Tossen ermittelten Checksumme von Absender- und Empfängername, sowie der MessageID (so vorhanden) getrennt nach Areas. Die Checksummen der letzten 10000 Messages werden in der Datei BBTDUPE.BBT gespeichert und bei jedem Tossvorgang mit den aktuellen Messages verglichen. ∙ DupeDays <Zahl> Wenn eine Message älter ist, als die hier angegebene Anzahl von Tagen, dann wird sie als Dupe behandelt. D.h sie wird nicht an andere Systeme weitergesendet. Der Wert sollte daher nicht zu klein gewählt werden. Ist DupeDays 0 ist diese Option abgeschaltet. Der kleinste einstell- bare Wert sind 15 Tage. ∙ MaxTime <Zahl> Zeitliche Begrenzung eines Tossvorgangs in Minuten. Z.B. MaxTime=10 beendet das Tossen nach ca. 10 Minuten, auch wenn noch nicht alle Packets verarbeitet sind. Dadurch besteht die Möglichkeit den Tosser so einzustellen, das der nächste Mailer-Event auf jedenfall eingehalten wird. Die noch nicht bearbeiteten Packets werden dann beim nächsten Aufruf getosst. Der kleinste einstellbare Wert ist 5 Minuten. ∙ HoldDays <Zahle> Wird beim Tossen bei einem Link ein Mailarchiv festgestellt, welches älter als die hier angegebene Anzahl von Tagen ist, wird der Link automatisch auf HOLD gesetzt. Der Link erhält eine Info-Netmail (mit Text BBTLNG.CFG Nr. 3012). Dadurch werden keine weiteren Echomails für den Link erstellt, bis er manuell (in BBTCFG) oder per Areamgr Request (Befehl %RESUME oder %ACTIV) wieder aktiv geschaltet wird. Dadurch wird ein ansammeln von Echomails, wenn ein Link z.B. bei längerem Urlaub vergessen hat ein %PAUSE Areamgr Request zu schicken vermieden. HoldDays=0 schaltet diese Funktion ab, der kleinste einstellbare Wert ist 3 Tage. ∙ TwoPassToss 2 Phasen Toss ->tossII, das heisst Tossen an die Up/Downlinks und einsortieren in die lokale Messagebase werden in 2 getrennten Aufrufen von BBToss (toss tossII) ausgeführt. Dies ist eine besonders interessante Option bei Netzwerkbetrieb, bzw. hohem Messageaufkommen oder schnell- aufeinanderfolgenden Polls. Mit TOSS werden die aktuellen Packets an die Links verteilt und dabei ein lokales Packet (LOCALPKT.1) im Workdir erstellt. Mit TOSSII werden die lokalen Packets in die Messagebase einsortiert. ∙ Multiline Im Multilinebetrieb unter einem Multitasker oder im Netzwerk sorgt dieser Schalter dafür, daß jeweils immer nur 1 Task von BBToss zu gleichen Zeit läuft. Dieser Schalter ist dann unbedingt zu setzen, da ansonsten Fehler auftreten können (z.B. Dupes). Im Multiline-Betrieb muß das Programm SHARE geladen sein. ∙ Kill0ByteNM Netmails mit 0 Byte Länge werden gelöschen ∙ KillAreaMgrNM löscht empfangene und bearbeitet AreaMgr Messages ∙ BounceBadDestNM zurückschicken an den Absender von nicht zustellbaren Netmails ∙ KillDupes Dupe-Messages werden nicht ins Dupe-Area geschrieben, sondern sofort gelöscht Section [BBTLIMITS] ------------------- ∙ MaxPktSize:<zahl> maximale Größe eines Msg-PKT-Files in Byte. Voreingestellt sind 1000000 Byte (1 MB) Überschreitet das aktuelle *.PKT File diese Größe, werden nachfolgende Messages in ein neues File geschrieben. Minimal einstellbare Größe ist 100000. ∙ MaxZipFileSize:<zahl> maximale Größe eines Msg-ARCMail-Archivs. Voreingestellt sind 1000000 Byte (1 MB). Übersteigt das Archiv diese Größe, wird beim !nächsten! Tossvorgang ein neues Archiv erstellt. Minimale einstellbare Größe ist 64000. Ist das Archiv kleiner als hier angegeben, werden weitere Packets mit in das Arcmail-Archiv gepackt, bis die angegebene Größe erreicht (oder überschritten ist) oder das Datum wechselt (d.h. eine andere Endung des Archives *.MO1 *.TH1 usw.) Da die beim aktuellen Tossvorgang immer in ein Archiv gepackt wird, kann die hier vorgegebene Größe z.T. auch leicht überschritten werden. ∙ MinDiskSpace:<zahl> minimaler freier Platz auf der Festplatte. Voreingestellt sind 10000000 (10 MB) Ist weniger Platz auf der Festplatte vorhanden, werden keine weiteren Messages an die Downlinks verteilt. Der freie Plattenplatz wird nur beim TOSS Befehl überprüft, BBPack BBTOSS PACK usw. werden weiterhin ausgeführt. Der größte einstellbare wert ist 200000000 (200MB). ∙ MaxFilesOpen:<zahl> Anzahl der Files, die BBToss gleichzeitig öffnen darf. Dieser Wert hängt von der jeweiligen Dos-Einstellung ab und muß immer kleiner sein, wie der Wert von FILES= in der CONFIG.SYS. Standardwert ist MaxFilesOpen:20 Da BBToss während des Tossens für jeden Downlink an den in diesem Tossvorgang Messages gesendet werden 1 File öffnen möchte ohne dieses Files sofort wieder schließen zu müssen, ist ein hoher Wert erwünscht. Ein Wert von MaxFilesOpen kleiner 10 sollte auf jedenfall vermieden werden. ∙ EchoStatistik mit diesem Schalter wird die Echomailstatistik eingeschaltet, d.h. BBToss merkt sich, wieviele Messages in jedem Area und für jeden Node verarbeitet wurden. Die Werte werden jeweils aufsummiert, bis die Statistik zurückgesetzt wird und dadurch alle Werte auf 0 gesetzt werden. ∙ PickAliasMsg schaltet das herauskopieren von Messages beim Tossen ein. Alle Msg's, auch in Passthrough Areas werden geprüft, ob sie an einen Namen gerichtet sind der in der Config-Datei BBTALIAS.CFG steht (siehe BBTCFG -> Aliasnamen). Wird eine entsprechende Message entdeckt, wird sie als Netmail an den Sysop (Mainaka) kopiert. ∙ NOZIP Verhindert, das die ausgehenden Packets sofort beim TOSS-Befehl gepackt werden, so das externe Tools noch die *.PKT Files bearbeiten können. Das Packen in ein ARCMail Archiv kann dann mit BBT.EXE ZIP durchgeführt werden. Diese Option muß manuell in die BBTOSS.INI eingetragen werden, oder kann als Parameter beim Aufruf z.B. BBTOSS <befehl> /NOZIP ver- wendet werden. ∙ DEBUG Angabe, auch als Parameter anzugeben, mit dem besonders viele Informationen zum Programmablauf ausgegeben werden (im Normalfall nicht notwendig). 5.2 Packereinstellung BBTZIP.INI ─────────────────────────────────────────────────────────────────────── In der Datei BBTZIP.INI sind die Packer/Entpacker und deren Parameter definiert. Die Datei ist folgendermaßen aufgebaut: [GLOB_PACKERDEF] Abschnitt mit globalen Angaben PACKERPATH= globaler Pfad zu den Packern [ZIP] Beginn eines Setupblocks, hier für *.ZIP Compress= (Pfad+)Exe mit Parameter zum packen Extract= (Pfad+)Exe mit Parameter zum entpacken ListSign= Parameter oder Zeichen des Packers um die Liste der zu packenden Files aus einer Textdatei zu entnehmen, default ist @ In den Compress= und Extract= Aufrufstrings werden folgende Parameter von BBToss zur Laufzeit ersetzt: %a mit dem Namen des zu ent-/packenden Archives %f mit dem Namen des zu packenden Files, bzw. mit dem Namen einer ASCII-Liste mit den zu packenden File- namen %p Pfad in das die Files entpackt werden sollen Im Extract= Befehl ist Parameter %a und %p anzugeben, im Compress= Befehl ist Parameter %a und %f anzugeben. Die möglichen Packerabschnitte sind: ZIP, ARJ, ARC, LHA, LZH, ZOO, SQZ, HYP, RAR, UC2, OS2_ZIP, OS2_ARJ, OS2_ARC, OS2_LHA, OS2_LZH, OS2_ZOO, OS2_SQZ, OS2_HYP, OS2_RAR, OS2_UC2 WIN_ZIP, WIN_ARJ, WIN_ARC, WIN_LHA, WIN_LZH, WIN_ZOO, WIN_SQZ, WIN_HYP, WIN_RAR, WIN_UC2 Die Abschnitte OS2_??? werden in der OS/2 Version verwendet, die WIN_??? in der kuenftigen Windows Version. Ist der benoetigte Packer nicht in der OS2_??? oder WIN_??? vorhanden, wird auf das fuer Dos konfigurierte Packprogramm zurueckgegriffen. Beispiel: [ZIP] Extract=PKUnzip.Exe -o -) %a %f %p Add=PKZip.Exe -ex -) %a %f ListSign=@ [ARJ] Extract=ARJ.Exe e -c -y %a %f %p Add=ARJ.Exe a -e -u -y %a %f ListSign=! 5.4 Areas BBTAREA.INI ─────────────────────────────────────────────────────────────────────── In der BBTAREA.INI sind alle Einstellungen der einzelnen Areas ent- halten. Bei Änderungen im Setupprogramm (BBTCFG.EXE) wird diese Datei neu erstellt. Manuelle Änderungen per Texteditor sind ohne weiteres möglich. BBToss vergleich bei jedem Aufruf das Dateidatum von BBTAREA.INI und der compilierten Version (aus denen BBToss seine Informationen liest) und führt automatisch eine Neucompilierung aus, wenn die INI-Datei jüngeren Datums ist. Die BBTAREA.INI Datei muß sich im Stammverzeichnis von BBToss befinden (dort wo BBT.EXE liegt). Die BBTAREA.INI Datei ist wie folgt aufgebaut: [ECHOTAG_1] schluesselwort=.... .... [ECHOTAG_2] schluesselwort=.... schluesselwort=.... Für die einzelnen Areas sind folgende Schlüsselworte (=Daten) möglich: NR=<zahl> Areanummer in der Messagebase/Mailbox-Config PATH=<dateiname> Areapfad/Datei BASETYP=<char> Area-Basistyp (J=Jam, H=Hudson, S=Squish, E=Ezycom usw.) GROUP=<char> Gruppen (Buchstabe oder Zahl 0..9, A..Z, a..z) TYP=<char> Area-Typ (E=Echo, P=Passthru, B=Badarea, N=Netmail usw.) MAINAKA=<aka> eigene Nodenummer für dieses Area UPLINK=<aka> Nodenummer des Uplinks bei dem die Area bestellt wurde FLAGS=<zahl> ASCII-Wert der Flags (bitte nicht ändern) WRITELEVEL=<zahl> Schreiblevel des Areas READLEVEL=<zahl> Leselevel des Areas MAXMSGS=<zahl> maximale Anzahl Messages (für BBTCLEAN) MINMSGS=<zahl> minimale Anzahl Messages (für BBTCLEAN) DESC=<text> Beschreibung des Areas (darf Leerzeichen enthalten) ORIGIN=<text> DAYSOLD=<zahl> maximales Message Alter in Tagen (für BBTCLEAN) STATDATE=<datum> Startdatum der Areastatistik im Format tt.mm.yy FLOW=<zahl> Anzahl getosster Msgs (wird von BBT berechnet) READONLY=1 Area fuer alle Links, mit Ausnahme des Areauplinks read only LINKCOUNT=<zahl> Anzahl der an das Area angeschlossenen Links, (muß mit der Anzahl jetzt folgender LINK= Einträge übereinstimmen) LINK=<aka> Nodenummern der angeschlossenen Links 5.5 Links BBTLINK.INI ─────────────────────────────────────────────────────────────────────── Bezüglich grundsätzlichem Aufbau und Änderungen gilt das selbe wie zu BBTAREA.INI gesagte. Der Aufbau: (jeder Link beginnt mit der in eckige Klammern gesetzten Nodenummer) [<nodenr>] schluesselworte=... ..... [2:2471/2400] schluesselworte=... ..... Die Schlüsselworte für die einzelenen Linkeinträge: SYSOP=<text> Sysopname USEAKA=<aka> als Absender zu verwendende eigene Aka PKTPWD=<text> Pkt-Passowrt (max. 8 Buchstaben) MGRPWD=<text> Areamgr-Passwort LEVEL=<zahl> Securitylevel des Links PACKER=<char> Packer für ARC-Mail Packets (Z=Zip, J=ARJ usw.) GROUP=<text> Gruppen zu denen der Link gehört (max. 15 Zeichen) ARCMAILSTATUS=<char> Status der ARCmail Packets (C=crash, H=hold) MSGMAILSTATUS=<char> Status der Areamgr und Fehler Netmails (C=crash...) FLAGS=<zahl> numerischer Wert der Linkflags (bitte nich ändern) CAPABILITY=<text> Packet Typ (Capability) *=unknown 2=FTS0001 oder 2+=FSC39 READONLY=1 Link kann Echoareas nur readonly anmelden FLOW=<zahl> Anzahl Messages die der Link erhalten hat (seit letztem Statistik-Reset) FLOWKB=<zahl> Anzahl Kilobyte (ungepackt) die der Link erhielt (wird z.Zt nicht aktualisiert) STATDATE=<datum> Datum ab wann Flow/FlowKb gezaehlt wurden LASTINDATE=<datum> Datum wann letztes empfangenes Packet verarbeitet wurde MAXPKTSIZE=<zahl> Max. File Size eines *.PKT Files MAXZIPSIZE=<zahl> Max. File Size eines ARCMail Archives 5.6 Gruppen BBTGROUP.INI ─────────────────────────────────────────────────────────────────────── Hier sind die Messagegruppen von BBToss definiert. Ein Eintrag beginnt mit dem in eckige Klammern gesetzes Schlüsselsort [GROUP 1], gefolgt von einer beliebigen Zahl. In den folgenden Zeilen wird jeweils ein Parameter angegeben. Es sind insgesamt 62 Gruppen möglich. [Group 1] Tag= Gruppen Buchstabe (Groß- Kleinschreibung wird unterschieden, zulässig 0..9 A..Z a..z) Desc=FidoAreas Beschreibungstext der Gruppe AreaBaseTyp= Area Basetyp/Format fuer autom. anlegen, (J=Jam, S=Squish usw.) AreaPath= Verzeichnis in dem die Areas angelegt werden StartArea= Areanummer bei der begonnen wird nach einer freien Nummer fuer neu anzulegendes Area zu suchen UpLink= Uplink bei dem Areas fuer diese Gruppe bestellt werden koennen StatArea= Echotag in dem eine Tagesstatistik erstellt wird 5.7 Routing BBTROUTE.CFG ─────────────────────────────────────────────────────────────────────── Routing nennt man den Weg, den NETMAILS vom Absender zum Empfänger nehmen. Dafür muß auf jedem System korrekt angegeben werden, wohin die Netmails für die verschiedenen Empfängeradressen gesendet werden sollen/müssen. Das Routing kann entweder der Mailer übernehmen oder der Tosser. BBToss bietet die Möglichkeit Netmails an den Empfänger zu packen. BBToss arbeitet ohne weitere Angaben mit dem eingebauten Standard- routing. Dies unterstütz Point, Direkt-Node und Host-Routing. Damit BBToss die Netmail auch bei anderen Routingwegen an die korrekte Routeadresse packt ist in der Configdatei BBTROUTE.CFG eine entsprechende Routezeile einzugeben. Der Aufbau einer Routezeile in der Datei BBTROUTE.CFG sieht folgender maßen aus: 2:123/8765.0 2:123/8765 2:123/* 2:* -------------- ---------------------- an diesen Node Msg's die an eine dieser wird die Msg Nodenummer gerichtet sind geschickt werden gepackt Ersatzzeichen sind * und ?, wobei * für 0 - 65534 steht und ? genau für eine Zahl 0 - 9. z.B. 2:* meint alle Nodes in Zone 2 2:247/* meint alle Nodes im Netz 247 in Zone 2 2:248/50 meint Node 50 im Netz 248 in Zone 2 incl. seiner Points 2:248/5? meint Node 50 bis 59 im Netz 248 in Zone 2 !!! 2:248/5* ist unzulässig 2:249/5?? meint Nodes 500 bis 599 im Netz 249 in Zone 2 !!! 2:250/?00 meint Node 0, 100, 200, 300 bis node 900 (jedoch nicht Node 101, 123, 211 ....) !!! 2:250/1?0 meint Node 100, 120, 130 bis 190 (jedoch nicht 111, 121, 131 ....) Die Angaben in BBTROUTE.CFG werden von oben nach unten abgearbeitet, nach der 1. Übereinstimmung wird nicht nach weiteren Route-Anweisungen gesucht. Also 2:246/1000 2:246/* 2:200/0 2:* sendet alle Netmails mit Empfänger im Netz 246 and 2:246/1000, alle anderen Netmails mit Empfänger in Zone 2 and 2:200/0 !!! und so macht mans verkehrt !!! Aber 2:200/0 2:* 2:246/1000 2:246/* hier werden alle Netmails mit Empfänger in Zone 2 and 2:200/0 ge- sendet, die 2. Zeile wird erst garnicht mehr bearbeitet, da ja bereits alle Netmails mit Zone 2 gepackt sind. BBToss enthält ein voreingestelltes Routing, d.h. wenn nichts anderes in der BBTROUTE.CFG steht, - werden Netmails, die an direkte Up/Down-Links gerichtet sind auch direkt an diese gepackt (incl. für deren Points). - Hat man einen HOST (zone:net/0) als Link, werden Netmails für Nodes im gleichen Net (die nicht bei dir direkt downlinks sind) an den Host gepackt. - Netmails an Points werden mit in das Packet an den Boss-Node gepackt - Netmails an eigene Points werden direkt an diese gepackt Andererseits brauchen diese voreingestellten Routingregeln nicht in BBTROUTE.CFG aufgenommen zu werden. Eine Routinganweisung wie z.B. 2:2491/1077 2:2491/1077.* oder 2:2491/1077 2:2491/1077 kann weg- gelassen werden (wenn 2:2481/1077 ein in BBToss eingetragener Link ist). 5.8 Uplinkmanager BBTUPLNK.INI ─────────────────────────────────────────────────────────────────────── In der ASCII-Datei BBTUPLNK.INI werden die Systeme angegeben, an die bei Areabestellungen durch Downlinks eine automatische Area-Bestell Message gesendet wird, wenn die Area auf dem eigenen System nicht vorhanden ist. Es werden nur Bestellmessages von Downlinks an den Uplink weiter- geleitet, die das Flag "Areamgr ok" im Linkmanager gesetzt haben. Dateiaufbau von BBTUPLNK.INI: [UpLink1] ZONE= Zone der das bestellenden Systems angehoeren muss. AKA= Nodenummer des Uplinks, an den die Bestellung gesendet wird. GROUP= Gruppe welcher das neue Area zugeordnet wird. MGR= Der Name an den die Bestellmessage gesendet werden muss, Vorgabe ist AREAMGR. ECHOLISTFILE=ASCII Datei der bei diesem Uplink verfuegbaren Areas READLEVEL= Vorgabe fuer den Readlevel des neuen Areas WRITELEVEL= Vorgabe fuer den Writelevel des neuen Areas AREAMAXMSGS= Vorgabe fuer "Max Msgs" des neuen Areas AREADAYSOLD= Vorgabe fuer "Max Msg Alter" des neuen Areas Beispiel: [UpLink1] ZONE=2 AKA=2:246/100 GROUP=F MGR=Areafix ECHOLISTFILE=fidoarea.lst READLEVEL=0 WRITELEVEL=0 AREAMAXMSGS=0 AREADAYSOLD=0 [UpLink2] ZONE=49 AKA=49:70/0 GROUP=E MGR=Areamgr ECHOLISTFILE= READLEVEL=0 WRITELEVEL=0 AREAMAXMSGS=0 AREADAYSOLD=0 Bestellt Downlink 2:2488/1017 eine Area, die nicht vorhanden ist, so wird im Listfile 'fidoarea.lst' nachgeschaut ob der Areaname dort enthalten ist (also das Area vom Uplink besorgt werden kann). Wurde der Areaname gefunden, wird eine Bestellmessage an 2:246/100 generiert. Bestellt Downlink 49:70/306 eine Area, die nicht vorhanden ist, wird eine Message an Uplink 49:70/0 generiert. Da kein Listfile angegeben ist, wird jedes angeforderte Area bestellt. Bestellt Downlink 9:4000/1213 eine Area, die nicht vorhanden ist, passiert garnichts, er bekommt eine Antwortmail zurück, das die Area nicht verfügbar ist (da für Zone 9 kein Uplink definiert ist). Existieren für einen Uplink mehrere Arealisten, so ist einfach ein weiterer Eintrag einzufügen. z.B. [Uplink1] Zone=2 AKA=2:246/100 Group=F Mgr=Areafix Echolistfile=fidoarea.nat ... [Uplink2] Zone=2 AKA=2:246/100 ... Echolistfile=fidoarea.int ... Auch verschiedene Uplinks für die selbe Gruppe oder ein Uplink für verschiede können so eingetragen werden. Die Uplinkliste wird dann von oben nach unten abgearbeitet und das Area bei dem Uplink bestellt, in dessen Arealiste es zuerst gefunden wird. 5.8.1 Uplinkmanager Arealistdatei ─────────────────────────────────────────────────────────────────────── ASCII Datei, die alle Areanamen enthält, die bei diesem Uplink verfügbar sind und bestellt werden können. Wird kein Dateiname angegeben wird immer eine Bestellmessage an diesen Uplink gesendet. Wird hier eine Listdatei angegeben prüft BBToss ob die vom Link bestellte Area beim Uplink verfügbar ist (in der Liste enthalten ist). Wenn ja, wird die Area bestellt, wenn nein erhält der Link eine Nachricht, daß die Area nicht verfügbar ist. Format der Arealistdatei ARETAG BESCHREIBUNG ... .... Also eine Zeile pro Area beginnend mit dem Areanamen und optional eine Areabeschreibung (durch ein oder mehrere Leerzeichen getrennt, die Beschreibung darf Leerzeichen enthalten). 5.9 AliasNamen (BBTALIAS.CFG) ─────────────────────────────────────────────────────────────────────── In der Datei BBTALIAS.CFG wird pro Zeile ein Name eingetragen. Wenn Messages an diesen Namen gerichtet sind, wird eine Kopie der Message im Netmailfolder anlegt (wenn der Schalter PickAlias gesetzt ist, siehe BBTOSS.INI). In der Sharewareversion sind 100 Alias-Einträge möglich [+] (unregistered = 3 Namen) Groß-/Kleinschreibung wird bei den Namen nicht unterschieden, im Namen sind Leerzeichen zulässig (im Areanamen nicht). Soll die Message nicht in das Netmailverzeichnis des Mailers kopiert werden, so kann hinter dem Aliasnamen (durch Komma getrennt) ein anderes Area angegeben werden (AREANAME) in das die Mail kopiert wird (z.B. Sysop,MYMAIL). Diese Area muß dann aber in BBToss bereits eingerichtet sein. Das kopieren in das Netmailfolder des Mailers ist Default (bei gesetzem Flag) d.h. sollen die Msgs in Netmailfolder kopiert werden ist kein Areaname anzugegben. 5.10 Lock-Semaphore BBTOSS.BSY ─────────────────────────────────────────────────────────────────────── BBToss schreibt im Multilinemode bei jedem Start ein Semaphorefile BBTOSS.BSY ins BBToss Verzeichnis. Bei einem weiteren Aufruf über ein Netzwerk oder einen Multitasker erkennt der 2. Task, das der Tosser bereits läuft und bricht ohne weitere Operation ab. Nach Beendigung seiner Aufgabe löscht BBToss diese Semaphorefile. Ist der Multilinemode nicht eingeschaltet, wird das Busy-Semaphore nicht berücksichtigt. Sollte aus irgendeinem Grund ein Fehler aufgetreten sein (z.B.Stromaus- fall) löscht BBToss das Semaphorefile nach 2 Stunden. Dadurch wird sicher- gestellt, dass auch nach einem Fehler der Tossvorgang nicht dauerhaft blockiert ist. Soll aus irgend einem Grund BBToss während der Ausführung eines anderen Programms nicht ausgeführt werden, kann dieses Semaphore File auch von einem anderen Programm erstellt werden. Es sollte dann jedoch darauf geachtet werden, dass BBTOSS.BSY von diesem Programm auch wieder gelöscht wird. 6. Zusatzprogramme und Utilities ─────────────────────────────────────────────────────────────────────── Zu BBToss gibt es einige zusätzliche Utilities. BBTPOST - um Textfiles in Echoareas/Netmailareas zu posten BBTCLEAN - um die Messagebase zu packen (aufzuräumen) BBTCOST - eine einfache Costsharing Berechnung und Verwaltung 6.1 BBTCLEAN Messagebase aufräumen ─────────────────────────────────────────────────────────────────────── BBTCLEAN unterstützt in der derzeitigen Version das packen und renumbern von Hudson, JAM-Areas und Fido-Msg-Style Areas, die anderen Messagebase- arten werden in folgenden Versionen hinzugefügt. BBTCLEAN dient zum aufräumen der Messagebase, es entfernt alte oder gelöschte Messages aus der Messagebase. Dabei wird die in BBTCFG ein- getragene maximale Anzahl von Messages in den einzelnen Areas be- rücksichtigt und das Area auf diese Anzahl gekürzt (natürlich werden dabei die ältesten Messages zu erst gelöscht). Die Aufrufparameter von BBTCLEAN: INDEX PACK PACKALL PACKONE:areaname LINK mit Befehl PACK entfernt BBTCLEAN alle gelöschten Messages und kürzt die Areas auf die in BBTCFG angegebene maximale Anzahl von Messages. Dabei werden nur solche Areas bearbeitet, die mehr als die angegebene maximale Anzahl Messages enthalten. mit Befehl PACKALL werden alle Areas gepackt und dabei alle ge- löschen Messages aus den Areas entfernt. Dies ist sehr zeitaufwendig und wird einige Minuten in anspruchnehmen, daher wird für die tägliche Aufräumarbeit der Aufruf bon BBTCLEAN ohne Argumente empfohlen, da sich die Packarbeit dann auf die Areas beschränkt, die lt. Setup- einstellung (max. Anzahl Messages) gepackt werden sollen/müssen. mit Befehl INDEX wird (z.Zt nur JAM-Areas) für alle Areas der Index neu aufgebaut. Dies kann notwendig sein, wenn durch irgend einen Umstand der Index nicht korrekt ist, was sich in der Regel dadurch erkennen läßt, das z.B. nur eine Msg lesbar ist, obwohl wesentlich mehr Msgs in der Base sind. mit Befehl PACKONE:areaname kann gezielt ein angegebenes Area re- organisiert werden. Der Befehl wirkt wie PACKALL nur das eben ausschliesslich das angegebene Area bearbeitet wird. Der Befehl kann z.Zt. auf Jam- und Squish-Areas angewendet werden. Bei Hudson und *.MSG Areas hat er keine Wirkung. Beispiel: bbtclean.exe PACKONE:REQUEST.GER mit Befehl LINK werden die Messages verkettet (erzeugen der link-reply-chain). D.h. wurde in einem Echoarea eine Msg ge- schrieben und darauf geantwortet, verkettet BBToss die Msg's. Das Original erhält einen Verweis auf die Antwort und umgekehrt. Für die Verkettung verwendet BBTCLEAN die unsichtbar in den Msgs enthaltenen MSGID und REPLY Kludge Zeilen. LINK mit Parameter /NEW (also BBTCLEAN LINK /NEW) linkt nur Areas in denen beim letzten Tosslauf neue Messages eingetosst wurden. BBToss erstellt beim eintossen die Datei IMPORT.LOG in der alle Areas mit neuen Msgs aufgeführt sind. BBTClean greift auf diese und bearbeitet nur die in IMPORT.LOG angegebenen Areas. Die IMPORT.LOG Datei wird bei jedem Toss-Lauf neu erstellt, daher sollte LINK /NEW vor dem naechsten Toss-Lauf aufgerufen werden. Der Link Befehl kann als Befehl (1. Parameter von BBTCLEAN) oder als Parameter bei einen der PACK Befehle angegeben werden. Der Unterschied besteht darin, daß bei LINK als Befehl die Areas nur geLINKt wird, jedoch keine Msg gelöscht (gepackt) wird. Als Parameter (/LINK) wird der Linkprozess während des packens eines Areas mit erledigt. Bei allen Befehlen sind als Parameter /HMB /JAM /SQU /MSG zulässig. Wird kein Parameter angegeben, werden alle Messagebase-Formate be- arbeitet. Bei den Pack Befehlen kann /LINK zum linken der Messages angegeben werden. Wir ein oder mehrere Parameter angegeben, werden nur die Message- base-Formate bearbeitet, die in den Parametern angegeben sind. Beispiel: BBTCLEAN PACK /HMB packt nur die Hudsonbase BBTCLEAN INDEX /JAM /SQUISH für ein Reindex der JAM und Suish Areas durch BBTCLEAN PACKONE:FLEA.GER packt/reorganisiert das angegebene Area (nur Jam/Squish) BBTCLEAN PACK /LINK packt alle Areas die mehr Msgs ent- halten als configuriert und führt ein link (reply chain) für diese Areas aus BBTCLEAN LINK /NEW Linkt (reply chain) nur Areas in denen beim letzten Tossvorgang neue Messages hinzugekommen sind 6.1.1 BBToss und das Squishformat ─────────────────────────────────────────────────────────────────────── Beim erstellen eines Squishareas wird die maximale Anzahl und maximales Messagealter von BBToss fest in die Squishbase geschrieben. Waehrend des tossens wird darauf geachtet, dass die Base nicht groesser wird als angegeben und bei überschreiten der Werte während des tossens Messages entsprechend der Einstellungen gelöscht. Diese Anfangswerte werden während eines BBTCLEAN pack Aufrufes auf die aktuellen Einstellungen in BBToss geändert. Die gelöschten Messages verbleiben aber physicalisch in der Message- base und werden (dem internen Aufbau der Squishbase zufolge) ggf. durch neue Messages überschrieben. Gelegentliches Aufrufen von BBTCLEAN um die verbliebenen Teile gelöschter Messages zu entfernen macht somit auch beim Squish Format Sinn. Zur Pflege der Squishbase können auch die Tools aus dem original Squishpacket eingesetzt werden. Im einzelnen: SQSET.EXE - zum setzen der Werte 'max day', 'max mail', 'skip' SQPACK.EXE - zum Packen (physikalischen loeschen) SQFIX.EXE/SQREIDX.EXE - zum reparieren einer beschaedigten Squisharea diese Programme sind im Squishpaket von Dudley enthalten. zur Nachrichtenverkettung (linking) QQLink (separates Programm) Wer Timed benutzt ist fein raus, da genuegt es sqset, sqpack, sqfix und sqreidx im Pfad zu haben, und mit ALT-U Areaweise seine 'Pflege' waehrend/nach dem lesen zu erledigen. Das wichtigste ist das physikalische Packen, mit SQPACK *.sqd werden alle Squish Areas im momentan aktiven Directory gepackt, also keine Notwendigkeit sich komplexe Kommandozeilen- optionen zu merken ... Das interne Limit von BBToss fuer maximale Anzahl Messages pro Squish Area ist 5200 Messages. 7. Referenz: Mailerunterstützung ─────────────────────────────────────────────────────────────────────── Nach dem packen von neuen Mails werden für die verschiedenen Mailer entsprechende Semaphore Files geschrieben um den Mailer darüber zu informieren. Im einzelenen werden folgende Nachrichten (per Semaphore) an den Mailer übergeben Frontdoor --------- - Nach dem erstellen/auffülen von ARCMail-Packeten wird FDRESCAN.NOW neu geschrieben. - Vor dem Packen von Netmails wird auf Existenz von FDRENUM.* ge- prüft und falls vorhanden PACK nicht ausgeführt. Intermail --------- - Nach dem erstellen/auffülen von ARCMail-Packeten wird IMRESCAN.NOW neu geschrieben. McMail --------- - Nach dem erstellen/auffülen von ARCMail-Packeten wird MCMSCAN.ALL neu geschrieben. Xenia --------- - Nach dem erstellen/auffülen von ARCMail-Packeten wird XMRESCAN.FLG (wenn vorhanden) mit neuem Filedatum versehen (getouched). 8. Was BBToss nebenher erledigt ─────────────────────────────────────────────────────────────────────── Netmail-Verzeichnis -------------------- Wird im Netmailverzeichnis eine Msg (*.MSG) mit 0 Byte gefunden, wird diese sofort gelöscht. Denn das ist mit Sicherheit ein Fehler. Clean Outbound -------------- Beim 1. Aufruf eines Tages löscht BBToss alle 0 Byte ARCmail Archive und setzt die Messagezähler für "heute verarbeitete Messages" auf 0 (Der 1. Aufruf wird anhand des BBTOSS.LOG Datei-Datums ermittelt). Routingfehler ------------- Wurde eine Netmail mehrmals vom eigenen System weitergeleitet (3x) und kommt immer wieder zurück ("ping-pong Routing") wird diese Netmail als Badmail erkannt und an den Absender zurückgeschickt. 9. Nutzungsbedingungen ─────────────────────────────────────────────────────────────────────── Von Seiten des Autors wird keine Zusage auf Fehlerfreiheit gegeben. Für Beschädigung oder Verlust von Daten durch die Benutzung wird keine Gewähr übernommen. Jegliche Gewährleistungs- und Ersatzansprüche sind auf die Höhe der Registriergebühr beschränkt. 9.1 Registrierung ─────────────────────────────────────────────────────────────────────── Registrierung für BBToss beträgt : DM 25,- Registrierformular BBTOSS.REG liegt bei. 9.2 Open Beta Politik ─────────────────────────────────────────────────────────────────────── Der Autor erlegt keine Einschränkungen für das testen, verwenden und weitergeben von Betaversionen auf. Festgestellte Fehler sollten mir jedoch mitgeteilt werden. Es wird ausdrücklich darauf hingewiesen, daß Betaversionen (erkennbar an der Versionsbezeichnung "ßxxxx" wobei xxxx das Erstelldatum angibt) in der Regel neue und ungetestete Features enthalten. Ein sichern der Konfigdateien (alle *.CFG und *.INI Dateien im BBToss Verzeichnis) vor Einsatz einer Betaversion wird als selbstver- ständliche Testvoraussetzung angesehen. Die aktuelle Betaversion ist in verschiedenen Boxen unter Magic BBTBETA requestbar und im Internet auf Homepage http://members.aol.com/bbuelte/bbtoss.htm (Die jeweils offizielle Version unter Magic BBTOSS) 10. Autor ─────────────────────────────────────────────────────────────────────── Burkhard Buelte Fido: 2:2471/2402 (mail-only) 6328 Silverbrooke West e-mail: bbuelte@aol.com West Bloomfield, MI 48322 Homepage: USA http://members.aol.com/bbtoss.htm 11. Bisher bekannte Probleme ─────────────────────────────────────────────────────────────────────── Novell 3.12: (Mitteilung von: Wolfgang Blecker 2:2435/40) Das Programm verträgt sich nicht mit den alten Novell Shells (IPX+NETX). Versucht man, das Programm damit zu starten, erhaelt man die Fehlermeldung : "Fehler bei der Initialisierung." PKZIP/PKUNZIP Abhängig vom Speichermanager können Probleme beim Speicher Sharing mit PKZIP auftreten. Abhilfe bringt PKZIP Aufrufparameter -) ggf. zusätzlich -- -+ womit der Speicherbedarf von PKZIP eingeschränkt wird. NT 4.0 Bei sehr schnellen Rechnern (CPU Takt) kann beim starten von BBToss [DOS/DPMI] im DOS-Fenster unter NT ein Division durch Null (Runtime-Error 200) auftreten. Abhilfe: Erstellen eines ShortCuts fuer Prompt/Batch von dem BBToss aufgerufen wird. Markieren von "Compatible Timer Hardware Emulation". in den Properties/Einstellung des ShortCuts (ShortcutMenu: Properties->Program->Windows-NT-> ) Anhang A Fehlermeldungen ─────────────────────────────────────────────────────────────────────── Beim Aufruf der Packer können ggf. folgende DOS-Fehler auftreten Dosfehler Bedeutung Abhilfe 8 kein Arbeitsspeicher frei Packeraufruf überprüfen und begrenzen des Memory Bedarfs des Packers (insbesondere EMS und/oder XMS) Anhang B Message Kludges die BBToss unterstützt ─────────────────────────────────────────────────────────────────────── Kludges oder Kludge-Zeilen sind spezielle Zeilen in Messages die zu- sätzliche Informationen enthalten, die in der Regel nicht in den Standard Messagebase Headern enthalten sind. Nachfolgend eine Liste von Kludges die BBToss kennt, verwendet oder unterstuetzt. Generelle Regel (natürlich mit einigen Ausnahmen :-) ) der Kludge- Zeilen ist, dass sie am Anfang der Message stehen, mit dem Zeichen Ctrl-A (ASCII 1) beginnen (nachfolgend mit ^ gekennzeichnet). Kludges sollten/können in allen Messages enthalten sein. Einige sind nur bei Echomails, andere nur bei Netmails sinnvoll/üblich. Die meisten Editoren bieten einen Schalter um die Kludges einer Message anzuzeigen. AREA: Name des Echoareas ^FLAGS non Standard Message Flags ^FMPT Pointnummer des Absenders ^INTL Nodenummer des Absenders und Empfängers ^MSGID: Absender Nodenummer und Message Identifikation ^ORIGAREA: Ursprüngliches (Original) Area ^PATH: Liste der Systeme die diese Mail verarbeitet haben (nur Echomail, Netmail=Via mit selber Funktion). Gibt somit Informationen welchen Weg die Message vom Ab- sender zum Empfänger tatsächlich genommen hat. ^PID: Programm Identifikation (üblicher Weise Programm mit dem die Msg erstellt wurde) ^REPLY: Zeigt an, dass sich diese Message auf eine andere bezieht, also eine Antwort ist und enthält die Informationen des MSGID Kludges der Original Message. ^REPLYADDR: Adresse an die eine Antwort auf dies Message gesendet werden sollte. ^REPLYTO: Name an die eine Antwort auf diese Message gesendet ^REPLYTO werden sollt. ^RESCANNED Kein Parameter, Existenz zeigt an, das die Msg per Area Rescan versendet wurde SEEN-BY: Liste von Nodenummern an die diese Message gesendet wurde. ^TID: Tosser Identifikation ^TOPT Empfänger Pointnummer ^Via Kennung und Datum der Systeme von denen die Msg be-/ verarbeitet wurde (nur Netmail) * Origin: Übliche letzte Textzeile in einer Echomail mit angabe eines Beliebigen Textes und der Nodenummer