PARP ::was::::Re: procmail abandonded?

Has anyone looked at/or is using PARP as a procmail replacement?

http://adamspiers.org/computing/parp/

In my brief review, it seems to have several pluses and minuses.

Thanks for any comments,

Jerry


On 10/14/10 12:29 PM, Ed Blackman wrote:
> On Thu, Oct 14, 2010 at 08:52:26AM -0500, cbarnard wrote:
>> It works, so why mess with it?  It does what in needs, no more
>> development is needed...
> 
> If procmail was still processing the mail stream of 10 years ago, I'd
> agree.  But increasingly I'm seeing headers that procmail doesn't handle
> well without external help, especially RFC2047 encoded strings.  A user
> sees "Subject: test message" in their mail reader, and creates a
> "^Subject: test message" recipe, but doesn't understand why it doesn't
> match.  That's because it was sent as =?ISO-8859-1?Q?test=20message?= or
> =?UTF-8?B?dGVzdCBtZXNzYWdlCg==?= or even =?US-ASCII?Q?test=20message?=. 
> Mail readers decode those strings for display, procmail can't without
> assistance.
> 
> Shelling out to perl or whatever for the decode is just kludgy when it's
> a handful of messages per week.  But I'm seeing an uptick in emails that
> have RFC2047-encoded headers when none of the characters actually
> required encoding, suggesting to me that some tools are encoding by
> default, and the problem of matching in procmail is only going to get
> worse.
> 
> Ed
> 
> 
> __