Re: [fetchmail-users] [PATCH] Re: Problem with Demon's new Microsoft Exchange Server 2010 service

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

Am 09.05.2012 10:35, schrieb Sunil Shetye:
> Hi,
> 
>>> Problem:
> 
>>> I have recently been migrated to Demon's new service which appears to be
>>> based on Microsoft Exchange Server 2010.  The migration appeared to have
>>> been successful with messages being fetched.  Then fetching of messages
>>> ceased.  I added "-vvv" to /etc/init.d/fetchmail and restarted
>>> fetchmail.  Here are edited highlights from /var/log/fetchmail:
> 
> ...
> 
>>> fetchmail: IMAP> A0009 FETCH 1 RFC822.HEADER
>>> fetchmail: IMAP< A0009 OK FETCH completed.
>>> fetchmail: Incorrect FETCH response: OK FETCH COMPLETED..
> 
> Attached is a patch to fix this problem. Please note that this patch will not change the behaviour for mails with such responses. It will ensure that mails after the current mail will be fetched as is expected.
> 
>> Sunil, for resilience towards massive faults on the server side, we'll
>> probably have to add an error counter so that fetchmail won't attempt to
>> fetch hundreds of messages' headers and skip over all of them when the
>> server exhibits systematic faults (and not just some individual
>> messages, as your report suggests).
> 
> I have added a counter to this patch to log the number of transient errors. I am tempted to add a open_warning_by_mail() instead of just logging it for too many transient errors. However, if such mails are accumulating, there will be a warning mail per poll leading to excessive warning mails.
> 
> Also note that the bug is that fetchmail currently stops fetching the remaining mails from the folder the moment it gets an unexpected response. As this problematic mail is not removed, fetchmail stops fetching mails from the folder completely across polls. This patch ensures that fetching of the remaining mails continues.

Sunil,

thanks a lot, the patch looks good at first inspection.

I think if the count of transient errors goes too high, we should skip
to the next server (else counting is pointless).  I'll add that, too.  I
understand your itch to add that "send warning mail", but I think
fetchmail needs a generic framework for reporting trouble by mail first
- or at least such a feature would have to be structured in a way to
support such a framework later on.  Not 6.3.X stuff though, but for
future development version (although fine for 7.0.X).
The underlying issue that has always been nagging (but not being
annoying enough) is that fetchmail makes a distinction between daemon
and regular mode...

I don't think a tool like fetchmail can survive without any operator
attention though.  We certainly don't want a message on every poll, but
a message after 4 hours and then every 24 hours should be good.  Only we
don't have code to support that outside daemon mode.

I think that part is stuff for the -devel list.

John,

can you try Sunil's patch, i. e. unpack the fetchmail sources, apply the
patch, ./configure --with-ssl --with-gssapi and install, then move the
offending message back in your inbox, send yourself another test
message, and see if the patched fetchmail version skips over the
offending message and retrieves the test message?

Thanks a bunch.

Best regards
Matthias