|
From: Sunil S. <sh...@bo...> - 2006-03-04 09:39:56
|
Quoting from Matthias Andree's mail on Fri, Mar 03, 2006:
> > The advice being given to force fetchmail to avoid using "TOP" with
> > these buggy servers is to enable the "fetchall" option. The FAQ is
> > littered with this advice for various servers with variety of
> > problems. The problems with "fetchall" option are:
> >
> > - "fetchall" cannot be used with "uidl"
>
> Well, we can fix eventual incompatibilities between these two options
> any time. 6.3.X is open for bug fixes.
Here is a patch for this.
================================================================
Index: fetchmail-6.3/pop3.c
===================================================================
--- fetchmail-6.3/pop3.c (revision 4719)
+++ fetchmail-6.3/pop3.c (working copy)
@@ -894,7 +894,7 @@
*/
last = 0;
*newp = -1;
- if (*countp > 0 && !ctl->fetchall)
+ if (*countp > 0 && (!ctl->fetchall || ctl->server.uidl))
{
int fastuidl;
char id [IDLEN+1];
@@ -902,6 +902,7 @@
/* should we do fast uidl this time? */
fastuidl = ctl->fastuidl;
if (*countp > 7 && /* linear search is better if there are few mails! */
+ !ctl->fetchall && /* with fetchall, all uids are required */
!ctl->flush && /* with flush, it is safer to disable fastuidl */
NUM_NONZERO (fastuidl))
{
================================================================
> The best option would be to use UIDL. Still we'll not be forcing UIDL
> downloads to use RETR in 6.3.X. We can safely do that in 6.4.X: the
> 6.3.X manpage already has warnings in place.
...
> > I don't get this part. If the pop3 server is supporting UIDL and
> > fetchmail is running with the "uidl" option, why bother about the LAST
> > pointer and message flags?
>
> Why bother? Because I promised I'd stop the ESR madness of gold versions
> and promised 6.3.X would be compatible with 6.3.0 when I released 6.3.0.
Ok.
--
Sunil Shetye.
|