I mean that if one runs an IMAP server
then the directories must be in Dovecot's format,
in which case they cannot be accessed by kmail running on the server
with a standard Local Account.
If that is indeed the case,
it seems surprising that kmail documentation
does not appear to contain any warning of this.
On the other hand, if I am wrong, I would be very grateful
if someone could explain how one can combine kmail + dovecot IMAP.
Timothy Murphy wrote:
Hi Tim,
As far as I know the KMail's Maildir follows the original Maildir format
from Daniel J. Bernstein's qmail, I will check to see if there are any
variants but as far as I can see it does seem to use the directory
structure.
If I get some time off tomorrow I could try to implement Maildir++ along
side the existing Maindir support.
Cheers,
GA
- --
Guillermo Antonio Amaral Bastidas (gamaral)
# Free & Open-source Software Advocate
# KDE Developer: gamaral
@ http://blog.guillermoamaral.com/
$ irc: gamaral@freenode pgp: 0x5D297B74
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG7JrIxxxW3F0pe3QRAsG+AJ0YW82HP2vY0mUfLjHQOXxRP0933gCgibR7
FcIDE4I7cN9TcDUHcmJ0Kfc=
=eHzu
-----END PGP SIGNATURE-----
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Timothy Murphy wrote:
>
>> As far as I can see, KMail's maildir format
>> (with folders ~/Mail/inbox/cur , etc)
>> is incompatible with Dovecot's IMAP format
>> (with folders ~/Mail/.inbox/cur).
>>
>> I mean that if one runs an IMAP server
>> then the directories must be in Dovecot's format,
>> in which case they cannot be accessed by kmail running on the server
>> with a standard Local Account.
>>
>> If that is indeed the case,
>> it seems surprising that kmail documentation
>> does not appear to contain any warning of this.
>>
>> On the other hand, if I am wrong, I would be very grateful
>> if someone could explain how one can combine kmail + dovecot IMAP.
>
> Hi Tim,
>
> As far as I know the KMail's Maildir follows the original Maildir format
> from Daniel J. Bernstein's qmail, I will check to see if there are any
> variants but as far as I can see it does seem to use the directory
> structure.
>
> If I get some time off tomorrow I could try to implement Maildir++ along
> side the existing Maindir support.
Thanks, let us know how you get on.
After looking at the rather confusing documentation
on the subject of Maildir and Maildir++,
as far as I can see the original Maildir format
used 3 directories, ~/Mail/[cur,new,tmp]/ .
The problems arose when subfolders of the Mail directory were introduced.
The Maildir format used in kmail follows what seems to me
the natural extension, with directories ~/Mail/inbox/[cur,new,tmp]/ , etc.
These are not seen by an IMAP client, at least with dovecot.
The Maildir++ format, for reasons which escape me,
has directories ~/Mail/.inbox/[cur,new,tmp]/ .
These cannot be seen by local kmail, at least as a local account.
If this is wrong, please correct me.
Also I would be interested to know why Maildir++
adopted this "dotty" system.
> Thanks, let us know how you get on.
>
> < snip >
>
> The Maildir++ format, for reasons which escape me,
> has directories ~/Mail/.inbox/[cur,new,tmp]/ .
> These cannot be seen by local kmail, at least as a local account.
>
> If this is wrong, please correct me.
> Also I would be interested to know why Maildir++
> adopted this "dotty" system.
Well if I remember correctly the `courier` project ( courier-imap ) or
it's author is the brains behind the Maindir++ spec, they needed something
that could support sub-folders, mail quotas and still be a little
compatible with the original Maildir; the `.` prefix is used to hide
subfolders from the mail root.
Now their is one problem I noticed, if I implement it as a local account
type the data will be moved into `~/.kde/share/apps/kmail`, this will
render the folder structure and your IMAP service useless. I will have to
base the new account type on the Disconnected IMAP account and that might
take a little longer.
Cheers,
gamaral
>> The Maildir++ format, for reasons which escape me,
>> has directories ~/Mail/.inbox/[cur,new,tmp]/ .
>> These cannot be seen by local kmail, at least as a local account.
>>
>> If this is wrong, please correct me.
>> Also I would be interested to know why Maildir++
>> adopted this "dotty" system.
>
> Well if I remember correctly the `courier` project ( courier-imap ) or
> it's author is the brains behind the Maindir++ spec, they needed something
> that could support sub-folders, mail quotas and still be a little
> compatible with the original Maildir; the `.` prefix is used to hide
> subfolders from the mail root.
Sorry but I just don't follow the logic.
If one uses kmail (local account) to create new folders,
using maildir format, they are called something like
~/Mail/Folder1 , ~/Mail/Folder2, etc,
and each contains the subdirectories cur,new,tmp
in which email messages are stored.
This does not seem to cause any problem at all.
> Now their is one problem I noticed, if I implement it as a local account
> type the data will be moved into `~/.kde/share/apps/kmail`, this will
> render the folder structure and your IMAP service useless. I will have to
> base the new account type on the Disconnected IMAP account and that might
> take a little longer.
I don't really understand this,
but let us know how you get on.
Timothy Murphy wrote:
>
> Sorry but I just don't follow the logic.
> If one uses kmail (local account) to create new folders,
> using maildir format, they are called something like
> ~/Mail/Folder1 , ~/Mail/Folder2, etc,
> and each contains the subdirectories cur,new,tmp
> in which email messages are stored.
> This does not seem to cause any problem at all.
Well to put it simply in Maildir++ all subdirectory levels are separated by
`.`. for example `~/Maildir/.inbox.family` is displayed as `inbox/family`
and so on.
- --
Guillermo Antonio Amaral Bastidas (gamaral)
# Free & Open-source Software Advocate
# KDE Developer: gamaral
@ http://blog.guillermoamaral.com/
$ irc: gamaral@freenode pgp: 0x5D297B74
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD4DBQFG7ZpDxxxW3F0pe3QRAm4kAJi/3K0FtKCqIlPlfteF2bFtcc0tAJ48b6Z6
kru0wScvpfHA3XqUNPqzhw==
=TkrW
-----END PGP SIGNATURE-----
I understand that perfectly well.
What I don't understand is WHY.
Why not just use subdirectories like everyone else ...?