Matthew T. O'Connor <matthew@zeut.net> said: > I would like to add one additional safeguard. That is add an > enable_is_header variable in dbmail.conf that defaults to false. This > requires that the mail admin knowingly turn this feature on knowing that > his database is uptodate.
This is a neat idea in concept, but I'm worried that we would end up with an unwieldy proliferation of such settings. > DBMail 2.0 branch is supposed to be stable, I should be able to upgrade > from 2.0.0 -> 2.0.1 -> 2.0.x without having to think, or having to do > anything special. People should be running dbmail-util on a regular basis, and as long as they run dbmail-util to do the is_header updates before running 2.0.2, everything should be fine. You bring up a good point, which I agree with, that there should be nothing special happening as we move upwards in 2.0.x, but is_header is going to be a big help and I think that one revision of explaining that dbmail-util should be in one's regular routine is worth the hassle. My original complaint was that it should be OK to upgrade and downgrade freely along 2.0.x, and I still hold by that, except that I think the dbmail-util solution is a reasonable compromise. > Aaron Stone wrote: > >>I thought some more about the is_header thing, and realized two issues: >> >>1) My complaint against not being able to downgrade and upgrade freely is >>10% valid and 90% ridiculous. >> >>2) We should add a check to dbmail-util that can repair incorrect >>is_header markings. >> >>1+2) The 10% validity of my complaint is alleviated by an attentive mail >>administrator who runs dbmail-util on a regular basis. So the worst case >>is that a few pieces of mail are inaccessible until the next run of >>dbmail-util. >> >>Was I the only objector to rolling in is_header support? If so, let's do >>this thing for 2.0.2 or 2.0.3! >> >>Aaron
