I'll answer to all above comments here to avoid duplication.

Most of your misunderstand me. Probably because my initial post was too emotional and overloaded with details. Here is short summary:

• I'm NOT complaining about CPAN modules at all! Maybe sometimes is sounds like it, don't know, but I don't try to say this.
• This node was just a question: is there exists reliable email parser module in CPAN (including RFC compatibility, because I consider this isn't optional feature for reliable email parser)? The answer was "No.". Ok, no problem.
• Current node is meditation about right attitude to development: goals and priorities required to develop useful software. I say "useful" because, as I say before, if software isn't reliable and secure it isn't useful for me.

So, we can discuss how may (10, 30) years of experience we've; we can discuss why I complain about CPAN modules instead of sending many more patches/bugreports than I send now; why my own modules non RFC compliant; etc. But I don't think this have sense.

I wrote this to discuss another thing: what you think about right attitude, goal and priorities used while developing reusable software like CPAN modules. Do you agree reliability and security must be 1st and 2nd priorities, or not and why?

blue_cowdawg: Are you trying to tell me that your own code is 100% bug free and does all the above (or some analog thereof) 100% of the time?

Of course, no. But I'm always (at least in last ~6-7 years :)) trying to develop everything with reliability and security in mind first, and all other things next. My success in this area depends on task and my experience X years ago when I developed it.

Fletch: I think you need to re-read the replies a bit harder. They mostly boil down to "Try module X or Y; if those don't work contact the maintainers with test cases which exercise the problems you think there are".

Yeah, you right. But I speak about attitude. There no replies like: "Yeah, sadly, but there no reliable email parsers on CPAN now. Most promising is Email::* branch, you can contact it author, maybe he interesting in making his module compliant to all RFC you've listed here... But possibly it's just another 'worksforme' module, just designed to be 'recommended best practice' replacement to all existing modules."
BTW, I've subscribed to PEP maillist and mail there my question, but looks like it dead.

b10m: "Simple (and non RFC compliant) email sending"

Yep. At least I include this note in documentation. This function was developed many years ago (in 2000-2001)... few months ago I wish to add GPG support and email parsing support, and found it realization terrible. I've checked CPAN. :( Then I've spend 2 weeks to carefully read and analyse all RFC related to this topic... I've begin developing parser, but then 'russian summer holydays' happens. :) So now I should return to this work... probably reread some RFC, etc. Complex, and distasteful task. So, I've tried to ask fellow monks - maybe I missed some module when checking CPAN few months ago. Sadly, but not, I don't missed anything. If I wish to have reliable email parser, I must develop it from the ground. :(

dave0: The project aims to identify the current best-of-breed email modules in CPAN

Good aim. But far away from mine. It's hard for me to believe in possibility to improve complex enough software developed without reliability/security in mind. 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.

Jenda: I'm kinda inclined to say "worksforme" IS good enough.
Albannach: ... far far better use of my time to pull pieces out of the CPAN than write them myself. Sure I may find spelling mistakes, bugs, or incomplete solutions, or even security issues, but ...

So, looks like we've two clean votes against 'reliable' and for 'worksforme'. I say "against" because if you agreeable to use 'worksforme' modules in your project then you even don't try to develop 'reliable' software. 'worksforme' works in both directions - if you think it's ok to use it then you think it's ok to develop it.
Anyway, I consider these two comments only 'on topic' for now.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.