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. __________________________________________________________________
