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
signature.txt
Description: Digital signature
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail