Quoting from Matthias Andree's mail on Sun, Aug 24, 2003 at 05:38:04AM +0200:
Note that imap servers do not allow adding custom flags.
Then, is there any way of probing if such a capability is supported by
the IMAP server? Is there any keyword in the output of either
CAPABILITY or SELECT?
I believe that only the first letter of the flag is actually used by
the IMAP server. So, \Fetchedmail is probably going to be the same \F
or \Flagged (which is an available flag).
A minor issue: The UIDVALIDITY number should be saved separately per
mailbox. If it changes across sessions, the saved UIDs should be
A major issue: The UIDs as saved in .fetchids do not save protocol
information. Assume that a server supports both IMAP and POP3 login
for the same mailbox. Are the UIDs to be assumed to be the same for
both IMAP and POP3? Or, should we store IMAP UIDs in a different file?
This issue is relevant when the protocol is auto and the imap server
is temporarily refusing connections,
1) Socket error from mail server during readbody() is not handled
correctly for MDA and BSMTP. On socket error,
the MDA pipe is closed. The MDA then delivers the incomplete mail!
The only solution would be to kill the MDA first before closing the
MDA pipe (this may not work if the MDA is a setuid program and has
changed its uid, but this is a side issue).
Do child setuid programs dodge signals from their former parent? Nasty,
but nevermind, the workaround is to disallow setuid MDAs. We know the
path, so we can stat().
No, the path is not known. The MDA is invoked using popen() which uses
/bin/sh which then interprets the MDA line. In particular, shell
substitution rules are applied to find out the command. So, it is not
possible to find out the path in cases like this without going into
mda "PATH=$PATH:~/bin mymda"
However, the problem is that the pid is not known currently as popen()
does not return the pid of the child. This means that a modified
version of popen() which returns both the fd and the pid should be
Unless the child changes the process group, kill(0,SIGTERM) should to,
provided we don't choke on SIGTERM ourselves.
Well, the pid is still required to find out if the MDA has exited
early. Assume that we get a SIGCHLD while we are still reading the
body. Unless the pid is known, there is no way of finding out if this
child or some previous child has exited.
Yup. Some alternatives exist though.
1. truncate BSMTP batch to former size (but that's ugly);
There is support for saving bsmtp output to stdout. So, truncation is
out of question.
I wonder on the "traffic" issue if fetchmail should keep a record of
UIDs from failed mail and set a steadily increasing fetch interval for
these that is clamped at 24hrs or 50 runs, whichever comes first.
A separate file for problematic UIDs? That seems to be a good idea.