Re: [imapsync] unexplicable 'no header used or found for message...' warnings

[Michele Marcionelli <michele dot marcionelli at math dot ethz dot ch>]

Hello Gilles

> Hello,
> 
>> with some "huge" Mailboxes (4'000-27'000 emails) I get very often following warning:
>> 
>> Warning: no header used or found for message NNN
>> no header so taking body first 2Ko
> 
> Maybe a --nofirst2Ko is needed.

Maybe not... if I manage to run imapsync correctly with the --usecache option ;-)

>> The problem is that in most cases (99%) the header exists and if I open the email in a mail-client 
>> (for instance mutt) I see it perfectly.
> 
> Ok.
> 
>> An unlucky consequence that in some cases I get up 
>> to 10'000 time this warning and this means that 10'000 x 2Ko are downloaded, so that the biggest
>> INBOX takes about 10 hours to be (re!!)-synced.
> 
> Ok.
> If you use --usecache then the resync should avoid taking the headers again.
> The cache is based on UID given from both sides, not on headers.

I already pre-synced days ago. Using the --usecache option nows seems not to be working resp. not having the desired effect. Should I use this option already for the very first sync, when the mailbox on host2 is empty to increase speedup?

>> Do you have experience with this kind of behavior?
> 
> No. I'll try a test on huge folder.

Good.

>> I already tried with the --debugimap1 option but I didn't get any useful information.
> 
> On a big folder --debugimap will output too much.

Indeed ;-)

>> Is it somehow possible to printout the whole email? No only the bady (or a part of)?
> 
> Are those missing header messages well transfered?

Fortunately yes!! How can I print out the whole email?

>> And... as you can imagine this problem it difficult to reproduce.
> 
> The issue is that if the header really exists then maybe the faulty
> part is in getting the header. But getting the first 2Ko on one
> side and the header on other side will bring imapsync to a resync
> of the same message and generate a duplicate message.
> 
> The --usecache should prevent this.
> 
>> PS: -5 days
> 
> If you think the process needs more tests to be confident then ask a delay.
> It's better to be late and good than on time and bad since bad implies
> correcting, new delay, stress, frustrated users, boss and sysadmin.

This is why I need your help ;-)

Thanks a lot, Michele

-- 
ETH Zürich
Michele Marcionelli
IT Support Gruppe D-MATH
HG G 32.1
Rämistrasse 101
CH–8092 Zürich

michele dot marcionelli at math dot ethz dot ch
http://www.math.ethz.ch/~michele

+41 44 632 6193 Telefon
+41 44 632 1354 Fax