[Users] Need help, moving from kmail-1.13.5 to claws-mail

[Steve Litt]

On Sun, 23 Feb 2014 15:08:45 -0500
Gene Heskett <gheskett at wdtv.com> wrote:

> On Sunday 23 February 2014 14:17:08 Steve Litt did opine:
> 
> > On Sat, 22 Feb 2014 22:05:35 -0500
> > 
> > Gene Heskett <gheskett at wdtv.com> wrote:

[clip]

> > That's not how I would do it. I'd just copy all your directories to
> > an IMAP server, then copy the IMAP directories locally. And
> > personally, I use a local IMAP server.
> > 
> IOW setup dovecot first.  I like that.

[clip]

> > Holger already gave you a way to do this in Claws, but I have to
> > ask: are your needs for immediacy so great that you can't just set
> > Claws to look for new mail every five minutes?
> 
> If Claws is anything like kmail, with its smorgasbord of functions,
> that means the mail composer will summarily die for about a minute
> once each 5, going away as you are typing in mid-word.  That is to me
> very disconcerting, and is the major driving force behind my doing
> the scripting that except for the fetch and sort from the
> local /var/spool/mail/$user, takes  all that "external" crap away
> from kmail, background duties it no longer has to worry about.  Those
> pauses now, unless somebody sends 20 megs of images, are a 100
> millisecond job I don't notice all that much. 

Your preceding point is why I actually don't have Claws pick up
automatically, but force myself to click the Get Mail button. Claws'
greatest annoyance is that it cannot do two things at a time, so I'm
pretty sure your composing progress *will* stop when it downloads,
whether by time or by the inotify system.


> > > How would one go about doing that from this looping script since
> > > claws-mail doesn't have a dbus port?
> > 
> > You use inotifywatch, so why would you need a loop?
> 
> Because inotifywatch exits, returning the name of the $USER as the

LOL, my bad, I was thinking of inotifywait -m.

[clip]

>  
> > I'll also leave you with my philosophy on email clients...
> > 
> > All email clients suck. Claws-Mail sucks the least. But once upon a
> > time, that could have been said of Kmail, and we all know what
> > happened to Kmail. With that in mind, I've tried to decouple my
> > email client from as much as possible. Instead of having my email
> > client contain my past emails, I have a Dovecot IMAP server contain
> > them, and my email client just reads them. Instead of relying on my
> > email client's filters, I implement them in .procmailrc. My email
> > client is nothing more than a viewport into my collection of emails
> > with reply mechanism, and that's the way I like it.
> 
> The ideal situation I am indeed shooting for.  I use my procmailrc
> for lots of stuff, but only have one non-normal mail file target
> setup in it. But now that you mention it, kmail apparently see's new
> mail placed in that ~/Mail/cur mail folder in a timely manner.  I'd
> ask then, can I do that same thing with dovecot, you indicate it can
> work?

I set up my fetchmail to grab mail every three minutes. My fetchmail
passes off to procmail, which, after filtering, drops the messages
directly in the correct maildir directories of Dovecot, and once
they've been so dropped, they're immediately available via Dovecot. I
believe your procmail calls spam detectors to do their thing, so that
might jam up the works a little, but probably not to the point of
impracticality.

> 
> I've no experience with imap, to am a  total noobie.  OTOH, I am
> subbed that dovecot list also and will not trouble this list with
> such questions.  
> 
> Too bad there is not a mailing list for "mail systems" where such
> questions would not be "off topic".  IMNSHO, Claws/Courier, or
> Claws/Dovecot should be treated as a pair of complete solutions, each
> with its own combined mailing list.  But I am just an old fart
> thinking out loud, without a hand on the tiller. ;-)

I've found most mailing lists and IRC channels to be pretty tolerant of
adjacent technologies. Of course, there are exceptions (#html comes to
mind, don't go there unless you want conflict), but I think the Claws
list is pretty cool.

[clip]

> > I do that often when trying to
> > figure whether a malfunction is due to Claws or not. And, if a
> > future band of Claws developers decide to do something as stupid as
> > binding Claws-Mail to Akonadi and Neepomuk, no big deal, I just
> > plug in a different (IMAP compatible) email client. Now *that's*
> > worry-free.
> 
> And that is exactly what I want, worry free, once its up and
> running. Because 90 days later, I will have mostly forgotten how I
> did it, and will have to start my troubleshooting from scratch.

I'd say the only worry is this: Be sure to put a catch-all recipe at
the bottom of your .procmailrc, and a special test recipe immediately
above that, and every time you change something, you send test mails to
make sure that you haven't accidentally diverted good emails. Also,
never do this:

:0:
* ^Subject.*[Dovecot]
.dovecot/

The preceding sends every email with d, o, v, e, c or t in its subject
into the dovecot folder. In other words, most messages. Heaven help you
if the destination were /dev/null instead: You'd never get them back.
You need to escape the square brackets, as follows:

:0:
* ^Subject.*\[Dovecot\]
.dovecot/

The preceding sends all messages whose subject contains "[Dovecot]" to
the dovecot folder. And as you probably know, procmail recipes are case
insensitive.

> I don't recommend getting old, its not for wimps. ;-)

I was thinking the same thing. I've forgotten where I put my walker.

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance