[Dovecot] procmail/formail --> Maildir

Andre Huebner

3 Dec 2007 3 Dec '07

2:02 a.m.

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:

^From.*gmx.de | (formail -t -I"procmail: gmx.de") >> /var/spool/mail/xxxxxx

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. 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/xxxxxx and picked up by dovecot if in dovecot.conf the convert-plugin ist always activated?

Thanks

Andre

Show replies by date

Asheesh Laroia

3 Dec 3 Dec

2:28 a.m.

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 -I"procmail: gmx.de") >> /var/spool/mail/xxxxxx

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

Karsten Bräckelmann

3:46 a.m.

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 -I"procmail: gmx.de") >> /var/spool/mail/xxxxxx

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/xxxxxx 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: .+ .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="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

0 0

Reply
Sign in to reply online Use email software

Andre Huebner

4:58 a.m.

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/xxxxx 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" guenther@rudersport.de 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 -I"procmail: gmx.de") >> /var/spool/mail/xxxxxx

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/xxxxxx 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: .+ .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="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i++x); c&128 && (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

0 0

Reply
Sign in to reply online Use email software

Karsten Bräckelmann

4:17 p.m.

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/xxxxx

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="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}

0 0

Reply
Sign in to reply online Use email software

6154
Age (days ago)

6155
Last active (days ago)

List overview

4 comments

3 participants

Add to favorites Remove from favorites

tags

participants (3)

Andre Huebner

Asheesh Laroia

Karsten Bräckelmann