The envelope, if you're talking about an SMTP envelope, isn't recorded on an IMAP server, IIRC, and, in this case, the replacement message wouldn't even have one, as it never went through SMTP channels.

It's not available via IMAP (except that the "internal date" comes from the envelope) but that doesn't mean it's not recorded. If the server keeps its mail in Berkeley mailfiles, the "From<space>" line (as opposed to the "From<colon><space>" line) contains the SMTP envelope From, which cannot be written correctly by IMAP APPEND (it always writes the email address of the imapd user). This issue is what the last paragraph of RFC2060 sec 6.3.11 is trying to alert people to.

For the same reason, you can't sensibly remove attachments but keep the message.

Oh, I think the BODYSTRUCTURE is pretty well defined in the BNF at the bottom of RFC2060.

Yes, it's well-defined how to parse it, it's figuring out what part-specifiers refer to what parts that's "interesting". (The rules are deterministic, they're just baroque.) Or at least I found them highly counterintuitive.

In case you're wondering how I developed these strong opinions, I did write about three-quarters of a Qt-based IMAP mail client once (it does all the reading stuff but the composer is only half-done and the address book isn't there yet). I gave up when Evolution came along, and now it doesn't compile against modern versions of Qt. The long-term game-plan had been (1) vanilla IMAP client (2) vanilla IMAP server less ludicrous than UW (3) IMAP extensions (hey, at least they got the extensibility right) for all the missing features such as whole-server search, isearch-with-summaries, annotations, server-side address book and so on -- but even step (1) proved to be an unnecessarily gigantic amount of work.

Peter