mail procmail

vkbr

Hello. Is it possible to whitelist people using procmail? how? Is it possible to have it looking into a flie for the list?
I'm using procmail and X-Spamlevel, to filter emails successfully, as in the example in the docs, but getting some false positives (good mail flagged as sapm). So I'm looking for a way to whitelist those.

Thanks.

sean

You can whitelist addresses in procmail with a rule like this (using bob@domain.com as the address):

:0:
* ^from:.*bob@domain\.com
$DEFAULT

The whitelist rules must come before the other rules in your procmailrc.

At this time we don't have a way for you to maintain the whitelist in a separate file.

vkbr

Ok.Thanks @sean. Does adding the address to webmail contacts have any influence in this process? I mean is there a Header for that?
And also, what would be the rule for all mails coming from @domain.com?

* ^from:.*.*@domain\.com is this correct?

sean

vkbr Does adding the address to webmail contacts have any influence in this process?

No, the webmail system doesn't know anything about your procmailrc and vice-versa.

vkbr what would be the rule for all mails coming from @domain.com?

* ^from:.*@domain\.com

vkbr a rule for each address

:0:
* ^from:.*(bob|bob2|bob3)@domain\.com
$DEFAULT

vkbr

Ah! One more question 🙂 Is it necessary a rule for each address, or can I just write

:0:
* ^from:.*bob@domain\.com
* ^from:.*bob2@domain2\.com
* ^from:.*bob3@domain3\.com
$DEFAULT

this should work, wright?

vkbr

sean thanks again!

Still one clarification please,

:0:
* ^from:.*person@domain\.com
* ^from:.*other@someotherthing\.com
* ^from:.*thirdperson@yetanotherdomain\.com
$DEFAULT

would work?

sean

vkbr No, it needs to be all on one rule with the addresses separated by pipes (|) and the whole list enclosed in parentheses, eg:

:0:
* ^from:.*(person@domain\.com|other@someotherthing\.com|thirdperson@yetanotherdomain\.com)
$DEFAULT

vkbr

sean All right thanks. Got it

VVVOID

Sorry for digging up an old thread, but it asks / answers almost what I'd like to do. Instead of matching exact addresses, I'd like to filter if the email address contains a string

* ^from:.*(domain | someotherthing | yetanotherdomain | someone@ )

So similar to the above - but it could be any person at one of various domains, including if the TLD is different (randomperson@domiantofilter.randomtld), or a name at a particular domain (nametomatch@randomdomain)

Thanks!

sean

VVVOID your example should work, just remove the spaces eg:

* ^from:.*(domain|someotherthing|yetanotherdomain|someone@)

VVVOID

Fab, thanks Sean - I've added it in and will see how it plays out in the next few days.

Axel

How big can this procmail file with white list be ? I have a white list that's about 45kb to start with.

sean

Axel we do not impose any specific limit on the size of your procmailrc.

Axel

So I changed a procmail file I'm using to something like this:
:0:
* ^From:.*(name1@domain.tld1|name2@domain2.tld2|name3@domain3.tld3).*
./
:0:
* ^From:.*
.Junk/
I would expect that any email that doesn't come from one of the email addresses in the first filter would be moved into the junk folder but this is not the case. Since the list of addresses in the first filter is actually some 45kb I've set LINEBUF=65536.
What am I missing ?

nick

Axel Hi Axel, I believe the second rule is overriding the first. If you use the E flag in the second, it should only execute if the previous conditions do not match.

Ref: https://porkmail.org/era/procmail/quickref#flag-E

Axel

nick It seems to me that if the second rule would be overriding the first, all email would end up in the junk folder, which is not happening. Also note that in my actual procmail file there are a number of other rules preceding the two that I listed. All the rules are tested on the email until there is one that applies. If nothing applies the email is delivered to the inbox, which is what is happening. So I have to conclude that the second rule is somehow not applied or is never applicable to any email. But why ?

nick

Axel Okay, my earlier suggestion may not be helpful in this instance. I suggest opening a support ticket with all the relevant details so we can enable logging on the procmail rule file to see what may be going on.