Re: [Dovecot] procmail/formail -- Maildir
On Mon, 3 Dec 2007, Andre Huebner wrote:
Hello List,
i switched mailformat from mbox to maildir. Now i have a little problem with
procmail/formail and headermanipulation of mails.
Here an example:
0
* ^From.*gmx.de
| (formail -t -Iprocmail: gmx.de) /var/spool/mail/xx
You can ask Procmail to deliver to a Maildir. For example:
:0 Waf
* ^From:.*gmx.de
| formail -A procmail: gmx.de
This uses formail as a filter, so that the message is transformed but
the transformed message is available for later rules. Once procmail
falls off the end of its rules, it will deliver the message (now the
transformed message) to the default mail spool. If you put these settings
at the top of .procmailrc:
MAILDIR=${HOME}/Maildir
DEFAULT=./
then the default mail spool is a Maildir!
I hope that helps.
-- Asheesh.
--
You're never too old to become younger.
-- Mae West
Re: [Dovecot] procmail/formail -- Maildir
On Mon, 2007-12-03 at 11:02 +0100, Andre Huebner wrote:
i switched mailformat from mbox to maildir. Now i have a little
problem with procmail/formail and headermanipulation of mails.
Here an example:
0
* ^From.*gmx.de
| (formail -t -Iprocmail: gmx.de) /var/spool/mail/xx
I would never do it that way anyway. You are bluntly appending the mail
to the raw spool (or mbox file) without any locking. Instead, make
procmail deliver the mail properly, figuring out the correct locking
method.
So, i can add some different headerlines for later evaluation and the
result is attached to inbox.
^
Now i have the problem that i don't know name of targetfile, cause it
is unique for every mail if maildir is used.
^^^
You made that example up, instead of copy-n-paste'ing real life procmail
receipts, right? Isn't the default system spool still an mbox file, even
when using Maildir?
Anyway, again -- let procmail figure out how to properly deliver the
mail. For Maildir storage, just use the directory name, including the
trailing slash. See 'man procmailrc'. Example below.
I did not found a Option or other workaround to solve this case.
I know, it is not a dovecot problem but i hope somebody can give a
hint.
Could it be a possibility to leave all unchanged? Mails could be
transported to /var/spool/mail/xx and picked up by dovecot if in
dovecot.conf the convert-plugin ist always activated?
No. At the very least you need to tell procmail you are using Maildir
instead if mbox for any delivery receipt.
Note: Example untested.
# Set the Maildir prefix, and have the Inbox in there, too.
MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
# Filter through formail, appending some custom header.
:0 fw
* ^From.*gmx.de
| formail -I X-procmail: gmx.de
# Keep mailing list traffic out of my Inbox. Let procmail care about
# proper locking.
:0 :
* ^List-Id: .+dovecot.dovecot.org
.mailing-lists.dovecot/
# Someone loves me. :) Whatever survived till this point will get
# delivered to the $DEFAULT Maildir.
Now, some words about that obscure tagging with formail. :)
Since you are using procmail with gmx.de (which does offer POP3 only for
free) I assume you are harvesting your mail using fetchmail.
Also, I assume the above example isn't actually what you use. It feels
rather useless to add a custom header for that. Your receipt above will
match on any From: header with a gmx.de substring, too. Which includes
the real name. Besides, you can directly evaluate that header anyway...
I guess you actually mean to tag all mail fetched from the gmx.de POP3
account. In that case, have a look at the fetchmail tracepolls option.
It will add info like polling $server account $user to the procmail
generated Received: header. You can directly filter on that header using
procmail, instead of a custom added one. If this is your use case, the
tracepolls option is the only accurate method anyway. Short of using
dedicated local users. ;)
HTH
guenther
--
char *t=[EMAIL PROTECTED];
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
[Dovecot] De-duplication / Single Instance Storage - WAS: Re: Updated v1.1 and summer plans
On 12/2/2007, Timo Sirainen ([EMAIL PROTECTED]) wrote: On Sun, 2007-12-02 at 10:02 -0500, Charles Marcus wrote: Do you have any idea as to a time frame for when you might be able to get to it (Single instance Storage)? Are you thinking post v2.0? Even 2.1 or 3.0? Right now I just want to get v1.1 finished. The main problem with it is that apparently in some installations it's slower than v1.0 and I haven't yet figured out why. And I want Squat rewrite to be included in it too (almost finished! just committed it to hg). After v1.1 I'm not sure. I'm more interested in implementing other features first (like v2.0's config rewrite, replication, etc.), but once I'm beginning to run out of money I'll start doing pretty much anything people pay me to do ;) Heh - understood... I'll talk to my boss, but he's - well, to put it politely, its a bit difficult to get money out of him... Actually, I'm looking into some form of file-system level de-duplication, which may negate the need for this... Anyone know of anything available on the cheap/free side? -- Best regards, Charles
Re: [Dovecot] procmail/formail -- Maildir
Hello,
thanks. I will test it in a few days. This week just holidays ;)
Sure, its just a modified example. Reason is to mark mails later graphical
in a webmailer using some procmail/formail technics.
I think, if i activate the dovecot convert plugin nothig of my procmail must
be changed. (just only the bugs ;) ) Mails will be deliverd in mbox format
to
/var/spool/mail/x
On Userlogin dovecot is picking up Mails and deliver them to maildir-inbox.
Don't know if this is a very Feasible way, not really clean...
http://wiki.dovecot.org/Plugins/Convert?highlight=%28convert_mail%29
Thanks
André
- Original Message -
From: Karsten Bräckelmann [EMAIL PROTECTED]
To: dovecot@dovecot.org
Sent: Monday, December 03, 2007 12:46 PM
Subject: Re: [Dovecot] procmail/formail -- Maildir
On Mon, 2007-12-03 at 11:02 +0100, Andre Huebner wrote:
i switched mailformat from mbox to maildir. Now i have a little
problem with procmail/formail and headermanipulation of mails.
Here an example:
0
* ^From.*gmx.de
| (formail -t -Iprocmail: gmx.de) /var/spool/mail/xx
I would never do it that way anyway. You are bluntly appending the mail
to the raw spool (or mbox file) without any locking. Instead, make
procmail deliver the mail properly, figuring out the correct locking
method.
So, i can add some different headerlines for later evaluation and the
result is attached to inbox.
^
Now i have the problem that i don't know name of targetfile, cause it
is unique for every mail if maildir is used.
^^^
You made that example up, instead of copy-n-paste'ing real life procmail
receipts, right? Isn't the default system spool still an mbox file, even
when using Maildir?
Anyway, again -- let procmail figure out how to properly deliver the
mail. For Maildir storage, just use the directory name, including the
trailing slash. See 'man procmailrc'. Example below.
I did not found a Option or other workaround to solve this case.
I know, it is not a dovecot problem but i hope somebody can give a
hint.
Could it be a possibility to leave all unchanged? Mails could be
transported to /var/spool/mail/xx and picked up by dovecot if in
dovecot.conf the convert-plugin ist always activated?
No. At the very least you need to tell procmail you are using Maildir
instead if mbox for any delivery receipt.
Note: Example untested.
# Set the Maildir prefix, and have the Inbox in there, too.
MAILDIR=$HOME/Maildir/
DEFAULT=$MAILDIR
# Filter through formail, appending some custom header.
:0 fw
* ^From.*gmx.de
| formail -I X-procmail: gmx.de
# Keep mailing list traffic out of my Inbox. Let procmail care about
# proper locking.
:0 :
* ^List-Id: .+dovecot.dovecot.org
.mailing-lists.dovecot/
# Someone loves me. :) Whatever survived till this point will get
# delivered to the $DEFAULT Maildir.
Now, some words about that obscure tagging with formail. :)
Since you are using procmail with gmx.de (which does offer POP3 only for
free) I assume you are harvesting your mail using fetchmail.
Also, I assume the above example isn't actually what you use. It feels
rather useless to add a custom header for that. Your receipt above will
match on any From: header with a gmx.de substring, too. Which includes
the real name. Besides, you can directly evaluate that header anyway...
I guess you actually mean to tag all mail fetched from the gmx.de POP3
account. In that case, have a look at the fetchmail tracepolls option.
It will add info like polling $server account $user to the procmail
generated Received: header. You can directly filter on that header using
procmail, instead of a custom added one. If this is your use case, the
tracepolls option is the only accurate method anyway. Short of using
dedicated local users. ;)
HTH
guenther
--
char
*t=[EMAIL PROTECTED];
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8?
c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){
putchar(t[s]);h=m;s=0; }}}
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.16.12/1163 - Release Date:
01.12.2007 12:05
[Dovecot] dovecot process nice value
My imap processes seem to all be running with a nice value of -15 (top priority). Is this usual? Not sure if this is a dovecot setting or something going on with my own system configuration somewhere. I know the userdb query can set the nice value but mine (a mysql query) does not... We're having problems with our mail partition being absolutely thrashed and thought over-strong imap processes might be a factor. Many thanks, Daniel
Re: [Dovecot] 1.1.Beta9 deliver problem: Unknown mail storage driver raw
And a general wiki question: is there some way you can remove the wiki help pages from the search results? A search for 'raw', for example, returns 41 results, 36 of which appear to be localized help pages that are installed by default. (Plus, 2 of the 5 'relevant' results are about halfway down the list.) I think I tried it once but then got tired of trying. If someone can give me simple instructions I'll do that. I think, at least with newer versions of moin, you can specify -domain:underlay in the advanced query or excludeunderlay=1 in the URL. Personally, I've removed the help pages (underlay) completely and just point to the official wiki. johannes signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot + SASL + allow_nets
On Mon, 2007-12-03 at 14:36 +0100, Marc Cuypers wrote: When using dovecot for authentication of an SASL (postfix) request, i cannot use the allow_nets parameter. The IP-address of the requester is not known in dovecot. I would like to allow sasl for certain users, others are not allowed to access via SASL. Some users can have access to imap and pop3 from certain IP-addresses. How could i combine this in then dovecot configuration? Since Postfix doesn't send the IP to Dovecot, there isn't anything on Dovecot's side you can do. You could try asking about this in Postfix list.. Someone at least had a patch which allowed sending local IP to Dovecot (http://marc.info/?t=119306971600010r=1w=2). Maybe it sends remote IP as well. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot process nice value
On Mon, 2007-12-03 at 13:05 +, Daniel Watts wrote: My imap processes seem to all be running with a nice value of -15 (top priority). Is this usual? Not sure if this is a dovecot setting or something going on with my own system configuration somewhere. Normally Dovecot doesn't touch processes' priorities, so they all run with whatever priority was specified for the master process when starting it. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot + SASL + allow_nets
On 3.12.2007, at 17.39, Marc Cuypers wrote: Timo Sirainen schreef: On Mon, 2007-12-03 at 14:36 +0100, Marc Cuypers wrote: When using dovecot for authentication of an SASL (postfix) request, i cannot use the allow_nets parameter. The IP-address of the requester is not known in dovecot. I would like to allow sasl for certain users, others are not allowed to access via SASL. Some users can have access to imap and pop3 from certain IP- addresses. How could i combine this in then dovecot configuration? Since Postfix doesn't send the IP to Dovecot, there isn't anything on Dovecot's side you can do. You could try asking about this in Postfix list.. Someone at least had a patch which allowed sending local IP to Dovecot (http://marc.info/?t=119306971600010r=1w=2). Maybe it sends remote IP as well. Would it be possible to use a different authentication method for pop/imap and sasl? What do you mean by different authentication method? Also all of POP, IMAP and SMTP use SASL actually, so I guess by SASL you mean Postfix? http://wiki.dovecot.org/Sasl and http://wiki.dovecot.org/ Authentication/Mechanisms might be useful to read. In any case if you want to add some IP checks to SMTP authentication, there's no way to do that on Dovecot's side without changing Postfix. PGP.sig Description: This is a digitally signed message part
Re: [Dovecot] Dovecot + SASL + allow_nets
Timo Sirainen schreef: On 3.12.2007, at 17.39, Marc Cuypers wrote: Timo Sirainen schreef: On Mon, 2007-12-03 at 14:36 +0100, Marc Cuypers wrote: When using dovecot for authentication of an SASL (postfix) request, i cannot use the allow_nets parameter. The IP-address of the requester is not known in dovecot. I would like to allow sasl for certain users, others are not allowed to access via SASL. Some users can have access to imap and pop3 from certain IP-addresses. How could i combine this in then dovecot configuration? Since Postfix doesn't send the IP to Dovecot, there isn't anything on Dovecot's side you can do. You could try asking about this in Postfix list.. Someone at least had a patch which allowed sending local IP to Dovecot (http://marc.info/?t=119306971600010r=1w=2). Maybe it sends remote IP as well. Would it be possible to use a different authentication method for pop/imap and sasl? What do you mean by different authentication method? Also all of POP, IMAP and SMTP use SASL actually, so I guess by SASL you mean Postfix? http://wiki.dovecot.org/Sasl and http://wiki.dovecot.org/Authentication/Mechanisms might be useful to read. In any case if you want to add some IP checks to SMTP authentication, there's no way to do that on Dovecot's side without changing Postfix. What i meant was, is there a way to: IMAP/POP3: authenticate with dovecot and checking for allow_nets SASL (postfix): authenticate with dovecot without the checking for allow_nets (just another pass_attrs) -- Marc
Re: [Dovecot] Dovecot + SASL + allow_nets
Timo Sirainen schreef: On Mon, 2007-12-03 at 14:36 +0100, Marc Cuypers wrote: When using dovecot for authentication of an SASL (postfix) request, i cannot use the allow_nets parameter. The IP-address of the requester is not known in dovecot. I would like to allow sasl for certain users, others are not allowed to access via SASL. Some users can have access to imap and pop3 from certain IP-addresses. How could i combine this in then dovecot configuration? Since Postfix doesn't send the IP to Dovecot, there isn't anything on Dovecot's side you can do. You could try asking about this in Postfix list.. Someone at least had a patch which allowed sending local IP to Dovecot (http://marc.info/?t=119306971600010r=1w=2). Maybe it sends remote IP as well. Would it be possible to use a different authentication method for pop/imap and sasl? -- Marc
Re: [Dovecot] Dovecot + SASL + allow_nets
On Mon, 2007-12-03 at 16:49 +0100, Marc Cuypers wrote: What i meant was, is there a way to: IMAP/POP3: authenticate with dovecot and checking for allow_nets SASL (postfix): authenticate with dovecot without the checking for allow_nets (just another pass_attrs) Hmm. There's no easy way with LDAP. You'd need to either run a separate Dovecot installation with a different config file, or alternatively have separate accounts in LDAP for SMTP and non-SMTP (where only non-SMTP has allow_nets). signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot process nice value
Timo Sirainen wrote: On Mon, 2007-12-03 at 13:05 +, Daniel Watts wrote: My imap processes seem to all be running with a nice value of -15 (top priority). Is this usual? Not sure if this is a dovecot setting or something going on with my own system configuration somewhere. Normally Dovecot doesn't touch processes' priorities, so they all run with whatever priority was specified for the master process when starting it. Hi timo - thanks for this. The /usr/sbin/dovecot process itself was indeed niced to -15. Why would that be? Can dovecot specify it's own nice value upon startup? When you say 'specified for the master process' I'm not sure if you mean in a config somewhere. Thanks, Dan -- Running Squirrelmail 1.5.2 in Production PHP 5.x Hardened with Eaccelerator Apache 2.x Mysql 5.0.x Imapproxy over Dovecot/Maildir all running on Gentoo Linux for ~5,000 users.
Re: [Dovecot] dovecot process nice value
Timo Sirainen wrote: On Mon, 2007-12-03 at 16:25 +, Daniel Watts wrote: Timo Sirainen wrote: On Mon, 2007-12-03 at 13:05 +, Daniel Watts wrote: My imap processes seem to all be running with a nice value of -15 (top priority). Is this usual? Not sure if this is a dovecot setting or something going on with my own system configuration somewhere. Normally Dovecot doesn't touch processes' priorities, so they all run with whatever priority was specified for the master process when starting it. Hi timo - thanks for this. The /usr/sbin/dovecot process itself was indeed niced to -15. Why would that be? Can dovecot specify it's own nice value upon startup? Nope. When you say 'specified for the master process' I'm not sure if you mean in a config somewhere. I meant whatever/however dovecot was started. I don't know if some init.d scripts play with priorities. Or it could have just been that your shell was running with -15 when starting dovecot. Anyway, I don't think Dovecot itself should change its priority on startup. Ok - you're probably right about my shell being reniced before startup. Will check that out. Thanks a lot for your time Timo. Just upgraded Dovecot to 1.0.7 as well. Looking good so far.
[Dovecot] v1.1.beta10 released
http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta10.tar.gz http://dovecot.org/releases/1.1/beta/dovecot-1.1.beta10.tar.gz.sig Changes since beta9: - dotlock_use_excl=yes is now the default. I think this should work in all NFS setups that are in use nowadays. O_EXCL has worked since NFSv3. - fs quota: Added noenforcing option - Fixed compiling with non-gcc - Fixed quota plugin crash - Lots of fixes to handling message searches, especially related to non-ASCII searches. And most importantly: It includes the new Squat full text search indexing code. There are a few things left in my TODO for it: - It's currently used only to optimize root level AND searches. So for example SEARCH (OR TEXT hello TEXT world) is still searched the slow way. - Expunged messages are never removed from the indexes. - The index could be updated while messages are being saved, but this isn't done yet. - Indexed substring length is hardcoded to 4 characters. This should be configurable, although I think 4 should work quite nicely. Lucene plugin is probably completely broken now, but it was also in beta9. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] dovecot process nice value
On Mon, 2007-12-03 at 16:25 +, Daniel Watts wrote: Timo Sirainen wrote: On Mon, 2007-12-03 at 13:05 +, Daniel Watts wrote: My imap processes seem to all be running with a nice value of -15 (top priority). Is this usual? Not sure if this is a dovecot setting or something going on with my own system configuration somewhere. Normally Dovecot doesn't touch processes' priorities, so they all run with whatever priority was specified for the master process when starting it. Hi timo - thanks for this. The /usr/sbin/dovecot process itself was indeed niced to -15. Why would that be? Can dovecot specify it's own nice value upon startup? Nope. When you say 'specified for the master process' I'm not sure if you mean in a config somewhere. I meant whatever/however dovecot was started. I don't know if some init.d scripts play with priorities. Or it could have just been that your shell was running with -15 when starting dovecot. Anyway, I don't think Dovecot itself should change its priority on startup. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot + SASL + allow_nets
Timo Sirainen schreef: On Mon, 2007-12-03 at 14:36 +0100, Marc Cuypers wrote: When using dovecot for authentication of an SASL (postfix) request, i cannot use the allow_nets parameter. The IP-address of the requester is not known in dovecot. I would like to allow sasl for certain users, others are not allowed to access via SASL. Some users can have access to imap and pop3 from certain IP-addresses. How could i combine this in then dovecot configuration? Since Postfix doesn't send the IP to Dovecot, there isn't anything on Dovecot's side you can do. You could try asking about this in Postfix list.. Someone at least had a patch which allowed sending local IP to Dovecot (http://marc.info/?t=119306971600010r=1w=2). Maybe it sends remote IP as well. I wrote that patch. It passes both endpoints (remote local) through to dovecot .This lets you restrict smtp-auth just like pop3 or imap using the remote IP.In my case, I had played around with a quick hack for doing per-ip realming (using the local IP) w/ dovecot-sql.
Re: [Dovecot] v1.1.beta10 released
On Mon, 2007-12-03 at 19:33 +0200, Timo Sirainen wrote: And most importantly: It includes the new Squat full text search indexing code. There are a few things left in my TODO for it: - It's currently used only to optimize root level AND searches. So for example SEARCH (OR TEXT hello TEXT world) is still searched the slow way. - Expunged messages are never removed from the indexes. - The index could be updated while messages are being saved, but this isn't done yet. - Indexed substring length is hardcoded to 4 characters. This should be configurable, although I think 4 should work quite nicely. Oh, two more things: mmap_disable=yes doesn't work with it - it always mmaps the files. Also it doesn't try to flush NFS caches. These should be pretty easy to fix though. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Dovecot + SASL + allow_nets
On Dec 3, 2007 7:36 AM, Marc Cuypers [EMAIL PROTECTED] wrote: Hi, When using dovecot for authentication of an SASL (postfix) request, i cannot use the allow_nets parameter. The IP-address of the requester is not known in dovecot. I would like to allow sasl for certain users, others are not allowed to access via SASL. Some users can have access to imap and pop3 from certain IP-addresses. How could i combine this in then dovecot configuration? -- Best regards, Marc You can do this in postfix main.cf using the smtpd_sasl_exceptions_networks parameter. Normally this parameter lists networks *not* allowed to use AUTH, but you can exempt certain hosts by proceeding them with a !. Note that order matters, here; exceptions must come before the static:all entry. For example. to offer AUTH only to 192.0.2.0-192.0.2.255: # main.cf smtpd_sasl_exceptions_networks = !192.0.2.0/24 static:all See also http://www.postfix.org/postconf.5.html#smtpd_sasl_exceptions_networks Or for an alternative method: http://www.postfix.org/postconf.5.html#smtpd_discard_ehlo_keyword_address_maps -- Noel Jones
[Dovecot] Please solve my query
hi my question is Start a POP3 server on rhel5 with a matching criteria 1) user jack must get mail 2 Allow your network lw.com 3)my133.org domain can not access your server Thanks And Regards Bhagwat Swarup NH India Ltd
Re: [Dovecot] Please solve my query
On Dec 3, 2007, at 11:59 AM, bhagwat swarup wrote: hi my question is Start a POP3 server on rhel5 with a matching criteria 1) user jack must get mail 2 Allow your network lw.com 3)my133.org domain can not access your server Deny by reverse DNS lookup, so that hosts that reverse to *.my133.org? What do you mean by a domain accessing a server? A domain label is just a record, so some clarification is neccesary
Re: [Dovecot] Please solve my query
On 03.12.2007 21:59, bhagwat swarup wrote: hi my question is Start a POP3 server on rhel5 with a matching criteria 1) user jack must get mail 2 Allow your network lw.com 3)my133.org domain can not access your server Thanks And Regards Bhagwat Swarup NH India Ltd You probably should start reading from here http://wiki.dovecot.org/
[Dovecot] LIST problem with Dovecot1.1beta10
Hi, Certain IMAP folder problems started popping up with Squirrelmail with the 1.1beta10 version of Dovecot (and possibly earlier versions). Looked into it and I am seeing odd behavior with the LIST command. Here is how to reproduce problem, unless I'm missing something obvious: a001 login dean password a001 OK Logged in. a002 list * * LIST (\NoInferiors \UnMarked) / Sent * LIST (\NoInferiors \UnMarked) / Trash * LIST (\NoInferiors \UnMarked) / Drafts * LIST (\NoInferiors \UnMarked) / INBOX a002 OK List completed. a003 list Trash* * LIST (\NoInferiors \UnMarked) / Trash a003 OK List completed. a004 list Trash a004 OK List completed. *** What? Shouldn't it have listed Trash instead of returning nothing? a005 list Trash *** Unbalanced quote causes total lockup! It appears that Squirrelmail, and possibly others, are using the LIST command to test for the presence of a mailbox, but it seems impossible to get an exact match. Am I missing something here? -- Dean Brooks [EMAIL PROTECTED]
Re: [Dovecot] procmail/formail -- Maildir
Please resist the urge to top-post.
On Mon, 2007-12-03 at 13:58 +0100, Andre Huebner wrote:
Sure, its just a modified example. Reason is to mark mails later graphical
in a webmailer using some procmail/formail technics.
Well, if the fetchmail tagging technique actually matches your use case,
of course depends on my assumptions being correct. ;) If so, it will
certainly be cleaner, more accurate, and much lighter on your machine.
It certainly seems to to me. However, you didn't confirm it yet.
Other than that, you probably want to look into your existing procmail
receipts for lurking problems and unwanted matching. Given the modified
example you posted.
The bad thing about majorly rewriting existing code that you actually
want to be discussed is, that those who want to help you have to guess.
If need be, just mask the actual match, x-ing out alphanumeric-strings
for privacy reasons. Depending on the topic, even changing an IP address
can be harmful and lead to false advice -- or a problem description,
that just doesn't make sense.
I think, if i activate the dovecot convert plugin nothig of my procmail must
be changed. (just only the bugs ;) ) Mails will be deliverd in mbox format
to /var/spool/mail/x
The beauty of procmail is, that it can pre-sort your mail. And yes, it
does work perfectly with Dovecot. :) If you want your mail to be sorted
or classified, why not just let procmail do it?
On Userlogin dovecot is picking up Mails and deliver them to maildir-inbox.
Don't know if this is a very Feasible way, not really clean...
Well, frankly, this is a totally unnecessary step. Since you are using
procmail anyway, just let it deliver the mail into the users Inbox. Why
have the mail being delivered twice?
http://wiki.dovecot.org/Plugins/Convert?highlight=%28convert_mail%29
Also, this plugin is not meant for delivery as you stated above. AFAIK
it is used to *convert* (sic) existing mbox format mail stores into
Maildir. Which pretty much should be a single task per user. OTOH
without looking through the wiki, there is another plugin, snarf or
something to do just that -- harvest an mbox spool, and deliver it to
the actual Inbox.
Even worse, since convert runs once each login, the user will *not* get
any new mail, while being logged in. It won't be before he logs out and
in again, that he will get his mail actually delivered while the user
was idling.
Again, using procmail for local delivery anyway, there is no need for
the snarf plugin either...
guenther
--
char *t=[EMAIL PROTECTED];
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;il;i++){ i%8? c=1:
(c=*++x); c128 (s+=h); if (!(h=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
