fetchmail-devel — Development related discussion

[fetchmail-devel] imap search improvements

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

Hi Matthias,

I am thinking of making some improvements to imap search in fetchmail.
Please check which of these improvements are acceptable for fetchmail
6.3 series.

============================================================================================
1. In r3838, the "SEARCH UNSEEN" was changed to "SEARCH UNSEEN NOT
DELETED". Some imap servers do not support such a complex search
phrase. I could find only one reference for that:

http://lists.ccil.org/pipermail/fetchmail-friends/2004-June/008897.html

I propose that that change should be undone.

Note that "SEARCH UNSEEN NOT DELETED" gives different result from
"SEARCH UNSEEN" only when

- another e-mail client has marked some mails for deletion without
  seeing,
- that e-mail client has not expunged the deleted mails, and
- fetchmail is keeping mails (so that fetchmail also has not expunged
  the deleted mails).

The comment in the code reads:

/* don't count deleted messages, in case user enabled keep last time */

This comment is incorrect. This is because fetchmail always marks the
mail as \Seen irrespective of whether fetchmail deletes it or keeps
it. So, that mail will not show up in the next "SEARCH UNSEEN".


============================================================================================
2. Some servers do not support "SEARCH" at all. Here are some
references for that:

http://lists.ccil.org/pipermail/fetchmail-friends/2004-May/008675.html
http://lists.ccil.org/pipermail/fetchmail-friends/2005-January/009351.html

In this case, as a fallback, fetchmail should use something like:

FETCH 1:1000 FLAGS

and process all mails without \Seen as unseen.


============================================================================================
3. The reply to "SEARCH UNSEEN" overflows fetchmail buffer when there
are more than 1860 unseen mails. fetchmail should do a range search:

SEARCH 1:1000 UNSEEN
SEARCH 1001:2000 UNSEEN
...


============================================================================================

-- 
Sunil Shetye.

Re: [fetchmail-devel] [PATCH-3] Re: fetchmail IMAP bug - causes some mails to not be delivered when using IDLE

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

Dear Sunil, dear readers,

Am 18.01.2010, 09:32 Uhr, schrieb Sunil Shetye  
<sh...@bo...>:

> Quoting from Matthias Andree's mail on Thu, Jan 14, 2010:
>> Perhaps a separate imap_untagged_parse() function would be more  
>> suitable here,
>> and possibly called from inside imap_ok()? See below.
>
> Ok, I have made a separate imap_untagged_response() to parse the
> untagged response. Other key changes:
>
> - use  stage == STAGE_GETAUTH && !strncmp(buf, "* CAPABILITY", 12)
>   - instead of  strstr(buf, " CAPABILITY")
>
> - use  stage == STAGE_GETAUTH && !strncmp(buf, "* PREAUTH", 9)
>   - instead of  strstr(buf, " PREAUTH")
>
> - use  stage == STAGE_GETRANGE && !check_only && strstr(buf,  
> "[READ-ONLY]")
>   - instead of  !check_only && strstr(buf, "[READ-ONLY]")
>
> - log  "* BYE"  message
>
>
> These changes should save a lot of string comparisons during runtime.

OK, makes sense (plus we don't want these anywhere on the line but just  
after the non-tag).

> In order to address this, I have made one more intermediate function
> imap_response(). Caller-specific parsers will call imap_response() in
> a loop and others will continue calling imap_ok().

Good.

> Please check if this patch addresses all the issues raised.

To me it seems fine, based on the testing that you and Matt have been  
doing, I've committed the change (r5459).

Thanks to the two of you, and to Timo Sirainen, for the help with  
resolving this issue.

Best regards
Matthias

Re: [fetchmail-devel] [PATCH-3] Re: fetchmail IMAP bug - causes some mails to not be delivered when using IDLE

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

Am 21.01.2010, 12:51 Uhr, schrieb Matt Doran <mat...@pa...>:

> On 19/01/2010 2:13 PM, Matt Doran wrote:
>> Sunil Shetye wrote:
>>> Quoting from Matthias Andree's mail on Thu, Jan 14, 2010:
>>>
>>>> Perhaps a separate imap_untagged_parse() function would be more  
>>>> suitable here,
>>>> and possibly called from inside imap_ok()? See below.
>>>>
>>>
>>> Ok, I have made a separate imap_untagged_response() to parse the
>>> untagged response. Other key changes:
>>>
>>> - use  stage == STAGE_GETAUTH&&  !strncmp(buf, "* CAPABILITY", 12)
>>>    - instead of  strstr(buf, " CAPABILITY")
>>>
>>> - use  stage == STAGE_GETAUTH&&  !strncmp(buf, "* PREAUTH", 9)
>>>    - instead of  strstr(buf, " PREAUTH")
>>>
>>> - use  stage == STAGE_GETRANGE&&  !check_only&&  strstr(buf,  
>>> "[READ-ONLY]")
>>>    - instead of  !check_only&&  strstr(buf, "[READ-ONLY]")
>>>
>>> - log  "* BYE"  message
>>>
>>>
>>> These changes should save a lot of string comparisons during runtime.
>>>
>>>
>>>> Which raises another question: does it make sense to have  
>>>> caller-specific
>>>> parsers for untagged replies? Perhaps those functions that need them  
>>>> - for
>>>> instance for * SEARCH, should call some new imap_ok_with_untagged()  
>>>> function
>>>> instead, and the normal imap_ok handles all untagged implicitly (we  
>>>> can rename
>>>> imap_ok, and uses dummy functions that just pass in an additional  
>>>> argument
>>>> whether or not returning PS_UNTAGGED is requested).
>>>>
>>>
>>> In order to address this, I have made one more intermediate function
>>> imap_response(). Caller-specific parsers will call imap_response() in
>>> a loop and others will continue calling imap_ok().
>>>
>>> On reading the RFCs, it looks like the [READ-ONLY] flag is actually
>>> part of a tagged response. Should the [READ-ONLY] check be moved to
>>> imap_response()?
>>>
>>> Functions cleaned up:
>>>
>>> imap_getrange()
>>> imap_getpartialsizes()
>>> imap_trail()
>>>
>>>
>>>> I think (unless I'm mistaken) we need to deal with asynchronous  
>>>> (non-requested)
>>>> untagged messages anyways, so perhaps all of the untagged logic needs  
>>>> to be in
>>>> imap_ok, but I'm not sure about that.  Since I haven't looked at the  
>>>> imap.c code
>>>> lately, please only consider this brainstorming or "thinking aloud"  
>>>> and not a
>>>> plea or request to do things in a certain way.  Design it the way you  
>>>> think fits
>>>> the needs best.
>>>>
>>>
>>> Please check if this patch addresses all the issues raised.
>>>
>>>
>> OK, tested and it looks good.   See -v -v output attached.
>>
>>
>
> Just letting you know I've been running this for a few days now with no
> problems.

Hi Matt,

thanks for the continued testing of this new feature, and helping us  
proceed with the work.

Dear Sunil,

thanks a lot for your work on this. I hope to audit and possibly commit  
the patch tonight.

Best regards
Matthias

-- 
Matthias Andree

Re: [fetchmail-devel] [PATCH-3] Re: fetchmail IMAP bug - causes some mails to not be delivered when using IDLE

[Matt D. <mat...@pa...>]

On 19/01/2010 2:13 PM, Matt Doran wrote:
> Sunil Shetye wrote:
>> Quoting from Matthias Andree's mail on Thu, Jan 14, 2010:
>>    
>>> Perhaps a separate imap_untagged_parse() function would be more suitable here,
>>> and possibly called from inside imap_ok()? See below.
>>>      
>>
>> Ok, I have made a separate imap_untagged_response() to parse the
>> untagged response. Other key changes:
>>
>> - use  stage == STAGE_GETAUTH&&  !strncmp(buf, "* CAPABILITY", 12)
>>    - instead of  strstr(buf, " CAPABILITY")
>>
>> - use  stage == STAGE_GETAUTH&&  !strncmp(buf, "* PREAUTH", 9)
>>    - instead of  strstr(buf, " PREAUTH")
>>
>> - use  stage == STAGE_GETRANGE&&  !check_only&&  strstr(buf, "[READ-ONLY]")
>>    - instead of  !check_only&&  strstr(buf, "[READ-ONLY]")
>>
>> - log  "* BYE"  message
>>
>>
>> These changes should save a lot of string comparisons during runtime.
>>
>>    
>>> Which raises another question: does it make sense to have caller-specific
>>> parsers for untagged replies? Perhaps those functions that need them - for
>>> instance for * SEARCH, should call some new imap_ok_with_untagged() function
>>> instead, and the normal imap_ok handles all untagged implicitly (we can rename
>>> imap_ok, and uses dummy functions that just pass in an additional argument
>>> whether or not returning PS_UNTAGGED is requested).
>>>      
>>
>> In order to address this, I have made one more intermediate function
>> imap_response(). Caller-specific parsers will call imap_response() in
>> a loop and others will continue calling imap_ok().
>>
>> On reading the RFCs, it looks like the [READ-ONLY] flag is actually
>> part of a tagged response. Should the [READ-ONLY] check be moved to
>> imap_response()?
>>
>> Functions cleaned up:
>>
>> imap_getrange()
>> imap_getpartialsizes()
>> imap_trail()
>>
>>    
>>> I think (unless I'm mistaken) we need to deal with asynchronous (non-requested)
>>> untagged messages anyways, so perhaps all of the untagged logic needs to be in
>>> imap_ok, but I'm not sure about that.  Since I haven't looked at the imap.c code
>>> lately, please only consider this brainstorming or "thinking aloud" and not a
>>> plea or request to do things in a certain way.  Design it the way you think fits
>>> the needs best.
>>>      
>>
>> Please check if this patch addresses all the issues raised.
>>
>>    
> OK, tested and it looks good.   See -v -v output attached.
>
>

Just letting you know I've been running this for a few days now with no 
problems.

Thanks,
Matt

Re: [fetchmail-devel] [PATCH-3] Re: fetchmail IMAP bug - causes some mails to not be delivered when using IDLE

[Matt D. <mat...@pa...>]

Old UID list from mail.papercut.com: <empty>
Scratch list of UIDs: <empty>
fetchmail: 6.3.13 querying mail.papercut.com (protocol IMAP) at Tue 19 Jan 2010 14:10:14 EST: poll started
Trying to connect to 216.92.193.84/143...connected.
fetchmail: IMAP< * OK Dovecot ready.
fetchmail: IMAP> A0001 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1 QUOTA STARTTLS AUTH=PLAIN AUTH=LOGIN
fetchmail: IMAP< A0001 OK Capability completed.
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: will idle after poll
fetchmail: IMAP> A0002 STARTTLS
fetchmail: IMAP< A0002 OK Begin TLS negotiation now.
fetchmail: Issuer Organization: The USERTRUST Network
fetchmail: Issuer CommonName: UTN-USERFirst-Hardware
fetchmail: Server CommonName: *.pair.com
fetchmail: Subject Alternative Name: *.pair.com
fetchmail: Subject Alternative Name: pair.com
fetchmail: mail.papercut.com key fingerprint: 46:1A:36:52:64:4B:71:ED:E8:D6:15:90:45:D7:74:0E
fetchmail: IMAP> A0003 CAPABILITY
fetchmail: IMAP< * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS UIDPLUS LIST-EXTENDED I18NLEVEL=1 QUOTA AUTH=PLAIN AUTH=LOGIN
fetchmail: IMAP< A0003 OK Capability completed.
fetchmail: Protocol identified as IMAP4 rev 1
fetchmail: will idle after poll
fetchmail: mail.papercut.com: upgrade to TLS succeeded.
fetchmail: IMAP> A0004 LOGIN "matt" *
fetchmail: IMAP< A0004 OK Logged in.
fetchmail: selecting or re-polling default folder
fetchmail: IMAP> A0005 SELECT "INBOX"
fetchmail: IMAP< * FLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk)
fetchmail: IMAP< * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk \*)] Flags permitted.
fetchmail: IMAP< * 0 EXISTS
fetchmail: IMAP< * 0 RECENT
fetchmail: IMAP< * OK [UIDVALIDITY 1227629703] UIDs valid
fetchmail: IMAP< * OK [UIDNEXT 78307] Predicted next UID
fetchmail: IMAP< A0005 OK [READ-WRITE] Select completed.
fetchmail: 0 messages waiting after first poll
fetchmail: IMAP> A0006 IDLE
fetchmail: IMAP< + idling
fetchmail: IMAP< * 1 EXISTS
fetchmail: IMAP> DONE
fetchmail: IMAP< * 1 RECENT
fetchmail: IMAP< A0006 OK Idle completed.
fetchmail: 1 message waiting after re-poll
fetchmail: IMAP> A0007 SEARCH UNSEEN NOT DELETED
fetchmail: IMAP< * SEARCH 1
fetchmail: 1 is unseen
fetchmail: IMAP< * 2 EXISTS
fetchmail: IMAP< A0007 OK Search completed (0.000 secs).
fetchmail: 1 is first unseen
1 message for matt at mail.papercut.com.
fetchmail: IMAP> A0008 FETCH 1 RFC822.SIZE
fetchmail: IMAP< * 1 FETCH (RFC822.SIZE 544)
fetchmail: IMAP< A0008 OK Fetch completed.
fetchmail: IMAP> A0009 FETCH 1 RFC822.HEADER
fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {535}
reading message ma...@pa...:1 of 1 (535 header octets) About to rewrite Return-Path: <pap...@na...>
Rewritten version is Return-Path: <pap...@na...>

About to rewrite From: pap...@na...
Rewritten version is From: pap...@na...

About to rewrite To: mat...@pa...
Rewritten version is To: mat...@pa...

Trying to connect to 127.0.0.1/25...connected.
fetchmail: SMTP< 220 smaug.papercutsoftware.com ESMTP Exim 4.69 Tue, 19 Jan 2010 14:10:30 +1100
fetchmail: SMTP> EHLO smaug.papercutsoftware.com
fetchmail: SMTP< 250-smaug.papercutsoftware.com Hello matt at localhost [127.0.0.1]
fetchmail: SMTP< 250-SIZE 52428800
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250 HELP
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<pap...@na...> SIZE=544
fetchmail: SMTP< 250 OK
fetchmail: SMTP> RCPT TO:<matt@localhost>
fetchmail: SMTP< 250 Accepted
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself
#
fetchmail: IMAP< )
fetchmail: IMAP< A0009 OK Fetch completed.
fetchmail: IMAP> A0010 FETCH 1 BODY.PEEK[TEXT]
fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {9}
 (9 body octets) **
fetchmail: IMAP< )
fetchmail: IMAP< A0010 OK Fetch completed.
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 OK id=1NX4UA-0000Qs-Le
 flushed
fetchmail: IMAP> A0011 STORE 1 +FLAGS (\Seen \Deleted)
fetchmail: IMAP< * 1 FETCH (FLAGS (\Deleted \Seen \Recent))
fetchmail: IMAP< * 2 RECENT
fetchmail: IMAP< A0011 OK Store completed.
fetchmail: IMAP> A0012 EXPUNGE
fetchmail: IMAP< * 1 EXPUNGE
fetchmail: IMAP< * 1 RECENT
fetchmail: IMAP< A0012 OK Expunge completed.
fetchmail: selecting or re-polling default folder
fetchmail: 1 message waiting after re-poll
fetchmail: IMAP> A0013 SEARCH UNSEEN NOT DELETED
fetchmail: IMAP< * SEARCH 1
fetchmail: 1 is unseen
fetchmail: IMAP< A0013 OK Search completed (0.000 secs).
fetchmail: 1 is first unseen
1 message for matt at mail.papercut.com.
fetchmail: IMAP> A0014 FETCH 1 RFC822.SIZE
fetchmail: IMAP< * 1 FETCH (RFC822.SIZE 544)
fetchmail: IMAP< A0014 OK Fetch completed.
fetchmail: IMAP> A0015 FETCH 1 RFC822.HEADER
fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {535}
reading message ma...@pa...:1 of 1 (535 header octets) About to rewrite Return-Path: <pap...@na...>
Rewritten version is Return-Path: <pap...@na...>

About to rewrite From: pap...@na...
Rewritten version is From: pap...@na...

About to rewrite To: mat...@pa...
Rewritten version is To: mat...@pa...

fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<pap...@na...> SIZE=544
fetchmail: SMTP< 250 OK
fetchmail: SMTP> RCPT TO:<matt@localhost>
fetchmail: SMTP< 250 Accepted
fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter message, ending with "." on a line by itself
#
fetchmail: IMAP< )
fetchmail: IMAP< A0015 OK Fetch completed.
fetchmail: IMAP> A0016 FETCH 1 BODY.PEEK[TEXT]
fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {9}
 (9 body octets) **
fetchmail: IMAP< )
fetchmail: IMAP< A0016 OK Fetch completed.
fetchmail: SMTP>. (EOM)
fetchmail: SMTP< 250 OK id=1NX4UC-0000Qs-IR
 flushed
fetchmail: IMAP> A0017 STORE 1 +FLAGS (\Seen \Deleted)
fetchmail: IMAP< * 1 FETCH (FLAGS (\Deleted \Seen \Recent))
fetchmail: IMAP< A0017 OK Store completed.
fetchmail: IMAP> A0018 EXPUNGE
fetchmail: IMAP< * 1 EXPUNGE
fetchmail: IMAP< * 0 RECENT
fetchmail: IMAP< A0018 OK Expunge completed.
fetchmail: selecting or re-polling default folder
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 smaug.papercutsoftware.com closing connection
fetchmail: IMAP> A0019 IDLE
fetchmail: IMAP< + idling

[fetchmail-devel] [PATCH-3] Re: fetchmail IMAP bug - causes some mails to not be delivered when using IDLE

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

Quoting from Matthias Andree's mail on Thu, Jan 14, 2010:
> Perhaps a separate imap_untagged_parse() function would be more suitable here,
> and possibly called from inside imap_ok()? See below.

Ok, I have made a separate imap_untagged_response() to parse the
untagged response. Other key changes:

- use  stage == STAGE_GETAUTH && !strncmp(buf, "* CAPABILITY", 12)
  - instead of  strstr(buf, " CAPABILITY")

- use  stage == STAGE_GETAUTH && !strncmp(buf, "* PREAUTH", 9)
  - instead of  strstr(buf, " PREAUTH")

- use  stage == STAGE_GETRANGE && !check_only && strstr(buf, "[READ-ONLY]")
  - instead of  !check_only && strstr(buf, "[READ-ONLY]")

- log  "* BYE"  message


These changes should save a lot of string comparisons during runtime.

> Which raises another question: does it make sense to have caller-specific
> parsers for untagged replies? Perhaps those functions that need them - for
> instance for * SEARCH, should call some new imap_ok_with_untagged() function
> instead, and the normal imap_ok handles all untagged implicitly (we can rename
> imap_ok, and uses dummy functions that just pass in an additional argument
> whether or not returning PS_UNTAGGED is requested).

In order to address this, I have made one more intermediate function
imap_response(). Caller-specific parsers will call imap_response() in
a loop and others will continue calling imap_ok().

On reading the RFCs, it looks like the [READ-ONLY] flag is actually
part of a tagged response. Should the [READ-ONLY] check be moved to
imap_response()?

Functions cleaned up:

imap_getrange()
imap_getpartialsizes()
imap_trail()

> I think (unless I'm mistaken) we need to deal with asynchronous (non-requested)
> untagged messages anyways, so perhaps all of the untagged logic needs to be in
> imap_ok, but I'm not sure about that.  Since I haven't looked at the imap.c code
> lately, please only consider this brainstorming or "thinking aloud" and not a
> plea or request to do things in a certain way.  Design it the way you think fits
> the needs best.

Please check if this patch addresses all the issues raised.

-- 
Sunil Shetye.

Re: [fetchmail-devel] fetchmail IMAP bug - causes some mails to not be delivered when using IDLE

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

Am 14.01.2010 11:45, schrieb Sunil Shetye:
> [switching to fetchmail-devel]
> 
> Hi Matthias,
> 
> Quoting from Sunil Shetye's mail on Wed, Jan 13, 2010:
>> I agree that many servers do not send it. Also, fetchmail can and should handle
>> the counts better. However, in my opinion, the fix from dovecot side should be
>> trivial. Whereas, the fix from fetchmail side will be non-trivial as a major
>> rewrite of the imap driver will be required.
> 
> I was thinking of rewriting the imap driver so that all imap server
> responses are routed via the imap_ok() function. This is so that all
> the unexpected 'EXISTS', 'EXPUNGE' responses get trapped properly.
> This is how it will work:
> 
> Any imap command will go through this kind of loop:
> 
> ===============================================================================
> #define PS_UNTAGGED 30 /* untagged response on imap command (internal use) */
> 
> ok = gen_send(sock, "SEARCH UNSEEN");
> while ((ok = imap_ok(sock, buf)) == PS_UNTAGGED)
> {
> 
>     /* if we have reached here, we have got an untagged response not parsable by imap_ok(). */
> 
>     if ((cp = strstr(buf, "* SEARCH")))
>     {
> 	/* parse the response */
>     }

Perhaps a separate imap_untagged_parse() function would be more suitable here,
and possibly called from inside imap_ok()? See below.

> 
>     /* go back to get the remaining response */
> }
> if (ok != 0)
> {
>     report(stderr, GT_("search for unseen messages failed\n"));
>     return(ok);
> }
> ===============================================================================
> 
> In essence, gen_recv() at many places in imap.c will get replaced by
> imap_ok().
> 
> Are all the above changes okay? Should I start with the changes in
> imap_getrange() only? imap_getpartialsizes() can be the next function
> if this works out.

Yes, the changes you propose are not only OK, but also desirable and
appreciated. (And as bug fix also fit for 6.3.14.)

The only thing I'm wondering about is PS_UNTAGGED: is it okay to have imap_ok()
return PS_UNTAGGED? It sort of breaks the assumption that imap_ok() fetches the
server's final verdict on the requested previous operation -- and that
propagates to all uses of gen_transact(), by reference.  Reason: imap_ok() is -
in spite of the "static" attribute - externally callable through the "struct
method imap", namely if other code calls method->parse_response when method is
imap -- for instance, driver.c and transact.c call imap_ok: (from cscope)

  File        Function     Line
0 fetchmail.h <global>      218 int (*parse_response)(int , char *);
1 driver.c    do_session   1154 err =
                                (ctl->server.base_protocol->parse_response)
                                (mailserver_socket, buf);
2 transact.c  gen_transact 1599 ok = (protocol->parse_response)(sock, buf);


Which raises another question: does it make sense to have caller-specific
parsers for untagged replies? Perhaps those functions that need them - for
instance for * SEARCH, should call some new imap_ok_with_untagged() function
instead, and the normal imap_ok handles all untagged implicitly (we can rename
imap_ok, and uses dummy functions that just pass in an additional argument
whether or not returning PS_UNTAGGED is requested).

I think (unless I'm mistaken) we need to deal with asynchronous (non-requested)
untagged messages anyways, so perhaps all of the untagged logic needs to be in
imap_ok, but I'm not sure about that.  Since I haven't looked at the imap.c code
lately, please only consider this brainstorming or "thinking aloud" and not a
plea or request to do things in a certain way.  Design it the way you think fits
the needs best.

Thanks for participating in the solution of this issue!

Best regards
Matthias

Re: [fetchmail-devel] fetchmail IMAP bug - causes some mails to not be delivered when using IDLE

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

[switching to fetchmail-devel]

Hi Matthias,

Quoting from Sunil Shetye's mail on Wed, Jan 13, 2010:
> I agree that many servers do not send it. Also, fetchmail can and should handle
> the counts better. However, in my opinion, the fix from dovecot side should be
> trivial. Whereas, the fix from fetchmail side will be non-trivial as a major
> rewrite of the imap driver will be required.

I was thinking of rewriting the imap driver so that all imap server
responses are routed via the imap_ok() function. This is so that all
the unexpected 'EXISTS', 'EXPUNGE' responses get trapped properly.
This is how it will work:

Any imap command will go through this kind of loop:

===============================================================================
#define PS_UNTAGGED 30 /* untagged response on imap command (internal use) */

ok = gen_send(sock, "SEARCH UNSEEN");
while ((ok = imap_ok(sock, buf)) == PS_UNTAGGED)
{

    /* if we have reached here, we have got an untagged response not parsable by imap_ok(). */

    if ((cp = strstr(buf, "* SEARCH")))
    {
	/* parse the response */
    }

    /* go back to get the remaining response */
}
if (ok != 0)
{
    report(stderr, GT_("search for unseen messages failed\n"));
    return(ok);
}
===============================================================================

In essence, gen_recv() at many places in imap.c will get replaced by
imap_ok().

Are all the above changes okay? Should I start with the changes in
imap_getrange() only? imap_getpartialsizes() can be the next function
if this works out.

-- 
Sunil Shetye.

Re: [fetchmail-devel] FYI - Berlios compromise

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

Am 13.01.2010, 22:57 Uhr, schrieb grarpamp <gra...@gm...>:

>>   http://lwn.net/Articles/369633/rss
>>  Apparently no code was tampered with.
>
> That would be pretty hard to prove if the only source for
> comparison was the code repository itself and it's descendants,
> such as backups, mirrors, releases and developer/user copies.
> At least the fetchmail releases are signed via OpenPGP.
> That's a good thing.
> But how many of them, dating back to 2005, were rolled
> from, or co mingled with, that repository?
> Now if the repository had builtin cryptographic checksums,
> as does git-scm.com, it would be quite easy to check and
> thus leave off the 'apparently', and say much more
> authoritatively: 'no code was tampered with'.
> And since releases would include a sig over the hash of the
> revision used to create the release, anyone on the planet
> could verify their repo copy was also good.
> code.google.com offers git repos, etc.

Well, fetchmail's SVN was hosted on BerliOS for a relatively short time,  
short after the handover from ESR to Rob, Graham and yours truly -- and  
only until the maintainers were pissed with the "quality" of the BerliOS  
SVN offering. SVN (1.0.X at the time) required frequent database  
recoveries at that time when used with svn+ssh, and Graham Wilson (a  
former maintainer) has been courteously hosting the repository outside of  
BerliOS since then, with https:// access, without a hitch.  Graham's  
repository was apparently created on 2005-08-11, which pre-dates the PHP  
file (2005-12-something) shown on Heise's screenshot of the defaced  
BerliOS page.

To be frank, BerliOS system administration is virtually nonexistent, the  
average support ticket response times approaches infinity, and given the  
little effort invested in its system administration, things such as  
break-ins must happen sooner or later. There's a truckload of software on  
the BerliOS cluster that I wouldn't allow on my computers. Not the least  
of which to be mentioned is PHP... but let's stop the ranting here.   
BerliOS is free of charge and feature-rich and I have better network  
connectivity there.

> Oh wait, I'm dreaming again, the world will never change :)
> Thanks for fetchmail though, been using it daily for years.

Actually, I've tried to migrate the SVN repo to Git, but I find the  
SVN-to-Git-tools insufficient, and it takes a long time even on reasonably  
powered computers (Phenom II X4 w/ sufficient RAM and the fastest 7200/min  
HDD I could find) and I'm not 100% convinced I've received a faithful  
representation of the SVN repo.

I've also tried to import into Mercurial, which went as smooth as a gentle  
breeze, but I lack experience with Mercurial in production and therefore  
don't dare put it to production.

-- 
Matthias Andree

[fetchmail-devel] [Patch #1859] PWMD support

[<ad...@be...>]

Patch #1859 has been updated. 

Project: fetchmail
Category: None
Status: Open
Submitted by: bjk
Assigned to : m-a
Summary: PWMD support

Follow-Ups:

Date: 2010-Jan-13 17:11
By: bjk

Comment:
This new version fixes reconnecting to the same socket specified in the rcfile. Useful if there is more than one account specified which uses the same pwmd socket.
-------------------------------------------------------

Date: 2009-Apr-29 20:10
By: bjk

Comment:
Updated to use libpwmd6.
-------------------------------------------------------

Date: 2008-Oct-19 13:10
By: bjk

Comment:
Really use the pwmd pinentry method.
-------------------------------------------------------

Date: 2008-Jul-11 13:23
By: bjk

Comment:
Now uses pwmds (v1.11) pinentry method for pinentry timeouts.
-------------------------------------------------------

Date: 2008-Jan-26 14:09
By: bjk

Comment:
Another fix for lock file checking.
-------------------------------------------------------

Date: 2008-Jan-12 15:37
By: bjk

Comment:
This re-adds pinentry timeout support and fixes the previous patch complaining about an existing fetchmail running.
-------------------------------------------------------

Date: 2008-Jan-06 13:05
By: bjk

Comment:
Updated to work with libpwmd5. This revision removes pinentry timeouts so make sure the password is cached on the server when running in daemon mode otherwise if your away pinentry will block the fetchmail daemon waiting for input. It also checks the pwmd server at each poll interval.
-------------------------------------------------------

Date: 2007-Oct-20 13:53
By: bjk

Comment:
Here's a new patch for fetchmail 6.3.8 and libpwmd4. Includes pinentry settings. I'm not sure how to handle timeouts and errors connecting to pwmd. As it is now it'll exit like fetchmail does when it encounters an rcfile parse error.
-------------------------------------------------------

Date: 2007-Feb-17 11:47
By: bjk

Comment:
Password Manager Daemon. It servers clients data whch is stored in an encrypted XML file. A client connects, provides a password to open a file and issues protocol commands to manipulate the data. It's a work in progress.

The fetchmail patch uses PWMD to get server info (hostname, sslfingerprint, port, etc), username and password info.
-------------------------------------------------------

Date: 2007-Feb-16 17:42
By: m-a

Comment:
What's PWMD?
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://developer.berlios.de/patch/?func=detailpatch&patch_id=1859&group_id=1824

Re: [fetchmail-devel] FYI - Berlios compromise

[grarpamp <gra...@gm...>]

>   http://lwn.net/Articles/369633/rss
>  Apparently no code was tampered with.

That would be pretty hard to prove if the only source for
comparison was the code repository itself and it's descendants,
such as backups, mirrors, releases and developer/user copies.
At least the fetchmail releases are signed via OpenPGP.
That's a good thing.
But how many of them, dating back to 2005, were rolled
from, or co mingled with, that repository?
Now if the repository had builtin cryptographic checksums,
as does git-scm.com, it would be quite easy to check and
thus leave off the 'apparently', and say much more
authoritatively: 'no code was tampered with'.
And since releases would include a sig over the hash of the
revision used to create the release, anyone on the planet
could verify their repo copy was also good.
code.google.com offers git repos, etc.

Oh wait, I'm dreaming again, the world will never change :)
Thanks for fetchmail though, been using it daily for years.

[fetchmail-devel] FYI - Berlios compromise

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

FYI:

 http://lwn.net/Articles/369633/rss

Apparently no code was tampered with.

-- 
                 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-devel] [BUG] \n missing in -v output

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

Am 13.11.2009, 17:58 Uhr, schrieb Melchior FRANZ  
<mel...@gm...>:

> Since I updated from openSUSE 11.1 to 11.2, fetchmail's output with one  
> verbose
> level doesn't look right. They use fetchmail 6.3.11, but I checked out  
> 6.3.13
> from your SVN repository and it has the same bug. (HEAD segfaults.)

Please send a stack backtrace along with the necessary debug information  
(note you need to use branches/BRANCH_6-3, not trunk/) as per  
http://www.fetchmail.info/fetchmail-FAQ.html#G3 - perhaps  
http://leafnode.sourceforge.net/doc_en/FAQ.html#backtrace can also help  
you with the stack backtrace.

> Looks like you want the space only if outlevel > O_VERBOSE, not >=.  (?)

I'll look into that.

-- 
Matthias Andree

[fetchmail-devel] [BUG] \n missing in -v output

[Melchior F. <mel...@gm...>]

Since I updated from openSUSE 11.1 to 11.2, fetchmail's output with one verbose
level doesn't look right. They use fetchmail 6.3.11, but I checked out 6.3.13
from your SVN repository and it has the same bug. (HEAD segfaults.)

I get lines like these:

  fetchmail: POP3< +OK message follows
  reading message so...@ad...o:2 of 9 (3429 octets) fetchmail: SMTP> MAIL FROM:<an...@ad...o> BODY=7BIT SIZE=3429
  fetchmail: SMTP< 250 2.1.0 Ok

That is: the line starting with "reading" isn't properly closed with '\n' and
the next line is just appended there. That's annoying, as I always fetch mail
via a wrapper, which calls "fetchmail -v" and extracts and colorizes the
interesting information. Something like:

  3       99299   << my.provider.com
  1/3     84243   ## oversized ## 
  2/3     5056    *osg users
  3/3     10000   *git     

Looks like you want the space only if outlevel > O_VERBOSE, not >=.  (?)

m.



PS: gcc 4.4.1, libc 2.10.1, Linux 2.6.31.6 (x86_64)

[fetchmail-devel] New Italian PO file for 'fetchmail' (version 6.3.12)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Italian team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/it.po

(This file, 'fetchmail-6.3.12.it.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] fetchmail 6.3.13 regression/bug fix release available (STABLE)

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

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

Greetings,

I am announcing the release of fetchmail 6.3.13.  This new stable
version of fetchmail fixes a bug introduced into 6.3.12 that would treat
all SMTP errors as temporary, regardless of the softbounce setting. It
also updates translations.  See below for details.

The software is available from:
<http://developer.berlios.de/project/showfiles.php?group_id=1824>

The fetchmail home pages are:
<http://www.fetchmail.info/>  or  <http://fetchmail.berlios.de/>

These are the relevant changes since the previous release.
Unless otherwise noted, changes to this release were made by Matthias Andree:

# REGRESSION FIXES
* The multiline SMTP error fix in release 6.3.12 caused fetchmail to lose
  message codes 400..599 and treat all of these as temporary error. This would
  cause messages to be left on the server even if softbounce was turned off.
  Reported by Thomas Jarosch.

# TRANSLATION UPDATES
* [cs]    Czech, by Petr Pisar
* [zh_CN] Chinese (simplified), by Ji ZhengYu
* [nl]    Dutch, by Erwin Poeze
* [id]    Indonesian, by Andhika Padmawan
* [ja]    Japanese, by Takeshi Hamasaki
* [pl]    Polish, by Jakub Bogusz
* [es]    Spanish (Castilian), by Franciso Molinero
* [vi]    Vietnamese, by Clytie Siddall

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkrqUroACgkQvmGDOQUufZUjvwCfeQgMAwj29Y6Ue0VJhEZ1BRFd
UpAAn1jiYlj4OO7HrmYiSw+IYq2iKYGl
=n9RM
-----END PGP SIGNATURE-----

[fetchmail-devel] 6.3.12 regression: SMTP error code parser

[Thomas J. <tho...@in...>]

Hello,

I just upgraded from fetchmail 6.3.11 to 6.3.12 and noticed that
the softbounce option wasn't working as expected.

As a test, I sent a message to an unknown recipient in a multidrop domain.
The message should then be bounced to the sender once (set no softbounce).

Here's the output from fetchmail 6.3.12 with smtp.c from fetchmail 6.3.11:

fetchmail: passed through gib...@re... matching recipient.com
fetchmail: Trying to connect to 127.0.0.1/25...connected.
fetchmail: SMTP< 220 intratest2.net.lan ESMTP
fetchmail: SMTP> EHLO intratest2.net.lan
fetchmail: SMTP< 250-intratest2.net.lan
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE 104857600
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-STARTTLS
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250 DSN
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<tho...@se...> BODY=7BIT SIZE=1756
fetchmail: SMTP< 250 2.1.0 Ok
fetchmail: SMTP> RCPT TO:<gib...@re...>
fetchmail: SMTP< 550 5.1.1 <gib...@re...>: Recipient address rejected: User unknown
fetchmail: SMTP error: 550 5.1.1 <gib...@re...>: Recipient address rejected: User unknown
fetchmail: SMTP listener doesn't like recipient address `gib...@re...'

-> Generates one bounce mail only

Output from a vanilla 6.3.12 installation:

fetchmail: passed through gib...@re... matching recipient.com
fetchmail: Trying to connect to 127.0.0.1/25...connected.
fetchmail: SMTP< 220 intratest2.net.lan ESMTP
fetchmail: SMTP> EHLO intratest2.net.lan
fetchmail: SMTP< 250-intratest2.net.lan
fetchmail: SMTP< 250-PIPELINING
fetchmail: SMTP< 250-SIZE 104857600
fetchmail: SMTP< 250-ETRN
fetchmail: SMTP< 250-STARTTLS
fetchmail: SMTP< 250-ENHANCEDSTATUSCODES
fetchmail: SMTP< 250-8BITMIME
fetchmail: SMTP< 250 DSN
fetchmail: forwarding to localhost
fetchmail: SMTP> MAIL FROM:<tho...@se...> BODY=7BIT SIZE=1757
fetchmail: SMTP< 250 2.1.0 Ok
fetchmail: SMTP> RCPT TO:<gib...@re...>
fetchmail: SMTP< 550 5.1.1 <gib...@re...>: Recipient address rejected: User unknown
fetchmail: SMTP> RSET
fetchmail: SMTP< 250 2.0.0 Ok
fetchmail:  not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK POP server signing off
fetchmail: SMTP> QUIT
fetchmail: SMTP< 221 2.0.0 Bye

-> Message stays on the server and will be refetched everytime fetchmail is called.

To me this looks like the new multiline smtp error code parser is broken?
The SMTP server in question is postfix 2.6.2.

Cheers,
Thomas

[fetchmail-devel] [Feature #4829] Add timestamps to logs

[<ad...@be...>]

Feature Request #4829, was updated on 2009-Oct-07 20:18
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=4829&group_id=1824

Category: None
Status: Open
Priority: 1
Summary: Add timestamps to logs

By: m-a
Date: 2009-Oct-07 22:53

Message:
Logged In: YES 
user_id=2007
Browser: Opera/9.80 (X11; Linux i686; U; de) Presto/2.2.15 Version/10.00

Logging to syslog should fix this, and might enable mixing fetchmail logs 
into other mail system logs into the same file in chronological order. Is that 
an option for you?

----------------------------------------------------------------------

By: martinmcclure
Date: 2009-Oct-07 20:18

Message:
Logged In: YES 
user_id=53493
Browser: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009100613 Gentoo Firefox/3.0.14

As of 6.3.10, the sleeping at/awakened at messages are
no longer logged unless in verbose mode. This gets rid
of a lot of noise, but in a typical non-verbose log
(mine, anyway) these were the only messages that
contained timestamps. 

Now, non-verbose logs do not contain any time markers,
making it very hard to correlate fetchmail log messages
with log messages from other components in an email
system. 

Fetchmail logs would be much more useful if at least
some common messages contained timestamps.

Personally, I don't care if log timestamps are on all
the time or are optional. I would always enable them.
Others might wish for the option to turn them off.

Thanks!

----------------------------------------------------------------------
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=4829&group_id=1824

[fetchmail-devel] New Dutch PO file for 'fetchmail' (version 6.3.12)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Dutch team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/nl.po

(This file, 'fetchmail-6.3.12.nl.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] fetchmail 6.3.12 language update patch available

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

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

Greetings,

Due to last-minute changes, the fetchmail 6.3.12 tarball released two
weeks ago didn't have all languages updated. I have now provided a patch
for the 6.3.12 tarball that updates the translations. Please extract the
6.3.12 tarball, then unpack and apply the translations patch called
fetchmail-6.3.12-transl1.patch, then build and package or install as
usual.

Note that I am skipping the Dutch update because it translates fixed
RFC-5322 strings such as Subject: to Onderwerp: which
isn't appropriate for mail headers that we feed to an SMTP server.

As the last updates are from 2008 anyways, I'm not waiting for the Dutch
team to fix this, but just skip the patch.  The two last translators and
the Dutch team are CC:d in the hopes that someone picks up the
translation.  It is in a reasonable shape with just 4 missing and 9
fuzzy translations, so it should be little effort to fix it.

The patch for fetchmail is available for download from:
<http://developer.berlios.de/project/showfiles.php?group_id=1824>
<http://home.pages.de/~mandree/fetchmail/>

The fetchmail home pages are:
<http://www.fetchmail.info/>  or  <http://fetchmail.berlios.de/>

Happy fetching!

- -- 
Matthias Andree
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkreRewACgkQvmGDOQUufZWATwCePqnpaSAJIEQ8eAIO2mcBGodY
dCEAoKWhhrnG2ELv5N+QGv7/VufQKdpj
=T44k
-----END PGP SIGNATURE-----

[fetchmail-devel] New Chinese (simplified) PO file for 'fetchmail' (version 6.3.12)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Chinese (simplified) team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/zh_CN.po

(This file, 'fetchmail-6.3.12.zh_CN.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] New Indonesian PO file for 'fetchmail' (version 6.3.12)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Indonesian team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/id.po

(This file, 'fetchmail-6.3.12.id.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>

[fetchmail-devel] [Feature #4829] Add timestamps to logs

[<ad...@be...>]

Feature Request #4829, was updated on 2009-Oct-07 20:18
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=4829&group_id=1824

Category: None
Status: Open
Priority: 5
Summary: Add timestamps to logs

By: m-a
Date: 2009-Oct-07 22:53

Message:
Logged In: YES 
user_id=2007
Browser: Opera/9.80 (X11; Linux i686; U; de) Presto/2.2.15 Version/10.00

Logging to syslog should fix this, and might enable mixing fetchmail logs 
into other mail system logs into the same file in chronological order. Is that 
an option for you?

----------------------------------------------------------------------

By: martinmcclure
Date: 2009-Oct-07 20:18

Message:
Logged In: YES 
user_id=53493
Browser: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009100613 Gentoo Firefox/3.0.14

As of 6.3.10, the sleeping at/awakened at messages are
no longer logged unless in verbose mode. This gets rid
of a lot of noise, but in a typical non-verbose log
(mine, anyway) these were the only messages that
contained timestamps. 

Now, non-verbose logs do not contain any time markers,
making it very hard to correlate fetchmail log messages
with log messages from other components in an email
system. 

Fetchmail logs would be much more useful if at least
some common messages contained timestamps.

Personally, I don't care if log timestamps are on all
the time or are optional. I would always enable them.
Others might wish for the option to turn them off.

Thanks!

----------------------------------------------------------------------
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=4829&group_id=1824

[fetchmail-devel] [Feature #4829] Add timestamps to logs

[<ad...@be...>]

Feature Request #4829, was updated on 2009-Oct-07 10:18
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=4829&group_id=1824

Category: None
Status: Open
Priority: 5
Summary: Add timestamps to logs

By: martinmcclure
Date: 2009-Oct-07 10:18

Message:
Logged In: YES 
user_id=53493
Browser: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.14) Gecko/2009100613 Gentoo Firefox/3.0.14

As of 6.3.10, the sleeping at/awakened at messages are
no longer logged unless in verbose mode. This gets rid
of a lot of noise, but in a typical non-verbose log
(mine, anyway) these were the only messages that
contained timestamps. 

Now, non-verbose logs do not contain any time markers,
making it very hard to correlate fetchmail log messages
with log messages from other components in an email
system. 

Fetchmail logs would be much more useful if at least
some common messages contained timestamps.

Personally, I don't care if log timestamps are on all
the time or are optional. I would always enable them.
Others might wish for the option to turn them off.

Thanks!

----------------------------------------------------------------------
You can respond by visiting: 
http://developer.berlios.de/feature/?func=detailfeature&feature_id=4829&group_id=1824

[fetchmail-devel] New Spanish PO file for 'fetchmail' (version 6.3.12)

[Translation P. R. <ro...@tr...>]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'fetchmail' has been submitted
by the Spanish team of translators.  The file is available at:

    http://translationproject.org/latest/fetchmail/es.po

(This file, 'fetchmail-6.3.12.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

    http://translationproject.org/latest/fetchmail/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/fetchmail.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

                                The Translation Project robot, in the
                                name of your translation coordinator.
                                <coo...@tr...>