Crawly Crypt Collection 1

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

/ Crawly Crypt Collection 1 / crawlyvol1.bin / bbs / ecu_200 / ecu.doc < prev next >

Wrap

Text File | 1993-02-07 | 38KB | 783 lines

****** ***** ****** ****** ** ** ** ** ** **** ** ** ** ****** ***** ***** ** ** ****** *** ****** ***** ** ** ** ****** *** ** ** ** ** ** *** ** ** ** ** ** *** ** ** ** ** ** ** ** ** ** ** ** ** ** ****** ****** ****** ****** **** ****** ***** ***** ***** *** E x p o r t & C r u n c h Version 2.00 (basierend auf Ecu 1.09 von Heinz Ozwirk) by Patrick Seemann 2:301/701.29@fidonet 7. Februar 1993 Grundsätzliches ECU ist Freeware. Jeder darf es für den privaten Gebrauch benut- zen und kostenlos weitergeben. Die Verbreitung durch Mailboxen ist zulässige, wenn dafür keine zusätzliche Gebühr verlangt wird. Der Vertrieb durch PD-Versender bedarf meiner schriftlichen Zu- stimmung. Jeder Anwender ist für den Schaden, der ihm durch ECU entsteht, oder den er mit ECU anrichtet, selbst verantwortlich. Fehlermel- dungen und/oder Verbesserungsvorschläge nehme ich aber gerne ent- gegen. Ich verspreche aber nicht, daβ ich sie auch berücksichti- gen werde. Allgemeines ECU ist als Ersatz von ComScan, Export, Bye und Crunch für ST- Points gedacht. Dabei arbeitet ECU bevorzugt mit LED und Binkley- Term zusammen. Einen anderen Editor kann man vermutlich verwen- den, wenn er das gleiche Dateiformat wie LED verwendet. Binkley durch The-Box zu ersetzen kann dagegen problematisch werden, da die beiden Mailer unterschiedliche Dateinamen voraussetzen. Voraussetzungen ECU benötigt zum Betrieb einen Atari-ST (1MB bevorzugt), eine Harddisk (es soll immer noch Leute geben, die mit einem Floppy- Laufwerk versuchen einen Point zum Laufen zu bringen), LED als Message-Editor (notfalls geht es auch mit Pandora), LHARC (oder ein beliebiges anderes Kompressionsprogramm) und BinkleyTerm oder The-Box (ab Ecu 1.06) als Mailer. Installation Bei der Installation setzen wir einmal einen funktionierenden Point voraus. Dann ist die gröβte Hürde bei der Installation von ECU bereits überwunden. Alles, was dann noch zu tun bleibt, ist: - Kopieren Sie ECU.PRG auf die Festplatte zu den ganzen anderen Point-Programmen. - Starten Sie LED, und überzeugen Sie sich, daβ die Option `Skip ComScan' nicht aktiv ist. LED darf Echo-Mails nicht in die Netmail Area kopieren. - Erstellen Sie die Datei ECU.CFG. Sie muβ sich im gleichen Ver- zeichnis wie ECU.PRG befinden. Vorteile von ECU - ECU ist zuverlässig. Im Gegensatz zu ComScan hat es mir noch nie - nicht einmal in der Testphase - die Platte zerschossen. - ECU kann Areas für mehrere Hosts verwalten. - ECU unterstützt 4d-Adressierung, und kann sie fast beliebig mit 3d-Adressen mischen. - ECU erzeugt Flow-Files wahlweise für BinkleyTerm oder The-Box. Nachteile von ECU - ECU ist langsamer als Export oder Bye. Dafür werden die Areas aber - wie bei ComScan - auch gleich komprimiert. Dies ist mir die etwas längere Laufzeit wert. Die Konfigurationsdatei In der Konfigurationsdatei werden die Hosts und die Areas be- schrieben. Aus dieser Datei erfährt ECU welche Mails für welchen Host bestimmt sind, und was mit den Mails zu tun ist. Die Be- schreibung dieser Datei befand sich bisher an dieser Stelle. Da die gleiche Datei aber auch von anderen Programmen verwendet wird, und ich keine Lust habe den Aufbau dieser Datei immer wie- der zu beschreiben, (vor allem bei Änderungen wird das lästig, wenn man in vielen Dateien immer die gleichen Änderungen vorneh- men muβ) habe ich beschlossen, für die Konfigurationsdatei eine eigene Beschreibung zu machen. Diese Beschreibung befindet sich in der Datei CFG.TFM. Sie gehört zur Dokumentation aller Program- me, die diese Konfigurationsdatei verwenden. Parameter in der Kommandozeile Einige Parameter können auch in der Kommandozeile angegeben wer- den. Diese Parameter haben in der Regel höhere Priorität als die entsprechenden Anweisungen in der Konfigurationsdatei. Statt mit / können Optionen auch mit - eingeleitet werden. flags können die Werte yes (1), no (0) und toggle annehmen. Es ist nur das jeweils erste Zeichen relevant. name Ein Filename ohne weitere Zusätze bezeichnet die zu lesende Konfigurationsdatei. Wenn keine Datei beim Aufruf angegeben wird, lieβt ECU die Datei ECU.CFG. /? Das Programm gibt einen Kurzen Hilfstext aus. Danach wird das Programm sofort abgebrochen. Die übrigen Parameter und die Konfigurationsdatei werden nicht mehr verarbeitet. Statt -? kann auch nur ? verwendet werden. /Cflag Hiermit kann das Komprimieren der Header- und Message-Files ein- und ausgeschaltet werden. Mit /Cyes werden Header- und Message-Files komprimiert. Dies entspricht dem Verhalten, wenn in ECU.CFG Compress angegeben wurde, aber nicht NoCrunch. Mit /Cno werden weder die Message- noch die Header-Files kompri- miert. Es werden auch keine alten Mails gelöscht. Dies ent- spricht dem Verhalten, wenn in der Konfiguartionsdatei No- Crunch aber nicht Compress angegeben wurde. /Dflag Mit dieser Option kann der Dupe-Checker ein- und ausgeschaltet werden. mit /Dyes wird er eingeschaltet, mit /Dno wird er aus- geschaltet. /Dtoggle kehrt den aktuellen Zustand um. Default ist /Dyes. /Fflag Ecu kann gezwungen werden, auch dann ein Flow-File zu erzeu- gen, wenn an einen Host nichts geschickt werden muβ. Auf diese Weise kann man BinkleyTerm zwingen dort anzurufen, ohne daβ Mail für den Host vorhanden ist. Mit /Fyes werden für alle Hosts Flow-Files erzeugt, mit /Fno nur für die Hosts, an die wirklich etwas geschickt werden muβ. /Ftoggle kehrt die Wir- kung von DummyFLO um. Default if /Fyes. Auch das Verhalten des /F-Schalters beim Aufruf von Ecu wurde leicht verändert. Wenn /F oder /F1 angegeben wurde, wird für alle Hosts ein Flowfi-le erzeugt. Wenn dabei für einen Host ein gepacktes oder ungepacktes Paket erforderlich ist, wird es erzeugt. Für Hosts, bei denen DummyFLO nicht angegeben wurde, oder für die Flowfiles mit `DummyFLO 0' abgeschaltet wurden, wird ein Flowfile aber kein Paket erzeugt. Wenn /F0 angegeben wurde, werden - unabhängig von den Angaben in der Konfigura- tionsdatei - keine Flowfiles erzeugt. /Lfilename Der Name des Log-Files wird festgelegt. Alle Meldungen werden in die Datei 'filename' geschrieben. Default ist BT.LOG. /Mloglevel Damit wird die Ausführlichkeit der Fehlermeldungen bestimmt. Zur Zeit sind nur die Werte 0 - keine Ausgabe ins Log-File - und 1 - alles ins Log-File sinnvoll. /Qflag Mit dieser Option kann QuickScan ein- und ausgeschaltet wer- den. Mit /Qyes wird QuickScan eingeschaltet.2 Mit /Qno wird QuickScan abgeschaltet, und mit /Qtoggle wird der bisher ein- gestellte Zustand umgedreht. Default ist /Qno. /Pflag Mit dieser Option werden die Areas unabhängig von der Anzahl der gelöschten oder exportierten Mails gepackt. Die Header werden komprimiert, wenn sie mindestens einen gelöschten Ein- trag enthalten, und alle Lücken in den Message-Files werden geschlossen. Das Crunch-Limit in den Areas (s. Crunch) wird ignoriert. Diese Option wird mit /Pyes (bzw. /P)eingeschaltet. /Wflag Das Verhalten von Ecu bei Fehlern bestimmt. Mit /Wyes hält ECU bei einem Fehler an und wartet auf eine Eingabe des Benutzers. Mit /Wno werden Fehler nur in das Log-File eingetragen, und das Programm - wenn möglich - fortgesetzt. /Wtoggle kehrt die Wirkung von NoPause um. Default ist /Wyes. Funktionen von ECU ECU liest die Header aller Areas und entscheidet an Hand der Message-Flags und des Datums, was mit der Mail gemacht werden soll. - Mails, die älter sind als die angegebene Anzahl von Tagen, werden gelöscht, es sei denn bei ihnen ist das HOLD- oder LOCAL-Flag gesetzt. Die Überprüfung des HOLD- bzw. LOCAL-Flags kann mit den Befehlen KillHold bzw. KillLocal in der Area- Beschreibung für einzelne Areas abgeschaltet werden. - Mails, die nach dem Senden gelöscht werden können, und die be- reits gesendet wurden, werden gelöscht. Eine als 'Kill if Sent' markierte Mail wird erst beim nächsten Aufruf von ECU nach dem Exportieren dieser Mail gelöscht. Nicht bei dem Auf- ruf, bei dem sie exportiert wurde. - Mails, bei denen das LOCAL-Flag gesetzt ist, werden expor- tiert. Dies kann durch setzen des HOLD-Flags verhindert wer- den. Als gelöscht markierte Mails werden natürlich nicht ge- sendet. Das LOCAL-Flag wird von LED bei allen eingegebenen Meldungen gesetzt. Bei importierten Mails ist das Flag ge- löscht. Es scheint daher ausreichend sicher zu sein, die Ent- scheidung über das Senden von diesem Flag abhängig zu machen. - Mails, bei denen das DELETE-Flag gesetzt ist, werden aus der Header-Datei entfernt. Wenn solche Mails gefunden werden, dann wird die Area auf jeden Fall komprimiert. Unabhängig davon, ob Compress selektiert wurde oder nicht. - Wenn das From-Feld im Header leer ist, trägt Ecu ein ? ein. LED betrachtet einen Header ohne Absender als Dateiende und zeigt die folgenden Mails nicht an. Eigentlich sollte ja der Import schon für richtige Message-Header sorgen, aber so lange das nicht der Fall ist, ist dies immer noch die beste Lösung. Wenn also der Verdacht besteht, daβ LED nicht alle Mails an- zeigt, sollte man Ecu einmal aufrufen bevor in die verdächtige Area neue Mails geschrieben werden. Aus einer exportierten Mail werden zuerst alle Kontrollinforma- tionen am Anfang und Ende der Mail entfernt. Diese Informationen werden neu erzeugt. Vor dem Text der Nachricht werden die folgenden Informationen eingefügt: - Wenn der Empfänger ein Point mit 4d-Adresse ist, wird eine TOPT-Zeile erzeugt (nur Netmail). - Wenn der Absender ein Point mit 4d-Adresse ist, wird eine FMPT-Zeile erzeugt (nur Netmail). - Wenn die Zone des Empfängers nicht mit der Zone des Hosts übereinstimmt, wird eine INTL-Zeile erzeugt (nur Netmail). - Bei einer Echo-Mail wird die AREA-Zeile erzeugt. - Die Message-Id wird erzeugt. Im Anschluβ an die eigentlich Nachricht folgen in einer Echomail noch - die Tearline - das Origin - das SEEN-BY - der Path (nur mit 3dPath in der Konfigurationsdatei) In der Meldung selbst kann ECU weiche Zeilenenden erzeugen. Dabei nimmt ECU an, daβ ein weiches Zeilenende vorliegt, wenn unmittel- bar vor dem Zeilenende ein Leerzeichen oder ein Divis steht. Die Übersetzung kann für jede Area eingestellt werden. Auch innerhalb einer Mail kann die Übersetzung ein- und ausgeschaltet werden. Wenn eine Zeile ein >-Zeichen enthält, wird vor und nach dieser Zeile immer ein hartes Zeilenende erzeugt. Ecu nimmt an, daβ es sich bei solchen Zeilen um Quotes handelt, und die sollten besser nicht verändert werden, da das erfahrungsgemäβ meistens unschön aussieht. Wenn eine Zeile in der Mail mit einem Punkt beginnt3, wird diese Zeile nicht ausgegeben, sondern als Befehl an ECU interpretiert. Zur Zeit sind die folgenden Kommandos implementiert: .h hard returns Ab sofort werden keine weichen Zeilenenden mehr erzeugt. .i include Der Rest der Zeile wird als Dateiname interpretiert. Der In- halt dieser Datei wird an Stelle dieser Zeile in die Mail ein- gefügt. Die eingefügte Datei ist in LED nicht sichtbar. .p Signatur unterdrücken Wenn für die Area, in der die Mail steht, eine Signatur defi- niert ist, wird diese in dieser Mail nicht erzeugt. .p kann irgendwo vor der Tearline stehen. .s soft returns Ab sofort dürfen weiche Zeilenenden erzeugt werden. .t tearline An Stelle dieser Zeile wird eine Tearline eingefügt. Notwendig wurde dieser Befehl, da einige AreaFix's eine Tearline erwar- tet, ECU sie aber entfernt und in einer Netmail nicht wieder einfügt. Netmail-Routing Echoareas werden in der Regel nur über einen Host geroutet. Da war die Entscheidung also leicht, jeder Area einen Host zuzuord- nen. Bei Netmails sieht es allerdings etwas anders aus. Es muβ die Möglichkeit bestehen, jedem Host eine Netmail zu schicken. Der erste Versuch dieses Problem zu lösen bestand in einer eige- nen Netmail-Area für jeden Host. Grundsätzlich funktioniert dies, es traten aber auch einige Probleme damit auf. Eine Alternative dazu ist eine Netmail-Area, in der man angeben kann, über welchen Host die Mail laufen soll. Mittlerweilen beherrscht ECU beide Va- rianten. Probleme sind dabei noch nicht aufgetreten, dafür sind aber einige überraschende Features entstanden. Eine eigene Netmail-Area für jeden Host hat den Vorteil, daβ es einfach zu programmieren ist, und daβ der Anwender auch recht gut die Übersicht behält, was über welchen Host läuft. ein Nachteil ist allerdings, daβ LED nur eine Netmail-Area unterstützt. In al- len anderen Areas ist der Anwender selbst dafür verantwortlich, daβ die richtige Adresse in den Header gelangt. ECU erlaubt es daher in der FROM- bzw. TO-Zeile auβer dem Namen noch die Adresse anzugeben. Die Adresse steht hinter dem Namen und wird durch @ vom Namen getrennt4. Diese Adresse ersetzt die von LED bzw. ECU eingetragene Adresse. Als Adresse kann auch ein in der Konfigura- tionsdatei definiertes Alias verwendet werden. Bei Netmails setzt ECU die Adresse des Absenders als Zieladresse ein. Wenn dann eine falsche (oder keine) Adresse in der TO-Zeile steht, kommt die Mail an den Absender zurück. Er weiβ dann wenigstens, daβ sie nicht angekommen ist. Es hat aber auch Vorteile nur eine Netmail-Area für alle Hosts zu verwenden. Man kann dann von einigen nützlichen Eigenschaften LEDs gebrauch machen, und man kann so ziemlich sicher sein, daβ alle Mails irgendwann ankommen. Ein Nachteil ist, daβ man bei ei- ner Mail angeben muβ, über welchen Host sie laufen muβ. Wenn man dies versäumt, kommt die Mail allerdings auch irgendwann einmal an - es sei denn, es handelt sich um eine Mail an AreaFix. Bei dieser Methode sollte man die Netmail-Area dem Host zuordnen, über den die meisten Netmails laufen. Durch einen Zusatz in der Subject-Zeile kann eine Netmail aber zu jedem Host geleitet wer- den. Dazu genügt es die Host-Adresse (oder ein Alias) in eckigen Klammern an den Anfang des Subject-Zeile zu schreiben. Zur Auswahl des günstigsten Hosts verwendet Ecu das folgende ver- fahren: - Wenn das Crash-Flag im Message-Header gesetzt ist, wird die Mail direkt an den Empfänger geschickt. Ist der Empfänger ein Point, so wird die Mail an seinen Bossnode geschickt. Dazu muβ die 4d-Adresse des Points angegeben werden. Wenn eine Fakenet- Adresse angegeben wurde, muβ diese Adresse in der Nodelist stehen, da BinkleyTerm das Paket nicht verschicken kann. Crashmail ist nur in der eigenen Zone möglich. - Wenn die Subject-Zeile einer Netmail einen Host in eckigen Klammern enthält, wird die Netmail an diesen Host geschickt. Der Host muβ in ECU.CFG definiert sein. Sonst wird die Mail an den Host geschickt, der die dem hier angegebenen Host ähnlich- ste Adresse hat (also im gleichen Netz oder wenigstens in der gleichen Zone liegt). - Wenn die Netmail an einen in der Konfigurationsdatei angegebe- nen Host oder an einen Point eines solchen Hosts gerichtet ist, wird sie direkt an den Host geschickt. - Wenn ein Host im gleichen Netz wie der Empfänger bekannt ist, wird die Mail an diesen Host geschickt. - Wenn keine der zuvor angegebenen Methoden zum Erfolg führt, wird die Mail an den Default-Host der Area geschickt. Tick-Files Tick-Files sollen das Versenden von Dateien erleichtern. Dazu wird auβer der eigentlichen Datei noch eine zusätzliche Datei übertragen, die Informationen über die Primärdatei enthält, und die vom empfangenden Rechner automatisch ausgewertet werden kann. So ist es dann möglich, daβ eine Datei automatisch in die Fileba- se des Empfängers aufgenommen wird, und allen Usern des Systems zur Verfügung steht, ohne daβ der Sysop eingreifen muβ, wie es bei einem normalen File-Attach notwendig ist. Auf dem ST gibt es meines Wissens zur Zeit ein Programm, das Tick-Files unterstützt, nämlich Stick&Hatch von Joop Koopman. Dieses Programm funktioniert zwar ganz ordentlich (wenn man ein- mal davon absieht, daβ Binkley die erzeugten Files nicht sieht), aber irgendwie war es mir immer etwas unklar, was da so alles ab- geht, und warum gerade das, was ich wollte, nämlich Fileareas mit unterschiedlichen Hosts austauschen, zwar so tut als ob es funk- tioniert, ich es aber irgendwie doch nicht zum Laufen kriege.5 Als ich anfing mir zu überlegen, wie man mit LED und ECU Tick- Files verschicken könnte, vielen mir recht schnell zwei Varianten ein. Beide haben ihre Stärken und Schwächen, so daβ ich mich schlieβlich entschloβ beide zu implementieren. Das Echomail-Konzept In dieser Variante setzt ECU für jede Filearea eine eigene Echomail-Area voraus. Das hat den Vorteil, daβ alle Informationen über die Area im Konfigurationsfile einmal definiert werden kön- nen, und das sich der Benutzer um die Details kaum noch kümmern muβ. Wenn man aber nur in Ausnahmefällen Files in eine Area schicken will, dann ist es natürlich schon etwas umständlich, wenn man diese Area erst einrichten muβ. Für diese Fälle ist das Netmail-Konzept etwas besser geeignet, aber noch geht es hier um das Echomail-Konzept. Eine Tick-Area wird wie eine Echo-Area definiert. In der Area- Beschreibung wird lediglich angegeben, daβ es sich um eine Tick- Area handelt (s. Tickarea) und welches Passwort verwendet werden soll (s. Password). In AREAS.BBS muβ die Area natürlich auch de- finiert werden, sonst wird sie von LED nicht erkannt. Wenn nun ein File in diese Filearea geschickt werden soll, so schreibt man in der Area einfach eine Mail an den Sysop des Hosts, an den man diese Area sendet. Als Subject wird der voll- ständige Dateiname, also ruhig mit Laufwerk und Pfad, angegeben. Die Mail selbst muβ eine Zeile enthalten, die mit dem Tick-Prefix und dem Schlüsselwort Desc beginnt. Der Rest dieser Zeile sollte die Datei kurz beschreiben. Alle Zeilen, die nicht mit dem Tick- Prefix beginnen, werden als Netmail an den Host dieser Area ge- schickt. (Daher sollte möglichst der Sysop als Empfänger angege- ben werden.) Das Netmail-Konzept In der zweiten Variante gibt es keine Areas, die wie Echoareas aussehen, in Wirklichkeit aber Netmails erzeugen. Vielmehr wird hierbei die Mail an den Empfänger tatsächlich als Netmail mit File-Attach geschrieben. Im Unterschied zum normalen File-Attach wird vor dem Dateinamen ein spezielles Zeichen, der Tick- Indicator, angegeben. ECU erzeugt dann, wie beim Echomail- Konzept, zum Primärfile ein Tick-File. Allerdings fehlen ECU in diesem Fall ein paar Informationen, die in der Netmail angegeben werden müssen. Die Netmail muβ, auβer der Desc-Zeile, auch noch die Area enthal- ten. Diese Zeile beginnt mit dem Tick-Präfix, gefolgt von dem Schlüsselwort Area und einem Wortzwischenraum oder Doppelpunkt. Danach folgt der Name der Filearea, wie sie beim Empfänger be- kannt ist. Beim Versenden eines Files geht man ähnlich wie im Echomail- Konzept vor. Man muβ nur zusätzlich die Area und den Empfänger angeben. Vorsicht ist geboten, wenn ein File nicht direkt ver- schickt wird, sondern aus versehen mit der normalen Netmail ge- routet wird. Die beteiligten Sysops finden es bestimmt nicht lu- stig. Daher sollten solche Mails immer als Crashmail verschickt werden. AREAS.BBS Die Datei AREAS.BBS wird benötigt, um die Reihenfolge der Areas, in der sie in LASTREAD.CED stehen, zu bestimmen. Ab Version 1.01 kann ECU auch die übrigen Angaben dieser Datei auswerten. Das ge- naue Format dieser Datei scheint nirgendwo dokumentiert zu sein. Daher soll hier eine kurze Beschreibung folgen, welches Format Ecu von dieser Datei erwartet. - Leerzeilen und Zeilen, die mit einem Semikolon beginnen werden ignoriert. Vor dem Semikolon darf jedoch kein anderes Zeichen, auch kein Leerzeichen, stehen. - Am Dateianfang werden alle Zeilen, die nicht mit einem Divis (-) beginnen, ignoriert. Normalerweise sind dies der Systemna- me und der Default-Origin. Die erste dieser Zeilen ist das Default-Origin. ECU benutzt dieses Origin bis eine -ORIGIN Zeile auftritt. Wenn in ECU.CFG schon Origins definiert waren, so werden sie durch das Default-Origin ersetzt. - Zeilen, die mit einem Divis beginnen werden ignoriert. Diese Zeilen enthalten in der Regel den Bossnode, Origins oder die Anzahl der Tage, die eine Nachricht im System bleiben soll. Ecu erhält dies Informationen aus ECU.CFG, kann aber auch die Informationen aus AREAS.BBS verwenden. In diesem Fall werden -DAYS und -ORIGIN ausgewertet. Die Angaben gelten für alle folgenden Areas. - In allen anderen Zeilen erwartet Ecu mindestens drei durch Leerzeichen und/oder Tabs getrennte Bestandteile - den Namen der Areadatei, den offiziellen Namen und den Host für diese Area. Ab Ecu 1.08 bzw. Llegada 1.03 werden mehr Informationen aus ARE- AS.BBS übernommen. Die Anzahl der Ausnahmen in ECU.CFG wird da- durch verringert. Im Einzelnen werden jetzt die folgenden Anwei- sungen erkannt. -ORIGIN text Der angegebene Text wird als Origin an alle Mails in dieser Area angehängt. Wenn als Text das Schlüsselwort -RANDOM auf- tritt, wird ein zufälliger Text aus der Origin-Datei gewählt. (s. Globale Anweisungen, Origin). -DAYS n m Empfangene Mails, die älter als n Tage sind werden gelöscht. Lokale Mails werden nach m Tagen gelöscht. m kann entfallen. In diesem Fall wird die Zeit aus ECU.CFG übernommen. -CRUNCH high low crunch Die Höchst- und Mindestzahl von Mails in der folgenden Area wird definiert. high gibt an wieviele Mails maximal in der Area bleiben dürfen, low bestimmt die Anzahl von Mails, die immer in der Area bleiben. Mit crunch kann angegeben werden, wieviele Änderungen (gelöschte oder exportierte Mails) erfor- derlich sind, um Ecu zum Packen der Area zu bewegen. Diese An- weisungen entspricht den Befehlen HighLimit, LowLimit und Crunch in ECU.CFG. -PASSWD pw Ein Passwrt für die Area wird definiert. Dise Anweisung ist nur für Tick-Area von Bedeutung. -SIGNATURE filename Der Inhalt der angegebenen Datei wird an das Ende jeder Mail in der folgenden Area geschrieben. Dies entspricht der Signa- ture-Anweisung in AREAS.BBS. -FLAGS flags... Für flags können KillLocal, KillHold, NoOutput und TickArea angegeben werden. Die Flags entsprechen den entsprechenden An- weisungen in ECU.CFG. Wie in ECU.CFG kann den Flags auch hier ein Ausrufezeichen vorangestellt werden. Das entsprechende Flag wird dann gelöscht, und nicht aktiviert. Zwischen Ausru- fezeichen und Flag dürfen keine anderen Zeichen stehen. Mehre- re Flags können auf einmal definiert werden. Sie müssen mit Leerzeichen oder Tabs voneinander getrennt werden. Anhang A - Beispiel-Mails FROM: Bustopher Jones@4:71/1 TO: Mr. Mistoffelees@5:18/0 SUBJ: [1:234/56]Test ----------------------------------------------------------------- Diese Mail geht an M.M. mit Adresse 5:18/0. Sie wird über den Host 1:234/56 geroutet. Sie wird aber nicht mit B.J.s Adresse bei 1:234/56 gesendet, sondern mit 4:71/1. Wozu auch immer das gut sein mag. .t Die vorherige Zeile erzeugt eine Tearline (---) in der Mail. Der darauf folgende Text könnte verloren gehen. FROM: Bustopher Jones TO: Mr. Mistoffelees SUBJ: [HoG]Test ----------------------------------------------------------------- .h MM> Quotes sollten immer mit harten Zeilenenden versehen werden, MM> da der Empfänger sonst beim Umbrechen noch mehr Unheil an- MM> richten könnte als er eh schon tut. .s In der eigentliche Mail können weiche Zeilenenden verwendet wer- den. Hier ist es im Allgemeinen egal wo der Empfänger eine neue Zeile beginnt. In Tabellen oder Programmfragmenten sollte man na- türlich mit harten Zeilenenden arbeiten. '.h' und '.s' erzeugen keine Leerzeile. Daher nach '.s' die extra Leerzeile. Setzt man die Konfigurationsdatei aus Anhang A voraus, werden alle Netmails über 2:249/6 [Spam] geroutet. Durch [HoG] in der Subject-Zeile wird diese Mail jedoch über 2:247/32 geroutet. Als Absender wird auch die entsprechende Fakenet Adresse (2:24000/9323) in den Message-Kopf eingetragen. Anhang B - Return-Codes Dieser Abschnitt ist für diejenigen interessant, die ECU in einer Batchdatei verwenden. ECU liefert beim Programmende einen Fehler- code, der Aufschluβ über das Vorliegen und evtl. über die Art ei- nes Fehlers gibt. Die folgenden Return-Codes können derzeit auf- treten: 0 kein Fehler ECU hat keine Fehler erkannt und ist bis zum Ende durchgelau- fen. 1 Fehler beim Laden des Resource-Files Dieser Fehler sollte eigentlich nicht auftreten, da das Re- source-File ein Teil des Programms ist. 2 ECU wurde mit /? aufgerufen Es liegt zwar kein Fehler vor, aber trotzdem hat ECU seine Ar- beit nicht getan, nämlich die Areas nach zu sendenden Mails zu durchsuchen. 3 Abbruch durch Benutzer Nach ein Fehler, nach dem ECU noch hätte weiter arbeiten kön- nen, hat der Anwender das Programm mit `Abbruch' verlassen, 4 Konfigurationsdatei nicht gefunden ECU hat die angegebene Konfigurationsdatei (oder ECU.CFG) nicht gefunden. 5 Zu wenig Speicher ECU hat nicht genug Speicher um alle Area- und Host-Beschrei- bungen oder eine Mail zu laden. Dieser Fehler ist eher unwahr- scheinlich und deutet auf ein internes Problem in der Spei- cherverwaltung hin. Wenn es nach einem Reset funktioniert, war es wohl tatsächlich ein Fehler in der Speicherverwaltung. Wenn auch Reset nichts hilft, dann liegt es wohl doch an einer sehr langen Mail. 6 Fehler in Konfigurationsdatei Das kann fast alles bedeuten. Vielleicht wurden 3d-Adressen gewählt, aber keine Fakenet-Adresse angegeben. Die Fehlermel- dung im Logfile sollte mehr aussagen. 7 Systemfehler Ein Fehler bei einer Systemfunktion ist aufgetreten. Viel- leicht hat ECU eine Datei nicht gefunden, oder die Platte ist voll, oder was auch immer. Auch hier sollte das Logfile nähe- res sagen. Anhang C - Änderungen 1.00 ---> 1.01 - Einführung der Default-Area (s. Default), - Übernahme der Daten aus AREAS.BBS (s. UseAreas), - wählbares Trennzeichen zwischen Name und Adresse (s. Addres- sPrefix) 1.01 ---> 1.02 - Programmkennzeichen vor Anweisungen (s. E:), - Löschen von Schaltern (s. !), - Statistik in Logfile, - Fehler beim Suchen eines passenden Hosts behoben, - Fehler beim Löschen alter Cludges behoben, - Verhindern von Netmails an einzelne Hosts (s. NoNetmail), - optionales Routing von Echomails (s. RouteEchos) 1.02 ---> 1.03 - Strategie zum Suchen eines passenden Hosts leicht verändert, - Korrektur des Flow-File-Eintrags, wenn als Outbound-Directory ein absoluter Pfad oder ein Laufwerk angegeben wird, - Dupe-Checker etwas schneller - Fehler bei zu langen Verweilzeiten korrigiert - andere Prioritäten bei der Übernahme von Daten aus AREAS.BBS - kein Leerzeichen mehr in AREA-Line - das neue Format für Last-Read-Pointer von LED 1.00 wird unter- stützt (s. LedNew) - für ArcMail Pakete werden andere Dateinamen verwendet, die Na- men können auch vom Anwender bestimmt werden. (s. ArcmailName) - 3dAddress wird nur noch für die Paket-Header verwendet. Für Message-Header wurden 3dNetmail und 3dEchomail eingeführt. 1.03 ---> 1.04 - ECU und LLEGADA greifen auf gemeinsame Routinen und Daten zu. - Tick-Files können erzeugt werden. - Crunch kann abgeschaltet werden. - Es ist einstellbar, wieviele Mails mindestens in einer Area bleiben sollen. 1.04 ---> 1.05 - QuickScan Modus, in dem nur die Areas untersucht werden, deren Header- oder Message-Files geändert wurden. - Meldungen statt in Log-File in eine wählbare Message-Area 1.05 ---> 1.06 - Flow-Files für The-Box können erzeugt werden. (s. CreateTB) - Mails können direkt in andere Zonen geschickt werden. (UseZones, DefaultZone) - Crashmail wird immer mit 4d-Adressen verschickt. - Als Default für Crunch wird 1 angenommen, statt bisher 0. So wird nicht auch dann die Messagebase komprimiert, wenn keine gelöschten Mails vorhanden sind, und kein Minimum angegeben wurde. - 3dMsgId funktioniert jetzt. - Crashmail funktioniert jetzt auch, wenn beim Outbound- Directory ein vollständiger Pfad angegeben wurde. - Es kann eine maximale Anzahl von Mails in einer Area angegeben werden (s. HighLimit) 1.06 ---> 1.07 - Die Generierung der INTL-Zeile kann erzwungen werden (s. For- ceIntl) - ECU kann beim Start durch Drücken der Alternate-Taste angehal- ten werden - Ein potentieller Fehler beim Exportieren der Mails wurde beh- oben. - Entgegen der Behauptung beim Update auf 1.06 wurde Crashmail doch nicht 4d verschickt. Jetzt wird in den Message-Header die korrekte 4d-Adresse eingetragen. Die Adresse im Paket richtet sich nach den Angaben für den Default-Host. - ECU kann in jeder Mail den Text für die Origin-Zeile zufällig aus einer Textdatei wählen (s. RandomOrigin, und Origin) - Für jeden Host kann ein Komprimierungsprogramm angegeben (s. ArcPack) 1.07 ---> 1.08 - Wenn in einer Area das NoOutput-Flag gesetzt ist, braucht für diese Area kein Host angegeben werden. - Zeilen, die mit einem TickIndicator beginnen, werden nur noch in Tick-Mails gelöscht. In normalen Mails bleiben sie - wie es eigentlich sein sollte - erhalten. - Weiche Zeilenenden werden nicht mehr erzeugt. Led fügt am Ende einer Bildschirmzeile kein Zeilenende mehr ein. Also braucht Ecu daraus auch keine weichen Zeilenenden zu machen. Falls noch jemand mit Led 0.10 arbeitete, dann wäre jetzt vielleicht der Augenblick gekommen, auf eine neue Version umzusteigen. - In Mails kann eine Signatur eingefügt werden (s. Signature) - Include-Dateien können in Mails eingefügt werden. - Das Received-Flag wird beim Exportieren nicht gelöscht. - Die Zonennummer in TB-Flow-Files wird - wie bei Crashmail - als Extension an den Namen des Outbound-Directories angehängt. - Wenn zu einem TB-Flow-File das passende Binkley-Flow-File nicht angelegt oder geöffnet werden kann, wird das TB-Flow- File nicht mehr gelöscht. - Bei ArcPack können die Paket- und Bundle-Name angegeben wer- den. - Beim Exportieren wird die Absenderadresse nur noch geändert, wenn es eine bekannte Pointadresse ist, die als 3d- oder 4d- Adresse in einer Host-Definition angegeben wurde. - Dummy-Flowfiles können für jeden Host einzeln erzeugt werden. - Crashmail kann komprimiert werden (s. PackCrashmail) - Für jeden Host kann angegeben werden, wie genau seine Adresse mit einer Netmail-Adresse übereinstimmen muβ, damit die Net- mail über diesen Host geroutet wird. (s. MatchMin) - In AREAS.BBS kann als Origin der Text -RANDOM angegeben wer- den. Ecu trägt dann einen zufällig gewählten Text aus der Origin-Datei in Mails in die so gekennzeichneten Areas ein. - Zusätzliche (bzw. geänderte) Optionen in AREAS.BBS: -DAYS (er- weitert), -CRUNCH, -PASSWD, -SIGNATURE, -FLAGS. - Hexadezimale Extension des Outbound-Directories für andere Zo- nen. - Domain-Directories werden unterstützt. In der Msgid wird, falls vorhanden, die Domain angegeben.