Die Nachrichten selbst werden jeweils in einer eigenen Datei abgelegt. Der Dateiname entspricht den im Kapitel Verzeichnis- und Datei-Struktur erwähnten Gepflogenheiten.
Die ersten vier Zeilen einer Nachricht haben organisatorische Bedeutung. Sie werden beim Auslesen der Nachricht grundsätzlich nicht ausgegeben, sondern ausgewertet.
Im Unterschied zu den rein maschinell erzeugten Dateien LIST.BCM und CHECK.BCM können die Nachrichten selbst sehr wohl editiert werden. Auch die Form ist relativ tolerant.
Erste Zeile der Nachricht:
HUMOR < OE3DZW DB0LNA @DL $04B4OE3DZW0E #30 %!#!!2 =!!! |B!!!!!!!!!!!!!!!
Im Prinzip haben die Felder in dieser Zeile exakt die gleiche Bedeutung wie in LIST.BCM. Allerdings wird hier nicht nach Feldlänge ausgewertet, sondern nach den entsprechenden Operatoren (``<'', ``@'', ``$'', ``%'', ``#'', ``='', ``|'') gesucht. Die Reihenfolge ist absolut unerheblich, ebenso die Feldlänge. Blanks dürfen an jeder Stelle eingefügt werden. Dadurch kann jede Nachricht problemlos per Hand editiert und umgebaut werden, es können sogar Nachrichten händisch erzeugt und gelöscht werden.
Die Anzahl der Zeilen und Bytes (nach dem ``%''-Operator) hat rein
informativen Charakter, sie wird nicht überprüft und anderweitig
verwendet, sondern nur beim Befehl READ ausgegeben. Bei der Anzahl der
Bytes wird bei AutoBIN-Mails die Länge des BIN-Anteils, bei Text-Mails
nur die Nachricht selbst, also ohne R:-Zeilen angegeben. Dadurch ist die
angezeigte Größe der Nachricht nicht von der Länge des
Forward-Weges abhängig. Der Operator ``='' kennzeichnet den Offset des
AutoBIN-Teils der Mail, ``=!!!'' bedeutet, daß die Mail keinen
AutoBin-Teil enthält. (Kodierung: ``!'' entspricht 0, jede Stelle
läuft von 0-127 (7 Bit); 7+7+7=21 Bit entsprechen einem maximalen
Zahlenwert von 2097151 (``unsigned int'' in C), das ist also der maximale
Offset). Mit dem Parameter ``|'' werden 16 Byte-Flags markiert.
Die 2. Zeile betrifft das Forwarding:
DB0WGS OE1XAB OE5XEM* ............
In dieser Zeile stehen Boxrufzeichen, zu denen die Mail geschickt werden soll bzw bereits geschickt wurde. Ein * hinter jedem Rufzeichen bedeutet, daß die Mail bereits geschickt wurde.
Wichtig ist, daß die Zeile mit einer hinreichend großen Anzahl von Platzhaltern beschrieben ist, da auf die Zeile im Laufe des Forwardingbetriebes schreibende Zugriffe erfolgen, um die Rufzeichen zu markieren. Als Platzhalter sind entweder Blanks oder Punkte zulässig.
Ein ``*'' am Anfang der Forwardzeile markiert die Nachricht als gelöscht.
In der 3. Zeile wird vermerkt, wer die Nachricht bereits gelesen hat. Das Format ist ähnlich wie bei den Forwardcalls, es wird allerdings nur ein Blank zwischen den Rufzeichen freigelassen. Als Platzhalter werden auch hier Punkte verwendet. Diese Zeile hat eine Länge von 79 oder 252 Zeichen (je nach Version).
In der 4. Zeile steht der Betreff der Nachricht. Dieser darf im Prinzip beliebig lang sein, muß jedoch in einer Zeile stehen.
In der 5. Zeile steht ``From:'', gefolgt vom Absendercall und Call der Box, in der die Mail eingegeben wurde:
From: <absender-call> @ <boxadr>
Stimmt die Absendermailbox <boxadr> nicht mit der MyBBS des Absenders überein, d.h. wird die Mail nicht von der MyBBS aus gesendet, so wird eine zusätzliche Zeile eingefügt:
Reply-To: <absender-call> @ <absender-mybbs>
Beim Empfang einer Mail wird der Name in der From-Zeile ausgewertet und falls der Name des Absenders im USERS.BCM noch nicht bekannt ist, dort eingesetzt. Das Rufzeichen <absender-call> in dieser Zeile muß mit dem Absenderrufzeichen übereinstimmen, sonst wird der Name ignoriert. Es wird neben ``From:'' auch ``de '' (DieBox) ausgewertet.
In der nächsten Zeile steht ``To:'', gefolgt vom Empfängercall und der vollständigen Empfängeradresse.
Wird die Nachricht im User-S&F empfangen, so wird eine Zeile
X-Info: Received in User S&F from OE3DZW at OE3XSR.#OE3.AUT.EU
eingefügt. Wird die Mail von einem User eingespielt, der sich an der Einspielbox kein Loginpaßwort gesetzt hat, so wird eine Zeile
X-Info: No login password bzw. X-Info: No upload password
zusätzlich eingefügt. Die X-Info-Zeilen werden beim Empfang nicht ausgewertet.
Die nächste Zeile ist immer eine Leerzeile.
Hinweis: In früheren Versionen war die Länge des Headers fix, damit war die Leerzeile (und damit der Beginn des Inhalts der Mail) ebenfalls fix in der 8. Zeile.
In der nächsten Zeile beginnt der Inhalt der Nachricht.
Zusammengefaßtes Beispiel:
HUMOR < OE3DZW ~ DB0LNA @DL $04B4OE3DZW0E #30 %!#!!2 =!!!
DB0WGS OE1XAB OE5XEM .......................................bis Pos. 79
............................................................bis Pos. 252
Langweiliger Titel
R:941104/0119z @:OE3DZW.#OE3.AUT.EU [BayCom-Mailbox] bcm1.39
From: OE3DZW @ OE3DZW.#OE3.AUT.EU (Dietmar)
To : HUMOR @ DL
Reply-To: OE3DZW @ OE1XAB.#OE1.AUT.EU
X-Info: No login password
Eine kurze Mail <CR><LF>
Eine Mail mit einem AutoBIN-Teil hat ein ähnliches Aussehen:
HUMOR < OE3DZW @OE3XSR.#BAY.DEU.EU $04B4OE3DZW0F #123 %!#!!, =!%}
DB0WGS .....................................................bis Pos. 79
............................................................bis Pos. 252
Ein kurzweiliger Titel
R:941104/0120z @:OE3DZW.#OE3.AUT.EU [BayCom-Mailbox] BCM1.39
From: OE3DZW @ OE3DZW.#OE3.AUT.EU (Dietmar)
To : HUMOR @ OE3XSR.#BAY.DEU.EU
Das ist der Text einer binären Mail.<CR><LF>
#BIN#10#|43301<CR><NUL><NUL>...<NUL> Bis Position 80
1234567890 Direkt anschließend folgt der binäre Teil der Nachricht
<NUL> = 0x00, <CR> = 0x0D, <LF> = 0x0A
Beim Empfang von Mails wird die Zeichenfolge ``//e '' am Zeilenanfang erkannt und der erste ``/'' gegen ``\'' ersetzt. Dies soll die Verbreitung von Mails unterbinden, die Terminals durch den ``//ECHO''-Befehl dazu veranlassen, beliebige Befehle an die Mailbox zu schicken.
Seit der Version 1.30 ist in die Box ein zur DieBox kompatibles AutoBIN eingebaut.
Unter ``binären'' Mails werden Nachrichten verstanden, welche eine beliebige Zeichen in einer beliebigen Reihenfolge enthalten dürfen. Das Übertragungsprotokoll beruht darauf, daß die Dateilänge am Anfang der Übertragung angegeben wird. Die Datei selbst wird transparent übertragen.
Der Befehl SEND hat die gleiche Syntax wie bisher. Wird jedoch ein
``<CR>#BIN#'' im Datenstrom erkannt, sucht die BayCom-Mailbox nach Zahlen
von 0-9, die nach dem zweiten # folgen. Die damit dargestellte Anzahl von
Zeichen wird eingelesen und sodann die Datei geschlossen.
Die generelle Zeichensequenz zur Einleitung eines AutoBIN-Transfers lautet:
<CR>#BIN#<länge>#|<CRC>#Dateiname<CR>
Verbindlich ist dabei allerdings nur das ``#BIN#'' sowie die Längen-Angabe. Der Dateiname wird nicht ausgewertet, sondern transparent durchgereicht.
Beispiel:
S OE3DZW BINTEST<CR>
Es folgt ein kurzer Binärteil<CR>
(Hier startet der Benutzer die AutoBIN-Übertragung bei seinem Terminalprogramm, der Rest geht automatisch.)
-> Terminal-Programm: <CR>#BIN#10#|23412#$1234567#C:\BOX\TEXTE\BIN.EXE<CR>
-> Box: #OK#<CR> (nicht im S&F)
-> Terminal-Programm: 123456789<CR> (Das sind genau zehn Zeichen!)
Wichtig: Die ``#BIN#''-Sequenz wird komplett gespeichert, die BayCom-Mailbox wertet aber nur die in der Sequenz übermittelte Anzahl von Zeichen und die CRC aus. Die Sequenz ist auf eine Zeile beschränkt und muß mit einem <CR> (HEX 0D) abgeschlossen werden. Das nächste Zeichen nach dem <CR> ist das erste Zeichen des Binärteils. Die Anzahl der Zeichen des Binärteils muß unmittelbar nach der ``#BIN#''-Sequenz folgen und darf nur die Ziffern '0' bis '9' enthalten. Bei jedem anderen Zeichen wird die Auswertung der Längenangabe abgebrochen.
Die CRC wird nach einem von DC4OX in den Boxen veröffentlichten Verfahren berechnet. Wurde keine CRC mitgesendet, so wird von der BayCom-Mailbox diese selbständig berechnet und hinzugefügt. Falls die berechnete mit der übermittelten CRC nicht übereinstimmt, so wird eine Fehlermeldung ausgegeben und die Nachricht nicht abgespeichert.
Das 16 Bit-Prüfpolynom bietet nur einen recht beschränkten Schutz gegen Übertragungsfehler. Es können damit Einzelbitfehler nur bis zu einer Größe von 8 kB sicher erkannt werden. Bei größeren Dateien können Einzelbitfehler unerkannt bleiben, die erreichte Übertragungssicherheit ist jedoch immer noch höher als ohne jede Prüfsumme, zumal meist nicht Einzelbitfehler auftreten, sondern von Digis oft Teile von Paketen verschluckt werden - womit es zur ``Fehlersicherung'' ausreicht die Dateilänge zu vergleichen - und diesen Zweck erfüllt das 16 Bit-Polynom.
In den Mail-Dateien wird der Binär-Start in der Headerzeile nach dem Operator ``='' im komprimierten Format angegeben. Am Binärstart ungleich ``=!!!'' (entspricht 0) erkennt man eine AutoBIN-Mail. Sie darf keinesfalls mit einem Editor bearbeitet werden, da sonst evtl. der Inhalt oder der Offset nicht mehr paßt. Am Beginn des eigentlichen Binärinhalts wird die #BIN#...-Zeile gespeichert und auf insgesamt 80 Zeichen mit <NUL> (nicht blank) aufgefüllt.
Der Titel im LIST.BCM ist mit dem Zusatz ``(BIN)'' versehen. Dadurch unterscheidet sich der Titel im LIST.BCM von dem in der Nachricht selbst. Der Zusatz ``(BIN)'' wird auch nicht geforwardet.
Hier ein für die Berechnung der Prüfsumme Implementierungsbeispiel in 'C':
/*
* CCITT Polynom x^16 + x^12 + x^5 + 1
*
* hier im Gegensatz zu CCITT, (A)X.25:
* - Datenbyte MSB zuerst
* - CRC-Start mit 0
* - keine Multiplikation Nachricht mit x^16
* (CRC wird bei Empfang nicht über CRC-Bytes berechnet)
* - kein Invertieren des CRC
*
* wird z.B. benutzt von: UoSat DCE, SEVEN
*/
unsigned crctab[256];
unsigned crc;
unsigned byte; /* Datenbyte, high Byte = 0 ! */
/*
* entweder beim Programmstart einmal aufrufen,
* oder die 512 Byte Tabelle einmal ausrechnen lassen und dann als
* initialisierte Tabelle ins Programm übernehmen
*/
void init_crctab(void)
{ unsigned n;
unsigned m;
unsigned r;
unsigned mask;
static unsigned bitrmdrs[] = { 0x9188,0x48C4,0x2462,0x12*,
0x8108,0x4084,0x2042,0x1021 };
for (n = 0; n < 256; ++n)
{ for (mask = 0x0080, r = 0, m = 0; m < 8; ++m, mask >>= 1)
if (n & mask) r = bitrmdrs[m] ^ r;
/*
* ``if (n & mask) r ^= bitrmdrs[m];'' ist kürzer, aber
* manche Compiler übersetzen das falsch
*/
crctab[n] = r;
}
}
/*
* byteweiser Algorithmus, C, portabel
*/
void do_crc(void)
{
crc = crctab[crc >> 8] ^ (crc << 8 | byte);
}
Hier ist die meiste Arbeit durch die Terminalprogramme zu erledigen.
Von der BayCom-Mailbox aus ist das Auslesen einer Nachricht mit Binärteil kaum anders als das normale Auslesen einer Nachricht. Sie erkennt intern den binären Zustand und unterbindet damit jegliche Unterdrückung nicht erwünschter Zeichen. Das ist alles!
Wichtig für Programmierer von Terminal-Programmen: Die ``<CR>#BIN#...''-Sequenz kann auch über Framegrenzen hinweg beim Terminalprogramm ankommen kann. Die Terminalprogramme sind verantwortlich für die Erkennung der Sequenz und haben entsprechende Vorbereitungen zu treffen, um den Binärteil auf die Festplatte zu schreiben.
Wichtig ist für den Binärteil nur das <CR>#BIN#<NUMMER><CR>. SP z.B. benutzt noch weitere Elemente, die auch mit ausgesendet werden, sie sind für die eigentliche Übertragung des Binärteils aus der Sicht der Mailbox jedoch ohne Belang.
Wichtig ist weiterhin, daß vor dem Binärteil einer Nachricht noch ein beliebiger anderer Text erscheinen kann. Die Terminalprogramme müssen also auf die #BIN#- Sequenz warten, und dürfen den Status nicht ändern, es sei denn, der Benutzer verlangt es.
Es kann immer nur ein Binärteil in einer Nachricht übermittelt werden.
Den Abschluß des Binärteils bildet die Zeichenfolge <CR>#OK#<Prüfsumme><CR> der von der Box ausgesendet wird (nicht im S&F).
Falls das Terminalprogramm ``#OK#'', ``BIN-RX'' oder ``BIN-TX'' aussendet, so wird dies von der Box ignoriert.
Die Option ``-X'' beim READ von AutoBIN-Mails bewirkt, daß nur der
Textteil der Nachricht ausgegeben wird. Das Lesen und Schreiben einer
AutoBIN-Mail kann nicht abgebrochen werden.
Binäre Nachrichten werden genauso wie gewöhnliche Text-Nachrichten entsprechend der Eintragungen im FWD.BCM weitergeleitet. Beherrscht die Nachbarbox AutoBIN nicht, so wird eine Nachricht erzeugt, welche angibt, wo die AutoBIN-Mail liegt.
Aktiviert wird AutoBIN beim Forward durch eine der Bedingungen:
Ist eine der Forward-Partner der eingenen Box eine DieBox, so ist bei dieser DieBox in der Datei MBSYS\SFWID.BOX folgender Eintrag zu machen:
BayCom-1.1 18 S BayCom-1.2 18 S BayCom- 19
Damit ist sichergestellt, daß ab der BayCom-Mailbox 1.30 auch der Forward von AutoBIN-Mails funktioniert.
Wird beim Forward ein CRC-Fehler erkannt, so wird dieser durch das Prompt ``|>'' statt ``>'' gekennzeichnet. Die Mail wird dann bis zu vier mal wiederholt.
Das Forward-Protokoll wurde nie definiert. Ausgehend von W0RLI's Mailbox [7] wurden von mehreren Autoren div. Prokollvarianten entwickelt. In der BayCom-Mailbox wurden die Erweiterungen von DF3AV, F6FBB und DL8HBS [2] implementiert.
Das in der BayCom-Mailbox implementierte Forwardprotokoll ist zumindest zu folgenden Mailboxsystemen kompatibel: W0RLI, DieBox, FBB, DP-Box, MSYS, diverse TNC-Minimailboxen. In [11] befindet sich eine ausführliche Beschreibung des FBB und DieBox-Protokolls.
Nach dem Verbindungsaufbau beim Forward tauschen die beiden Mailboxen Zeichen aus, welche als SID (System IDentifier) bezeichnet werden. Dieser SID dienet zum Aushandeln des Forwardprotokolls. Das beim anschließenden Forward verwendete Protokoll wird durch die Menge der von beiden Forward-Partnern unterstützen Features bestimmt. (Minimalkonsens).
Der System-Identifier ist folgendermaßen strukturiert:
``[f1-f2-f3]''
Die Bindestriche (-) kennzeichnen das Ende des ersten Felds und den Anfang des letzten Felds.
f1, f2 und f3 dürfen die Zeichen ``['' oder ``]'' nicht enthalten.
f1 ist die Identifizierung für den Autor der Software.
f2 enthält softwarespezifische Daten. Es kann enthalten, was sich der Autor wünscht, zum Beispiel die Versionsnummer der Software. Dieses Feld darf Bindestriche (-) enthalten.
f3 ist das Set von unterstützen Features. Es darf keine Bindestriche enthalten. Es enthält einen String von nicht-numerischen Zeichen, jeweils ein Zeichen für ein von der Box unterstützem Feature. Jedes Zeichen kann auch von Ziffern gefolgt werden, diese geben die Revisionsnummer des Features an. Das Fehlen der Ziffer(n) ist mit der Revisionsnummer 0 gleichzusetzen.
Die BayCom-Mailbox sendet folgendes SID:
[BayCom-1.42-AB1D1FHMRW$]
^Unterstützte Features
^Versionsnummer
^Name der Software
Das Feature D ist wie folgt definiert:
Der Buchstabe D wurde von DL8HBS vorgeschlagen, er bedeutet so viel wie ``D''L8HBS oder ``D''ieBox. Die D-Features werden derzeit von folgenden Mailboxen verwendet:
Die Existenz des SIDs impliziert, daß das System die Richtung des Forwards ändern kann und OK/NO-Meldungen erzeugt.
Die BayCom-Mailbox wertet jedes empfangene SID aus. Bei der BayCom Mailbox wird untersucht, ob das $-Zeichen in der SID enthalten ist. Falls nicht, erfolgt ein Disconnect, weil Systeme ohne BID nicht unterstützt werden.
Im SID anderer Boxen kann es auch folgende Zeichen geben:
Einige Beispiele von SIDs:
Sende den SID in der ersten Zeile nach dem Connect. Beantworte den SID (wenn er empfangen wurde) mit einem kurzen Kommandoprompt ``>''.
Wenn ein SID beim Connect empfangen wurde, antworte mit dem SID der eigenen Box.
Das verwendete Protokoll ergibt sich aus der Schnittmenge der SIDs der beiden Forward-Partner.
Mit diesem Befehl wird eine Nachricht gesendet.
Sx TO [@ BBS[.LOC]] [< FROM] [$BID/MID]
x kann A, B, T oder P sein. Wenn x fehlt, so wird P angenommen, falls TO ein Rufzeichen ist, ansonsten wird ein B angenommen. Das Dollarzeichen $ ist kein Teil der MID, es kennzeichnet das Feld. Zwischen dem ``$''-Zeichen und der BID darf kein Leerzeichen sein. Die Leerzeichen rund um den Klammeraffen @ können weggelassen werden. Beim User S&F muß das FROM-Feld mit dem Rufzeichen des Forward-Partners übereinstimmen. ST-Mails werden nicht angenommen.
Die andere Box wird als Antwort auf das SEND-Kommando eine OK/NO/REJ-Meldung
erzeugen, welche möglicherweise von irgendeinem Text gefolgt wird. Wenn
die Antwort NO oder REJ ist, so wird sie von einem Prompt gefolgt. Wenn die
Antwort OK ist, so muß der Forward-Partner (also jener, der SEND
gesendet hat) die Mail forwarden. Normalerweise wird NO nur gesendet, wenn
versucht wurde, eine Mail weiterzuleiten, deren BID bereits dem Empfangssystem
bekannt war. REJ wird dann gesendet, wenn die Empfangsbox wegen eines
Routingfehlers die Mail nicht annimmt. Eine solche Mail wird dann in die Datei
TRACE/SFHOLD.BCM eingetragen. Eine Abfrage ist mit dem Befehl
SFHOLD möglich.
Von den Meldungen ``NO'', ``REJ'' und ``OK'' muß jeweils nur der erste Buchstabe (``N'', ``R'', ``O'') angegeben werden.
Zur Kompatibilität mit W0RLI/DP-Box werden noch folgende Antworten unterstützt:
Wenn mit OK geantwortet wurde, sendet die Nachbarbox die Nachricht. Die erste Zeile der Nachricht ist der Nachrichten-Titel. Die weiteren Zeilen sind der Text der Nachricht. Die Nachricht wird durch <CR><Ctrl-Z><CR> beendet, von der empfangenden Mailbox wird durch ein Linefeed und das Prompt (``>'') der Empfang bestätigt. Darauf wird von der sendenden Box eine weitere Nachricht angeboten.
Falls keine Nachrichten mehr zum Forward bereitliegen, wird ``F>'' statt ``>'' als Prompt gesendet. Damit tauschen sendende Box und empfangende Box ihre Rolle.
Wenn auch diese Box keine Nachricht mehr anzubieten hat, beendet sie das Forward durch das Senden der Zeichenfolge ``***done''.
Um Kompatibilität zu den DieBox-Systemen zu gewährleisten, wurde
zusätzlich zum Befehl DIR NEWS der Befehl CHECK eingebaut.
Dieser Befehl liest aus der Datei CHECK.BCM, die chronologisch aufgebaut
ist und dasselbe Format hat wie die Board-Listen LIST.BCM in den
jeweiligen Verzeichnissen der Boards.
CHECK.BCM wird neu erzeugt, wenn es fehlt oder fehlerhaft ist. Dazu
werden von allen Boards die Dateien LIST.BCM aneinandergereiht. Sind die
Listen alle eingelesen, so wird die Datei lexikalisch sortiert. Dieser Vorgang
kann nicht im RAM, sondern muß auf der Festplatte erfolgen, da die Datei
sehr groß werden kann (bei 30000 Mails ca. 4 MB). Der Sortiervorgang
wird deshalb sehr lange dauern (je nach Rechner/Datenbestand bis zu einer
Stunde) und erfolgt nur, wenn es unbedingt notwendig ist. Ein absichtliches
Erzeugen von CHECK.BCM ist mit dem Befehl REORG C möglich.
Bei der Ausgabe des Befehls CHECK wird vom Ende zum Anfang hin gelistet.
Da zum Zeitpunkt der Auflistung die Nummer einer Mail innerhalb eines Boards
nicht bekannt ist, wird die Datei CHECKNUM.BCM angelegt. In dieser
Datei ist zu jeder in CHECK.BCM aufgelisteten Mail die Position der
Mail innerhalb ihres Boards abgespeichert.
Über die Mailboxsoftware wird ein Task-Scheduler gelegt, der folgende Eigenschaften hat: