Bugreport: maxage deleting old email from destination

Vladimir Marek Vladimir.Marek at Oracle.COM
Sun Jul 31 09:56:24 UTC 2011


> > For testing purposes it might be good to limit offlineimap to just some
> > small folder, where you can try maxage.
> 
> Well, my test setup was a bit different (because it's a LIVE mailbox
> and a live sync).

I don't understand that. What is a 'LIVE' mailbox and live sync? How
does it differ from normal mailbox and normal sync? I don't see why you
can not create new folder called 'test' and copy one email there. And
play just with the one folder so that you won't trash your real emails
if something goes wrong.


> For the already synced account I add maxage=180 and
> the debug parameters you suggested. Some mail gets deleted:

Ok, so let me try to re-phrase what your problem is.

You have local and remote mailboxes. In the local mailbox you deleted old
mails, but you don't want to delete them from remote mailbox. So you run
offlineimap with maxage setting. But you still see old emails being
deleted.

> Syncing 1A_invoices: Gmail -> MappedIMAP
> Deleting 23 messages (26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
> 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48) in Gmail[1A_invoices],
> LocalStatus[1A_invoices]
> Syncing 1A_tracking: Gmail -> MappedIMAP
> Deleting 26 messages (33, 34, 35, 36, 37, 38, 75, 76, 77, 78, 79, 80,
> 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94) in
> Gmail[1A_tracking], LocalStatus[1A_tracking]
> 
> So I grep the log for 1A_invoices (which is a folder name) and attach
> it. Yes, the SINCE date is correct, but still the messages get
> deleted. Anything else I can do?

Right. Looking at
http://tools.ietf.org/html/rfc3501#section-2.3.3
offlineimap is using 'internal date' of a messages. That means date when
message was added to a given folder. That can differ a lot from the date
when the message was sent/received, I think. For example if you receive
the message 1.1.2011 into INBOX and 12.12.2011 you decide that you want
to move the message into folder OLD, depending on how exactly your
client moves the message, internal date can be set to 12.12.2011. If you
deleted old mail locally based on what is written in each mail header
(that again depends on what exactly does your client), mail server could
have different idea about 'age' of the message than your local client
has.

To find out, it would be interesting to see that. Let's login to your
IMAP server. I suppose it's using ssl connection. Lines beginning with
'#' are my comments. Lines beginning with '->' is what I suppose to see
as a response.

$ openssl s_client -crlf -connect YOUR_SERVER:993
# a lot of unimportant stuff will be here
. login your_name your_password
# please note that the dot at the beginning is important
-> . OK LOGIN completed
. examine 1A_tracking
-> . OK [READ-ONLY] EXAMINE completed
. fetch 1:10 internaldate
-> * 1 FETCH (INTERNALDATE "08-Jul-2011 02:02:13 -0700")
-> * 2 FETCH (INTERNALDATE "08-Jul-2011 05:31:18 -0700")
-> * 3 FETCH (INTERNALDATE "09-Jul-2011 17:01:09 -0700")
-> * 4 FETCH (INTERNALDATE "10-Jul-2011 22:21:05 -0700")
-> * 5 FETCH (INTERNALDATE "10-Jul-2011 22:21:06 -0700")
-> * 6 FETCH (INTERNALDATE "08-Jul-2011 06:51:15 -0700")
-> * 7 FETCH (INTERNALDATE "08-Jul-2011 07:01:11 -0700")
-> * 8 FETCH (INTERNALDATE "08-Jul-2011 07:01:49 -0700")
-> * 9 FETCH (INTERNALDATE "08-Apr-2011 03:41:10 -0700")
-> * 10 FETCH (INTERNALDATE "09-Jul-2011 22:58:59 -0700")
-> . OK FETCH completed
# So those are the dates the server compares to your MAXAGE setting
# you can list the Date field of the emails:
. fetch 1:10 (body[header.fields (Date)])
-> * 1 FETCH (BODY[HEADER.FIELDS ("Date")] {46}
-> Date: Fri, 8 Jul 2011 03:02:01 -0600 (MDT)
-> 
-> )
# etc.
# In my case the dates correspond. What about you? You can use bigger
# range instead of 1:10. !:* selects all messages in the folder.

-- 
	Vlad



More information about the OfflineIMAP-project mailing list