Re: Cyrdeliver mit jedem User ausführen
Hallo zusammen,
On Mon, Feb 10, 2003 at 04:07:47PM +0100, Hans Wilmer wrote:
^^^^^^
sorry, daß ich erst jetzt antworte, aber bei dem Traffic hier vergißt man
schon mal was. :)
> On Sat, Feb 08, 2003 at 11:41:01PM +0100, Mike Dornberger wrote:
>
> > Daher ein kleines C-Programm, welches ich cyrdeliver_wrapper genannt habe:
> >
> > #include <pwd.h>
> > #include <sys/types.h>
> > #include <errno.h>
> > #include <unistd.h>
> > #include <string.h>
> >
> > int main(int argc, char *argv[]){
> > struct passwd *userinfo;
> >
> > /*if (argc != 2) return EINVAL;*/ /* invalid argument, too many/too
> > few args */
> > if (argc != 2) return ECANCELED; /* invalid argument, too many/too
> > few args; EINVAL is also returned
> > by execle */
>
> Bei Fehlern würde ich EX_TEMPFAIL an den MTA zurückgeben, damit die
> Mail nicht gleich endgültig abgewiesen wird.
Ich müßte mal ausprobieren, wie eigentlich cyrdeliver reagiert, wenn man es
mit fehlerhaften Argumenten aufruft und dieses Verhalten nachahmen. Läuft
aber auf eine (so oder so) fehlerhafte .procmailrc hinaus. Sollte das der
Sender einer E-Mail von mir erfahren? Gerade wenn ich da an Spam-Mail
denke... Diesen Leuten möchte ich eigentlich nicht zeigen, daß der von ihnen
angeschriebene Account noch aktiv ist.
> > userinfo = getpwuid(getuid()); /* get user info from /etc/passwd for
> > calling user */
> > execl("/usr/sbin/cyrdeliver", "cyrdeliver", "-a", userinfo->pw_name, "-m",
> > argv[1], NULL);
>
> Funktioniert das auch bei seltsamen Namen? Das Programm sollte
> entsprechend reagieren, wenn EACCES zurückkommt oder -1. Siehe auch
> man errno und popen().
getopt (ich nehme mal an, daß diese Funktion von cyrdeliver verwendet wird)
sollte daß so als Argument zum Schalter -a erkennen. Da mein kleines
Programm im Prinzip "unsichtbar" zwischen procmail und cyrdeliver sitzt, (ich
mache keinen fork sondern ersetze meinen Prozeß mit cyrdeliver, das dann
auch stdin, ...out usw. erbt,) soll cyrdeliver sich auch genau so beschweren,
wie es das täte, wäre mein Programm nicht da (und man würde z.B. mit
globalen procmailrcs arbeiten).
> > return errno; /* if execle fails, it sets errno; see man execle or man
> > execve */
>
> siehe man errno
>
> Eine Fehlermeldung auszugeben, wäre schon irgendwie sinnvoll :)
Hm, ich habe noch nicht ausprobiert, was passiert, wenn ich cyrdeliver
umbenenne, sodaß es nicht ausgeführt werden kann. Da es dann ein (mehr oder
weniger) permanenter Fehler ist, daß die E-Mail nicht zugestellt werden
kann, wird der MTA sich entsprechend verhalten und womöglich die E-Mail
entweder mit "Internal server error" oder sowas bouncen oder postmaster
informieren. Wenn die E-Mail aber bounced, braucht es doch den Sender nicht
zu interessieren, daß cyrdeliver nicht ausgeführt werden konnte. (S.a. oben,
Spam.)
> > /* Hm, I cannot see in man page, what cyrdeliver returns... */
> >
> > }
>
> Ggf. gibt cyrdeliver einen permanenten Fehler zurück, wenn die Mailbox
> über Quota ist. Außerdem kann (bzw. wird) es eine Fehlermeldung nach
> stdout (oder stderr?) ausgeben, die Du entsprechend an den MTA
> weiterleiten müßtest, damit dieser einen Bounce mit sinnvoller
> Fehlermeldung erzeugen kann. Was es sonst noch zurückgibt, weiß ich
> nicht, aber ich kann mir vorstellen, daß irgendwas kommt, wenn
> z. B. die angesprochene Mailbox nicht existiert.
Nun, wenn cyrdeliver ausführbar ist, kehrt der Aufruf von exec nie in mein
Programm zurück. Da, wie oben schon gesagt, die fds vererbt werden, brauche
ich mich um cyrdeliver->procmail nicht zu kümmern.
Ich habe gerade nochmal in man cyrdeliver geschaut, da steht tatsächlich
nicht, was passiert, wenn die Mailbox (-m) nicht existiert. Nur was
passiert, wenn die ACLs nicht stimmen. Wird wohl ein Bugreport fällig...
(Nunja, man könnte es so interpretieren: Nicht vorhandene Mailbox => User
hat für diese Mailbox das (p)osting-Recht nicht => deliver nach INBOX.
Selbst wenn die Logik so ist, sollte es trotzdem in der man page explizit
stehen.)
> Ob die Fehlerbehandlung mit dem zwischen MTA und cyrdeliver hängenden
> procmail funktioniert, sei dahingestellt ...
Ja, das wäre auch noch etwas, was ich/man ausprobieren/besser recherchieren
müßte...
> Wie stellst Du sicher, daß bei der Verwendung Deines Programms keine
> Mails verlorengehen?
Bis jetzt... nicht wirklich. Bei mir hängt in der .procmailrc bis jetzt
hinten ein:
:0w
| $IMAP
(Da die Generierung einer "From "-Zeile in meinem MTA abgestellt habe, da
ich ja alles im IMAP haben möchte, kann ich nicht ohne weiteres nach
/var/mail/usermbox zustellen lassen.)
Danch sollte es wohl eine Fehlermeldung von procmail->MTA geben, wenn
cyrdeliver von meinem Programm nicht gefunden wurde. Um richtig transparent
zu werden, müßte ich hier das Verhalten von procmail nachahmen, wenn es das
Programm, welches mit | aufgerufen werden soll, nicht finden kann.
(Achso, jetzt muß ich da noch was anfügen, daß nach der Zeile auch kein
deliver nach /var/mail/user passiert, wenn cyrdeliver_wrapper fehlschlägt.
S.a. Klammer oben.)
Besser wäre natürlich, wenn die E-Mail dann z.B. im /var/mail/user
landet oder evt. postmaster informiert wird (der dann hoffentlich nicht auch
so eine "fehlerhafte" .procmailrc besitzt *g*).
Wie immer bläht die Fehlerbehandlung die Sache ziemlich auf. :)
Hier also als Zusammenfassung nochmal die Punkte, die (bei mir) bis jetzt
noch offen sind:
(i) Die ~/.procmail/log sieht durcheinandergewürfelt aus. Könnte ein lock
Problem sein, da auch scheinbar einige Logs über manche E-Mails fehlen.
Vermutlich werdem beim fetchmail-Aufruf vom MTA mehrere Instanzen von
procamail gleichzeitig aufgerufen. ("Eigenen" lock-Mechanismus über die
.procmailrc implementieren? Bugreport?)
(ii) Auf der Konsole sehe ich nicht mehr, wenn ich neue E-Mail bekommen
habe. Die meisten Programme schauen ja nach dem Datum von z.B.
/var/mail/user oder ~/Mail/...
(iii) Sollte man einen lokalen User ins Killfile gesteckt haben, kann er
einen trotzdem in der INBOX nerven. :)
(iv) Können E-Mails verloren gehen? (Fehlerbehandlungen: keine Messages ohne
"From "-Zeile dürfen in der /var/mail/usermbox landen; was machen, wenn
der Aufruf von cyrdeliver nicht klappt; ...)
Naja, wenn die Punkte mal abgehakt sind, schreibe ich vielleicht mal ein
fetchmail->MTA(exim)->procmail->cyrus imapd(v. 1.5.19) - (mini)HOWTO. Da ich
bis jetzt aber mit den Punkten (außer (i)) leben kann (und eigentlich
schonmal recht zufrieden bin), wird das wohl aber noch eine Weile dauern. :)
Grüße,
Mike
Reply to: