Was mu noch getan werden?

- autoconfig/xprog.c komplettieren bzgl. gkermit/zmodem etc

- sprintf gehrt abgeschafft. Alternativcode ist da!

- Zcall: Bei Abbruch bleibt das Empfangsdirectory mit dem caller.zip da.
- Zcall: Abbruchcodes sollten nochmal berarbeitet werden

- Backout fuer ZConnect

- Januslogin: offene Dateien?

- flock() verwenden.

- BUG: anruf() initialisiert die Schnittstelle nicht richtig besteht
  weiter, wird durch meinen Patch NICHT behoben.

- Das ganze fork()-Gezumpel sollte mal in eine Unterfunktion verbannt und
  mit Fehlerhandling versehen werden.

- Warum klappt O_NONBLOCK unter NetBSD nicht?

- isatty(2) benutzen, um die Ausgaben auf stderr einzuschrnken, wenn
  zcall von Cron gestartet wird...

- Ausgehende Puffer beim Janus-Netcall gehen manchmal verloren!!
  Zmodem hack?

- MA: call.c aufrumen. Alle Checks, PreArc VOR dem Onlinegehen!

- AIX: rtty.c: cfmakeraw?

### Problems:

- einfaches Return in Headerzeilen.

- News verwerfen, wenn ordnungsgeme Wandlung nicht mglich.

- generell Fehlerhafte Nachrichten berspringen.
  ohne das der ganze Puffer verworfen werden mu.

- Maps-Nachrichten enthalten den Header 'STAT: CTL'. Nachrichten, die diesen
  Header enthalten, drfen niemals gebounced (schreckliches Wort) werden.
  Wissen die ZConnect<->RFC Konverterbastler, da sie bei einer "STAT:
  CTL" Zeile den Envelope-Absender auf <> setzen mssen?

### Extensions:

- Passworte case-sensitiv pruefen.

- Kein Date:-Header (legal) fhrt zu Nachricht ohne EDA (illegal).

- MIME-Verpackung eines langen Headers ohne Whitespace (z.B. PGP-KEY)

- Header-Inhalt auf ungueltige Zeichen pruefen

- GATE sollte base64 statt uuencode kodieren.

- Quoted-printable decodieren! Optional auch erzeugen?
  Binaerfiles auch in Base64 dekodieren (oder mpack aufrufen?)

- WAB: vernnftig behandeln, speziell beim ersetzen von Point-ABS: !!!

- Wenn eine rfc-Mail - einige Mailer machen das anscheinend so, ich habe es
  bei verschiedenen beobachtet - sowohl den Header In-Reply-To:<Bezugs-ID>
  als auch den Header Reference:<Bezugs-ID> mitbringen, werden daraus zwei
  identische BEZ: Bezugs-ID. Ich knnte mir vorstellen, da einige
  Pointprogramme dann Probleme mit der Bezugsverkettung bekommen.
  Reference: hat aber in Mail nichts verloren IMO. Wenn In-Reply-To:
  dieselbe Message-ID mitbringt wie References, sollte der zustzliche BEZ
  unterbleiben, weil er keine zustzliche Information trgt. Allerdings
  wre ein Pointprogramm, das dann Bezge falsch verkettet, dem Vorwurf
  ausgesetzt, da es defekte Nachrichten nicht korrekt handhaben kann,
  obwohl es das mhelos knnte.

### Features:

- Es kann nur ein Call-Dev. angegeben werden. Ich moechte aber mehrere angeben
  koennen, deren locks dann in dieser Reihenfolge geprueft werden und dann zum
  Anrufen genutzt werden.

- Batchfhige Verwaltungsroutinen mit perl
  TCL/TK Frontend

- TCP/IP support auch in zcall,
  evtl. 'ftp' als Transfer-Protokoll integrieren

- support fr mail: exim zmail

###
