Home Page
Aktuelles
Verein
Satzung
Geschichte
Vorstand
Mitgliedsantrag
Dienste/Tarife
Technik
Mapserver
Ansprechpartner
Stammtisch
English Summary
Impressum
   
sub-Netz e.V.
Verein zur Förderung der privat betriebenen Datenkommunikation
gegründet 1989

Erläuterungen zum Domainantrag

Matthias Urlichs / Stephan Niemz
From: Stephan Niemz 
Newsgroups: de.org.sub
Subject: Antragsformular: Domain (Erlaeuterung)
Followup-To: de.org.sub.d
Approved: Stephan Niemz 
Reply-To: domain@sub.net

Archive-Name: domain/antrag.doku

Inhalt: WasSollDas?, Vorgehensweise, Erlaeuterung, Beispiele.

Was sind Domains, wozu brauche ich sie?

Es waren einmal zehn Rechner, die haben sich alle gekannt, sich gegenseitig
  Mail zugeschachert, und alle waren happy.
Es waren einmal hundert Rechner, und man musste Dateien hin- und herschaufeln,
  in denen drinsteht, wer wie mit wem. Diese wurden "Maps" genannt.
Es waren einmal tausend Rechner, das Ganze begann unhandlich zu werden, und
  einige Rechner merkten ploetzlich, dass ihr Name schon mal vergeben war, und
  waren ungluecklich.
Es waren einmal zehntausend Rechner, und die Verwaltung der Grossen Listen
  fing an zu nerven (die US-Maps haben ungefaehr soviele Eintraege).
Es waren einmal hunderttausend Rechner, und das System brach in sich zusammen
  (das Internet hatte das Problem vor einigen Jahren).
Es waren einmal eine Million Rechner (Groessenordnung des Internets), alle
  verstehen und verwenden Domainnamen, keiner kennt genaue Daten des gesamten
  Netzes, trotzdem bzw. gerade deshalb sind alle happy.
(Oder so ungefaehr.)

Domains sind _die_ Methode, die einzelnen Rechnernamen sowie die Wege, auf
denen diesen Rechnern elektronische Post zugestellt wird -- werden soll --,
in eine Hierarchie zu bringen. Folgerung: Es muss nicht mehr jeder alle
anderen kennen, und der Aufwand ist nicht mehr quadratisch, sondern irgend-
wo zwischen logarithmisch und linear.

Die meisten Rechnerbetreiber auf dem Internet haben inzwischen weder Zeit,
Lust, noch ueberhaupt den Bedarf, sich um das Einspielen von Maps zu
kuemmern, so dass Rechner ohne Domainnamen nicht mehr oder nur mit mehr oder
weniger grossen Adressierungskruecken erreichbar sind.

Domainnamen sind im Prinzip nichts anderes als Rechnernamen mit Punkten drin,
zB smurf.sub.org Das Ganze bildet eine Hierarchie: "org" steht ueber
"sub.org" steht ueber "smurf.sub.org" steht neben "ka.sub.org" ... etc.pp.
"org" ist hier die "Toplevel"-Domain. Alle Topleveldomains muessen in den
USA bei der dortigen Netzkoordination registriert sein. Neue Topleveldomains
werden grundsaetzlich nur fuer anschlusswillige Staaten vergeben, in der
Form von ISO-2-Buchstaben-Abkuerzungen ("de", "us"); das Beantragen einer
solchen Domain fuer ein Mailboxnetz ist daher sinnlos.

Logischerweise muessen zwei Domains verschiedene Namen haben, wenn sie
denselben "Vater" besitzen. Ansonsten hat jedes Namenssegment max 64 Zeichen
(ueblicherweise weniger als 12), Namen bestehen aus Buchstaben gefolgt von
Buchstaben oder Ziffern oder Bindestrichen, und der vollstaendige Name ist
weniger als 256 Zeichen lang. Ausnahmen bestaetigen die Regel -- und zwar
die, dass Ausnahmen fast immer zu Problemen fuehren. :-/

Wer mehr wissen will, muss jemanden finden, der eine der diversen
ausfuehrlichen Dokumentationen zu dem Thema uebersetzt. Oder selber eine
schreiben. ;-)
Oder jemand anders fragen. Aber bitte nicht mich, es sei denn es geht
wirklich nicht anders.

Der VzFdpbD eV (Verein zur Foerderung der privat betriebenen Daten-
kommunikation eV; im folgenden Subnetz-Verein genannt) hat sich die
weltweiten Vermarktungsrechte der Domains .sub.org, .sub.de und
.sub.com gesichert, unter der sich alle registrieren lassen koennen,
die das wollen oder brauchen.
Wer E-Mail senden oder empfangen will, die ueber das Subnetz hinausgeht,
braucht eine Domainadresse. (Rein theoretisch geht es auch ohne, mit
Kruecken. Rein praktisch schliessen sich domainlose Adressen und reibungs-
loser Mailverkehr gegenseitig aus.)

sub.org ist dabei der "Normalfall" fuer private Nutzer. Kommerzielle
Aktivitaet ist in sub.org unerwuenscht bzw. via Vereinbarung mit
XLink (unserem Internet-Dienstanbieter) untersagt.
sub.com ist gedacht fuer hauptsaechlich kommerzielle Teilnehmer.
sub.de ist fuer Leute, die unbedingt eine .de-Domain brauchen. ;-)

Mit einem erfolgreichen Antrag auf eine Unterdomain geht die Verantwortung
fuer das korrekte Verhalten (Weiterleiten von Mail, Nicht-Zumuellen des
Subnetzes, Bezahlung von Mailrechnungen) der an die Domain angeschlossenen
Rechner auf den Antragsteller ueber. Unter anderem aus diesem Grund ist das
Formular (welche Verantwortung geht auf wen ueber) mit definiertem "Hand-
shake" (Antrag wird gestellt, Domain wird eingerichtet und bestaetigt,
Daten werden dem Rest der Welt bekanntgegeben) notwendig.

Eine Domain unterhalb von .sub.org / .sub.de / .sub.com einzurichten ist eine
Sache von fuenf Minuten nach Eingang des Antrags. Daneben gibt es noch die
Moeglichkeit, eigene Domains unterhalb von .org / .de / .com zu beantragen.
Das dauert laenger -- momentan ca. eine Woche (zwei Monate bei .de) -- und
ist mit mehr Aufwand verbunden.
Domains unter von .sub.org kann jeder beantragen. Fuer alle anderen Domains
ist eine Vereinsmitgliedschaft erforderlich. (Fuer .org / .com / .de gilt
das natuerlich nur, wenn der Verein die Anmeldung organisieren und die
Nameservereintraege aufsetzen soll.)

Mit einem erfolgreichen Domainantrag geht die Verantwortung fuer die
betreffende Unterdomain automatisch an den Antragsteller ueber. Wer an
einer existierenden Unterdomain teilnehmen will, muss also mit dem
Inhaber dieser Domain reden. 


Mailrechnungen etc.pp.:
Entfaellt fuer Leute, die keine internationalen Mails brauchen bzw. dafuer
nix zahlen wollen. (In letzterem Fall bekommen sie naemlich keine Mails.  ;-)

Der Subnetz-Verein hat folgende Gebuehrenstruktur:
- Nationale Mails sind kostenlos.
- Internationale Mails kosten Geld, naemlich 3 Pf/kByte. Wegen der
  einfacheren Rechnerei ist das kByte bei uns 1000 Bytes gross. Zum
  Ausgleich werden Mailheader nur zur Haelfte mitgerechnet.
- Es gibt ein Freikontingent von 300 kBytes/Quartal je Vereinsmitglied.
- Aus diversen Gruenden gibt es Domains mit internationaler Konnektivitaet
  nur fuer Vereinsmitglieder. Die Mitgliedschaft kostet DM 60/Jahr fuer
  Studenten, DM 120/Jahr fuer normale Menschen und DM 240/Jahr fuer Firmen.
  (Als Studenten gelten auch Arbeitslose, Zivildienstleistende, etc.
  Nachweis mitschicken!)
- Wie all diese Kosten und Kontingente auf die lokalen Teilnehmer in einer
  Unterdomain aufgeteilt werden, ist dem Verein egal.

Ein Mitglied kann waehlen, ob er/sie/es fuer seine Unterdomain eine eigene
Abrechnung vom Verein haben will und/oder welcher Domain das Freikontingent
zugeschlagen werden soll. (Fuer diesen Spezialfall ist auch fuer Unter-
domains ein Antragschnipsel an den Verein zu mailen. _Nach_ Klaerung mit
dem Inhaber der Unterdomain.) Fuer Zwecke der Abrechnerei gelten
"bla.sub.org" und "alles unter *.bla.sub.org, *.*.bla.sub.org, etc.,
ueber die beim Verein nix anderes bekannt ist" als zwei verschiedene
Domains, fuer die aber gemeinsam ein Antrag gestellt werden muss (logisch).
Es ist moeglich, mehrere Domains ueber ein Abrechnungskonto zu fuehren.


Vorgehensweise:  ("+": Dieser Punkt muss vom Antragsteller erledigt werden.)

+ Formular ausfuellen, mailen.
  Bei Problemen mit dem Formular Mail an mich.
+ Eigenen Rechner auf Akzeptanz der Domainnamen umstellen.
  Die Domain sollte aber noch nicht aktiv in Mailadressen verwendet werden.
- Nach zwei Wochen kommt (spaetestens!) Antwort mit Bestaetigung und
  vorgeschlagener Ergaenzung zum Mapeintrag. Falls diese Antwort nicht kommt,
  meckern.  (Ich verspreche hiermit hoch und (h)eilig, alle Antraege
  innerhalb einer Woche zu bearbeiten.) Wenn keine Antwort ankommt, nachfragen!
+ Eigenen Mapeintrag aendern und an zustaendigen Map-Administrator schicken.
- Mapergaenzung kann in de.admin.submaps, in der Datei u.sub.domains,
  erscheinen, muss aber nicht.
+ Abwarten, bis die Domain in u.sub.domains bzw. in der regulaeren Submap
  erscheint.
+ Eigenen Rechner auf aktive Verwendung der Domainnamen umstellen.
  Siehe dazu auch das Kapitel "Domainadressen im Envelope", weiter unten.
  Der alte Name sollte fuer eine Uebergangszeit (Monate) noch erkannt werden.
- Mapergaenzung verschwindet wieder aus u.sub.domains.

Das Erscheinen eines Domainalias in u.sub.domains ist optional, weil
u.sub.domains automatisch generiert wird und es haeufig maptechnische
oder organisatorische Probleme gibt. Beispiel: Der fuer die Domain zu-
staendige Rechner steht (noch) nicht in der Submap.


< Formular
Erklaerung.

XX bedeutet Text, 99 Zahl, JN Ja/Nein, JNB Ja/Nein/Beides.

< Name:	 XXX
< Vorname: XXX
< Firma:	 XXX
< Strasse: XXX 99
< Ort:	 99999 XXX

Sollte offensichtlich sein. (Beachte die neue PLZ.)
<
< Telefon: 0XXX-XXXXX

Die Nummer, unter der der Verantwortliche normalerweise zu erreichen ist.
Sie koennen hier auch mehrere Nummern angeben (Tag, Nacht, Anrufabwimmler,
Fax). Die Nummern werden nicht weitergegeben. Bitte unbedingt die Art
der angegebenen Nummer dazuschreiben -- es bringt nichts, wenn ich wegen
einem dringenden Problem am Wochenende anrufe und nur den Anrufabwimmler
einer Firma erreichen kann.

< Zustaendig (administrativ): XXX@YYY.ZZZ
< Zustaendig     (technisch): XXX@YYY.ZZZ
< 
Mailadresse und evtl. Name des fuer die administrative Seite
(Verantwortlichkeit fuer das korrekte Verhalten der Rechner und der Leute in
der Domain) und fuer die technische Seite (Mapeintraege erstellen, Mailer
installieren etc.) verantwortlichen Menschen.

< Vereinsmitglied: JN
< 
Falls nein, kostet jede Domain einmalig DM 10 und es gibt keine inter-
nationale Konnektivitaet. Mitgliedsantraege, Satzungen, etc., gibt's 
via Mail an info@subnet.sub.net.

< Domainname:    XXX.sub.org

Beispielsweise stadt.sub.org fuer Kleinhintermuehlhausen ;-), oder
murks-ag.sub.com fuer die betreffende Firma. (Vorsicht: Firmenanschluesse
sind an besondere Bedingungen gebunden. Vorher bitte nachfragen.)

Domainantraege fuer Unterdomains (kiste.stadt.sub.org) werden an die
Verantwortlichen fuer die Oberdomain weitergeleitet, wenn vorhanden. Wenn
nicht, muessen sich die Betreffenden (Kleinhintermuehlhausener) zusammensetzen
und jemanden bestimmen, der stadt.sub.org beantragt.

< Rechner (Map): XXX
Der fuer die Domain primaer verantwortliche Computer, der weiss, wie er an
saemtliche evtl. Unterdomains per Mail rankommt. (Name so, wie er in der
Sub-Map erscheint/erscheinen soll.) Anhand dieses Eintrags werden die
Eintraege im Mapschnipsel u.sub.domains generiert; naehere Infos zur Map
finden Sie in der Newsgroup de.admin.submaps.
Falls der Antrag fuer eine Unterdomain ist (zB wegen Mailkosten), koennen Sie
diesen Eintrag weglassen, da fuer das korrekte Routing in diesem Fall der
Inhaber der "Ober"domain zustaendig ist.

< Unterdomains:  JNB
< 
NEIN heisst: Es gibt einen Rechner XXX alias murks-ag.sub.com, aber keine
unterhalb dieser Domain, wie zB sonstwas.murks-ag.sub.com. Die Domain ist
also "nur" ein anderer Name fuer diesen einen Rechner.

JA heisst: es gibt einen Rechner, beispielsweise kiste.stadt.sub.org, der
sich fuer die Domain verantwortlich fuehlt. Es existiert kein Rechner namens
"stadt.sub.org".

BEIDES heisst: Es existiert der Rechner murks-ag.sub.com, der zusaetzlich noch
andere Rechner unter sich duldet; also beide Moeglichkeiten oben.

Bitte machen Sie hier eine korrekte Angabe. Die Angabe von "Unterdomains: J"
und "user@domain.sub.org" in einer der Mailadressen (als Beispiel dafuer, wie
man es _nicht_ machen sollte) fuehrt im Zweifelsfall zu einer verzoegerten
Bearbeitung des Antrags.

< Intl.erreichbar: JN
< Intl.Mail ueber: XXX.XXX.XXX
< 
Falls der Rechner von ausserhalb Deutschlands erreichbar sein soll, JA
angeben, sonst NEIN.
Falls der Betreiber eines am Internet direkt(!) angeschlossenen Rechners sich
bereiterklaert hat, Mail fuer die Domain entgegenzunehmen, bitte hier den
Namen dieses Rechners angeben. (Koennen auch mehrere sein.)
"An das Internet angeschlossen" heisst: Von jedem anderen Internet-Rechner
kann eine direkte TCP/IP-Verbindung zu dieser Maschine hergestellt werden.
Dieser Rechner muss derart konfiguriert werden, dass er Mail an die
betreffende Domain korrekt routet!

Bitte tragen Sie hier _nicht_ den Rechner ein, bei dem Sie pollen, es sei
denn er erfuellt die obige Voraussetzung re Erreichbarkeit.

Falls kein solcher Rechner benannt wird, lassen Sie die "Intl.Mail ueber:"-
Zeile bitte ganz weg. Die Mail laeuft in diesem Fall ueber smurf.sub.org,
kostet drei Pfennig pro Kilobyte, und die nachfolgenden drei Zeilen muessen
ausgefuellt werden.

< Account fuer Abrechnungen:  XXX@YYY.ZZZ
Mailadresse, an die die Rechnungen geschickt werden.

< Limit fuer Domainrechner: XXX DM
Nur ausfuellen wenn "Unterdomains" != "J".
Begrenzt die Mailkosten fuer Mails von und nach user@domain.sub.org auf
maximal XXX DM. Dieser Betrag ist der "Kreditrahmen", bis zu dem Mails
durchgelassen werden.

< Limit fuer Unterdomains:  XXX DM
Nur ausfuellen wenn "Unterdomains" != "N".
Begrenzt die gesamten offenen Mailkosten fuer Mails von und an die an der
Domain angeschlossenen Systeme ("user@rechner.domain.sub.org") auf maximal
XXX DM insgesamt.

Die Abrechnerei wird jeweils pro Domain / Unterdomain durchgefuehrt. Bei
Angabe von "B" bei den Unterdomains (es soll also sowohl ein Rechner
domain.sub.org als auch Rechner innerhalb dieser Domain existieren) gibt es
hier also zwei Konten mit eigenen Begrenzungen. Wenn jemand alle Abrech-
nungen auf dasselbe Konto laufen lassen will, moege er/sie/es das mir mit-
teilen; meine Abrechnungssoftware ist darauf vorbereitet.

Die Grenzen gelten fuer alle Mails auf diesem Konto; es wird keine Abrechnung
fuer einzelne Systeme oder gar Benutzer durchgefuehrt. Wenn ein Einzelsystem
eine eigene Abrechnung wuenscht, z.B. weil der "Kreditrahmen" anders sein soll,
brauche ich dafuer einen Extraantrag.

Es gibt ausserdem die Moeglichkeit, pro Mail eine Groessenbegrenzung
anzugeben. Alle Mails, die groesser sind als dieses Limit, werden
abgewiesen.
Diese Begrenzung ist gedacht fuer technische Hindernisse, z.B. beim
Anschluss eines Mailboxnetzes, in dem groessere Mails nicht geroutet
werden koennen.
Im Fall einer solchen Abweisung wird grundsaetzlich die gesamte Mail
an den Absender zurueckgesendet. Dasselbe gilt fuer Mails, deren Ueber-
tragung den Kreditrahmen sprengen wuerde. Aus technischen Gruenden ist
eine Teiluebermittlung zB der ersten 20 Zeilen nicht moeglich.


Domainadressen im Envelope (WICHTIG!!!)
==========================
! Bei Mails muss grundsaetzlich sichergestellt sein, dass alle Adressen
! in Domainform vorliegen. Dies betrifft insbesondere die Envelope-From-
! Adresse, die z.B. beim rmail-Kommando in der ersten Zeile auftaucht
! ("From   remote from ").  muss hier entweder
! eine Domainadresse sein, oder der empfangende Rechner muss in der Lage
! sein, diesen Namen in Domainform umzuwandeln. (Letzteres ist meistens
! nicht der Fall.)  kann auch in "user@adresse"-Form auftauchen; dann
! muss diese Adresse ebenfalls in Domainform sein.
! Adressen der Form "bla.uucp" sind _nicht_ in Domainform, weil ".uucp" keine
! registrierte Toplevel-Domain ist.

Wenn Mails mit einer nicht domainisierten Quelladresse ins Internet gelangen
(und das kann auch bei innerdeutschen Mails passieren), kann es sein, dass
die Adresse umgeroutet order als ungueltig angesehen wird. Fehlermeldungen
oder andere automatisierte Mitteilungen finden dann nicht mehr ihren Weg
zum Absender. Die Zuverlaessigkeit des Netzes sinkt und ein paar Postmaster
haben mehr Arbeit. :-(

Diese Aenderung in einen Mailer einzubauen ist leider nicht immer ganz
einfach. Hilfestellung kann evtl. der Postmaster des Systems geben, bei
bei dem man pollt. Eine Anfrage in de.admin.mail kann ebenfalls weiter-
helfen. Bei diesem Problem _nicht_ weiterhelfen kann urlichs@smurf.sub.org.

PS: "Envelope" sind die Adressen, die "aussen" auf der Mail stehen und
die angeben, wer diese Mail ausgeloest hat und wo sie hin soll. Im "Header"
dagegen stehen unter anderem die Adressen des Autors und aller Adressaten.
Diese Unterscheidung ist analog zu den Adressen aussen auf einem Brief und
denen im Briefkopf, die auch nicht unbedingt was miteinander zu tun haben
muessen.
Der Header ist in der Norm RFC 822 beschrieben. Die Envelopeangaben sind
abhaengig vom verwendeten Uebertragungsprotokoll. Im Normalfall sollten
alle Rechneradressen in Envelope und Header in Domainform sein.

Diese Adressproblematik hat in der Vergangenheit immer wieder zu Problemen
bei Mailabrechnungen, Kostenzuordnungen, etc.pp. gefuehrt. Im Zweifelsfall
sende eine kurze Mail an postmaster@subnet.sub.net mit der Bitte um
Ueberpruefung.


Beispiel
========

Es sei "junker" einer von mehreren Rechnern in Kleinmichelshausen. Die
Kleinmichelshausener Leute wollen bzw. brauchen fuer ihre Stadt eine Domain.
Als Verantwortlicher stellt sich Hans Fuzzi (Besitzer des Rechners "junker",
aber das ist nicht Voraussetzung -- nur mit dem Besitzer abgesprochen sollte
das Ganze schon sein ;-) zur Verfuegung, drueckt das Managen des ganzen
Krempels aber seinem kleinen Bruder Peter auf (der auf "junker" einen Account
mit den entsprechenden Berechtigungen hat, und ausserdem gewillt ist, sich
das noetige Wissen anzueignen. Das _ist_ Voraussetzung).

Da Hans ein grosses Modem hat, und sich der Postmaster der Uni Sonstwo, USA,
(Internet: sonstwo.in.amiland.edu) bereiterklaert hat, internationale Mail
fuer diese Rechner zwischenzulagern und Anrufe des Rechners Junker zwecks
Abholung derselben entgegenzunehmen, kann er das so im Antrag angeben und hat
sich damit die internationale Mail-Erreichbarkeit gesichert.
(Obiges funktioniert auch mit jedem anderen Rechner auf der Welt, solange
selbiger per TCP/IP weltweit direkt erreichbar ist.)

Name:	 Fuzzi
Vorname: Hans
Firma:	 ---
Strasse: Grossmichelshausener Strasse 123
Ort:	 1234 Kleinmichelshausen
Telefon: 01234-5678 (Tag)
Telefon: 01234-4321 (Anrufbeantworter)

Zustaendig (administrativ): hans@junker.michel.sub.org
Zustaendig (technisch): peter@junker.michel.sub.org

Vereinsmitglied: Ja

Domainname:    michel.sub.org
Rechner (Map): junker
Unterdomains:  Ja

Intl.erreichbar: Ja
Intl.Mail ueber: sonstwo.in.amiland.edu

(Der Abschnitt re Kostenuebernahme faellt weg; das muss mit der Uni Sonstwo
 abgesprochen werden.)

Peter Fuzzi wird den Mapeintrag des Rechners dann so ergaenzen:

junker = junker.michel.sub.org
junker .michel.sub.org(DAILY*2)

Die erste Zeile besagt, dass junker ab sofort auch junker.michel.sub.org heisst.
Die zweite Zeile sagt allen, dass junker fuer die anderen Kleinmichelshausener
Rechner Mail entgegennimmt, wobei jeder spaetestens alle zwei Tage seine Mail
abholt. (Letzteres ist keine "harte" Voraussetzung, macht aber das Mailrouting
robuster.)

Dem Rechner junker muss gesagt werden, wie er die anderen Kleinmichelshausener
Rechner erreichen kann. Das geht am besten ueber einen lokalen Mapzusatz, der
nicht in der normalen Subnetz-Map erscheint; seien fguw, azu, und fduzgdu die
uebrigen Kleinmichelshausener Kisten, dann lautet dieser Zusatz

fguw = fguw.michel.sub.org
azu = azu.michel.sub.org
fduzgdu = fduzgdu.michel.sub.org

Damit ist dann sichergestellt, dass die Rechner in dieser Domain immer erkannt
werden, auch wenn in der Map fuer den Bereich, in dem Kleinmichelshausen
liegt, mal was schiefgelaufen ist (Mapverwalter hat Plattenueberlauf und
schickt versehentlich eine leere Map raus...).

Zusaetzlich werden natuerlich noch Verbindungsdaten benoetigt. Siehe dazu die
Doku in de.admin.submaps, Mapschnipsel u.sub.0.
Die anderen Kleinmichelshausener Rechner, die nur am junker pollen, brauchen
jetzt keinen eigenen Mapeintrag mehr. Sie muessen aber entweder dazu gebracht
werden koennen, selber zu wissen, dass sie jetzt auch nicht nur fduzgdu.uucp,
sondern auch fduzgdu.michel.sub.org heissen, oder der Mailer von junker muss
intelligent genug sein, die Domainnamen beim Senden und Empfangen einzufuegen
bzw. rauszuwerfen.


Rechner frozzel, der auch woanders pollt, wird seinen (subnetz-weiten)
Mapeintrag um

frozzel = frozzel.michel.sub.org

ergaenzen, damit seine Mail direkt zugestellt werden kann und nicht unbedingt
ueber junker laufen muss.


VORSICHT: Domainlose Namen, zB "frozzel" oder "junker", muessen international
eindeutig sein. Siehe dazu die Newsgroup de.newusers, "internationale Submap".

Alternativ koennen die Namen auch nur in Domainform verwendet werden, wenn
den beteiligten Rechnern das beigebracht werden kann.
Bei den meisten Rechnern, wie sie von den Herstellern konfiguriert sind, ist
das aber nicht ohne kleinere (und gelegentlich groessere) Probleme moeglich.
Der Mapeintrag von "fguw" wuerde dann zB so aussehen:

#N fguw.michel.sub.org
#X diverse Kommentare, siehe u.sub.0
#
fguw.michel.sub.org   junker.michel.sub.org(DAILY)

In diesem Fall darf der Rechner "fguw.michel.sub.org" Mail an "fguw" nun
_nicht_ lokal zustellen, sondern muss sie an seinen Smarthost weiterreichen
(im Normalfall der Rechner, ueber den internationale Mails laufen).


Beispiel 2:

Fuer die Domain netz.sub.org werden internationale Mails nicht akzeptiert.
(Aktuelles Beispiel: Z-Netz.)
Der Betreiber des Systems test.netz.sub.org moechte aber trotzdem Mails
bekommen und versenden koennen. Fuer diesen Fall fuellt er aus:

Name Vorname Firma Strasse Ort Telefon Zustaendig(administrativ)
Domainname (hier: test.netz.sub.org)
Unterdomains (meist N)
Account fuer Abrechnungen
Limit fuer Domainnamen  (also fuer test.netz.sub.org)
Limit fuer Unterdomains (falls "Unterdomains != "N")

sowie einen Mitgliedsantrag des Vereins.


So. Wer sonst noch was wissen will, ist hiermit herzlich eingeladen, mich zu
nerven. Aber bitte per Mail, nicht per Telefon.
PS: Ergaenzungsvorschlaege sind ebenfalls willkommen!
   
sub-Netz Webmaster
17.04.1998