Sunil Shetye <shetye(_at_)bombay(_dot_)retortsoft(_dot_)com> writes:
For custom \Fetchedmail flag:
I had asked for such a feature of using an available (but unused) flag
for IMAP. You may refer to it under the thread
"fetchmail and email clients" at:
<http://lists.ccil.org/pipermail/fetchmail-friends/2002-March/001773.html>
The response then was not very encouraging :-(
Well, I decided to give this idea a new try anyways. If fetchmail sees
itself as mail transport rather than as MUA, it has no business checking
\Seen flags.
Note that imap servers do not allow adding custom flags.
Some do.
A minor issue: The UIDVALIDITY number should be saved separately per
mailbox. If it changes across sessions, the saved UIDs should be
discarded!
Yup.
Another minor issue: Should the \Seen flag be set on such mails?
It'd better retain the previous state because fetching doesn't mean
reading. Peeking at the mail may be feasible.
1) Socket error from mail server during readbody() is not handled
correctly for MDA and BSMTP. On socket error,
[for MDA]
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().
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
used.
Unless the child changes the process group, kill(0,SIGTERM) should to,
provided we don't choke on SIGTERM ourselves.
[for BSMTP]
the BSMTP file is closed! Since the terminating .<CR><LF> has not been
sent, the next mail which will be appended in the next session will
get merged into this mail!
The only solution is to save the whole mail into a separate file
first. Only after receiving the complete mail should the mail be
appended to the bsmtp file.
Yup. Some alternatives exist though.
1. truncate BSMTP batch to former size (but that's ugly);
2. save one mail per file and batch up the real BSMTP transaction only
on demand or after complete run.
Apart from fixing the above bugs, a host of options will have to be
added like bouncemda, bouncesmtphost, mta, bouncemta, options for
doublebounce, etc. Whether adding so many options is going to make it
easier or difficult to use fetchmail is an important issue.
Using separate settings for bounces to separate them from regular
sessions doesn't make sense to me. Configure doublebounce? Not
necessarily, postmaster should do. An option to turn them 2bounces off
and treat them as failed might be OK.
OTOH, if adding options removes overloading from other options, that's a
good thing, because it removes a batch of "ifs" and "whens" from the
documentation. Less magic may be less convenient to use, but it's so
much easier to debug.
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.
--
Matthias Andree