[Bug 247895] New: moved mail using filter is chmoded 600, on an IMAP server with umask set to 026

[Mathieu Roy]

https://bugs.kde.org/show_bug.cgi?id=247895

           Summary: moved mail using filter is chmoded 600, on an IMAP
                    server with umask set to 026
           Product: kmail
           Version: 1.13.5
          Platform: Debian testing
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: filtering
        AssignedTo: kdepim-bugs at kde.org
        ReportedBy: yeupou at gnu.org


Version:           1.13.5 (using KDE 4.4.5) 
OS:                Linux

Hello,

The setup of my IMAP server is so that all incoming mails get filemode 640
(group readable), umask being defined as 026.
The IMAP server is dovecot as currently shipped on Debian stable.

Whenever I move, within Kmail over IMAP, a mail with drag and drop, the
filemode 640 of the mail is preserved.

I created a filter that sole purpose is to move files to a specific directory
whenever I use a given keyboard shortcut (alt-S, for instance). Actually, it
also tags the mail - but that makes no difference, I made several tests, I
tried removing the tagging part of the filter, keeping only the moving file
part. 

I would have expected this filter to behave exactly like a drag n drop. But it
does not, it actually create a new file on the IMAP server. 
For instance, I had one mail stored in a file
1281807134.P3217Q0M185114.moe:2,S. When I run the filter on it, it creates,
while renaming 1281807134.P3217Q0M185114.moe:2,S into
1281807134.P3217Q0M185114.moe:2,ST, a new file called
1281813409.P3217Q1.moe:2,S.

diff between the two files returns:
44,45c44,45
< X-UID: 8470
< X-KMail-Filtered: 187622
---
> X-UID: 8469
> X-KMail-Filtered: 187620

Even if there are two files on the IMAP server, there is only one mail shown in
kmail. I guess that's normal, I'm not familiar enough with IMAP to comment it.

But, and this is where I'm getting at, the new file 1281813409.P3217Q1.moe:2,S
filemode is set to 600.

I do not know if kmail is at fault here. I wonder if the mail client is enabled
to set filemode over IMAP, disregarding the IMAP server umask. So maybe it is a
bug in dovecot that miss in some case to set properly the new filemode
according to umask in its own configuration, please tell me.

Anyway, even if dovecot is faulty for wrongly setting the filemode
unaccordlingly configured umask (which is not clear to me - if it is Kmail that
somehow override dovecot umask, then it is an obvious bug), I would have
expected kmail filter option "move to this directory" to behave exactly like
the drag and drop.

What am I misunderstanding? :)
Do you need more info?

Reproducible: Always

Steps to Reproduce:
- Set up a filter which does only when thing: move selected mails to a given
directory over IMAP.
- Select a mail, run the filter on it

Actual Results:  
- Check on the IMAP server, you should have two copies of the mail, the later
being created by kmail filter, set in mode 600

Expected Results:  
- I would have expected to have a single copy of the mail as it would have
happened if I had simply made a drag and drop.


Obviously, this bug have two parts:
 A - the filter move to X directory create a new file on the IMAP server
 B - this new file is not according to IMAP server umask, which I understand
may be a bug in dovecot (in which case I'll fill a report against it too, tell
me)

If kmail, not dovecot, is at fault in B, then fixing this part only would do
the trick. I have no opinion about how kmail should handle filters, it surely
have a purpose to create a new file whenever a filter is run, hence the
specific X-KMail-Filtered and X-UID headers.

However, if kmail is not responsible for B, then it would be very useful to
make it, at least, an option for filters to avoid creating new files. Say it
may be useful to run filters not altering the message in any way, just like a
drag and drop would have done.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.