Table of Contents

Previous Chapter

5. Realisierung der PC/Novell-Anbindung

Bei den Mail-Servern werden die Bereiche NetWare und UNIX getrennt betrachtet, um die jeweils nötigen Installationsschritte auf den entsprechenden Rechnern besonders herauszustellen. Im Bereich der Mail-Clients werden nur die hier relevanten PCClients betrachtet. Dabei steht die Anbindung bzw. Konfiguration auf NGM im Vordergrund, da die Konfiguration für Mercury (SMTP) als Standardkonfiguration angesehen wird.

5.1 Anbindung mit Mercury

Als Client auf den Arbeitsplatzrechnern werden hierbei überwiegend PMail und WinPMail eingesetzt. Es stehen aber auch Mail-Clients wie FirstMail, Mail von Novell und Groupwise aus dem WordPerfect-Office-Paket zur Verfügung. Diese Programme sind allerdings zum größten Teil bereits überholt und sollten daher nicht mehr eingesetzt werden. Für den Mail-Client MS-Mail stand kein entsprechender Protokoll-Treiber zur Verfügung.

5.1.1 Voraussetzungen

• Ein eigenes Class B oder Class C IP-Netz
  
• Einhergehend damit ein eigener Domainname
  
• korrekt konfigurierter Domain Name Service
  
• Routing der IP-Pakete durch einen IP-Provider, z. B. DFN
  

DFN-Verein e. V.
Pariser Str.44
10707 Berlin

Telefon: +49 30 884299-22
Telefax: +49 30 884299-70
E-Mail: dfn-verein@dfn.d400.de

NTG Netzwerk und Telematic GmbH
Geschäftsbereich Xlink
Vincenz-Prießnitz-Str.3
76131 Karlsruhe

Tel.: 0721/9652-0
Fax: 0721/9652 210
E-Mail: info@xlink.net

EUnet Deutschland GmbH
Emil-Figge-Str. 80
D-44227 Dortmund

Tel. +49 (0)231 972-00
Fax +49 (0)231 972-1111
Hotline: +49 (0)231 972-2222 (Mo.-Fr. von 09:00 bis 12:00 und von 13:00 bis 17:00 Uhr)
E-Mail: postmaster@Germany.EU.net

5.1.2 NetWare-Seite

SET MAXIMUM PHYSICAL RECEIVE PACKET SIZE=2048

Da Mercury zwei Methoden bietet, Nachrichten zu verwalten, ist nun zu entscheiden, welches Interface optimalerweise eingesetzt werden soll. Im Falle des Rechenzentrums fiel die Wahl auf die Verwaltung via Queues, da die Dimensionierung von RAM und Rechenleistung der Server ausreichend groß waren.

Mercury verwendet eine NetWare-Queue, um Mails zu verwalten. Diese muß bereits existieren, bevor Mercury geladen wird. Man kann sie wie eine normale Printer-Queue mit PCONSOLE anlegen, z. B. eine Queue mit dem Namen MAILQUEUE. Anschließend muß nur noch ADDQ.EXE (aus dem Mercury-Archiv) ausgeführt werden, um den Benutzer SUPERVISOR als zulässigen Bediener für die Warteschlange einzutragen. Dadurch kann Mercury die Queue über die Verbindung (Connection) 0 ansprechen. Das Kommando lautet ADDQ <queue_name>, z. B.:

ADDQ MAILQUEUE

Die Vorbereitungen sind nun abgeschlossen, und man kann die eigentliche Installation durchführen. Dazu müssen die drei NLMs (MERCURY, MERCURYC und MERCURYS) und die Datei MERCURY.INI nach SYS:SYSTEM des entsprechenden Servers kopiert werden. Wenn die POP3-Unterstützung von Mercury genutzt werden soll, so ist auch das NLM MERCURYP.NLM nach SYS:SYSTEM zu kopieren. Nun ist noch ein Verzeichnis SYS:SYSTEM/MERCURY anzulegen, in das die restlichen Dateien aus dem Mercury-Archiv kopiert werden.

Im Archiv ist eine einfache Batch-Datei MINSTALL.BAT enthalten, welche die Kopierarbeit übernehmen kann. Bevor man sie ausführt, muß sichergestellt sein, daß man sich in dem Verzeichnis befindet, in das das Mercury-Archiv entpackt wurde. Dann ist einfach MINSTALL einzugeben. Bei Verwendung von MINSTALL ist zu beachten, daß es versucht SYS:SYSTEM auf das Laufwerk K: zu legen. Falls dieses bereits belegt ist, muß die Batch-Datei abgeändert werden.

Nun ist die Konfigurationsdatei MERCURY.INI an die entsprechende Umgebung anzupassen. Die mitgelieferte Beispieldatei kann dabei als Vorlage dienen. Meist sind nur geringfügige Modifikationen vorzunehmen.

Die Datei ist in mehrere Abschnitte unterteilt, für allgemeine Einstellungen, einzelne Module und Sektionen für Adreßumformung, Domain-Umsetzung und Gruppenbeschränkung. Eine vollständige Datei MERCURY.INI ist im Anhang D.1 zu finden. Es werden auch nur die wichtigsten Optionen in den einzelnen Abschnitten erläutert, eine vollständige Beschreibung erhält man in [9]. Im Folgenden werden nun die Abschnitte der Konfigurationsdatei MERCURY.INI beschrieben.

1. Allgemeine Einstellungen:
   

[General]

myname:  rzi.ngate.uni-regensburg.de    # Canonical name for this server
timezone:  +0100                        # Time Zone to add to date fields
mailqueue:  MAILQUEUE                   # Queue: where mail is submitted by PMail
smtpqueue:  MAILQUEUE                   # Queue: where outgoing mail should be placed
                                        # note: smtpqueue and mailqueue can be the same

• 
  
  • myname
    Rechnername und Domain des File-Servers
    
  • timezone
    Zeitzone, die Mercury an den Date:-Header anhängt (max. 10 Zeichen)
    
  • mailqueue, smtpqueue
    Name der jeweiligen Queue, die verwendet werden soll (kann auch dieselbe Queue sein)
    
    

1. Modulspezifische Einstellungen
   
   1. Der Abschnitt für das Mercury-Modul:
      

[Mercury]

failfile:  SYS:SYSTEM/MERCURY/FAILURE.MER    # Delivery failure notification template
confirmfile:  SYS:SYSTEM/MERCURY/CONFIRM.MER # Delivery confirmation template
aliasfile:  SYS:SYSTEM/MERCURY/ALIAS.MER     # System-wide alias file
synfile:  SYS:SYSTEM/MERCURY/SYNONYM.MER     # User synonym database
listfile:  SYS:SYSTEM/MERCURY/LISTS.MER      # List of lists
logfile:  SYS:SYSTEM/MERCURY/MERCURY.LOG     # Traffic logging file 
#bitnethost:  rrzs1.rz.uni-regensburg.de     # Relay host for ".bitnet" rewrites
poll:  10                                    # Seconds between queue polling cycles
scratch:  SYS:SYSTEM/MERCURY                 # Where we can write temp files
switch:  2                                   # number of ms to yield per op on heavy I/O
returnlines:  15                             # How many lines of failed messages to return
postmaster:  SUPERVISOR                      # NetWare UIC of postmaster

• 
  
  • failfile, confirmfile
    Schablonen für Fehler- bzw. Bestätigungs-Meldungen (Beispieldateien werden mitgeliefert)
    
  • aliasfile
    Datei mit Mail-Aliases für vollständige Adressen; ein solches Alias wird mit MALIAS.EXE erzeugt; die Datei kann auch upgedatet werden, während Mercury läuft; Beispieldatei ALIAS.SRC (siehe Anhang D.4) wird mitgeliefert.
    
  • synfile
    Datei mit Synonymen für Benutzernamen; Synonyme werden mit dem Programm PMGRANT von PMail erzeugt, die Synonym-Datenbank wird mit CH_SYN.EXE erzeugt.
    
  • listfile
    Name der sog. "List of lists", Datei, in der alle Verteilerlisten enthalten sind, die von Mercury verwaltet werden.
    
  • logfile
    Datei, in der Daten zum Mail-Verkehr erfaßt werden sollen; es werden Absender, Adressat, Datum, Uhrzeit und Größe der Nachricht gespeichert; falls keine Datei angegeben wird, erfolgt keine Protokollierung.
    
  • bitnethost
    Adresse, an die Mails mit BITNET-Adressen weitergeleitet werden sollen; es erfolgt ein sog. Address-Rewriting, z. B.
    USER@HOST.BITNET
    wird zu
    USER%HOST:BITNET@rrzs1.rz.uni-regensburg.de
    
  • poll
    Intervall (in Sekunden) in dem Mercury in der Warteschlange nach neuen Jobs sehen soll, hier alle 10 Sekunden
    
  • scratch
    Verzeichnis, in dem Mercury seine temporären Dateien speichern soll
    
  • switch
    Anzahl, wie oft Mercury den Prozessor während intensiver I/O-Tätigkeit freigeben soll
    
  • returnlines
    Anzahl Zeilen der ursprünglichen Nachricht, die Mercury in eine Fehlerbenachrichtigung übernehmen soll
    
  • postmaster
    NetWare-Benutzername, an den Nachrichten gesendet werden, die an Postmaster gerichtet sind; darf kein Alias oder Synonym sein.
    
    
  1. Die Sektion für das NLM MercuryC:
     
  • [MercuryC]
    
  • host: 132.199.3.13
    # mail mail host which relays for us
    
  • scratch: SYS:SYSTEM/MERCURY
    # Where we can write temp files
    
  • poll: 30 # Seconds between queue polling cycles
    
  • switch: 2 # number of ms to yield per op on heavy I/O
    
  • returnlines: 15
    
  • # How many lines of failed messages to return
    
  • failfile: SYS:SYSTEM/MERCURY/FAILURE.MER
    # Delivery failure template
    
• 
  
  • host
    Internet-Adresse (numerische Form) des Rechners, an den MercuryC Nachrichten weiterleiten soll, hier ngate.rz .
    
  • scratch, poll, switch, returnlines, failfile
    Selbe Bedeutung wie im Abschnitt zu Mercury. Sie können auf unterschiedliche oder gleiche Werte eingestellt sein.
    
    
  1. Der MercuryS-Abschnitt:
     
  • [MercuryS]
    
  • switch: 2
    
  • debug: 1 # Whether or not to show session progress
    
  • discard: 100000 # Max. number lines to allow in a message
    
• 
  
  • switch
    Selbe Bedeutung wie in der Mercury-Sektion.
    
  • debug
    Falls dieser Wert ungleich 0 ist, so zeigt MercuryS genauere Informationen über ankommende Verbindungen auf dem Bildschirm an.
    
  • discard
    Maximale Anzahl von Zeilen, die eine Nachricht haben darf, damit sie von MercuryS noch angenommen wird. Überschreitet eine Mail diese Zeilenzahl, so wird sie vollständig gelöscht.
    
    

1. Abschnitt, in dem Alias-Namen an NetWare-Gruppen vergeben werden. An diese Gruppen dürfen dann sog. Groupmails geschickt werden, z. B. macht der folgende Eintrag aus einer Nachricht an EVERYONE@RZI eine Mail an alle Mitglieder der Gruppe MAILUSERS. Somit ist Groupmail auch von außen möglich.
   
   • [Groups]
     
   • # Alias for group Actual NetWare group name
     
   • everyone : MAILUSERS
     
     
2. Domain-Abschnitt:
   Hier werden Domain-Adressen an einen bestimmten NetWare-Server gebunden. Um lokale Mail-Distribution zu ermöglichen, sollte immer ein Verweis auf den eigenen Rechner erfolgen, z. B. rzi : rzi. Da ngate das Routing auf andere Novell-Server übernimmt, sind keine weiteren Domains an andere Server gebunden.
   
   • [Domains]
     
   • # NetWare Server Domain name
     
   • rzi : rzi
     
   • rzi : rzi.ngate.uni-regensburg.de
     
   • rzi : rzi.rz.uni-regensburg.de
     
   • rzi : rzi.uni-regensburg.de
     
     
3. Abschnitt für Address-Rewriting Definition von Rewrite-Adressen. Hier wird durch "*" ein "default rewrite" angegeben, das an jedes Domain angehängt wird, das keinen Punkt enthält, z. B. SCHWARZ@RZI wird zu SCHWARZ@RZI.ngate.uni-regensburg.de.
   
   • [Rewrite]
     
   • * : ngate.uni-regensburg.de
     

:load MERCURY
:load MERCURYS
:load MERCURYC

Diese Aufrufe können in einer Art Batch-Datei zusammengefaßt werden, um das Starten und Beenden von Mercury zu vereinfachen, z. B. STARTMER.NCF (siehe Anhang D.2) und STOPMER.NCF (siehe Anhang D.3). Damit Mercury bei jedem Serverstart auch mit hochgefahren wird, kann STARTMER.NCF in die Datei AUTOEXEC.NCF aufgenommen werden.

Jedes Modul öffnet beim Starten einen eigenen Konsolen-Bildschirm, auf dem wichtige Informationen zum entsprechenden Modul und zum Mail-Transport angezeigt werden. Eine genaue Beschreibung dazu findet man im Handbuch [9].

5.1.3 UnixWare-Seite

1. Evtl. unvollständige und unbekannte Domain-Namen korrigieren
   
2. Mails zwischen Novell-Servern werden direkt geroutet,
   
3. alle anderen werden an die comsun weitergegeben, sie funktioniert als sog. Smarterhost, d. h. sie weiß, wie mit diesen Mails zu verfahren ist.
   
4. Korrigieren einer Race-Condition beim Absenden der Mails
   

1. Korrektur unvollständiger und unbekannter Domain-Informationen
   
   
   1. Bei an den Gateway selbst adressierten Mails wird nur der Benutzername (\\1) behalten, Rechnername (%U=Name des Gateways von uname, %L=Name des Gateways von hostname) und evtl. vorhandenes Domain werden abgeschnitten:
      
      

'.+'    '(.+)@%U\.rz\.uni-regensburg\.de'    'Translate R=\\1'
'.+'    '(.+)@%U\.uni-regensburg\.de'        'Translate R=\\1'
'.+'    '(.+)@%U'                            'Translate R=\\1'
'.+'    '(.+)@%L\.rz\.uni-regensburg\.de'    'Translate R=\\1'
'.+'    '(.+)@%L\.uni-regensburg\.de'        'Translate R=\\1'
'.+'    '(.+)@%L'                            'Translate R=\\1'

1. Wird nur eine virtuelle Domain angegeben, so wird ".uni-regensburg.de" angehängt:
   
   

'.+'   '(.+)@bibliothek'  'Translate R=\\1@bibliothek.uni-regens
burg.de'
'.+'  '(.+)@biologie'  'Translate R=\\1@biologie.uni-regens
burg.de'
'.+'   '(.+)@chemie'  'Translate R=\\1@chemie.uni-regens
burg.de'
'.+'   '(.+)@extern'  'Translate R=\\1@extern.uni-regens
burg.de'
'.+'   '(.+)@geographie'  'Translate R=\\1@geographie.uni-regens
burg.de'
'.+'  '(.+)@geschichte'  'Translate R=\\1@geschichte.uni-regens
burg.de'
'.+'  '(.+)@jura'  'Translate R=\\1@jura.uni-regens
burg.de'
'.+'  '(.+)@klinik'  'Translate R=\\1@klinik.uni-regens
burg.de'
'.+'  '(.+)@mathematik'  'Translate R=\\1@mathematik.uni-regens
burg.de'
'.+'  '(.+)@paedagogik'  'Translate R=\\1@paedagogik.uni-regens
burg.de'
'.+'  '(.+)@physik'  'Translate R=\\1@physik.uni-regens
burg.de'
'.+'  '(.+)@psk'  'Translate R=\\1@psk.uni-regensburg.de'
'.+'  '(.+)@psychologie'  'Translate R=\\1@psychologie.uni-
regensburg.de'
'.+'  '(.+)@rz'  'Translate R=\\1@rz.uni-regensburg.de'
'.+'  '(.+)@soziologie'  'Translate R=\\1@soziologie.uni-regens
burg.de'
'.+'  '(.+)@sprachlit'  'Translate R=\\1@sprachlit.uni-regens
burg.de'
'.+'  '(.+)@student'  'Translate R=\\1@student.uni-regens
burg.de'
'.+'  '(.+)@theologie'  'Translate R=\\1@theologie.uni-regens
burg.de'
'.+'  '(.+)@verwaltung'  'Translate R=\\1@verwaltung.uni-regens
burg.de'
'.+'  '(.+)@vkl'  'Translate R=\\1@vkl.uni-regensburg.de'
'.+'  '(.+)@wiwi'  'Translate R=\\1@wiwi.uni-regens
burg.de'

1. Bei Mails ohne Angabe von Domains wird angenommen, daß es sich um eine Mail an einen Novell-Server handelt, entsprechend wird das Domain "ngate.uni-regensburg.de" angehängt:
   

'.+'   '(.+)@([^.]+)'   'Translate R=\\1@\\2.ngate.uni-regens
burg.de'

1. Mails, die die X.400-Domains "ngate.uni-regensburg.d400.de" und (veraltet) "ngate.uni-regensburg.dbp.de" enthalten, werden ebenfalls in das lokale SMTP-Domain ("ngate.uni-regensburg.de") umgelenkt:
   
   

'.+'   '(.+)@([^.]+)\.ngate\.uni-regensburg\.d400\.de'  'Trans
late R=\\1@\\2.ngate.uni-regensburg.de'
'.+'   '(.+)@([^.]+)\.ngate\.uni-regensburg\.dbp\.de'   'Trans
late R=\\1@\\2.ngate.uni-regensburg.de'

1. Routen von Mails zwischen Novell-Servern direkt
   

1. Mail zu bekannten Novell-Servern direkt abliefern:
   
   

#
# all servers in subdomain rz
#
'.+'   '(.+)@rzi\.ngate\.uni-regensburg\.de'      '< B=4096; smt
pneu -u %R rzi.rz.uni-regensburg.de'       
'\\1@rzi.ngate.uni-regensburg.de'
'.+'   '(.+)@rio\.ngate\.uni-regensburg\.de'      '< B=4096; smt
pneu -u %R rio.rz.uni-regensburg.de'       
'\\1@rio.ngate.uni-regensburg.de'
'.+'   '(.+)@edi\.ngate\.uni-regensburg\.de'      '< B=4096; smt
pneu -u %R edi.rz.uni-regensburg.de'       
'\\1@edi.ngate.uni-regensburg.de'
# Testhalber via dawn
'.+'   '(.+)@(rrznw.|dawn)\.ngate\.uni-regensburg\.de' '< B=4096; 
smtpne u -u %R dawn.rz.uni-regensburg.de'       
'\\1@\\2.ngate.uni-regensburg.de'
'.+'   '(.+)@mars\.ngate\.uni-regensburg\.de' '< B=4096; smtpneu 
-u %R mar s.rz.uni-regensburg.de'  '\\1@mars.ngate.uni-
regensburg.de'
'.+'   '(.+)@rzbnw1\.ngate\.uni-regensburg\.de'   '< B=4096; smt
pneu -u %R rzbnw1.rz.uni-regensburg.de'    
'\\1@rzbnw1.ngate.uni-regensburg.de'
#
# all servers in subdomain alf (don't make a MX-query)
#
'.+'   '(.+)@alf1\.ngate\.uni-regensburg\.de'   '< B=4096; smt
pneu -u -N %R alf1.alf.uni-regensburg.de'   
'\\1@alf1.ngate.uni-regensburg.de'
'.+'   '(.+)@alf2\.ngate\.uni-regensburg\.de'   '< B=4096; smt
pneu -u -N %R alf2.alf.uni-regensburg.de'   
'\\1@alf2.ngate.uni-regensburg.de'
'.+'   '(.+)@alf3\.ngate\.uni-regensburg\.de'   '< B=4096; smt
pneu -u -N %R alf3.alf.uni-regensburg.de'   
'\\1@alf3.ngate.uni-regensburg.de'
'.+'   '(.+)@alf4\.ngate\.uni-regensburg\.de'   '< B=4096; smt
pneu -u -N %R alf4.alf.uni-regensburg.de'   
'\\1@alf4.ngate.uni-regensburg.de'
'.+'   '(.+)@alf5\.ngate\.uni-regensburg\.de'   '< B=4096; smt
pneu -u -N %R alf5.alf.uni-regensburg.de'   
'\\1@alf5.ngate.uni-regensburg.de'
#
# all servers in subdomain cip
#
'.+'   '(.+)@cip6\.ngate\.uni-regensburg\.de'   '< B=4096; smt
pneu -u %R cip 6.cip.uni-regensburg.de'      
'\\1@cip6.ngate.uni-regensburg.de'
#
# all servers in subdomain physik
#
'.+'   '(.+)@rphnw1\.ngate\.uni-regensburg\.de' '< B=4096; smt
pneu -u %R rph nw1.physik.uni-regensburg.de'   
'\\1@rphnw1.ngate.uni-regensburg.de'
'.+'   '(.+)@rphnw2\.ngate\.uni-regensburg\.de' '< B=4096; smt
pneu -u %R rph nw2.physik.uni-regensburg.de'   
'\\1@rphnw2.ngate.uni-regensburg.de'
'.+'   '(.+)@rphnw3\.ngate\.uni-regensburg\.de' '< B=4096; smt
pneu -u %R rph nw3.physik.uni-regensburg.de'   
'\\1@rphnw3.ngate.uni-regensburg.de'
#
# all servers in subdomain chemie
#
'.+'   '(.+)@rchnw2\.ngate\.uni-regensburg\.de'  '< B=4096; smt
pneu -u %R rchnw2.chemie.uni-regensburg.de'   
'\\1@rchnw2.ngate.uni-regensburg.de'
#
# all servers in subdomain klinik
#
'.+'   '(.+)@rklnw1\.ngate\.uni-regensburg\.de'  '< B=4096; smt
pneu -u %R rklnw1.klinik.uni-regensburg.de'   
'\\1@rklnw1.ngate.uni-regensburg.de'
# remaining Stuff for subdomain klinik to kgate without MX-Query
'.+'   '(.+)@(rk.+)\.ngate\.uni-regensburg\.de'  '< B=4096; smt
pneu -u -N % R kgate.klinik.uni-regensburg.de'   
'\\1@\\2.ngate.uni-regensburg.de'
'.+'   '(.+)@kgate\.ngate\.uni-regensburg\.de'  '< B=4096; smt
pneu -u -N %R kgate.klinik.uni-regensburg.de'   
'\\1@kgate.ngate.uni-regensburg.de'
#
# all servers in subdomain wiwi
#
'.+'   '(.+)@rrwnw1\.ngate\.uni-regensburg\.de'  '< B=4096; smt
pneu -u %R rrwnw1.wiwi.uni-regensburg.de'     
'\\1@rrwnw1.ngate.uni-regensburg.de'
'.+'   '(.+)@rrwnw2\.ngate\.uni-regensburg\.de'  '< B=4096; smt
pneu -u %R rrwnw2.wiwi.uni-regensburg.de'     
'\\1@rrwnw2.ngate.uni-regensburg.de'
#
# all servers in subdomain sprachlit
#
'.+'   '(.+)@rlirnw1\.ngate\.uni-regensburg\.de' '< B=4096; smt
pneu -u %R rlirnw1.sprachlit.uni-regensburg.de' 
'\\1@rlirnw1.ngate.uni-regensburg.d e'
#
# all servers in subdomain vkl
#
'.+'   '(.+)@rvklnw1\.ngate\.uni-regensburg\.de' '< B=4096; smt
pneu -u %R r vklnw1.vkl.uni-regensburg.de'      
'\\1@rvklnw1.ngate.uni-regensburg.d e'
#
#
# all servers in subdomain fh (don't make a MX-query)
#
'.+'   '(.+)@rfhnw7006\.ngate\.uni-regensburg\.de'   '< B=4096; 
smtpneu -u -N %R rfhnw7006.fh-regensburg.de'   
'\\1@rfhnw7006.ngate.uni-regensbur g.de'
#
# all servers in subdomain verwaltung (don't make a MX-query, 
pfui!!!)
#
'.+'   '(.+)@urv\.ngate\.uni-regensburg\.de'   '< B=4096; smtpneu 
-u -N %R urv.verwaltung.uni-regensburg.de'   
'\\1@urv.ngate.uni-regensburg.de'
#
# 
'.+'   '(.+)@deep3\.ngate\.uni-regensburg\.de'   '< B=4096; smt
pneu -u %R deepthought3.rz.uni-regensburg.de'   
'\\1@deepthought3.rz.uni-regensburg.de'
#
#

1. Mails an unbekannte Server werden abgewiesen und an den Absender zurückgeschickt:
   
   

'.+'   '(.+)@(.+)\.ngate\.uni-regensburg\.de' 'Deny Host 
unknown!'

1. Alle anderen Mails werden direkt an die comsun als Smarterhost (%X) weitergeleitet:
   
   

'.+'    '([^@,:]+)@(.+)'                            '< B=4096; 
smtpneu -u %R %X' '\\1@\\2'

1. Die Lockfiles der Prozesse in.smtpd, smtpsched und smtpqer, die für das Einsortieren der ankommenden Mails in den Spoolbereich sorgen, verhindern, daß diese Mails anschließend - nachdem das Mailsurr-File abgearbeitet wurde - gleich wieder versandt werden. Die Prozesse und ihre zugehörigen Lockfiles existieren noch, wenn der Sendeprozeß smtpneu (und damit smtpsched und smtp) aufgerufen werden, was dazu führt, daß die Sendeprozesse ihre Arbeit nicht ausführen können.
   
   

Um diesen Konflikt zwischen smtpqer und smtpsched zu lösen muß smtpsched nochmals aufgerufen werden, nachdem alle Send- und Empfangs-Prozesse beendet sind. Dies geschieht am einfachsten durch ein sog. Post-Delivery-Command:

'.+'    '.+'         '> smtpsched'

5.2 Anbindung mit NetWare Global Messaging (NGM)

Abbildung 30 : Anbindung mit NGM (1 Active- und 2 Passive-Server) 

5.2.1 Voraussetzungen

• mind. 11 MB RAM, bei Directory Synchronisation sind mind. 12 MB Speicher erforderlich
  
• 8 MB freier Plattenspeicher zur Installation
  
• Der Bedarf an Plattenspeicher für den Einsatz hängt von der Anzahl der NGM-Benutzer und der Größe und Komplexität des Nachrichtenverkehrs ab. Für die NGM Datenbank werden ca. 2 kB pro Benutzer benötigt. Der Platzbedarf für die Mailboxen der Benutzer orientiert sich an der Anzahl von gespeicherten Nachrichten und Attachments, in der Praxis ca. 500 kB pro Mailbox.
  
• Modem und NetWare-Modem-Treiber für asynchrone Übertragung
  
• Asynchrone Verbindungen mit mehr als 2400 bps benötigen einen seriellen I/O-Adapter, z. B. Digiboard, und einen entsprechenden asynchronen I/O-Treiber (AIO.NLM).
  

• IPX für den normalen Einsatz
  
• NCP für NIMP-Pipelines
  

5.2.2 Novell-Seite

Viele der Installationsanweisungen und Konfigurationsschritte können nur an der File-Server-Konsole bzw. über RCONSOLE durchgeführt werden. Im folgenden sind solche Kommandos am vorangestellten ":" (Prompt der Server-Konsole) zu erkennen. Der ":" darf nicht mit eingegeben werden. Diese Befehle sind für die Server-Konsole und RCONSOLE identisch und können daher bei beiden Möglichkeiten gleichermaßen eingesetzt werden.

Voraussetzung für den Einsatz der RCONSOLE ist, daß die Module RSPX.NLM und REMOTE.NLM auf dem entsprechenden File-Server geladen sind. Außerdem muß das Paßwort für die RCONSOLE bekannt sein, falls es gesetzt ist. Es ist ratsam das Paßwort zu setzen, da RCONSOLE alle Funktionalitäten einer File-Serverkonsole bietet. Das Paßwort kann das SUPERVISOR-Paßwort sein, das über die Option "-s" gesetzt wird. Es besteht aber auch die Möglichkeit ein frei definiertes Paßwort anzugeben. Dieses wird beim Aufruf von RCONSOLE übergeben, z. B. test:

:load RCONSOLE test

5.2.2.1 Installation von NGM

Die Installation von NGM kann auf zwei Arten erfolgen:

• aus einem Installationsverzeichnis direkt am Server
  
• von Diskette (nur direkt von der Server-Konsole, wegen Diskettenlaufwerk)
  

Nun zu der Vorgehensweise bei den beiden Methoden. Falls man keinen direkten Zugang zur Konsole des File-Servers hat, kann die Installation über RCONSOLE durchgeführt werden. Dazu muß man sich als erstes als SUPERVISOR oder Äquivalent an diesem Novell-Server anmelden. Als nächstes ist das Volume (meist SYS:) auf ein Laufwerk zu legen, auf dem NGM installiert werden soll. Schließlich müssen nur noch die Inhalte der 4 Disketten kopiert werden. Dazu geht man auf das eben eingerichtete Laufwerk und führt folgenden Befehl für jede Diskette aus (Natürlich müssen die Disketten nach jedem beendeten Kopiervorgang gewechselt werden):

ncopy /s /e a:*.* .

Da dabei evtl. bereits vorhandene Dateien überschieben werden, z. B. AIO.NLM im Verzeichnis SYSTEM, besteht noch eine Alternative. Man legt ein eigenes Verzeichnis, z. B. NGMINST, an und kopiert die Disketteninhalte dort hin. Die Installation wird dann von diesem Verzeichnis aus durchgeführt. Allerdings müssen nach Beendigung der Installation noch die Verzeichnisse MHS und NGM aus NGMINST auf die entsprechenden Arbeitsverzeichnisse umkopiert werden, da die Installationsprozedur lediglich die Directories anlegt und bestimmte Dateien generiert, aber nicht die Inhalte kopiert.

Nachdem die Disketten kopiert sind, kann man mit der eigentlichen Installation beginnen. Dazu verwendet man das Installationsmodul von NetWare. Allerdings muß sichergestellt sein, daß das Programm btrieve mit einer Seitengröße von 4096 Bytes geladen ist. Deshalb wird am besten btrieve vorher beendet und neu gestartet:

:unload btrieve
:load btrieve -P=4096
:load install

Hat man direkten Zugang zur Server-Konsole, so kann auch direkt von den Disketten (Arbeitskopien) installiert werden. Dazu muß nur Diskette #1 eingelegt und das Installationsprogramm wie oben mit "load install" aufgerufen werden.

Das Installationsprogramm meldet sich mit einem Auswahlmenü mit den Punkten:

• Disk Options
  
• Volume Options
  
• System Options
  
• Product Options
  
• Exit
  

• NGM Messaging Area
  Zielverzeichnis für die Dateien von NetWare Global Messaging.
  default: rrzmhs\sys:\ngm
  
• Is MHS 1.5 installed on this Server?
  In diesem Feld wird angegeben, ob auf dem NetWare-Server bereits MHS 1.5 oder 1.5C installiert ist.
  default: No
  (Falls MHS 1.5 installiert ist und das MHS-Verzeichnis ist SYS:\MHS, dann ist die default-Einstellung automatisch YES)
  
• MHS Messaging Area
  Verzeichnis, in dem die MHS-Directory-Struktur angelegt wird, d. h. für die Mailboxen und Gateway-Bereiche zum Nachrichtenaustausch.
  default: rrzmhs\sys:\mhs
  

Bei der Installation von Diskette werden jetzt die Dateien von Diskette in die angegebenen Verzeichnisse kopiert. Wenn der File-Transfer einer Diskette abgeschlossen ist, erfolgt eine Aufforderung, die nächste einzulegen und mit <ESC> fortzufahren. Falls zu kopierende Dateien bereits existieren, wird nachgefragt, ob diese überschrieben werden sollen.

Wird die Installation aus einem Verzeichnis durchgeführt, dann werden die Dateien nicht kopiert. Daher muß dies noch nachträglich per Hand erledigt werden.

Als nächstes sind Angaben zur Administrative Domain zu machen und sollten auch wieder auf dem Arbeitsblatt notiert werden. (Genaue Feldbeschreibungen siehe [10], Seite 2-4):

• Domain Name
  Name des administrativen Domains, z. B.:
  Rechenzentrum
  
• Domain Description
  Optional kann hier eine Beschreibung für das Administrative Domain eingetragen werden, z. B.:
  Domain des Rechenzentrums Regensburg
  
• Root Workgroup Name
  Name der höchsten Workgroup, der sog. Root Workgroup, z. B.:
  mhs
  
• Root Workgroup Short Name
  Verkürzter Name der Root Workgroup mit max. 8 Zeichen Länge für SMF v70, z. B.:
  mhs
  
• Root Workgroup Description
  Root Workgroup des Rechenzentrums
  

• Messaging Server Name
  Langer Name des NGM-Servers (mit angehängter Root Workgroup für SMF v71), z. B.:
  rrzmhs.mhs
  
• Messaging Server Short Name
  Verkürzter Name des NGM-Servers mit max. 8 Zeichen, z. B.:
  rrzmhs
  
• Messaging Server Description
  Beschreibung für den NGM-Server (optional), z. B.:
  MHS-Server des Uni-RZ
  
• Default Workgroup Name
  Name einer Workgroup, der Benutzer defaultmäßig angehören sollen, das kann auch die Root Workgroup sein, z. B.:
  mhs
  
• Default Workgroup Short Name
  Kurzer Name der Default Workgroup mit max. 8 Zeichen (SMF v70), z. B.:
  mhs
  
• Default Workgroup Description
  Erklärende Beschreibung für die Default Workgroup (optional), z. B.:
  Default Workgroup des Rechenzentrums
  
• Postmaster Account Name
  Benutzername, an den Systemnachrichten geschickt werden.
  default: Admin
  
• Postmaster Account Short Name
  Verkürzter SMF v70-Benutzername mit max. 8 Zeichen des Postmasters.
  default: Admin
  
• Postmaster Bindery Password
  ****
  

Sind alle Angaben vollständig und richtig, werden sie durch Drücken von <ESC> und Auswählen von Yes bestätigt. Es werden noch ein paar Meldungen angezeigt, z. B. daß NGM erfolgreich installiert wurde und noch zu erledigende Tätigkeiten. Diese werden jeweils mit <ESC> verlassen.

Schließlich wird ein Fenster geöffnet, in dem alle auf dem File-Server installierten Produkte aufgelistet sind. Unter diesen Einträgen sollte sich auch einer für NetWare Global Messaging befinden. Auch dieses wird durch Drücken von <ESC> verlassen und man gelangt zurück ins Hauptmenü vom Installationsprogramm.

Damit NGM automatisch gestartet wird, wenn der Server neu hochgefahren wird, muß noch die Datei AUTOEXEC.NCF erweitert werden. Das kann ebenfalls vom Installationsprogramm aus durchgeführt werden. Dazu wählt man "System Options" vom Hauptmenü aus und daraufhin "Edit AUTOEXEC.NCF File" aus dem Untermenü der System Optionen. Es erscheint der Bildschirm eines Editors mit dem Inhalt der Datei AUTOEXEC.NCF. Am Ende dieser Datei sind folgende Zeilen hinzuzufügen:

rem NetWare Global Messaging
search add sys:\NGM\bin
load btrieve
load aio
load NGM
load NGMADMIN

sys:\NGM\bin ist dabei das Verzeichnis, in das die ausführbaren Programme von NGM installiert wurden.

Folgender Eintrag darf nicht in der Datei AUTOEXEC.NCF enthalten sein:

SET REPLY TO NEAREST SERVER=OFF

Falls diese Zeile doch existiert, so muß sie gelöscht werden bzw. die Einstellung auf ON geändert werden.

Wenn alle Änderungen vorgenommen sind, dann kann der Editor durch Drücken von <ESC> und Bestätigen mit Yes verlassen werden. Es erscheint wieder das Untermenü mit den möglichen System Optionen. Um das Installationsprogramm zu verlassen, muß zweimal <ESC> gedrückt und mit Yes bestätigt werden, daß man das Programm verlassen möchte.

Somit ist die Installation von NGM fast abgeschlossen. Es sind nur noch die fehlenden Dateien zu kopieren, wenn die Installation nicht direkt von den Disketten durchgeführt wurde. Das kann mit folgenden Befehlen in einem DOS-Fenster durchgeführt werden, wenn das Installationsverzeichnis NGMINST und die Arbeitsverzeichnissse auf SYS: liegen.

ncopy /s /e SYS:\NGMINST\NGM SYS:\NGM
ncopy /s /e SYS:\NGMINST\MHS SYS:\MHS

NetWare Global Messaging muß nun nur noch von der Server-Konsole aus gestartet werden:

:search add sys:\NGM\bin
:load btrieve
:load aio
:load NGM
:load NGMADMIN

Das letzte Kommando startet das Admin-Tool (siehe Abbildung 31 auf Seite 72), mit dem alle Konfigurationen von NGM durchgeführt werden. Mit diesem Programm kann nun die Konfiguration des NGM-Servers überprüft und ggf. geändert werden. Dazu wählt man den Menüpunkt "This Server" und dann "Configuration". Dadurch gelangt man in das Konfigurationsfenster des NGM-Servers (siehe Abbildung 32 auf Seite 72):

Abbildung 31 : Hauptmenüdes Admin-Tools 

Abbildung 32 : Konfigurationsfenster des NGM-Servers 

5.2.2.2 Upgrade von NGM

Voraussetzung zur Durchführung des Upgrades ist, daß mindestens 7 MB freier Plattenplatz zur Verfügung stehen.

Bevor mit dem Upgrade begonnen werden kann, muß NGM erst beendet werden. Dazu verläßt man das Admin-Tool mit <ESC> und bestätigt mit Yes, daß das Programm verlassen werden soll. Nun kann NGM mit folgendem Kommando beendet werden:

:unload NGM

Die darauf folgende Abfrage, ob NGM abgebrochen werden soll ist mit No zu beantworten, da ein solcher Abbruch häufig zu einem Stillstand des File-Servers führt. Wird die Abfrage mit Yes beantwortet, erhalten die NGM-Module ein Halt-Signal und beenden sich nach einiger Zeit ordnungsgemäß.

Wenn alle NGM-Module einen unload durchgeführt haben, kann mit dem Upgrade begonnen werden. Allerdings sollte aus Sicherheitsgründen vorher noch ein Backup des NGM- und des MHS- Verzeichnisses gemacht werden.

Für den Upgrade-Patch muß man sich als SUPERVISOR in den NetWare-Server einloggen, hier rrzmhs. Anschließend müssen die Dateien PATCH.EXE, PATCHNGM.BAT und NGM20D.RTP aus dem Archiv ins NGM-Wurzelverzeichnis kopiert werden. Wurde bei der NGM-Installation keine Änderung vorgenommen, so ist das sys:\NGM.

Nun muß in das NGM-Verzeichnis gewechselt werden (cd sys:\NGM). Es ist sicherzustellen, daß sich kein Verzeichnis BACKUP in diesem Directory befindet, denn sonst könnten Probleme beim Upgrade auftreten. Gegebenenfalls muß ein solches Verzeichnis umbenannt oder in ein anderes Unterverzeichnis verlegt werden. Existiert dieses Verzeichnis nicht, kann einfach der Patch gestartet werden:

PATCHNGM

Dieses Programm führt an allen entsprechenden Dateien ein Upgrade durch und hält die Ergebnisse in der Log-Datei RESULTS.TXT fest. Das Upgrade dauert ca. 30 Minuten. Ist der Patch abgeschlossen, dann sollte nachgeprüft werden, ob Fehler aufgetreten sind und ob alle Dateien ordnungsgemäß bearbeitet wurden. Dazu sind die Attribute der Dateien im NGM\bin-Verzeichnis mit denen in der Datei README.UPG unter dem Abschnitt "which files are upgraded?" zu vergleichen.

Die Angaben in README.UPG sind allerdings teilweise unrichtig. Nach Rücksprache mit Entwicklern von Novell wurde bestätigt, daß die Größe der Dateien NGM.NLM (688333 Bytes) und DIRADM.EXE (230469 Bytes) nach dem Patch korrekt sind. In README.UPG sind die Größen mit 17893 Bytes für NGM.NLM und 243003 für DIRADM.EXE angegeben. Treten davon abgesehen weitere Abweichungen auf, dann sollte man sich mit einem Novell-Vertreter in Verbindung setzen.

Sind keine Fehler aufgetreten und stimmen die Dateiattribute überein, dann ist das Upgrade somit fast abgeschlossen. Es muß nur noch die Datei DIRADM.EXE von sys:\NGM\DPATCH nach sys:\MHS\EXE kopiert werden. Nun kann NGM wieder mit folgenden Kommandos gestartet werden:

:load NGM
:load NGMADMIN

Während des Upgrades wird ein Verzeichnis BACKUP unter dem Directory angelegt, von wo aus PATCHNGM gestartet wurde. Darin sind alle Dateien, die modifiziert wurden, enthalten und eine Datei UNPATCH.BAK. Damit ist es möglich, den Patch rückgängig zu machen. Um das Sytem wieder zurückzusetzen, muß die Datei UNPATCH.BAK in UNPATCH.BAT umbenannt und mit UNPATCH aufgerufen werden. Dadurch werden alle neuen Dateien durch die ursprünglichen ersetzt. Nachdem man sich überzeugt hat, daß die Originaldateien richtig kopiert wurden, sollte man das Verzeichnis BACKUP löschen, bevor man das System erneut versucht upzugraden.

5.2.2.3 Einrichten der Passive-Server

Vom Hauptmenü wählt man die Option "This Server". Aus dem daraufhin erscheinenden Messaging Server Menü wählt man die Option "Passive Messaging Servers". Dadurch erhält man eine Liste, der auf dem Server konfigurierten Passive-Server. Um einen neuen Passive-Server zu registrieren, muß man die Taste <INS> drücken. Es wird ein Fenster angezeigt, in dem die entsprechenden Informationen für den passiven Server anzugeben sind (genaue Felderklärungen siehe [11], Seite 8-16f)

• NGM Server Name
  Name des passiven Servers, z. B.:
  rzi.mhs
  
• NGM Short Name
  Verkürzter Name für den passiven Server (SMF v70), z. B.:
  rzi
  
• NGM Server Password (optional)
  ****
  
• Server Description
  Beschreibung des passiven Servers (optional), z. B.:
  Passive Server des Uni-RZ
  
• NetWare Server Name
  Name des NetWare File-Servers, z. B.:
  RZI
  
• MHS Messaging Area Directory
  In diesem Feld wird das Wurzelverzeichnis angezeigt, das NGM und MHS für den Nachrichtenaustausch auf dem NetWare-Server verwenden. Dieses Feld kann nicht geändert werden.
  SYS:\MHS
  
• MHS Messaging Area Username
  NetWare-Benutzername, der zum Verbindungsaufbau an den Passive Server verwendet wird. Dieser Benutzer muß ein SUPERVISOR-Äquivalent sein, damit er in das MHS-Verzeichnis schreiben kann. Es ist evtl. ratsam, eine spezielle Kennung dafür anzulegen, z. B.:
  MHS
  
• MHS Messaging Area Password
  ****
  
• Default Workgroup
  Name der Default Workgroup für den Passive Server, z. B.:
  mhs
  
• Postmaster Mailbox
  Optional kann hier die Adresse einer Mailbox eingetragen werden, an die System und Fehlermeldungen gehen sollen, z. B.:
  Admin
  

Sollen an einem bestehenden Passive-Server Modifikationen vorgenommen werden, so ist die Vorgehensweise sehr ähnlich. Man wählt hierzu den entsprechenden Passive-Server mit Hilfe der Cursor-Tasten aus der Liste aus und drückt <RETURN>. Dadurch gelangt man in das Menü des Passive-Servers und wählt dann den Punkt "Configuration" aus und gelangt so zum selben Fenster wie beim Einrichten eines neuen passiven Servers, allerdings sind die Konfigurationsdaten bereits enthalten. Hier können nun die gewünschten Modifikationen vorgenommen und ebenfalls wieder mit <ESC> und Yes bestätigt werden.

5.2.2.4 Konfigurationen für den SMF-Gateway

• Gateway NGM Name
  Name des Gateway-Rechners, z. B.:
  ngate.mhs
  
• Gateway NGM Short Name
  Verkürzter Name des Gateway-Rechners mit max. 8 Zeichen Länge (SMF v70), z. B.:
  ngate
  
• Gateway NGM Password
  ****
  
• Gateway Description
  Beschreibung zum Gateway, z. B.:
  MHS-Gate ans Internet
  
• Command Line
  Hier kann ein DOS-Kommando mit den notwendigen Parametern angegeben werden. Falls kein Befehl ausgeführt werden soll, so ist NULL einzutragen.
  
• Execution Interval
  Zeitintervall in Minuten, in dem der Gateway den Austausch der ankommenden und abgehenden Nachrichten ausführen soll, z. B.:
  2
  
• Default Workgroup
  Default Workgroup, die für den Gateway verwendet werden soll, z. B.:
  mhs
  
• Postmaster Mailbox
  Admin
  
• SMF-Version
  Hier kann die für den Gateway verwendete SMF-Version angegeben werden (SMF v70 oder SMF v71). Im Falle des Rechenzentrums muß dieser Eintrag auf SMF v70 lauten, da auf UnixWare-Seite nur diese Version unterstützt wird:
  v70
  

Zum Verlassen des Eingabefensters muß man <ESC> drücken und die folgende Abfrage mit Yes bestätigen. Danach gelangt man wieder zur Liste der SMF-Gateways. Somit ist der Gateway registriert. Änderungen an der Konfiguration können wie bei den Passive-Servern entsprechend durchgeführt werden (siehe Kapitel 5.2.2.3 auf Seite 74).

Damit der Gateway ordnungsgemäß funktionieren und die Nachrichten richtig routen kann, muß noch ein bestimmtes Adreßformat angegeben werden. Hierzu wählt man aus der Liste der registrierten SMF-Gateways ("This Server" -> "SMF-Gateways") den entsprechenden Eintrag aus, hier ngate. Aus dem Menü des Gateways ist nun die Option "Additional Address Formats Supported" zu selektieren. Es erscheint eine Liste der bekannten Adreßformate. Diese Liste ist meist leer. Nun muß das neue Format angelegt werden, dazu drückt man <INS> und macht im erscheinenden Eingabefenster die entsprechenden Angaben:

• Address Pattern:
  **@**
  
• Priority:
  1
  

• ?
  steht für jedes beliebige, alphanumerische Zeichen
  
• *
  steht für ein beliebiges Zeichen, mit Ausnahmen von "." und "@"
  
• **
  steht für jedes beliebige Zeichen (auch "." und "@")
  

5.2.3 UnixWare-Seite

Abbildung 33 : MHS_Setup im UnixWare-Desktop 

• MHS-Gateway: der Name, unter dem der UnixWare-Rechner dem Novell-Server bekannt ist. , z. B. "ngate"
  
• Internet Gateway: Name der MHS-Subdomain, z. B. "mhs"
  
• MHS File Server: Novell-Server, der die MHS-Mails hält, z. B. "rrzmhs"
  
• MHS Volume: NetWare-Volume, auf dem die MHS-Mail gehalten wird, z. B. "sys". Darf kein ":" enthalten!
  
• MHS Login: Login auf dem Novell-Server, das zur Gruppe "Mail" gehört und im Spool-Verzeichnis des Servers schreiben und lesen darf, z. B. "mhs"
  
• MHS Password: Passwort der obigen Kennung, z. B. pwMHS
  
• MHS Mail Check Interval: Alle wieviel Minuten sich der UnixWare- auf dem NetWare-Server einloggt und nach neuen Mails sieht. Normal "1".
  

1. /etc/mail/mailsurr
   
2. /usr/lib/mail/surrcmd/smfpoll
   
3. /usr/lib/mail/surrcmd/smf-in
   
4. /usr/lib/mail/surrcmd/suid/smf-out
   
5. /usr/lib/mail/surrcmd/getDomain
   

1. Für die Einbindung der MHS-Benutzer in den SMTP-Setup wird eine eigene Domain "mhs.uni-regensburg.de" aufgemacht. Mails an diese Domain bzw. an Rechner innerhalb der Domain werden durch smfqueue an den MHS-Gateway weitergereicht. Folgende Ergänzungen sind in /etc/mail/mailsurr nötig:
   
   

'[^@]+`      '([^@,:]+)@%g%D`        '< B=4096; /usr/lib/mail/
surrcmd/smfqueue -h 0 -r %R.%L%D ' '\\1@%g%D`
'.+` '([^@,:]+)@%g%D`                '< B=4096; /usr/lib/mail/
surrcmd/smfqueue -h 0 -r %R ' '\\1@%g%D`
'[^@]+`      '([^@,:]+)@(.+)\.%g`    '< B=4096; /usr/lib/mail/
surrcmd/smfqueue -h 0 -r %R.%L%D ' '\\1@\\2`
'.+` '([^@,:]+)@(.+)\.%g`            '< B=4096; /usr/lib/mail/
surrcmd/smfqueue -h 0 -r %R ' '\\1@\\2`
'[^@]+`      '([^@,:]+)@(.+)\.%g%D`  '< B=4096; /usr/lib/mail/
surrcmd/smfqueue -h 0 -r %R.%L%D ' '\\1@\\2`
'.+` '([^@,:]+)@(.+)\.%g%D`          '< B=4096; /usr/lib/mail/
surrcmd/smfqueue -h 0 -r %R ' '\\1@\\2`
'.+` '([^@,:]+)@%g%D`                'Deny smf-out failed (2)`
'.+` '([^@,:]+)@(.+)\.%g%D`          'Deny smf-out failed (3)`
'.+` '([^@,:]+)@(.+)\.%g`            'Deny smf-out failed (4)`

1. Das Script "smf-poll" wird periodisch (via cron) aufgerufen. Es loggt sich dann in den Novell-Server ein und prüft, ob Mail für den Gateway bereitliegt. Ist dies der Fall, so wird das Script "smf-in" (s.u.) für jede Mail aufgerufen. Vor dem eigentlichen Aufruf wird die Datei, die die Mail enthält, noch mit einem temporären Namen versehen, der sich aus dem Originalnamen und der Prozeß-ID des smfpoll-Prozesses, getrennt durch einen ".", zusammensetzt.
   
   

1. Das Script "smf-in" wird aufgerufen, wenn Mail für den SMTP-Gateway auf dem Novellserver bereitliegt. Es nimmt dann eine Umwandlung von SMF nach RFC 822 vor und leitet die Mail entsprechend den Header-Feldern weiter.
   
   

• Tippfehler: { statt [
  
• SMTP-Mail wird durch vorangestelltes "SMTP:" gekennzeichnet, nicht "MHS:"
  
• smf-date versteht Zeitzone GMT-1 nicht, ggf. durch GMT ersetzen
  
• Spezielle Behandlung der From:-Header-Zeile
  
  

1. "smf-out" ist das Gegenstück zu "smf-in" und übernimmt als solches die Umwandlung von Mails im RFC 822- ins SMF-Format. Für die Codierung der Attachments mit Hilfe von uuencode wird dabei auf dem Novell-Filesystem mittels mkfifo eine Named Pipe erstellt. Da Novell dies jedoch nicht verläßlich handhaben kann, wird diese Pipe stattdessen im Verzeichnis /tmp erstellt.
   
   

1. Das Script "getDomain" wird zur Bestimmung des Mail-Domains benutzt, in dem sich der Mail-Gateway befindet. Dazu wird zuerst die Datei /etc/resolv.conf, dann /etc/mail/mailcnfg durchsucht. Da resolv.conf jedoch den Namen der DNS-Domain enthält, muß der Domainname aus der mailcnfg-Datei bestimmt werden. Um dies zu bewerkstelligen sind im getDomain-Script die beiden if-Abfragen zu vertauschen.
   
   

5.2.4 Mail-Clients

Als erstes sind mit dem Programm PCONFIG.EXE allgemeine Einstellungen zu machen, um die Zusammenarbeit mit NGM zu ermöglichen. Dazu wird der Menüpunkt Define Novell MHS Interface angewählt. Im nun angezeigten Eingabeformular sind folgende Einstellungen zu machen. Genauere Informationen zu den einzelnen Feldern kann man in den Online-Dokumentationen [7] und [8] finden:

• Enabled
  Mit diesem Parameter wird angegeben, ob auf diesem NetWare-Server MHS zur Verfügung steht.
  Y
  
• Preferred
  Dieses Feld gibt an, ob das MHS/SMF-Interface bevorzugt verwendet werden soll. Da im Rechenzentrum jedoch SMTP standardmäßig verwendet werden soll, ist dieses Feld auf "Nein" zu setzen.
  N
  
• Use always?
  Ist diese Option auf Y gesetzt, so werden alle Nachrichten über MHS geroutet, unabhängig vom Adressenformat.
  N
  
• Default Workgroup
  Default Workgroup, die verwendet werden soll, z. B.:
  mhs
  
• Local delivery
  Dieses Feld gibt an, ob ein File-Server, auf dem sowohl SMTP als auch MHS zur Verfügung stehen, Meldungen lokal verteilen oder zum Smarter-Host routen soll. Da im Rechenzentrum auf keinem NetWare-Server beide Mail-Systeme gleichzeitig laufen, muß dieses Feld auf "Nein" gesetzt werden.
  N
  
• SMF-71 available
  Wenn SMF-71 zur Verfügung steht, sollte dieses Feld auf "Ja" gesetzt werden.
  Y
  
• UTC time value
  Hier wird der Zeitunterschied zur GMT in einem 4-Ziffernwert angegeben, für Mitteleuropa ist das:
  +0100
  
• Use SMFSEND
  Dieses Feld sollte auf "Nein" gesetzt werden, da die Option Mails lokal zu verschicken nicht fehlerfrei funktioniert.
  N
  
• DOS MV-Path
  Pfadname, in dem das Wurzelverzeichnis von MHS liegt, z. B.:
  rrzmhs/sys:
  

• Im "Preferences"-Menü ist der Unterpunkt "NetWare MHS/SMF Settings" anzuwählen. Hier muß das Feld "Scan the MHS userdir" auf Yes gesetzt werden, damit auch im MHS-Verzeichnis nach neuen Nachrichten gesehen wird.
  
• Beim Antworten auf Nachrichten mit Reply ist darauf zu achten, daß die "Sender field"-Option auf No gesetzt ist, da sonst zwei Nachrichten gesendet werden, wovon eine bounct, d. h. mit einem Fehler zurückgeschickt wird.
  

5.3 Anbindung von MS-Mail über NGM

5.3.1 Voraussetzungen

• auf einem File-Server muß NGM korrekt installiert sein
  
• Windows for Workgroups oder Windows NT müssen auf den Clients zur Verfügung stehen
  
• NetWare MHS Treiber für MS-Mail (Bezugsadresse siehe Anhang B.3)
  
• ein normales IPX-Netzwerk
  

5.3.2 Aufsetzen des Mail-Clients auf NGM

Zunächst ist das Archiv mit dem NetWare MHS Treiber in einem eigenen Verzeichnis zu entpacken, z. B. G:\TREIBER. Für weitere Installationen wäre es günstig, wenn es ein Netz-Laufwerk ist. Falls der MS-Mail Client bereits installiert ist, dann ist es empfehlenswert, die bereits existierenden Nachrichten zu sichern, indem man sie vom Mail-Client aus in eine Datei exportiert. Diese können später wieder aus dieser Datei importiert werden, wenn der MHS-Treiber installiert ist. Außerdem sollte man von der bisherigen MS-Mail- und Windows-Installation eine Sicherheitskopie anlegen. Sollte der Mail-Client noch nicht installiert sein, so muß das vorher noch durchgeführt werden.

Nun ist eine Verbindung zu einem NetWare-Server mit attach oder login herzustellen, auf dem NGM läuft. Danach ist das Verzeichnis, in dem sich der MHS-Verzeichnisbaum befindet, auf ein Laufwerk zu legen und die Umgebungsvariable MV ebenfalls auf dieses Directory zu setzten (rzi ist ein Passive-Server):

MAP J:=rzi/SYS:
SET MV=J:

Als nächstes ist Windows zu starten. Vom Programm Manager aus wird nun das Setup-Programm gestartet. Dafür muß aus dem "Datei"-Menü der Punkt "Ausführen" gewählt werden und im erscheinenden Fenster ist das folgende Kommando einzugeben:

G:\TREIBER\SETUP

Dabei ist G:\TREIBER das Verzeichnis, in dem sich die Dateien des NetWare MHS Treibers für MS-Mail befinden. Das Setup-Programm kopiert die nötigen Dateien in die entsprechenden Windows-Verzeichnisse. Nachdem die Installation beendet ist, kann das Setup-Programm verlassen werden. Bei der Installation ist eine neue Windows-Programmgruppe angelegt worden. Diese enthält das Programm "MS Mail System Selector", mit dem man für MS-Mail einstellen kann, welches Mailsystem verwendet werden soll.

Durch einen Doppelklick auf das Icon ist das Selektor-Programm aufzurufen. Es folgt ein Fenster, das eine Liste der verfügbaren Mailsystem-Treiber enthält. Davon ist der Eintrag "Novell MHS Mail" mit einem Doppelklick auszuwählen, dadurch wird dieser in das "current"-Feld übernommen. Danach kann das Programm verlassen werden. Diese Prozedur muß durchgeführt werden, denn sonst bleibt der vorherige Treiber für MS-Mail aktiv.

Im letzten Arbeitsschritt sind einige Konfigurationen am MS-Mail Client vorzunehmen. Nachdem MS-Mail gestartet ist, wird nach dem Namen und einem Paßwort gefragt, hier gibt man am besten seinen NetWare-Benutzernamen an. Das Paßwort ist optional, damit kann die Mailbox davor geschützt werden, daß sie Unbefugte kopieren oder lesen. Wenn man sich das erstemal einloggt, erscheint die Fehlermeldung "Can`t find MHS tree stucture" zweimal. Diese kann jedoch ignoriert werden und taucht später nicht mehr auf, wenn der MHS-Treiber konfiguriert ist. Zur Konfiguration wählt man aus dem Nachrichten-Menü den Menüpunkt Optionen und daraus die Option Server. Danach erscheint ein Fenster, in dem man das Verhalten von MS-Mail an die Benutzerwünsche anpassen kann.

Es gibt folgende Checkboxes, die beliebig wählbar sind:

• Exclude OLE Data
  Diese Option sollte man wählen, wenn man Nachrichten auch an Benutzer schikken möchte, die unter UNIX arbeiten, denn dadurch werden Windows-spezifische Informationen weggelassen, z. B. für Icons Art, Position und Aussehen. Außerdem werden Attachments direkt in den Text kopiert und nicht nur ein Verweis auf die entsprechende Datei.
  
• Include Unrecognized Headers
  Ist diese Option ausgewählt, dann werden Header im Nachrichtentext angezeigt, die von MS-Mail nicht erkannt wurden. Ansonsten werden diese Header herausgefiltert.
  
• Disable Mail Login
  Durch diese Option kann man die Abfrage beim Starten von MS-Mail unterbinden. Das sollte man allerdings nur dann machen, wenn der Arbeitsplatzrechner nur für Befugte zugänglich ist, die ggf. auch die eigenen Nachrichten lesen dürfen.
  
• Also Check MHS Directory
  Diese Option ist besonders dann wichtig, wenn im Feld "Preferred MHS Application" etwas anderes als MHS eingetragen ist, denn sonst wird nicht mehr im MHS-Verzeichnis nach neuen Nachrichten gesucht.
  

• MHS User Name
  Hier wird der NGM-Benutzername eingetragen, z. B. schwarz.
  
• MHS Short User Name
  In diesem Feld ist ein verkürzter Benutzername anzugeben, der max. 8 Zeichen lang sein darf, z. B. schwarz. Dieser wird verwendet, wenn SMF v70 eingesetzt wird. Er kann auch mit dem normalen Benutzernamen übereinstimmen, wenn dieser nicht länger als 8 Zeichen ist.
  
• MHS Path
  Mit diesem Feld wird spezifiziert, auf welchem NetWare-Server und Laufwerk sich die MHS-Verzeichnisstruktur befindet, z. B. rzi\sys: (Hier befindet sich das Verzeichnis MHS mit den entsprechenden Unterverzeichnissen)
  
• Preferred MHS Application
  Dieses Feld muß unbedingt ausgefüllt werden. Es kann eine beliebige MHS-Applikation angegeben werden, aber es ist zu empfehlen nur mhs einzutragen, damit MS-Mail ordnungsgemäß funktioniert.
  

5.3.3 MS-Mail & Attachments

Es gibt zwei mögliche Lösungen für dieses Problem:

1. Man kann die Nachricht speichern und später mit einem Editor oder Textanzeigeprogramm lesen, die so große Dateien verarbeiten können.
   
2. Mit Hilfe des Datei-Managers ist es möglich, die Verknüpfung einfacher Textdateien zum Windows-Editor auf ein anderes Programm, z. B. Word für Windows, umzulenken. Dazu muß der Datei-Manager aufgerufen werden. Als nächstes wird eine Textdatei selektiert (*.txt) und dann aus dem Datei-Menü die Option "Verknüpfung" ausgewählt. Jetzt kann man das gewünschte Programm für diesen Dateityp einstellen. Zum Schluß sind die neuen Einstellungen noch zu sichern.
   

Table of Contents

Next Chapter