>> mutt didn't need that header to operate well in the original folder. >> In general, can't think of any reason to modify any Maildir message on disk >> and view this as tainting the msgs with unecessary and un-asked-for mods. > > well, they don't really hurt, but may even help mutt and other tools.
'Really' hurt or 'may' help is not relevant, and vague. The msg file is being tampered with on disk when, as far as I know, there is no RFC or other such non-optionable specification requiring such modification. Though I'm still searching for one and would like to read it to make sure of this, I've not found such spec requirement yet. >> And it breaks external indexes of security/archive crypto hashes. >> I'm not referring to the msg filename (maildir spec) or its location (as >> instructed), just the content of the msg file itself. > > Well, if you are using sane crypto you are talking PGP and SMIME. Both I'm referring to the entire 'message file itself' on the disk, like sha1 <filename>. Not the header/body content of the message as interpreted by some mailer. >> And it also appears to be lying by preserving the msg file modification >> time when it adds this header. [1] > > Well, I don't see any problem with that - the real message has not been > changed, only some metadata that help mutt. The file has been changed. When you change/write contents of a file under unix/POSIX, the mod time is automatically bumped. You should never revert it with another system call unless you have good reason. >> Why does mutt do this? > > A rough assumption from myself only: It does it always, with every mailbox > type, and in case of mbox and similar mailbox types a correct > content-length help for sure to improve the access. If memory serves, older mutt's used to add content-length even upon reading in 'A', not just upon copy to 'B'. However that may have been back when I had some mbox'es, not Maildirs. I don't use mbox now so I can't say about mbox now, just Maildir. Whichever format... if mutt is capable of calculating and putting in 'correct' content-length, then it has no need for such a header, it's redundant. > Please answer me one question: what kind of crypto/archive system do you > use that does not understand Maildir in it's whole and what kind of use > case does it have. Unix people commonly store the hashes of every file on disk. They rehash and compare using various tools at various intervals. When those hashes change, it may indicate any number of potentially bad things, from security to apps/hardware gone bad. >> What else is being surreptitiously modified during mutt operation? > Well, I think you should check mutt's codepath yourself if you want to > know that exactly. That's why it's called open source. Open source isn't supposed to change people's files like this unless required by some specification. This would be like an image or mp3 editor or Microsoft Office adding metadata to all your such files just because it wanted to. In the absense of documentation saying 'oh, by the way, we do this, and here's a way to opt out...', that's generally very taboo with open source and shouldn't have to be checked for. This is about modifying the Maildir files on disk in the absense of RFC or other non-optionable requirement to do so. Not about the content of those files as interpreted by a MUA unless under such requirement.
