[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