Hi. I've recently reported several bugs against MUAs and mail tools, that employ the mboxo (note the trailing "o") format to either store or import mails.
This however leads to irrecoverable data corruption, as the partial quoting of so called From_ lines cannot be undone anymore. An easy solution for that dilemma is known for years, namely the other mbox formats (either mboxrd, mboxcl or mboxcl2), of which mboxrd is typically the one which fits best the needs for staying backwards compatible. Given that mails are the core business and data of MUAs and mail tools, I'd personally say that any corruption of them, even if it seems to be minor deserves the most critical severity. Similarly, if a DBMS like postgres would silently modify integers, even if joust a tiny bit, it would be considered unacceptable. For mails one may easily think, that a "small" corruption isn't a problem, but not only does it break signatures or perhaps corrupt in-line content like patches, it's IMHO also not the decision of upstream, the maintainers or anyone else but each single user which kind of corruption of his data he/she considers to be severe. No first I've had reported these corruptions at the different upstreams (and apart from KMail and mutt...all the major players I've tested, e.g. Thunderbird, Evolution, getmail, postfix, were affected). Apart from the getmail upstream all reacted rather stubborn and without much insight,... bringing up obscure "arguments" like "this corruption has always been the case historically, therefore it's ok". Well we, as Debian, can't of course force upstreams to fix their crap, but IMHO neither should we let our users at risk for silent data corruption. So I've opened bugs at the BTS, too, with severities critical (justification: data loss) where I mentioned the upstream bug and further suggested what I think we should do at the Debian level to adequately warn users. IIRC, in all but the getmail case (where the issue has been fixed) upstream, this was neither accepted by the Debian maintainers, referring to the same obscure arguments from the upstreams. I personally have no longer much interest in tracing this family of issues, especially when being confronted with so much narrow-mindedness and arrogance (IMHO, deciding for the users that they can live with mail corruption is arrogance)...and when it's tried at nearly all levels to hide these corruption bugs away behind duplicates or lesser severities.. So,... bringing this up here at d-d, as I think it would be good for Debian to have a well thought position in how to handle this family of corruption bugs... If it's agreed upon with upstreams/maintainers that it's ok to let people live with them... fine for me... If not, than the majority opinion might perhaps even convince the maintainers to handle this with some higher severity :) Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
