fetchmail-users — User questions and discussion

Re: [fetchmail-users] Fetchmail socket error.

[Matthias A. <mat...@gm...>]

Ernst Verhaar <e.v...@vi...> writes:

> fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {375012}
> (375012 body octets)
> ******************.***************.*********************.**********
> **********.***************.***************fetchmail: socket error while
> fetching from vid_dbmanta@212.204.236.251
> fetchmail: 6.3.2 querying 212.204.236.251 (protocol IMAP) at Fri Mar 24
> 16:30:12 2006: poll completed
> fetchmail: Query status=2 (SOCKET)
>
> According to the FAQ, I should set the MTU to 552. This doesn't help.
> I tried fetchmail versions 6.2.5.2 (included in Suse 10) and fetchmail
> 6.3.2 (builded on Suse 10) On the same machine. I also tried fetching
> the same emailbox on a different machine Fedora Core 4 (fetchmail
> 6.2.5.5). And on a Fedora Core 4 machine at a different
> Internetprovider. I get the same error everytime...
>
> Fetchmail 6.2.5 on an very old Slackware distro runs
> perfectly. (different machine, same and different internet provider).

This appears to happen a few kBytes into a larger transfer.

Are you (on the client end) using routers, Linux-based firewalls, other
firewalls along the way? Does the server use such? Or FreeBSD ipfw,
ipfw2, ipfilter?  

Are those devices or filters letting ICMP traffic through between server
and client? What physical network is between server and client?
Modem/PPP, DSL, ...?

Is fetchmail -vvv any more helpful? Perhaps attaching strace?

> The host with is being contacted is a FreeBSD running both dovecot and
>imap-uv (different port).

Which FreeBSD version is the server running?

> Could this be a fetchmail error? Or is it a combination between a
> specific Distribution and a specific fetchmail version?

Theoretically possible, but both unlikely. Socket errors are reported to
fetchmail by the network stack built into your kernel (or kernel
module), and 6.3.2 has been around for a while, if there'd been
systematic incompatibilites, we'd pretty surely see more reports.

Are wireless networks (WLAN, IEEE 802.11*) involved?

On any Linux machine that has troubles, if it runs netfilter (firewalls,
SUSEfirewall for instance), run:
/sbin/sysctl net.ipv4.netfilter.ip_conntrack_tcp_be_liberal=1
to work around Linux kernel bugs.

Perhaps running [t]ethereal or tcpdump on either side sheds some light
about the nature of the socket error, if it starves, if it's reset (TCP
RST), shut down (FIN), if it's killed (some ICMP) or what else.

-- 
Matthias Andree

Re: [fetchmail-users] Fetchmail socket error.

[Rob M. <rob...@gm...>]

On 3/24/06, Ernst Verhaar <e.v...@vi...> wrote:
> Hi All,
>
> I have some troubles with fetchmail. Fetchmail dies every time with a
> socket error:

Forgot to ask - did you build fetchmail from source, or are you using
a pre-built binary?

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

Re: [fetchmail-users] Fetchmail socket error.

[Rob M. <rob...@gm...>]

On 3/24/06, Ernst Verhaar <e.v...@vi...> wrote:
> Hi All,
>
> I have some troubles with fetchmail. Fetchmail dies every time with a
> socket error:
>
> fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {375012}
>  (375012 body octets)
> ******************.***************.*********************.**********
> **********.***************.***************fetchmail: socket error while
> fetching from vid_dbmanta@212.204.236.251

Communication failure with 212.204.236.251

> Fetchmail 6.2.5 on an very old Slackware distro runs perfectly.
> (different machine, same and different internet provider).
<---SNIP--->
> ----- Question ----
> Could this be a fetchmail error? Or is it a combination between a
> specific Distribution and a specific fetchmail version?
> --------------------

Does 6.3.2 work from the Slackware box?  If so it suggests a problem
with the FC4 boxes.

--
                 Please keep list traffic on the list.
Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn't become a monster.                  Friedrich Nietzsche

[fetchmail-users] Fetchmail socket error.

[Ernst V. <e.v...@vi...>]

Hi All,

I have some troubles with fetchmail. Fetchmail dies every time with a 
socket error:

fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {375012}
 (375012 body octets) 
******************.***************.*********************.**********
**********.***************.***************fetchmail: socket error while 
fetching from vid_dbmanta@212.204.236.251
fetchmail: 6.3.2 querying 212.204.236.251 (protocol IMAP) at Fri Mar 24 
16:30:12 2006: poll completed
fetchmail: Query status=2 (SOCKET)

According to the FAQ, I should set the MTU to 552. This doesn't help.
I tried fetchmail versions 6.2.5.2 (included in Suse 10) and fetchmail 
6.3.2 (builded on Suse 10) On the same machine. I also tried fetching 
the same emailbox on a different machine Fedora Core 4 (fetchmail 
6.2.5.5). And on a Fedora Core 4 machine at a different 
Internetprovider. I get the same error everytime...

Fetchmail 6.2.5 on an very old Slackware distro runs perfectly. 
(different machine, same and different internet provider).

The host with is being contacted is a FreeBSD running both dovecot and 
imap-uv (different port).

----- Question ----
Could this be a fetchmail error? Or is it a combination between a 
specific Distribution and a specific fetchmail version?
--------------------

I am happy to provide additional information and access to the 
host-machine running dovecot and imap-uv, if this is needed.

Kind regards,

Ernst

Re: [fetchmail-users] Fetchmail crash (SIGSERV)

[Matthias A. <mat...@gm...>]

Voldemar <de...@it...> writes:

[crash with fetchmail 6.3.2 on FreeBSD 4.11-RELEASE i386]
> $ cat .fetchmailrc
> poll inet.tsu.ru    

[...]

> poll pop3.mail.ru   

[...]

> poll 212.192.112.206

[...]

> It seems to me, the function getaddrinfo returns 0 (no error),
> but thus res->ai_canonname == 0, that leads SIGSERV at attempt
> strcpy(0) in xmalloc.c:xstrdup.

Upon closer inspection in the FreeBSD sources found at
<http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/net/getaddrinfo.c>,
I think it's the numeric hostname that caused the problem.

That particular issue was fixed in FreeBSD 5.4/6/7, with MFC
getaddrinfo.c version 1.55 (January 2005). I am requesting a backport
for 4.10, 4.11, 4-STABLE and 5.3 from the FreeBSD security officer.

-- 
Matthias Andree

Re: [fetchmail-users] Fetchmail crash (SIGSERV)

[Matthias A. <mat...@gm...>]

Voldemar <de...@it...> writes:

> $ uname -a                                                                      
> FreeBSD netadmin.ssmu.ru 4.11-RELEASE FreeBSD 4.11-RELEASE #3: Wed Aug 17 10:31:
> 07 OMSST 2005     ro...@ne...:/usr/src/sys/compile/netadmin  i386
...
> $ gdb fetchmail
> ...[skip]...
> Program received signal SIGSEGV, Segmentation fault.
> 0x8061c20 in xstrdup (s=0x0) at xmalloc.c:56
> 56          p = (char *) xmalloc(strlen(s)+1);
> (gdb) backtrace
> #0  0x8061c20 in xstrdup (s=0x0) at xmalloc.c:56
> #1  0x805478d in do_session (ctl=0x8081600, proto=0x80642c0, maxfetch=0) at driver.c:1030
> #2  0x8055573 in do_protocol (ctl=0x8081600, proto=0x80642c0) at driver.c:1630

[...]

> It seems to me, the function getaddrinfo returns 0 (no error),
> but thus res->ai_canonname == 0, that leads SIGSERV at attempt
> strcpy(0) in xmalloc.c:xstrdup.

Yes, that's what I'd have guessed from your backtrace, too.  BTW, thanks
for a detailed report. I'd wish more reports were as complete as yours
was - very useful. This saved me any asking further questions.

> I do not know, whether is a mistake: fetchmail or incorrect behaviour
>libc.

Probably unfortunate coincidence. FreeBSD probably implemented
getaddrinfo() (from KAME perhaps) before IEEE Std 1003.1-2001 stipulated
the final specification, and someone forgot to update it to the
standard.

>My variant of patch (not assured of its correctness, however fetchmail
>starts to work normally):
>
> $ diff driver.c ../driver.c
> 1030c1030,1034                                                               
> <                   ctl->server.truename = xstrdup(res->ai_canonname);       
> ---                                                                          
>>                   if (res->ai_canonname) {                                 
>>                     ctl->server.truename = xstrdup(res->ai_canonname);     
>>                   } else {                                                 
>>                     ctl->server.truename = xstrdup(ctl->server.queryname); 
>>                   };      

Спасибо!

I had read IEEE Std 1003.1-2001, which requests that the implementation
copies the nodename if no canonical name is available.  FreeBSD 4.11's
implementation however does not do that.

Please file a bug report (use send-pr and file against "standards") for
FreeBSD 4.11, too. Mention that the standard deviation causes
application crashes, and ask politely that they update their
getaddrinfo() for standards conformance. (And please send me the PR
number, so I may add further FreeBSD versions should 6.0 also turn out
to be noncompliant.)

I have taken your patch (with trivial modifications, and with a comment
added) for fetchmail-6.3.3. It is already committed to SVN. Thanks a lot.

(I suspect other IPv6 enabled BSD implementations might suffer from the
same deviation from the standard, so I'd rather work around this in
fetchmail.)

In the future, when sending patches, please use "diff -u" or "diff -c"
to generate a "unified" or "context" patch. These work even if line
numbers change, as was the case here.

Finally, can I ask you for your full name (best two times: 1-in original
Cyrillic, 2-with English transcription) to be mentioned in the "NEWS"
file, or would you prefer to be listed as "Voldemar"?

Thanks again,

I've set Reply-To: to my personal address, as I think this is completely
covered as far as the mailing list is concerned.

-- 
Matthias Andree

Re: [fetchmail-users] Re: O'Reilly DevCenter weighs in on fetchmail

[Nico G. <ni...@ng...>]

Hallo Michelle,

* Michelle Konzack <lin...@fr...> [2006-03-20 16:03]:
> Am 2006-03-13 18:40:17, schrieb Rob Funk:
> > Matthias Andree wrote:
> > > If they need K* software, what clue of Unix do they have anyways?
> > 
> > Check my X-Mailer header.  ;-)
> 
> You have no "X-Mailer:" header.  ;-)
> 
> ONLY a "User-Agent:".  :-P

"Du kannst es wirklich nicht lassen, auf jeder Liste deinen 
unnötigen Senf noch dazuzugeben oder? Bei Debian ist das ja 
bereits bekannt" I haven't read any productive mails from 
your side just SPAM, please stop it.

> ##################### Debian GNU/Linux Consultant #####################

BTW, this signature ist just embarrassing
Regards Nico
-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!

[fetchmail-users] Fetchmail crash (SIGSERV)

[Voldemar <de...@it...>]

Fetchmail crash (SIGSERV)

Hello !

$ uname -a                                                                      
FreeBSD netadmin.ssmu.ru 4.11-RELEASE FreeBSD 4.11-RELEASE #3: Wed Aug 17 10:31:
07 OMSST 2005     ro...@ne...:/usr/src/sys/compile/netadmin  i386

fetchmail-6.3.2_1
Build from FreeBSD-ports (from source)

$ gcc -v                                 
Using builtin specs.                     
gcc version 2.95.4 20020320 [FreeBSD]    

$ fetchmail -V
This is fetchmail release 6.3.2+POP2+RPA+SDPS+SSL+OPIE+NLS.

$ cat .fetchmailrc
poll inet.tsu.ru    
timeout 120         
protocol pop3       
user deka           
pass ****
                    
poll pop3.mail.ru   
timeout 180         
protocol pop3       
user vega0          
pass ****
                    
poll 212.192.112.206
timeout 30          
protocol pop3       
user deka           
pass ****

$ fetchmail                                                     
fetchmail: No mail for deka at inet.tsu.ru                      
POP3 connection to pop3.mail.ru failed: Connection refused      
fetchmail: Query status=2 (SOCKET)                              
Segmentation fault                                              

$ gdb fetchmail
...[skip]...
Program received signal SIGSEGV, Segmentation fault.
0x8061c20 in xstrdup (s=0x0) at xmalloc.c:56
56          p = (char *) xmalloc(strlen(s)+1);
(gdb) backtrace
#0  0x8061c20 in xstrdup (s=0x0) at xmalloc.c:56
#1  0x805478d in do_session (ctl=0x8081600, proto=0x80642c0, maxfetch=0) at driver.c:1030
#2  0x8055573 in do_protocol (ctl=0x8081600, proto=0x80642c0) at driver.c:1630
#3  0x804bf6e in doPOP3 (ctl=0x8081600) at pop3.c:1304
#4  0x80501cd in query_host (ctl=0x8081600) at fetchmail.c:1403
#5  0x804eac4 in main (argc=1, argv=0xbfbffb10) at fetchmail.c:685

It seems to me, the function getaddrinfo returns 0 (no error),
but thus res->ai_canonname == 0, that leads SIGSERV at attempt
strcpy(0) in xmalloc.c:xstrdup.

I do not know, whether is a mistake: fetchmail or incorrect behaviour libc.
My variant of patch (not assured of its correctness,
however fetchmail starts to work normally):

$ diff driver.c ../driver.c
1030c1030,1034                                                               
<                   ctl->server.truename = xstrdup(res->ai_canonname);       
---                                                                          
>                   if (res->ai_canonname) {                                 
>                     ctl->server.truename = xstrdup(res->ai_canonname);     
>                   } else {                                                 
>                     ctl->server.truename = xstrdup(ctl->server.queryname); 
>                   };      

Excuse me, if to you already informed on this mistake. Thanks 

[fetchmail-users] Re: O'Reilly DevCenter weighs in on fetchmail

[Michelle K. <lin...@fr...>]

Am 2006-03-13 18:40:17, schrieb Rob Funk:
> Matthias Andree wrote:
> > If they need K* software, what clue of Unix do they have anyways?
> 
> Check my X-Mailer header.  ;-)

You have no "X-Mailer:" header.  ;-)

ONLY a "User-Agent:".  :-P

> I switched from mutt to kmail when I started needing to access multiple 
> IMAP servers, with different identities, keeping received and sent mail 
> on the server.

This can be done with mutt too.  ;-)

Greetings
    Michelle Konzack
    Systemadministrator


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
                   50, rue de Soultz         MSM LinuxMichi
0033/3/88452356    67100 Strasbourg/France   IRC #Debian (irc.icq.com)

[fetchmail-users] fetchmail 6.3.3.rc2 release candidate

[Matthias A. <mat...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

collecting a few more bugfixes and cleanups, I have uploaded a second
and hopefully final release candidate for fetchmail 6.3.3 to
http://mandree.home.pages.de/fetchmail/

Please test and see if it fixed the bug(s) you reported recently.

My thanks go to Sunil Shetye for lots of the fixes.

Changes in fetchmail 6.3.3.rc2 (from 6.3.3.rc1 - see previous
announcement for differences between the latter and 6.3.2):

* LMTP: fix bug in LMTP port validation (patch by Miloslav Trmac).
* Miloslav Trmac's patch (with minor changes) to fix char * sign consistency,
  unused arguments and variables.
* SDPS: Warn and disable SDPS if POP3 is disabled to avoid compilation errors.
* More signedness, unused argument/variable and other warning fixes.
* IMAP: Stop sending EXPUNGE after NOOP-idling (patch by Sunil Shetye).
* POP3: Lower default fastuidl span to 4 (i. e. every 4th run fetches the
  whole UIDL list), patch by Sunil Shetye.

Happy fetching,
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFEGFJ9vmGDOQUufZURAq/EAKDZ+DsoQ+NHT4QKfqHaehfgseaKLACgkZOd
Y6Ev89Ek3IjB5UynHEHaHl8=
=F7ox
-----END PGP SIGNATURE-----

Re: [fetchmail-users] [PATCH-2] Re: Bug in imap_idle() with mail servers not supporting "idle"

[Matthias A. <mat...@gm...>]

Sunil Shetye <sh...@bo...> writes:

> Looks like an accident.
>
> The original intention is to do an EXPUNGE immediately after SELECT.
> In this case, since no mails were found after SELECT, the EXPUNGE was
> sent after the NOOP(s). This EXPUNGE after NOOP is pointless and
> confusing. This patch should remove this.

Thanks, merged.

-- 
Matthias Andree

Re: [fetchmail-users] O'Reilly DevCenter weighs in on fetchmail

[Rob F. <rf...@fu...>]

Matthias Andree wrote:
> If they need K* software, what clue of Unix do they have anyways?

Check my X-Mailer header.  ;-)

I switched from mutt to kmail when I started needing to access multiple 
IMAP servers, with different identities, keeping received and sent mail 
on the server.

-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

Re: [fetchmail-users] O'Reilly DevCenter weighs in on fetchmail

[Matthias A. <mat...@gm...>]

Rob Funk <rf...@fu...> writes:

> I couldn't help being amused at this....
>
> http://www.linuxdevcenter.com/lpt/a/6502
> In an article on "Fine-Tuning Kubuntu", we have:
> | Other services are optional, so start them at boot only
> | if you know you need them:
> | *  atd, for scheduled batch jobs.
> | *  bluez-utils, for Bluetooth devices.
> | *  bootlogd, not necessary, as syskslogd handles bootlogs.
> | *  cupsys, necessary for printing.
> | *  evms, logical volume manager. Don't use this unless you have logical
> |    volumes configured. 
> | *  fetchmail, but who uses fetchmail anymore?
> [...]

If they need K* software, what clue of Unix do they have anyways?

SCNR.

-- 
Matthias Andree

Re: [fetchmail-users] [PATCH] Re: Bug in imap_idle() with mail servers not supporting "idle"

[Matthias A. <mat...@gm...>]

Brendan Lynch <bre...@ai...> writes:

> That seem to be intentional first-pass behaviour (i.e. not really the general
> Idle polling case).  Look at these lines from imap_getrange():
>
>     732          * We should have an expunge here to
>     733          * a) avoid fetching deleted mails during 'fetchall'
>     734          * b) getting a wrong count of mails during 'no fetchall'
>     735          */
>     736         if (!check_only && !ctl->keep && count > 0)
>     737         {
>     738             ok = internal_expunge(sock);
>     739             if (ok)
>
> This generates the EXPUNGE you see.  However this only happens for the first
> message, since this is the "else" case of the if statement:
>
>     672     if (pass > 1)
>     673     {
>     674         /* deleted mails have already been expunged by
>     675          * end_mailbox_poll().
>
> and will only be taken before the first message has been seen. After the first
> message has been seen no EXPUNGE is sent (and the comment suggests why the
> code does not do an EXPUNGE in this case).

Well, yes, but I think it's pointless to run EXPUNGE in this particular
context. We might only expunge the deletions of another process, and
that's probably not what fetchmail should be doing.

I'll probably merge Sunil's patch tomorrow.

-- 
Matthias Andree

Re: [fetchmail-users] [PATCH] Re: Bug in imap_idle() with mail servers not supporting "idle"

[Brendan L. <bre...@ai...>]

That seem to be intentional first-pass behaviour (i.e. not really the 
general Idle polling case).  Look at these lines from imap_getrange():

    732          * We should have an expunge here to
    733          * a) avoid fetching deleted mails during 'fetchall'
    734          * b) getting a wrong count of mails during 'no fetchall'
    735          */
    736         if (!check_only && !ctl->keep && count > 0)
    737         {
    738             ok = internal_expunge(sock);
    739             if (ok)

This generates the EXPUNGE you see.  However this only happens for the 
first message, since this is the "else" case of the if statement:

    672     if (pass > 1)
    673     {
    674         /* deleted mails have already been expunged by
    675          * end_mailbox_poll().

and will only be taken before the first message has been seen. After the 
first message has been seen no EXPUNGE is sent (and the comment suggests 
why the code does not do an EXPUNGE in this case).

A trace shows exactly this behaviour:

First time:

    18:00:55 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:00:55 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={28, 0}}, NULL) = 0
    18:00:55 recv(4, 0xbfea66fb, 8192, MSG_PEEK) = ? ERESTARTSYS (To be
    restarted)
    18:01:23 --- SIGALRM (Alarm clock) @ 0 (0) ---
    18:01:23 sigreturn()                    = ? (mask now [])
    18:01:23 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:01:23 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={0, 0}}, NULL) = 0
    18:01:23 write(4, "A0013 NOOP\r\n", 12) = 12
    18:01:23 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={300,
    0}}, NULL) = 0
    18:01:23 recv(4, "A0013 OK NOOP completed\r\n", 8192, MSG_PEEK) = 25
    18:01:23 read(4, "A0013 OK NOOP completed\r\n", 25) = 25
    18:01:23 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:01:23 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={28, 0}}, NULL) = 0
    18:01:23 recv(4, "* 1 EXISTS\r\n", 8192, MSG_PEEK) = 12
    18:01:47 read(4, "* 1 EXISTS\r\n", 12)  = 12
    18:01:47 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:01:47 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={0, 0}}, NULL) = 0
    18:01:47 write(4, "A0014 EXPUNGE\r\n", 15) = 15
    18:01:47 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={300,
    0}}, NULL) = 0
    18:01:47 recv(4, "* 1 RECENT\r\nA0014 OK EXPUNGE completed\r\n",
    8192, MSG_PEEK) = 40
    18:01:47 read(4, "* 1 RECENT\r\n", 12)  = 12
    18:01:47 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:01:47 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={300, 0}}, NULL) = 0
    18:01:47 recv(4, "A0014 OK EXPUNGE completed\r\n", 8192, MSG_PEEK) = 28
    18:01:47 read(4, "A0014 OK EXPUNGE completed\r\n", 28) = 2818:01:47
    setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
    18:01:47 write(4, "A0015 FETCH 1 RFC822.SIZE\r\n", 27) = 27
    18:01:47 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={300,
    0}}, NULL) = 0
    18:01:47 recv(4, "* 1 FETCH (RFC822.SIZE 7640)\r\n", 8192, MSG_PEEK)
    = 30

Later times:

    18:03:12 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={28,
    0}}, NULL) = 0
    18:03:12 recv(4, 0xbfea66fb, 8192, MSG_PEEK) = ? ERESTARTSYS (To be
    restarted)
    18:03:40 --- SIGALRM (Alarm clock) @ 0 (0) ---
    18:03:40 sigreturn()                    = ? (mask now [])
    18:03:40 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:03:40 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={0, 0}}, NULL) = 0 18:03:40 write(4, "A0024 NOOP\r\n", 12) = 12
    18:03:40 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={300,
    0}}, NULL) = 0
    18:03:40 recv(4, "A0024 OK NOOP completed\r\n", 8192, MSG_PEEK) = 25
    18:03:40 read(4, "A0024 OK NOOP completed\r\n", 25) = 25
    18:03:40 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:03:40 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={28, 0}}, NULL) = 0
    18:03:40 recv(4, "* 1 EXISTS\r\n", 8192, MSG_PEEK) = 12
    18:03:49 read(4, "* 1 EXISTS\r\n", 12)  = 12
    18:03:49 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:03:49 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={0, 0}}, NULL) = 018:03:49 write(4, "A0025 NOOP\r\n", 12) = 12
    18:03:49 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={300,
    0}}, NULL) = 0
    18:03:49 recv(4, "* 1 RECENT\r\nA0025 OK NOOP completed\r\n", 8192,
    MSG_PEEK) = 37
    18:03:49 read(4, "* 1 RECENT\r\n", 12)  = 12
    18:03:49 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:03:49 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={300, 0}}, NULL) = 0
    18:03:49 recv(4, "A0025 OK NOOP completed\r\n", 8192, MSG_PEEK) = 25
    18:03:49 read(4, "A0025 OK NOOP completed\r\n", 25) = 25
    18:03:49 setitimer(ITIMER_REAL, {it_interval={0, 0}, it_value={0,
    0}}, NULL) = 018:03:49 setitimer(ITIMER_REAL, {it_interval={0, 0},
    it_value={0, 0}}, NULL) = 018:03:49 write(4, "A0026 FETCH 1
    RFC822.SIZE\r\n", 27) = 27

After the first RECEIVE further RECEIVES are followed by a FETCH without 
intervening EXPUNGE.

Brendan

mat...@gm... wrote:

>I've committed the patch. One thing makes me wonder though:
>
>fetchmail: IMAP> A0004 NOOP
>fetchmail: IMAP< A0004 OK NOOP completed.
>fetchmail: IMAP> A0005 NOOP
>fetchmail: IMAP< * 1 EXISTS
>fetchmail: IMAP< * 1 RECENT
>fetchmail: IMAP< A0005 OK NOOP completed.
>fetchmail: IMAP> A0006 EXPUNGE
>fetchmail: IMAP< A0006 OK Expunge completed.
>
>Why does fetchmail perform an EXPUNGE after NOOP?
>Accident or intent?
>
>  
>

Re: [fetchmail-users] O'Reilly DevCenter weighs in on fetchmail

[Rob F. <rf...@fu...>]

Nico Golde wrote:
> > | *  fetchmail, but who uses fetchmail anymore?
>
> What do they use? ;-)
> Kmail builtin pop3 support? ;)

Kmail, Evolution, Thunderbird, or maybe just Gmail.

-- 
==============================| "A slice of life isn't the whole cake
 Rob Funk <rf...@fu...> | One tooth will never make a full grin"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

Re: [fetchmail-users] O'Reilly DevCenter weighs in on fetchmail

[Nico G. <ni...@ng...>]

Hi,
* Rob Funk <rf...@fu...> [2006-03-11 17:57]:
[...] 
> | *  fetchmail, but who uses fetchmail anymore?
> [...]

What do they use? ;-)
Kmail builtin pop3 support? ;)
Regards Nico
-- 
Nico Golde - JAB: ni...@ja... | GPG: 0x73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org
Forget about that mouse with 3/4/5 buttons -
gimme a keyboard with 103/104/105 keys!

[fetchmail-users] O'Reilly DevCenter weighs in on fetchmail

[Rob F. <rf...@fu...>]

I couldn't help being amused at this....

http://www.linuxdevcenter.com/lpt/a/6502
In an article on "Fine-Tuning Kubuntu", we have:
| Other services are optional, so start them at boot only
| if you know you need them:
| *  atd, for scheduled batch jobs.
| *  bluez-utils, for Bluetooth devices.
| *  bootlogd, not necessary, as syskslogd handles bootlogs.
| *  cupsys, necessary for printing.
| *  evms, logical volume manager. Don't use this unless you have logical
|    volumes configured. 
| *  fetchmail, but who uses fetchmail anymore?
[...]

-- 
==============================|   "A microscope locked in on one point
 Rob Funk <rf...@fu...> |Never sees what kind of room that it's in"
 http://www.funknet.net/rfunk |    -- Chris Mars, "Stuck in Rewind"

[fetchmail-users] [PATCH-2] Re: Bug in imap_idle() with mail servers not supporting "idle"

[Sunil S. <sh...@bo...>]

Quoting from Matthias Andree's mail on Fri, Mar 10, 2006:
> I've committed the patch. One thing makes me wonder though:
> 
> fetchmail: IMAP> A0004 NOOP
> fetchmail: IMAP< A0004 OK NOOP completed.
> fetchmail: IMAP> A0005 NOOP
> fetchmail: IMAP< * 1 EXISTS
> fetchmail: IMAP< * 1 RECENT
> fetchmail: IMAP< A0005 OK NOOP completed.
> fetchmail: IMAP> A0006 EXPUNGE
> fetchmail: IMAP< A0006 OK Expunge completed.
> 
> Why does fetchmail perform an EXPUNGE after NOOP?
> Accident or intent?

Looks like an accident.

The original intention is to do an EXPUNGE immediately after SELECT.
In this case, since no mails were found after SELECT, the EXPUNGE was
sent after the NOOP(s). This EXPUNGE after NOOP is pointless and
confusing. This patch should remove this.

======================================================================
Index: fetchmail-6.3/imap.c
===================================================================
--- fetchmail-6.3/imap.c	(revision 4730)
+++ fetchmail-6.3/imap.c	(working copy)
@@ -737,16 +737,6 @@
 				    "%d messages waiting after first poll\n",
 				    count), count);
 
-	/* no messages?  then we may need to idle until we get some */
-	while (count == 0 && do_idle) {
-	    ok = imap_idle(sock);
-	    if (ok)
-	    {
-		report(stderr, GT_("re-poll failed\n"));
-		return(ok);
-	    }
-	}
-
 	/*
 	 * We should have an expunge here to
 	 * a) avoid fetching deleted mails during 'fetchall'
@@ -765,6 +755,23 @@
 					"%d messages waiting after expunge\n",
 					count), count);
 	}
+
+	if (count == 0 && do_idle)
+	{
+	    /* no messages?  then we may need to idle until we get some */
+	    while (count == 0) {
+		ok = imap_idle(sock);
+		if (ok)
+		{
+		    report(stderr, GT_("re-poll failed\n"));
+		    return(ok);
+		}
+	    }
+	    if (outlevel >= O_DEBUG)
+		report(stdout, ngettext("%d message waiting after re-poll\n",
+					"%d messages waiting after re-poll\n",
+					count), count);
+	}
     }
 
     *countp = count;
======================================================================

-- 
Sunil Shetye.

[fetchmail-users] fetchmail 6.3.3.rc1 release candidate

[Matthias A. <mat...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

collecting six weeks worth of bugfixes, I have uploaded a release
candidate for fetchmail 6.3.3 to http://mandree.home.pages.de/fetchmail/

Please test and see if it fixed the bug(s) you reported recently.

My thanks go to Sunil Shetye for lots of the fixes.

Changes in fetchmail 6.3.3.rc1 (from 6.3.2):

# BUG FIXES:
* Do not attempt to overwrite the netrc password if none has been specified.
  This fixes a segmentation fault bug introduced into 6.3.2.
  Fixes BerliOS bug #6234.  BerliOS patch #804 by Craig Leres.
  The patch, as accepted into fetchmail, was available separately from
  <http://download.berlios.de/fetchmail/patch-6.3.2.1-fix-netrc-SIGSEGV.diff>
* Handle other clients concurrently accessing IMAP mailboxes better.
  Fetchmail quits the poll if the EXPUNGE count does not match expectations, and
  servers not updating RECENT counts after EXPUNGE are handled in a better way.
  (Patch by Sunil Shetye.)
* fetchmail no longer replaces the local user ID for an empty envelope sender
  when using the proprietary SDPS extension for POP3. Fixes Debian Bug#353575,
  reported by Roger Lynn.
* fetchmail no longer prints empty lines in verbose mode when using syslog.
* fetchmail no longer prints UID lists in verbose mode when using syslog.
* POP3: fetchmail can now use UIDL in fetchall keep mode, to avoid re-fetching
  the same messages again when the fetchall keyword is removed. Patch by
  Sunil Shetye. For details, please see
  <http://lists.berlios.de/pipermail/fetchmail-users/2006-March/000308.html>
* IMAP: fix hangs in NOOP-based IDLE emulation. Reported by Casper Gripenberg
  and Brendan Lynch, fix by Sunil Shetye (his patch was merged) and Brendan
  Lynch.
* ./configure --quiet is now quieter (no SSL and fallback-related output).

# CHANGES:
* --idle can now be specified on the command line, too.
* --fetchall is now supported on the command-line.

# DOCUMENTATION:
* "ssl" is a user option rather than a server option. Patch by Nico Golde.
  Fixes Debian Bug#354661, reported by Keith Hellman.
* The manual page now suggests "--" before the addresses in the sendmail MDA
  example, for safety.
* The FAQ item X9, Domino IMAP omits Content-Transfer-Encoding header, was
  added. Information provided by Anthony Kim on the fetchmail-friends list
  in March 2006.
* Credit Chris Boyle with the NOOP emulation code for IDLE in fetchmail 6.2.4.
  Eric forgot to credit Chris, thanks to Sunil Shetye for providing these links:
  http://lists.ccil.org/pipermail/fetchmail-friends/2003-July/007705.html
  http://lists.ccil.org/pipermail/fetchmail-friends/2003-July/007713.html

Happy fetchmailing,
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFEEV7GvmGDOQUufZURAjl5AJ9fBOAS+WO+hOQFM6AFPcEW+opMUwCfZQlv
c8JaKWTGJHrK29QHTkgDFcw=
=VIjl
-----END PGP SIGNATURE-----

Re: [fetchmail-users] [PATCH] Re: Bug in imap_idle() with mail servers not supporting "idle"

[Matthias A. <mat...@gm...>]

I've committed the patch. One thing makes me wonder though:

fetchmail: IMAP> A0004 NOOP
fetchmail: IMAP< A0004 OK NOOP completed.
fetchmail: IMAP> A0005 NOOP
fetchmail: IMAP< * 1 EXISTS
fetchmail: IMAP< * 1 RECENT
fetchmail: IMAP< A0005 OK NOOP completed.
fetchmail: IMAP> A0006 EXPUNGE
fetchmail: IMAP< A0006 OK Expunge completed.

Why does fetchmail perform an EXPUNGE after NOOP?
Accident or intent?

-- 
Matthias Andree

Re: [fetchmail-users] After reading the FAQ, a question about lost/mangled attachments

[Matthias A. <mat...@gm...>]

Peter N. Spotts wrote:

> My apologies for the tardy reply. I'll remove the fetchall command from
> my rc file and see how things work. I should have said earlier that I
> had just updated to 6.3.2 that morning but hadn't tried it yet...I just
> had this urge to write something after several weeks of
> frustration!  ;-)

Well, I hope that your frustration ended with the installation of 6.3.2 and
you'll find out that next time you run it.

Otherwise, let me know quick so the fix can become part of the 6.3.3 release.

Thanks,
Matthias

Re: [fetchmail-users] After reading the FAQ, a question about lost/mangled attachments

[Peter N. S. <ps...@al...>]

On Sat, 2006-03-04 at 19:31 +0100, Matthias Andree wrote:
> "Peter N. Spotts" <ps...@al...> writes:
> 
> > I've been running fetchmail on SuSE 10.0 on my laptop, and until today
> > (when I installed the latest version of fetchmail) I've been running
> > 6.2.X.
> 
> [...]
> 
> > So although my ISP is Comcast (I noted the Comcast caveats on
> > the FAQ page), Comcast does not seem to be the problem either.
> 
> That would be news.
> 
> fetchmail, beginning with version 6.3.2, recognizes Comcast's broken
> servers ("Maillennium POP3/PROXY server") and disables the problematic
> use of the TOP command and uses RETR instead - so updating to 6.3.2
> should have fixed all known Comcast problems.
> 
> -- 
> Matthias Andree

Matthias,

My apologies for the tardy reply. I'll remove the fetchall command from
my rc file and see how things work. I should have said earlier that I
had just updated to 6.3.2 that morning but hadn't tried it yet...I just
had this urge to write something after several weeks of
frustration!  ;-)

With best regards,

Pete
-- 

      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Peter N. Spotts | Science Correspondent
                 The Christian Science Monitor
             One Norway Street, Boston  MA  02115
      Office: 617-450-2449 | Office in home: 508-520-3139
        Email: ps...@al... | www.csmonitor.com
                 Amateur-radio call - KC1JB
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

"The knack of flying is to throw yourself at the ground and miss."
                                                 -- Douglas Adams

[fetchmail-users] Re: [PATCH] Re: Bug in imap_idle() with mail servers not supporting "idle"

[Brendan L. <bre...@ai...>]

Your patch works too.  I cannot say the code is clearer than my fix, but 
you are no doubt a lot more familiar with this code than I am.  The key 
fix (beyond not waiting for a tagged response when no tagged command had 
been issued) in your fix is at line 595, where you do not attempt to 
enter the pseudo-idle wait if a RECENT message has been received 
(recentcount != 0).

Thanks,

Brendan

sh...@bo... wrote:

>Quoting from Brendan Lynch's mail on Thu, Mar 02, 2006:
>  
>
>>However I believe the servers is behaving correctly according to the 
>>IMAP spec: I have attached an explanation of the secondary problem I am 
>>seeing (extra 28 s wait) that I sent to Casper; let me know if you need 
>>more info.
>>    
>>
>
>Yes, I have now read RFC 3501 section 5.3. This behaviour is correct.
>
>  
>
>>The key point is that the imap_idle() code when 'faking' IDLE support 
>>calls imap_ok() (at line 637) without having issued any tagged command:
>>    
>>
>
>...
>
>  
>
>>Since there is no tagged command outstanding the server will not (and 
>>should not) ever send a tagged response.  If we set imap_ok to only 
>>return after a tagged response we are guaranteeing it will always only 
>>return after a timeout.
>>    
>>
>
>...
>
>  
>
>>This again first does a gen_transact() which results in sending "A0130 
>>NOOP" at 17:00:49.  A "RECENT" update is already on its way form the 
>>server, so we receive it before the "A0130 NOOP completed" at 17:00:49.  
>>In imap_ok() we first process the "* 1 RECENT" notification at line 117, 
>>setting recentcount, then (since we ARE waiting a tag) loop and process 
>>the NOOP ok.  we then return to gen_transact(), which in turn returns to 
>>imap_idle().
>>
>>Since setting "recentcount" does not also change the stage, we fail the 
>>test at line 633 of imap_idle() and continue to do an extra imap_ok() 
>>which sets a 28 second timer at 17:00:49 and does a recv() which times 
>>out at 17:01:17.  We then return from imap_idle() to imap_getrange() 
>>line 679.  At this point recentcount is set and we exit the "while 
>>(recentcount == 0 && do_idle)" loop.
>>
>>The wait between 17:00:49 and 17:01:17 was unnecessary, as already had 
>>our RECENT notification.  The second part of my fix causes imap_ok() to 
>>change the stage to STAGE_FETCH on receipt of a RECENT notification, 
>>just as it already did on receipt of a EXISTS notification. This causes 
>>the if condition "if (ok != 0 || stage != STAGE_IDLE)" to be met at line 
>>633 of imap_idle() so it immediately exits and does not do the extra 
>>unneeded imap_ok() call.
>>    
>>
>
>Yes, you have diagnosed the problem correctly and your patch is also
>correct. Based on your patch, I have prepared a new patch which does
>not modify imap_ok(), but cleans up the code in imap_idle(). Could you
>test this patch and see if this patch is acceptable to you? This patch
>is identical to the patch I had sent to Casper Gripenberg, except that
>comments relating to compliance with RFCs have been updated.
>
>  
>
>------------------------------------------------------------------------
>
>Index: fetchmail-6.3/imap.c
>===================================================================
>--- fetchmail-6.3/imap.c   (revision 4705)
>+++ fetchmail-6.3/imap.c   (working copy)
>@@ -621,7 +621,6 @@
> {
>     int ok;
> 
>-    stage = STAGE_IDLE;
>     saved_timeout = mytimeout;
> 
>     if (has_idle) {
>@@ -629,6 +628,7 @@
>    * at least every 28 minutes:
>    * (the server may have an inactivity timeout) */
>   mytimeout = 1680; /* 28 min */
>+  stage = STAGE_IDLE;
>   /* enter IDLE mode */
>   ok = gen_transact(sock, "IDLE");
> 
>@@ -637,37 +637,43 @@
>       SockWrite(sock, "DONE\r\n", 6);
>       if (outlevel >= O_MONITOR)
>       report(stdout, "IMAP> DONE\n");
>-  } else
>-      /* not idle timeout */
>-      return ok;
>+      /* reset stage and timeout here: we are not idling any more */
>+      mytimeout = saved_timeout;
>+      stage = STAGE_FETCH;
>+      /* get OK IDLE message */
>+      ok = imap_ok(sock, NULL);
>+  }
>     } else {  /* no idle support, fake it */
>-  /* when faking an idle, we can't assume the server will
>-   * send us the new messages out of the blue (RFC2060);
>-   * this timeout is potentially the delay before we notice
>-   * new mail (can be small since NOOP checking is cheap) */
>-  mytimeout = 28;
>+  /* Note: stage and timeout have not been changed here as NOOP
>+   * does not idle */
>   ok = gen_transact(sock, "NOOP");
>-  /* if there's an error (not likely) or we just found mail (stage 
>-   * has changed, timeout has also been restored), we're done */
>-  if (ok != 0 || stage != STAGE_IDLE)
>-      return(ok);
> 
>-  /* wait (briefly) for an unsolicited status update */
>-  ok = imap_ok(sock, NULL);
>-  /* again, this is new mail or an error */
>-  if (ok != PS_IDLETIMEOUT)
>-      return(ok);
>+  /* no error, but no new mail either */
>+  if (ok == PS_SUCCESS && recentcount == 0)
>+  {
>+      /* There are some servers who do send new mail
>+       * notification out of the blue. This is in compliance
>+       * with RFC 2060 section 5.3. Wait for that with a low
>+       * timeout */
>+      mytimeout = 28;
>+      stage = STAGE_IDLE;
>+      /* We are waiting for notification; no tag needed */
>+      tag[0] = '\0';
>+      /* wait (briefly) for an unsolicited status update */
>+      ok = imap_ok(sock, NULL);
>+      if (ok == PS_IDLETIMEOUT) {
>+      /* no notification came; ok */
>+      ok = PS_SUCCESS;
>+      }
>+  }
>     }
> 
>     /* restore normal timeout value */
>+    set_timeout(0);
>     mytimeout = saved_timeout;
>     stage = STAGE_FETCH;
> 
>-    /* get OK IDLE message */
>-    if (has_idle)
>-        return imap_ok(sock, NULL);
>-
>-    return PS_SUCCESS;
>+    return(ok);
> }
> 
> static int imap_getrange(int sock, 
>  
>

Re: [fetchmail-users] After reading the FAQ, a question about lost/mangled attachments

[Matthias A. <mat...@gm...>]

"Peter N. Spotts" <ps...@al...> writes:

> I've been running fetchmail on SuSE 10.0 on my laptop, and until today
> (when I installed the latest version of fetchmail) I've been running
> 6.2.X.

[...]

> So although my ISP is Comcast (I noted the Comcast caveats on
> the FAQ page), Comcast does not seem to be the problem either.

That would be news.

fetchmail, beginning with version 6.3.2, recognizes Comcast's broken
servers ("Maillennium POP3/PROXY server") and disables the problematic
use of the TOP command and uses RETR instead - so updating to 6.3.2
should have fixed all known Comcast problems.

-- 
Matthias Andree