IDA-Sendmail 5.65
Joachim Astel
Ich scheitere im Augenblick an folgenden Dingen:
1. Mit GCC 1.37 und GDBM liefert sendmail beim Einlesen der
ersten Database (MAILLIB/aliases) nur core-dumps.
2. Mit GCC 1.37 und -ldbm stolpert der Linker beim Compilieren
von ida/aux/dbm ueber die ganzen "dbm_"-Aufrufe ("unresolved...")
Mit diversen Defines (#define dbm_firstkey firstkey) kann man
zwar dennoch ein lauffaehiges Executable erzeugen, jedoch
bekommen die *.dir und *.pag Files beim Erzeugen einer Data-
base (mit "dbm load") 0 Bytes Laenge, und -- das ist besonders
strange -- das File, aus dem die Database erzeugt wird, ebenso.
Mit dem normalen "cc" und "gdbm" ist das Ganze dann doch noch zum Laufen
zu bringen. Nur warum nicht mit GCC? Hat das schon jemand geschafft?
Schoener waer's auf jeden Fall mit GCC (kleineres Executable).
Ich kenne mich mit den Funktionalitaeten der einzelnen DBM's nicht genau
aus. Sind die Aufrufe von dbm mit denen von gdbm (die die gleichen Namen
haben, nur eben zusaetzlich mit dbm_ anfangen) etwa nicht 'kompatibel'?
(Was die Fehlfunktionen unter Punkt 2. natuerlich erklaeren wuerde...)
3. Wenn ich dem "bsmtp"-Kommando einen Packen Mails zum
Frass vorwerfe (natuerlich mit HELO am Anfang, jeweils
MAIL From:, RCPT To:, DATA, Mail selbst und "."), wird
nach erfolgreichem Versenden von einer Mail die darauf-
folgende "MAIL From:"-Zeile einfach ueberlesen:
-- Auszug der _Ausgabe_ von bsmtp, wenn ich ihn per stdin fuettere:
[...]
354 Enter mail, end with "." on a line by itself
250 Ok
-- An dieser Stelle muesste eigentlich "MAIL From" bestaetigt werden.
250 <@jattmp:tex...@bagdad.jat.imp.com>... Recipient ok
503 Need valid MAIL command
^^^^^^^^^^^^^^^^^^^^^^^
-- Und diese Fehlermeldung entsteht dann noch dazu.
Was kann man dagegen am besten tun?
Schwitzing and keeping on sourcing...
+++ Achim +++
_______________________________________________________________________________
Joachim Astel, Wiesenweg 4, D-8566 Leinburg, BBS: (+49)9120-9939 (300-2400 bps)
Joachim Astel
> 503 Need valid MAIL command
> ^^^^^^^^^^^^^^^^^^^^^^^
> -- Und diese Fehlermeldung entsteht dann noch dazu.
Der BSMTP-Fehler ist inzwischen auch schon lokalisiert: Sendmail
macht beim "MAIL From:"-Kommando einen fork() und sucht seine
Databases als Child im Hintergrund ab, waehrend der Parent-Process
im Vordergrund schon auf den naechsten Befehl (RCPT...) wartet.
Das mag auf einem normalschnellen System zwar ganz effizient sein,
dem XENIX-System gefiel das aber gar nicht.
NEUES Problem:
Unter XENIX 2.3.2 gibt es offensichtlich immer noch keinen rename()-
Aufruf (oder wie war das? Habe ich den und er ist bloss nicht doku-
mentiert?) Den kann man bekanntlich durch rename() und unlink()
nachbilden. So weit so gut...
Der Haken an der Sache: Bei der neuen Sendmail-Version wird ein
Filedescriptor mit flock() traktiert, danach erst geoeffnet.
Spaeter wird dieses geoeffnete File renamed. Bei einem System
mit rename()-Aufruf scheint das problemlos machbar zu sein.
Allerdings stoert sich mein unlink()-Befehl bei der rename()-
Nachbildung an dem Lock-Status. Somit gibt's eine nette Fehler-
meldung in meinem syslog und das Lock-File haengt fuer den Rest
des Lebens als t*-File in der Queue herum.
Genug ueber die Hintergruende gesuelzt, hier meine Fragen:
- Gibt es unter SCO XENIX einen rename()-Ersatz, der
auch ein gelocktes File umbenennen kann (so dass
das neue File auch wieder gelockt ist?)
Nochmal die alte Frage:
- Was ist der gemeine Unterschied zwischen DBM und GDBM?
Always sources auseinanderpfluecking
Christian Kaiser
)Hat schon einmal jemand den IDA-Sendmail 5.65 auf SCO XENIX angepasst?
)Ich scheitere im Augenblick an folgenden Dingen:
)
) 1. Mit GCC 1.37 und GDBM liefert sendmail beim Einlesen der
) ersten Database (MAILLIB/aliases) nur core-dumps.
)
) 2. Mit GCC 1.37 und -ldbm stolpert der Linker beim Compilieren
) von ida/aux/dbm ueber die ganzen "dbm_"-Aufrufe ("unresolved...")
Tja, die Utilities wollen im Gegensatz zu sendmail unbedingt
Berkeley-ndbm-Funktionalitaet (erkennbar an den dbm_*-Funktionsnamen).
Leider ist dbm + ein paar #defines ungleich ndbm; u.a. kann ndbm mehrere
dbm-Files zur gleichen Zeit offen haben, dbm kann das nicht (was wahr-
scheinlich die genannten Symptome ausloest).
gdbm bietet alle Interfaces (dbm, ndbm, gdbm).
) 3. Wenn ich dem "bsmtp"-Kommando einen Packen Mails zum
) Frass vorwerfe (natuerlich mit HELO am Anfang, jeweils
) MAIL From:, RCPT To:, DATA, Mail selbst und "."), wird
) nach erfolgreichem Versenden von einer Mail die darauf-
) folgende "MAIL From:"-Zeile einfach ueberlesen:
Ha! *Hab'* ich lang nach der Loesung dieses Problems gesucht!
Such mal in src/main.c nach folgendem Code:
if (OpMode == MD_SMTP || OpMode == MD_BSMTP) {
bool batched = (OpMode == MD_BSMTP);
OpMode = MD_SMTP;
#ifdef notdef
/* test without this first */
/* have to run unbuffered or else will lose synchronization */
if (batched)
setbuf(InChannel, (char *) NULL);
#endif /* notdef */
smtp(batched);
}
Irgendein Schlauberger hat hier einen #ifdef eingefuegt, der verhindert,
dass stdin ungepuffert betrieben wird. Leider ist das mit den SYSV-stdio's
aber anscheinend unbedingt notwendig, wenn stdin zwischen mehreren geforkten
Prozessen geteilt werden soll.
Abhilfe: #ifdef raus, und alles geht (nur halt quaelend langsam bei grossen
Mails :-( )
)Was kann man dagegen am besten tun?
Artikel in sub.os.xenix schreiben... :-)
Gruesse,
Christian
--
Christian Kaiser, Munich, Germany Mail: c...@chi.sub.org, c...@chiuur.UUCP
"A free society is one where it is safe to be unpopular." -- Adlai Stevenson