Hi Gang!
Can anyone comment on the reasons one should/should not use a single
"monolithic" .procmailrc as opposed to one .procmailrc *plus* several
"INCLUDERC" files?
For example, I see Jari's procmailrc (which is mindbending BTW) and one
gigantic file
I use INCLUDERC's because I don't (yet) understand where certain recipes
should live in a monolithic evironment, so to avoid breaking stuff I put
autoresponders in one, /dev/nulls in another and so on. Other than that, I
wondered if anyone had a more formal explanation for this approach.
Regards to all,
procmail recipes are entirely hard enough to comprehend without having dozens
of them in the one file.
I find it convenient to have one that's used to detect spam. All mail gets
passed through this.
Another to do some basic filtering. For example, some lists don't set
Reply-to: to my preference, so I fix them.
I have the mainline recipe detect lists from Red Hat; they get their own file
of recipes.
I also try to detect mail from other lists (Precedence: header) and direct
that to a file of recipes to try to deduce the list name. Not entirely
successful, I must say.
Breaking programs down into separate modules is a proven programming
productivity enhancer. It helps clarify the thinking process. It also helps
identify what you changed recently - just look at the file dates.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail