Hi list,
I understand that dovecot's deliver does a little more than deliver:
it also updates the dovecot metadata stored with each Maildir. Thus,
if I use deliver as opposed to procmail's internal Maildir delivery,
it seems that the IMAP server later has less work to do since the
metadata is can use are up to date.
Doing this, however, incurs an extra process for each mail
delivered. I thus wonder whether the two balance each other out, or
whether there is a strong difference.
What do you think will be less resource-heavy: calling deliver for
every mail received *in addition to* procmail, or letting the IMAP
server update the metadata on access?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"
net at madduck
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20070814/aed89af8/attachment-0002.bin>
On Tuesday, August 14 at 04:38 PM, quoth martin f krafft:>I understand that dovecot's deliver does a little more than deliver:It also understands the 'seive' filter language (an alternative to procmail).>What do you think will be less resource-heavy: calling deliver for >every mail received *in addition to* procmail, or letting the IMAP >server update the metadata on access?Unless you're cutting it close to the limit on what your server can handle, that's probably the wrong question to ask. A better question is: which gives my users better performance? And the answer to THAT is 'using deliver'. The issue is that updating the metadata on access means that dovecot does more work when your users ask for their mail, as opposed to doing more work when your users aren't paying attention. Dovecot will *seem* snappier if you do the indexing work on delivery rather than on access, even though it may spend more CPU cycles overall to do so. ~Kyle -- You cannot reason a person out of a position he did not reason himself into in the first place. -- Jonathan Swift -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070814/5e8c2150/attachment-0002.bin>
On Aug 15, 2007, at 5:00 AM, dovecot-request at dovecot.org wrote:> Message: 7 > Date: Wed, 15 Aug 2007 00:58:40 +0200 > From: martin f krafft <madduck at madduck.net> > Subject: Re: [Dovecot] use of deliver from procmail advisable? > To: dovecot at dovecot.org > Message-ID: <20070814225840.GA23721 at piper.oerlikon.madduck.net> > Content-Type: text/plain; charset="us-ascii" > > also sprach Charles Marcus <CMarcus at Media-Brokers.com> > [2007.08.14.2028 +0200]: >>> Well, the whole point of sieve, I believe, is to make it >>> something that an >>> admin would want to let arbitrary users modify on their own >>> recognizance, >>> and the ability to specify arbitrary programs to run would be >>> just *asking* >>> to be hacked. >> >> Wouldn't a decent, secure alternative to procmail be sieve+amavisd- >> new? > > Except it's not really possible to make amavisd-new do per-user spam > filtering. And it's even more of a performance hog. > > -- > martin; (greetings from the heart of the sun.) > \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck > > "all language designers are arrogant. goes with the territory..." > -- larry wall > > spamtraps: madduck.bogus at madduck.net > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: Digital signature (see http://martin-krafft.net/gpg/) > Url : http://dovecot.org/pipermail/dovecot/attachments/ > 20070815/3d429306/attachment-0001.bin > > ------------------------------ >It is true that amavis-new does over-ride or otherwise seemingly discard some but not all of the individual user configuration options from SpamAssassin, but have you considered trying the following? a) Postfix milter to run ClamAv, eh something like this (for Linux fans) http://wiki.linuxquestions.org/wiki/Postfix_with_clamav-milter It is a bit dated, so double check the docs over at the Postfix site to take advantage of updates to the milter abilities in Postfix. b) then use the regular Postfix <--> SpamAssassin <--> LDA (with sieve) setup (message routing via Postfix master.cf) so that individual users can set their own SA rules and vacation stuff. Jerry Yeager -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2447 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070815/424521be/attachment-0002.bin>
On Aug 15, 2007, at 5:00 PM, dovecot-request at dovecot.org wrote:> ------------------------------ > > Message: 3 > Date: Wed, 15 Aug 2007 18:08:58 +0200 > From: martin f krafft <madduck at madduck.net> > Subject: Re: [Dovecot] use of deliver from procmail advisable? > To: dovecot at dovecot.org > Message-ID: <20070815160858.GA22429 at piper.oerlikon.madduck.net> > Content-Type: text/plain; charset="utf-8" > > also sprach Jerry Yeager <jerry at scene-naturally.dyndns.org> > [2007.08.15.1758 +0200]: >> a) Postfix milter to run ClamAv, eh something like this (for Linux >> fans) >> b) then use the regular Postfix <--> SpamAssassin <--> LDA (with >> sieve) >> setup (message routing via Postfix master.cf) so that individual >> users can >> set their own SA rules and vacation stuff. > > This is exactly how I used to have it but then the need for > a vacation autoresponse to the From: address (as opposed to > Return-Path) arose and I had to switch to procmail: > > http://dovecot.org/list/dovecot/2007-August/024766.html > > Before that, I was using spamc with --pipe-to, but always had a bad > feeling about that, since the manpage says: > > Note that there is a very slight chance mail will be lost here, > because if the fork-and-exec fails there?s no place to put the > mail message. > > and my message to SA-users on this was never answered[0]. > > 0. http://marc.info/?l=spamassassin-users&m=115185095923772&w=2 > > Now I am using procmail and at least now that failure will cause > postfix to defer a message. > > -- > martin; (greetings from the heart of the sun.) > \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net at madduck > > half a bee, philosophically, must ipso facto half not be. > but half the bee has got to be, vis-a-vis its entity. you see? > but can a bee be said to be or not to be an entire bee, > when half the bee is not a bee, due to some ancient injury? > -- monty python > > spamtraps: madduck.bogus at madduck.net > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: Digital signature (see http://martin-krafft.net/gpg/) > Url : http://dovecot.org/pipermail/dovecot/attachments/ > 20070815/96f09f99/attachment-0001.bin > > ------------------------------ >Ouch, that does pose a bit more of a problem. Putting an additional case type structure in Sieve to use the From: field along with either dropping back to the current reply-path or gracefully do not reply for messages from those folks that use a web-mailer without filling in the from: field, then recompiling Sieve would do it, but you really would not be gaining a lot over what you currently have. Jerry Yeager -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2447 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20070815/6c2c8152/attachment-0002.bin>