|Pathologically Eclectic Rubbish Lister|
I think you're missing a huge part of the picture of OSS development, and what CPAN is. CPAN is a way to share code.
Someone, one day, needed to parse mail messages from an internal system, and wrote a module to do it. It works reasonably well, but doesn't consider all of the edge cases. Still, though, they spent hours just getting what they have to work, so they upload it to CPAN so that no one else will have to duplicate that work.
Yes, this means that most of CPAN isn't of the highest quality. That doesn't mean that the advice to "go find a CPAN module to do your task" isn't valid: it just means that it won't save you 100% of the work you need to do.
You claim to have, on your website, better-quality versions of several modules which you felt were incomplete. The point behind CPAN is that it's collaborative: have you sent patches (with tests) to the module maintainers so that other people can benefit from your improvements?
When we say "don't reinvent the wheel, use a CPAN module", we mean that you shouldn't re-do the work others have done. If no CPAN module quite cuts it, then download the closest one and build on it to complete your solution. Ideally, then, also contribute your improvements back to the CPAN module.
The responses to your questions about mail parsing were not as you phrase them. They were "don't start from scratch, a lot of work has already been done and is available on CPAN: start there".
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet