Most of your misunderstand me.

May I make a suggestion? That's not because we're dense. It's because you're bandying about words like "reliable" and "RFC compliant" without defining what you mean by them. And no, your code doesn't count, because, frankly, you're sitting on it. Why is it not on CPAN, if you've made such great strides in the programming realm?

I read your original post yesterday. You utterly confused me, and I suspect a lot of people, by saying it must conform strictly to the RFCs...except that it must also understand mails that are not compliant with the RFCs.

I've seen no links to bug reports from you on these modules. No precise definitions as to the problems you see, so we all can follow along -- few of us have the time to parse through a near-dozen RFCs and the 600+ modules in question, and you, apparently, already have this information. No commentary that you're willing to talk to the various maintainers of the modules about how you might improve them -- which is, after all, the point of Open Sourcing one's code. It's really not to come on a public source, like this, and bash the hard work of many before you.

Let me ask you this -- have you actually talked to any of the developers, or asked for insight as to why they didn't conform to the RFCs? They are, after all, only Requests For Comments. I had a similar issue when I was developing an application to work with ICal files -- the RFC for ICal, and the reality on the ground with regard to Outlook's ICal files, was two slightly different things -- and it was folks from MS that wrote the damn spec! Naturally, I opted for interoperability over adherence to spec, and I strongly suspect you'll find the various Mail maintainers have done similar.

If. You. Ask. And no, asking on Perlmonks does not equate to asking maintainers of modules.

There no replies like: "Yeah, sadly, but there no reliable email parsers on CPAN now.

Sure there are. The problem is, you have a very narrow, and likely unrealistic, definition of reliable. That's why we keep not answering your question; we're trying, very nicely, to point out the reality, based on people using these modules in Real Life situations -- the kinds where security holes, non-RFC compliant emails, etc., are ripped apart very, very quickly. You can either take that advice, or insist on conformance to specs and buzzwords. Your choice, mate.

Ranting on here about "reliability" (which you've also failed to define, aside from some arguments about "Object Orientation" and "Security First!") isn't going to solve the problem, either. They are, in the end, just words -- as Microsoft's "attention" to Security in their products prove. Following the RFCs does NOT equate to a secure product -- and if you don't mean to co-mingle the two, please write so we can understand what you mean.

If you think we're idiots who cannot write code, point out the lines of code that suck in the mail business. That way, we can actually solve problems, rather than play "whack the mole" with your issues and suggestions.

I’m sorry for the rant, and I tried to be as nice as possible. But I’m utterly frustrated that you’re not listening to very good advice, the kind I wish I’d had access to when I first started working with Mail in Perl. I strongly recommend a listen, and deep re-read, of the commentary both here and in your original post. And then to ask deep questions, over insisting that your programming knowledge exceeds those who wrote the various modules, as well as those of us on Perlmonks.

EDITED to clarify programming issues

Can you believe in reliable&secure Sendmail or BIND? I can't, that's why I use DjbDNS and Qmail... And looking for Apache replacement.

Ah, you're one of those people. Can I say it? Sure I can. I've been running both Sendmail and BIND on many systems, for over 10+ years, with tens of thousands of users and I sleep just fine. Never had a reliablity problem or a security problem.

Worrying about security and reliablity are good things, don't get me wrong. Worrying about them TOO MUCH, at the expense of everything else is like only drinking pure distilled water and eating brown rice because anything else MIGHT cause cancer. You can do it, but please stop bitching because everyone else doesn't wear the same tin foil hat you are wearing.

Read Worse is Better. And the followup article. And try to understand it.

It is all about how the Lisp world's attempt to put reliability and security first resulted in nobody using Lisp. And it therefore gives an argument for not putting reliability and security first.

I think your question is an interesting one:

I must admit, I fall into the 'works for me™*' school of thought -- but I'm open to being gently encouraged or corrected. Your original 'rant' and subsequent posts have not (yet) inspired me to change (mostly because they are long, somewhat rambling, and I don't have a lot of extra time today). I was surprised to see that your initial node is (or was, at the time of this comment) still in positive reputation territory ... because I think you come across as complaining or rebuking but not really offering a solution. Can you succinctly sum-up your arguments for why you think the bar of reliable and secure software should be raised, and how you propose to raise the bar on CPAN or within this community? What solution are you offering?

Most of us are not against producing more reliable and secure software ... but you have to gently convince us that:

1. we are not already doing so
2. we (both individually and as a community) will gain something tangible by doing so
3. there is a workable path to improving in this direction

I'm a very pragmatic person, and I'm generally rewarded by delivering results on a day-to-day and week-to-week basis, which is partly why I love Perl. If I'm going to redirect bandwidth toward more secure and reliable software and away from delivering those immediate results, I'll need some justification.

*works for me = Works within the context of my current environment. Currently, that means I am developing for internal users within the semi-safe confines of an intranet.

BTW, I've subscribed to PEP maillist and mail there my question, but looks like it dead.

I sadly fall into the category of a), but am now retreating to b).