Hello all, While reviewing overall file path sanitizing (JAMES-3646) I found maildir to incorrectly sanitize some file path.
Playing around, I discovered some magic names that leads to maildir errors namely MAILBOX-406, and a NPE with an empty mailbox (MAILBOX-407). Moreover, over time the list of maildir defects keeps on growing: - MAILBOX-389 Mailbox rename fails with Maildir - MAILBOX-393 mailboxId support for mailDir is partial Now looking on the bug tracker I notice people encounter (and nobody answers): - MAILBOX-390 Unexpected error accessing mailbox - MAILBOX-344 Maildir do not support MODSEQ search - MAILBOX-299 Maildir should fail gracefully when mailbox name is too long - MAILBOX-241 Maildir implementation does not check namespace on existance - MAILBOX-183 readUidFile is taking too much time for large uid file and blocks other threads - JAMES-3612 Cryptic errors upon bad permissions - JAMES-1515 Maildirstorage backend crashes with Exception due to "wrong" filename With such a high number of critical issues that no one dare fixing, it sounds reasonable to me to state that maildir implementation do not match quality standards that one would expect from an Apache project. Other mail servers do have great maildir implenentation, which mistakenly lead users to think the maildir implementation is a quality one, which is very far from the truth. Moreover, maildir code is outdated, hard to work with, and pulls us back in many way. Given the currently small amount of contributors, we do not have time and resources to give it the love it deserves. Also, alternatives exist: embedded JPA database do also run well in single instance mode, and could server as a maildir replacement. People could use utilities like imapsync to plan their migration. As such, I propose myself to retire maildir and remove related code from the repository. Regards, Benoit --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
