Easy-to-use archiving mail in kontact?

Hi all,

this is maybe more kontact specific than Kolab, but seeing
that many
participants on this list use kontact in a corporate
environment, maybe
someone has a suitable suggestion...

The problem: We want to give our users the possibility to
archive their
mails to a CD-ROM, so they can clean up their IMAP accounts
from time to
time, thus saving space on the server. Given that our work
is mostly
project-based, this can e.g. be done on a per-project basis.

Unfortunately, there doesn't seem to be an easy option to
do so in kontact
- e.g. you cannot simply drag'n'drop a mailfolder into k3b
to burn it on a
CD-ROM. Hence, my question: Has anybody out there solved
this problem and
devised a method for users to easily get their mails
archived on a CD
(and preferably also a way to easily read them back)? If so,
I'd be much
obliged if you had some tips for me. 

Regards,

Thomas


_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Monday, 10. July 2006 15:45, T. Ribbrock wrote:

> The problem: We want to give our users the possibility
to archive their
> mails to a CD-ROM, so they can clean up their IMAP
accounts from time to
> time, thus saving space on the server. 

> Unfortunately, there doesn't seem to be an easy option
to do so in kontact
> - e.g. you cannot simply drag'n'drop a mailfolder
into k3b to burn it on a
> CD-ROM. Hence, my question: Has anybody out there
solved this problem and
> devised a method for users to easily get their mails
archived on a CD

Hi, 
I'm sorry but I also don't know an easy
"one-click" solution for your problem. 
But I appreciate very much an "export/import"
function for mails in the same 
way we know it for addresses or events. Maybe we should
discuss this here or 
on the devel list or simply open an issue for this in the
tracker. 

The only options I can imagine at the moment are:

1. Copying the mails by hand into a local Foder under ~/Mail
and burn this 
folder in a second step. This could be done by most users
but might be 
unpractical if you have large folder structures.

2. Burn Mailfolders found in .kde/share/apps/kmail/dimap ...
I think would be 
the most easy way... if the user understand how folder are
organized here. Ok 
I think in most cases this is no option.

Reimporting archived mails is done in the oposite way and
should be no 
problem.

However, I think an import and export function using mbox
would be great.

Best Torsten  


-- 
Torsten Irländer                                   
Intevation GmbH

torsten.irlaenderintevation.de
http://www.intevation.de/
_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Am Dienstag, 11. Juli 2006 14:56 schrieb Torsten Irländer:
> On Monday, 10. July 2006 15:45, T. Ribbrock wrote:
> > The problem: We want to give our users the
possibility to archive
> > their mails to a CD-ROM, so they can clean up
their IMAP accounts
> > from time to time, thus saving space on the
server.
> >
> > Unfortunately, there doesn't seem to be an easy
option to do so in
> > kontact - e.g. you cannot simply drag'n'drop a
mailfolder into k3b
> > to burn it on a CD-ROM. Hence, my question: Has
anybody out there
> > solved this problem and devised a method for users
to easily get
> > their mails archived on a CD
>
> Hi,
> I'm sorry but I also don't know an easy
"one-click" solution for your
> problem. But I appreciate very much an
"export/import" function for
> mails in the same way we know it for addresses or
events. Maybe we
> should discuss this here or on the devel list or simply
open an issue
> for this in the tracker.
>
> The only options I can imagine at the moment are:
>
> 1. Copying the mails by hand into a local Foder under
~/Mail and burn
> this folder in a second step. This could be done by
most users but
> might be unpractical if you have large folder
structures.
>
> 2. Burn Mailfolders found in
.kde/share/apps/kmail/dimap ... I think
> would be the most easy way... if the user understand
how folder are
> organized here. Ok I think in most cases this is no
option.
>
> Reimporting archived mails is done in the oposite way
and should be
> no problem.
>
> However, I think an import and export function using
mbox would be
> great.

Exporting single folders as mbox is possible by selecting
all messages 
in a folder and then saving them, i.e. Ctrl+A, Ctrl+S.

Using archived folders from CD-ROM directly is not possible
because 
KMail tries to open all mbox files and messages files (for
maildir) in 
read-write mode. Obviously, this doesn't work for files
stored on a 
CD-ROM. We'll make sure that this will be possible with
Akonadi in 
KDE4.

Regards,
Ingo

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Tuesday, 11. July 2006 15:26, Ingo Klöcker wrote:
> Am Dienstag, 11. Juli 2006 14:56 schrieb Torsten
Irländer:
> > On Monday, 10. July 2006 15:45, T. Ribbrock wrote:
> > > The problem: We want to give our users the
possibility to archive
> > > their mails to a CD-ROM, so they can clean up
their IMAP accounts
> > > from time to time, thus saving space on the
server.
> > >
> > > Unfortunately, there doesn't seem to be an
easy option to do so in
> > > kontact - e.g. you cannot simply
drag'n'drop a mailfolder into k3b
> > > to burn it on a CD-ROM. Hence, my question:
Has anybody out there
> > > solved this problem and devised a method for
users to easily get
> > > their mails archived on a CD
>>
> > I'm sorry but I also don't know an easy
"one-click" solution for your
> > problem. But I appreciate very much an
"export/import" function for
> > mails in the same way we know it for addresses or
events. Maybe we
> > should discuss this here or on the devel list or
simply open an issue
> > for this in the tracker.
>
> Exporting single folders as mbox is possible by
selecting all messages
> in a folder and then saving them, i.e. Ctrl+A, Ctrl+S.

Thanks, that is nice to know  I think
with this approach even large folder 
structures can be archived with moderate effort. But beeing
able to do this 
recursively for a whole folder tree would be even better.
Maybe with the 
option to compress the archive or so. 

> Using archived folders from CD-ROM directly is not
possible because
> KMail tries to open all mbox files and messages files
(for maildir) in
> read-write mode. Obviously, this doesn't work for
files stored on a
> CD-ROM. We'll make sure that this will be possible
with Akonadi in
> KDE4.

Ok I understand.

-- 
Torsten Irländer                                   
Intevation GmbH

torsten.irlaenderintevation.de
http://www.intevation.de/
_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Tue, Jul 11, 2006 at 03:26:51PM +0200, Ingo Klöcker
wrote:
> Exporting single folders as mbox is possible by
selecting all messages 
> in a folder and then saving them, i.e. Ctrl+A, Ctrl+S.

Ah, that helps, thanks. I'm still pondering writing a
little tool using
perl+kdialog, though - that tool could write a complete
folder (including
subfolders) to CD-ROM and also restore it. That should help
most users
here immensely. In conjunction with that I'm wondering
about something:

kontact from KDE 3.5 as supplied by SuSE seems to store the
"Local
Folders" somewhere in ~/.kde, but detects the presence
of ~/Mail and uses
it. In that case, it adds a "folders=" entry to
"[General]" in kmailrc.

The proko2 client (which, as far as I understand it, is
older) does no
such thing - as far as I can see, it always uses ~/Mail for
"Local
Folders" (which is my preference anyway - I don't
like hiding the local
folders somewhere in ~/.kde).

Is my understanding of this correct?

Cheerio,

Thomas


_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

Am Donnerstag, 13. Juli 2006 10:17 schrieb T. Ribbrock:
> On Tue, Jul 11, 2006 at 03:26:51PM +0200, Ingo Klöcker
wrote:
> > Exporting single folders as mbox is possible by
selecting all
> > messages in a folder and then saving them, i.e.
Ctrl+A, Ctrl+S.
>
> Ah, that helps, thanks. I'm still pondering writing a
little tool
> using perl+kdialog, though - that tool could write a
complete folder
> (including subfolders) to CD-ROM and also restore it.
That should
> help most users here immensely. In conjunction with
that I'm
> wondering about something:
>
> kontact from KDE 3.5 as supplied by SuSE seems to store
the "Local
> Folders" somewhere in ~/.kde, but detects the
presence of ~/Mail and
> uses it. In that case, it adds a "folders="
entry to "[General]" in
> kmailrc.

It always adds a folders= entry. Starting with KDE 3.5 (or
3.4 ?) the 
standard location was changed from ~/Mail to 
~/.kde/share/apps/kmail/mail
Two reasons for this change were:
- Some users did apparently delete ~/Mail because they
didn't know why 
it's there. Hiding the mail storage hopefully prevent users
from doing 
so.
- The new path should make it much clearer that the mail
storage must 
not be accessed by any other applications than KMail.

> The proko2 client (which, as far as I understand it, is
older) does
> no such thing - as far as I can see, it always uses
~/Mail for "Local
> Folders" (which is my preference anyway - I
don't like hiding the
> local folders somewhere in ~/.kde).

Since the proko2 client is based on the KDE 3.3 (?) version
of KMail it 
still uses the old location.

> Is my understanding of this correct?

Yes.

Regards,
Ingo

_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Thu, Jul 13, 2006 at 11:23:27AM +0200, Ingo Klöcker
wrote:
> 
> [KMail] always adds a folders= entry. Starting with KDE
3.5 (or 3.4 ?) the 
> standard location was changed from ~/Mail to 
> ~/.kde/share/apps/kmail/mail
> Two reasons for this change were:
> - Some users did apparently delete ~/Mail because they
didn't know why 
> it's there. Hiding the mail storage hopefully prevent
users from doing 
> so.

<sigh> :-}

> - The new path should make it much clearer that the
mail storage must 
> not be accessed by any other applications than KMail.

That's precisely what annoys me - I for example have mutt
and KMail
(proko2) running in parallel for more than a year now. Both
of them are
open all the time - and the only problem I ever encountered
was that mutt
didn't detect new mails because kmail got there first. No
biggy. kmail
will never reach the speed and ease-of-use mutt has, but I
need it for its
agenda functionality, hence the duo. But I'm the first to
admit that I'm
not a "standard user".
Also, I never quite understood why each and every mail
program seemingly
needs its own format and own extension of mbox/mdir, making
switching ever
so difficult. But that's another discussion that doesn't
belong here...



[...]
> > Is my understanding of this correct?
> 
> Yes.

Great, thanks. I'll build my tool to look for
"folders=", then, and assume
"~/Mail" if none is found.

Regards,

Thomas


_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Thursday 13 July 2006 11:38, T. Ribbrock wrote:
> On Thu, Jul 13, 2006 at 11:23:27AM +0200, Ingo Klöcker
wrote:
> > - The new path should make it much clearer that
the mail storage
> > must not be accessed by any other applications
than KMail.
>
> That's precisely what annoys me - I for example have
mutt and KMail
> (proko2) running in parallel for more than a year now.
Both of them
> are open all the time - and the only problem I ever
encountered was
> that mutt didn't detect new mails because kmail got
there first. No
> biggy. kmail will never reach the speed and ease-of-use
mutt has, but
> I need it for its agenda functionality, hence the duo.
But I'm the
> first to admit that I'm not a "standard
user".
> Also, I never quite understood why each and every mail
program
> seemingly needs its own format and own extension of
mbox/mdir, making
> switching ever so difficult. But that's another
discussion that
> doesn't belong here... 

Well, we do use standard mbox and maildir, but with index
files. And 
since we are lazy  we never
made sure that KMail does cope well with 
other apps messing around with the contents of the folders.
It's great 
that it seems to work for you.

Regards,
Ingo
_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Fri, Jul 14, 2006 at 12:01:57AM +0200, Ingo Klöcker
wrote:
[...]
> Well, we do use standard mbox and maildir, but with
index files. And 
> since we are lazy  we never
made sure that KMail does cope well with 
> other apps messing around with the contents of the
folders.
[...]

Hm... I can understand the "lazy" part... :-}
However, given the above, am
I right in assuming that there is no mechanism to let kmail
re-sync its
"Local Folders"? That's one of the few issues I
have with mutt||kmail: If
I create a new local folder in mutt, kmail won't pick it up
until I
restart the program, which is slightly annoying. This also
causes problems
with the backup util I have in mind, hence I'd be very
interested if there
was another way.

Thanks,

Thomas


_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users

On Fri, Jul 14, 2006 at 12:01:57AM +0200, Ingo Klöcker
wrote:
[...]
> Well, we do use standard mbox and maildir, but with
index files. And 
> since we are lazy  we never
made sure that KMail does cope well with 
> other apps messing around with the contents of the
folders.
[...]

Hm... I can understand the "lazy" part... :-}
However, given the above, am
I right in assuming that there is no mechanism to let kmail
re-sync its
"Local Folders"? That's one of the few issues I
have with mutt||kmail: If
I create a new local folder in mutt, kmail won't pick it up
until I
restart the program, which is slightly annoying. This also
causes problems
with the backup util I have in mind, hence I'd be very
interested if there
was another way.

Thanks,

Thomas


_______________________________________________
Kolab-users mailing list
Kolab-userskolab.org
https:
//kolab.org/mailman/listinfo/kolab-users