Folder visit/save/summarize: Variable binding depth exceeds max-specpdl-size

I received an email that whenever it's in a vm mail folder it causes many operations (including vm-visit-folder, vm-summarize, vm-save-folder) to fail with the error message:
Variable binding depth exceeds max-specpdl-size

The only thing that seems "different" about this message is that it has bounced back-and-forth about 26 times or so due to a mail loop which I think resulted in 28 nested MIME chunks... which presumably is related to the error message.

Indeed, increasing max-specpdl-size from the default of 2126 to 5000 eliminates the error.
According to the doc string, this variable defines a "Limit on number of Lisp variable bindings and `unwind-protect's.

While perhaps technically not a "bug" in vm in the sense that the behavior is known and avoidable by increasing the specpdl size, I am wondering whether perhaps it might be advisable and possible to rewrite the code in such a way that one doesn't run out of such bindings -- especially since the nesting in the email that caused the failure is larger than normal but not crazy large.

Would any of the following be possible:
(1) Eliminate the need for multiple levels of unwind-protect and/or other recursive overhead so that stack space is not exhausted

(2) Only try to decode a fixed number of mime levels (perhaps based on the value of max-specpdl-size) so that the message parsing will fail gracefully without generating a fatal error. Presumably, the net result will only be that some of the mime levels won't be displayed but the folder operations will otherwise complete without aborting on error

(3)Wrap the vulnerable routines in a local variable copy of max-specpdl-size to create some temporary extra stack space (perhaps based on the number of expected nested levels)

(4) At least warn the user before or after the limit is reached with a vm-specific message so that at least the user knows what the problem is and what must be done to get vm working again (i.e. delete the message)

Note that just increasing max-specpdl-size to an arbitrarily large size is warned against as follows "if you increase it too far,
Emacs could run out of memory trying to make the stack bigger" -- so I don't want to just forever increase the value of this variable to cover the rare case of emails with a large number of nested MIME chunks.

I am running emacs 23.1 (on Fedora 12) with vm-8.2.0b

I am attaching a copy of the mbox format email that causes the problem -- I have tested it and verified that the attached email causes the above failure when stored as a standalone vm folder under a separate, fresh emacs & vm process.