James Knott wrote:
On 08/19/2014 05:24 PM, Linda Walsh wrote:
That's it. As near as I can tell, none of the files in /etc/dovecot/conf.d are actually used (which was intentional)... The previous dovecot.conf was 619 bytes -- That grew to ~ 4000+ in 2.x and had all those includes....
I combined what I wanted and ended up with the 1871 byte file above. Hope this helps..
Thanks. I'll have to look into it. Does this also get the mail from the user to dovecot? That's what I'm stuck on right now.
??? dovecot doesn't handle my outgoing email -- just IMAP. I use fetchmail to pull it in from the remote server -- that delivers it to 'sendmail'... which does it's normal thing (incoming in /var/spool/mail). In my home dir I have a ".forward" file that forwards my incoming email to my "procmail" equivalent (the perl script that calls spamassassin). But it just diverts some of the email into folders under ~/mail The post-filter stuff that gets through ends up in /var/spool/mail (which is where fetchmail seems to think it's inbox is). I'm using classic 'mbox' format -- makes searching and organization a bit easier for me... My perl script drops a summary of the incoming in mail/.log that looks like: 20140701:031807 (Tue) OpenSuSE mail (Re: [opensuse] Firefox Location-Aware Browsing ?)[CLEANED] received (john layt <>) (9.19sec processing) 20140701:032216 (Tue) OpenSuSE mail ( Re: [opensuse] Firefox Location-Aware Browsing ?)[CLEANED] received (per jessen <>) (9.32sec processing) 20140701:033029 (Tue) Firebug mail ([firebug] Re: Missing files on script tab with Firefox 30 + Firebug 2.0)[CLEANED] received () (7.96sec processing) 20140701:033036 (Tue) SpamAssassin mail (Changes in Spamhaus DBL DNSBL return codes) received (axb <>) (9.00sec processing)... 20140819:144406 (Tue) SPAM tagged mail , Supposedly to localaddress , thru localalias: mail (***SPAM*** Perfect solution: Up to 25pounds OFF!) received (daily health tip <>) (8.08sec processing) --- 95% of the processing time is really waiting on network responses. Fortunately, when email comes in, a different copy of the script gets invoked for each message... so if fetchmail has been inactive for some reason, it will pull down hundreds of messages that it tries to process mostly in parallel...(as most of it is waiting)... Yeah, as Anton says, I could short-circuit the path, but that can create problems if I try to integrate other standard tools in to replace something in my "supply chain"... I suppose eventually, I'll have my email delivered by systemd? *cough*.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org