On 11/11/05, Professional Software Engineering
<PSE-L(_at_)mail(_dot_)professional(_dot_)org> wrote:
I really don't understand the fierce opposition to facilitating new
features.
For me, at least, (a) I wouldn't call it "fierce" and (b) it depends
on the feature.
I suggest those who want to hold on
to old versions go and check to see if your recipes work on an older
version of procmail. INCLUDERC? Sorry.
You've got it backwards. Recipe files written for new versions don't
have to work with older versions. Recipe files written for old
versions really ought to work with newer versions.
I'd really like to see procmail be able to parse multipart messages, handle
encodings (imagine being able to search for text and match it even if it is
encoded, just by indicating you want to search the "decoded" target
These are features that I'd support, because they're more than just
sugar. However, it's important to have a realistic understanding of
just how difficult this is to get right. For example, what happens
when the text you've decoded is in a different character set than the
one in which your recipe file is written? The IMAP working group in
the IETF has been arguing for literally *years* about how to resolve
that problem for the SEARCH command, and there are similar discussions
going on in the SIEVE group (SIEVE being the moral equivalent of
procmail).
____________________________________________________________
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