[fetchmail-devel] Assorted minor bugs

[Brian C. <B.C...@po...>]

On Mon, Nov 08, 2004 at 01:01:31AM +0100, Matthias Andree wrote:
> Can you try the tarball from
> http://home.pages.de/~mandree/tmp/fetchmail-6.2.6.tar.bz2

Thanks for making this interim release.

I reported some problems with 6.2.5 and posted patches to the old
fetchmail-friends list in April, but none appear to have been incorporated
into 6.2.6. The small patchset I keep is attached, and still applies cleanly
to 6.2.6.

The bugs were described more fully on fetchmail-friends, but in summary:

(1) There is a completely unnecessary sleep(3) after logging in. I cannot
see any justification for this; the comment in the code talks about mailbox
locking and tempfiles, but when the POP3 server has replied "+OK" to a
login, then it is by its own admission locked and ready to receive commands.

I am guessing this was a workaround for some ancient and broken server, but
I think it should be removed as it just wastes time and resources.

(2a) When talking to an SSL server, where the certificate name does not
match, then annoyingly a 'certificate name mismatch' error is given three
times. The patch changes it so that this warning is only given if you select
verbose or sslcertck, to be the same as the other certificate
warnings/errors.

(2b) When talking to an SSL server, honour the sslcertpath option even if
sslcertck is not set (currently it is ignored); this allows you to use
fetchmail -v to get useful information on the certificate chain, even if
it's not being strictly enforced using sslcertck.

(3) There is a bug where 'showdots' fails to work if there are two 'poll'
entries in .fetchmailrc; I spent a while chasing this down, and it turns out
to be an option parsing bug. Full description here:
http://lists.ccil.org/pipermail/fetchmail-friends/2004-April/008518.html

This URL also contains separately the patches which are combined in the
attached bundle.

You might want to change my fix for (1) though: instead of #ifdef BOLLOCKS
then just remove the sleep and the (incorrect) comment associated with it
:-)

Regards,

Brian.