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
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
