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(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org