[Dovecot] new user questions

Jerry jerry at seibercom.net
Sun Jul 14 17:00:44 EEST 2013

On Sun, 14 Jul 2013 08:38:39 -0400
Gene Heskett articulated:

> On Sunday 14 July 2013 07:28:21 Paul van der Vlis did opine:
> > On 13-07-13 19:56, Gene Heskett wrote:
> > > Greetings;
> > > 
> > > Trying to follow along with the wiki2 setup instructions and
> > > thought I'd hit a snag with the first "send me a mail" snippet as
> > > it took several minutes to arrive, so I assume that somehow
> > > procmail was involved in the delivery and my procmail runs mail
> > > thought a whole bunch of checks before finally handing it off to
> > > a mailfile as /var/mail/gene.
> > 
> > Normally procmail is called from the MTA, e.g. Postfix.
> > If you use Postfix disable this line in /etc/postfix/main.cf:
> > mailbox_command = procmail -a "$EXTENSION"
> > 
> > Look at /var/log/mail.log for more information.
> > 
> > > Then the next script seems to only try whats in my home dir, and
> > > of course doesn't find it as neither exists, yet...
> > > 
> > > I assume that is because dovecot needs a kill -HUP.  But I am not
> > > familiar with that, so how is it done, and as what user, me, or
> > > root, on a ubuntu 12.04.2 LTS install?
> > 
> > I don't know what the wiki exactly says. But what you can do is a
> > "service dovecot restart" as root.
> > 
> > I think your questions are more MTA questions then Dovecot
> > questions.
> > 
> > With regards,
> > Paul van der Vlis.
> I should have been a bit more verbose.
> My present setup uses fetchmail to call mailfilter, and scans 3
> different mail servers for what survives mailfilter, handing the
> survivors  to the MTA duties of procmail.
> Procmail in turn uses a bunch of recipes to black hole a few, then
> calls Spamd, clamd to catch and or mark the mail.  What survives
> winds up as mailfiles in /var/spool/mail.

See comment below.
> I have a bash script that uses inotifywait to watch that spool dir,
> and when a file has been written and closed, inotifywait exits,
> returning the filename to my script, which in turn sends kmail a 'get
> this mail' to kmail over the dbus facility.  And restarts
> inotifywait  In this manner, with fetchmail doing 3 minute sleeps
> between runs, mail arrives in a fairly timely manner, usually around
> 3 or 4 seconds processing time from the port blinks on the router to
> an incremented count of unread messages in whatever folder kmail
> stores the mail in.
> kmail is so broken for the version installed for Ubuntu 12.04.2 LTS
> that it will not even start, hence the push to get claws working in
> imap mode, using dovecot on this machine as the imap server so that I
> can then access my email from any of the other 5 machines on my local
> network.  It a bit of a PIMA to be out in the shop, carving metal on
> one of my cnc'd machines and have to run back to the house to check
> the mail because it isn't on an imap server.
> I am assuming that claws-mail can do filtering to individual
> "folders" in the same manner that kmail now sorts, putting anything
> from dovecot.org, in the dovecot folder as one example.  I'd also at
> this point assume I can use a cron job to synchronize the claws-mail
> filtering lists, but that is of course not a dovecot problem.

Way too much work. I use "sieve" with dovecot and accomplish all of the
presorting, etcetera before it ever gets to "claws-mail". Claws-mail
does not directly respect flagged messages with color attributes, but
you can easily have the sieve script add a flag for that and then have
claws-mail read the flag and implement it.

> And of course I need to keep record copies of both incoming and
> replied to mails like this kmail does.  Which is part of the problem
> here because of the size of the corpus, 4.5Gb in ~/gene/Mail, and for
> some unk reason, ~/gene/kde/.../nepomuk/.../sopranodb and virtuosodb
> are using 16 gigabytes! If I don't stop, and restart kmail at about
> 12 hour intervals, it gets so slow its pathetic.  I had to convert
> kmail from mailfiles to maildirs several years ago because an earlier
> versions math could nut handle a single mailfile above 2.1Gb.
> I assume that dovecot can take the incoming mail in /var/spool/mail, 
> leaving those files zero'd out, put it into an assigned dir in the
> users home dir, then serve it up to that user?

Of course, via sieve.
> So what I'd like to do is have dovecot serve up everything it finds
> in /var/spool/mail to any claws-mail client that sends the correct
> password to my local ipv4 network address ###.###.###.##:143.  ipv6
> has not arrived in any detectable form here in West Virginia.
> I am also assuming that claws-mail can handle its own mail sending,
> or does it depend on the imaps to do that?, at this initial stage I
> don't know.  So far, I don't even have claws-mail set to look for an
> imaps.  I suppose that's next because I'll need a way to test dovecot
> as I set it up.
> What do I put, in which file, in /etc/dovecot/conf.d to achieve that?
> The wiki2 pages I know about, but are a bit short on examples to
> define the exact syntax IMO.

Personally, it sounds like you are trying to reinvent the wheel here.
Your setup seems to be way to complicated. I would start by redesigning
you whole system and eliminating "procmail". It has not been touched in
over a dozen years and there are far more powerful and reliable sorting
methods. In your case, fetchmail combined with Postfix, Dovecot and
having dovecot using a sieve script would make your life far easier.

Jerry ♔

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.

More information about the dovecot mailing list