Re^3: Reliable software OR Is CPAN the sacred cow

[powerman]

The problem is, you have a very narrow, and likely unrealistic, definition of reliable.

Hmm. Very interesting. Maybe you right, maybe... but ... can you explain what's wrong with my definition of reliable?

As least few people in the world develop reliable, by my definition, software - DJB, as example. For me it looks like problem isn't in "unrealistic, definition of reliable", but in people who doesn't try to develop really reliable software. They doesn't try, and so they doesn't got it.

Anyway, I'm really interested in your opinion on this topic, so I hope you'll reply. Only few monks reply "on topic" here (and I agree it mostly my fault - I've mixed too many different topics and emotions in otiginal post), so every "on topic" reply I really appreciate.
I'm here not to just rant my opinion, but mostly to calibrate it.

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.

I can't understand.
If you think existing modules are reliable, because they support all possible cases, both RFC compliant and Real Life - then why you doesn't reply on my yesterday quesion with names of such modules?
Or you think existing modules are reliable, even if they doesn't support some emails (which comply to RFC!) because authors/users of these modules doesn't received such emails?
Or you mean something else?

[Anonymous Monk]

You complain about mbox storage format, but there is no RFC for mbox