Sunil Shetye <shetye(_at_)bombay(_dot_)retortsoft(_dot_)com> writes:
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?
I once had code that saved UIDs in a more compact format, grouped by
server, but best would be to save UIDs in server-specific files in a
separate .fetchmail directory (that could then also hold configuration
and lock file). Any non-printable character, _ and - would be escaped by
_XX (XX being the hex code of the character), and I'd suggest naming the
ID after server-port-proto-options. We'd also need to save the
UIDVALIDITY.
This issue is relevant when the protocol is auto and the imap server
is temporarily refusing connections,
"proto=auto" is a very bad idea, generally speaking. It may convenience
the user, but the concept is botched because the machine might fall back
to a POP3 server without SSL and send password in clear text or
something. automating authentication must not happen IMHO.
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
shell parsing:
mda "~/bin/mymda"
mda "$MYMDA"
mda "PATH=$PATH:~/bin mymda"
Then we'd better stop using popen at all. Although I don't see
implementation defects that could expose untrusted data to shell
parsing, I'd rather use execve directly.
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.
Correct. If we had just one child, that'd be fine, but plugin might
spoil the whole project.
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.
Either that or storing flags with UIDs. Another issue that should be
fixed if the UID code is touched is the linear search that fetchmail
does, the UIDs are best read into a collision-attack-proof hash or into
a balanced tree or something (Damian Ivereigh's redblack trees come to
mind, it's a LGPL'd implementation, available on sourceforge.)
I once had a new fetchids format that was both more compact, more robust
and faster to read, it had sections per-server and then used netstrings
to store the UID in case some rotten server decided to stuff NUL bytes
or something. Shouldn't happen, but also lends itself to alloc because
you know the size before reading the actual
string. http://cr.yp.to/proto/netstrings.txt
--
Matthias Andree