<DKIM> [PATCH 1/2] decouple utime_from_header from rtime

[Abdó Roig-Maranges]

This one is ready to be applied, if you accept that we make utime_from_headers
nonfunctional on IMAP folders.

Also, you suggested adding a comment regarding direct feeding to dovecot. But I
think it is not necessary. We concluded that this patch doesn't break dovecot
anymore than it was broken before, isn't it? 

Abdó.



Nicolas Sebrecht writes:

> On Fri, Apr 03, 2015 at 03:17:35AM +0200, Abdó Roig-Maranges wrote:
>> 
>> Oh, you mean that utime_from_header should also affect IMAP folders?
>
> That's how utime_from_message worked since introduced, AFAICT.
>
>>                                                                      I imagined
>> that this feature was intended for Maildirs. If someone has a use case for this
>> we can do the same on IMAP folders, it's just a few lines of code.
>
> That's exactly what I was trying to say. Just a side note.
>
>> > When rtime was introduced, it really was to fix the modification file
>> > times. The filename was not affected. This allowed John to feed Dovecot
>> > directly with the OfflineIMAP Maildir, behind Dovecot's back. Let's call
>> > this configuration "direct feeding".
>> >
>> > This was at the time IMAP/IMAP didn't exist, yet. Today, I think direct
>> > feeding configurations are just wrong and users should migrate from
>> > their direct feeding to IMAP/IMAP, instead. I expect there's a lot of
>> > direct feeding configurations out there because this is how it was
>> > implemented for a long time and probably what users were told to do.
>> >
>> > Since recent 25513e90387f6, Janna and me decided to put rtime
>> > (INTERNALDATE) in the filename rather than use the modification file
>> > time. But this was while fixing maxage in mind, only.
>
> I'm wrong, here. We decided to put the remote INTERNALDATE in the
> filename rather than the downloaded date and time...
>
>> >                                                       By doing so, we
>> > ARE breaking all existing direct feeding configurations.
>
> ... By doing so, I don't know how it will impact direct feeding.
>
>> > IOW, the quick sync mode is used with WRONG assumptions of what the
>> > modification file time really means FOR YEARS. This was mainly not
>> > hurting because INTERNALDATE are always expected older than the download
>> > date times of a sync.
>
> I'm wrong here, too.
>
>> > What you are doing with this last hunk is not only decouple
>> > utime_from_header from rtime but also FIX the modification file times to
>> > reflect only what it should be: last modification time of the file, as
>> > expected for quick syncs.
>> 
>> Ok, I am a bit confused now. Let me ask some questions:
>
> Let's forget. I did confused you because I've mixed things between the
> different WIPs, bugs, real values of rtime plus other discussed issues.
> I'm sorry about that.
>
>> 1. Does anyone rely on the timestamp in the filename being the same as the
>>    modification time? Or can we use different values in the filename and the
>>    modification time?
>
> Both should be unrelated outside of utime_from_header.
>
>> 2. Is there people out there relying on doing funny things with modification
>>    times? You mentioned the "direct feeding", but I don't understand what they
>>    need and how we break it.
>
> Each time we change the Maildir format, we expose users to new failures.
>
> This is because we are not alone to work on the Maildir. It is a
> database shared accross various softwares, each coming with its own assumptions.
>
>> If the answer to question 2 above is yes, then the assumptions of those people
>> were not met, because due to bugs, we were not interfering with the usual file
>> mtimes anyways. Is this what you were saying? Then keeping not interfering with
>> mtimes should not be any worse for them than it has been.
>
> Correct.
>
>> I'd argue that not messing with file modification times should be what we do by
>> default, because I think it is what most people would expect. One thing we could
>> do is add a config option "utime_from", with values:
>> 
>> - none:    leave modification times alone (default)
>> - header:  use header date as modification time
>> - remote:  use rtime (remote time) as modification date
>> 
>> Would this make sense?
>
> Forget about the third. I'm mixing things because I believe we don't
> honor Dovecot assumptions and I suspect this is because of this third
> case. But as I said, direct feeding is a wrong setup we don't want to
> support anymore.
>
>> I can't write about this because I don't fully understand the direct feeding
>> thing.
>
> This is just this:
>
>   IMAP server -> OfflineIMAP -> Maildir -> Dovecot (or whatever)
>
> This is wrong and should be:
>
>   IMAP server -> OfflineIMAP -> IMAP -> Dovecot (or whatever) -> Maildir
>
>
> Otherwise, thinking twice, the patch looks good.