TODO

Was muß noch getan werden?

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

- sprintf gehört 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 einzuschränken, wenn
  zcall von Cron gestartet wird...

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

- MA: call.c aufräumen. Alle Checks, PreArc VOR dem Onlinegehen!

- AIX: rtty.c: cfmakeraw?

### Problems:

- einfaches Return in Headerzeilen.

- News verwerfen, wenn ordnungsgemäße Wandlung nicht möglich.

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

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

### Extensions:

- Passworte case-sensitiv pruefen.

- Kein Date:-Header (legal) führt 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: vernünftig 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 könnte 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 zusätzliche BEZ
  unterbleiben, weil er keine zusätzliche Information trägt. Allerdings
  wäre ein Pointprogramm, das dann Bezüge falsch verkettet, dem Vorwurf
  ausgesetzt, daß es defekte Nachrichten nicht korrekt handhaben kann,
  obwohl es das mühelos könnte.

### 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.

- Batchfähige Verwaltungsroutinen mit perl
  TCL/TK Frontend

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

- support für mail: exim zmail

###