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.
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.
Matthew
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
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
