MIME canonicalization: lurking dragons

["Lucky Green" <shamrock@cypherpunks.to>]

The proposal to let the user's MTA construct the MIME blob, with
mixminion canonicalizing the MIME before further processing sounds
appealing. The issue in my mind that creates a slight cloud over this
proposed solution is that I don't believe it is feasible to implement on
all target platforms and with all target MUAs. [BTW, the requirements
will need to contain a list of target platforms and MUAs. Perhaps they
already do].

It is not necessary to know the answers to the questions below to
determine if mixminion should support canonical MIME. It is however
necessary to answer these questions (and probably some 20 more questions
that I could come up with in short order) to determine if the use case
that everybody seems to have in mind that factored into this requirement
during the BoF is in fact correct: that users will be a able to use
their existing MUAs with mixminion.

On to the questions. Just for clarification; I don't know the answers.
:)

1) How do you plan to hook a MIME canonicalization engine into Microsoft
Outlook and Outlook Express?

2) Do you _know_ that the hooks that your answer to 1) assumes to be
available actually do exist?

PGP's Outlook Express plug-in is unable to encrypt attachments because
there is no API in OE that would allow such processing. Granted,
processing attachments before MIME encoding is a different problem than
processing attachments after MIME encoding. Is there an API on Windows
to do the latter?

3) If so, do you know of anybody who has succeeded in using that API?

4) If you can't get at the output of Microsoft's MimeOLE via an API,
what other options exist?

5) If you answered "local SMTP proxy", how will your proxy interact with
the Norton Antivirus SMTP proxy already operating on the same host?
Alternatively, how will that proxy be able to act as an MIM for the
MUA-MTA smtps connection without negatively impacting existing user
experience during non-mixminion-related use of the MUA? (Alert boxes
displaying dire warnings generated by the existing MUA count as
negatively impacting user experience).

6) If you plan to avoid some of the above problems by selecting amongst
multiple MIME engine based on whether an outgoing email is to be
remailed, do you know that the MIME engine that will be used by the MUA
can be selected by a MUA plug-in?

7) Once the mixminion MIME engine has somehow performed the
canonicalization, how do you inject the output back into the MTA?

8) Do you know for fact that the functionality that your answer to 7)
assumes to be available on the host is indeed available?

9) Replace Outlook and Outlook Express in the above questions with
"Netscape" and "AOL's email client" and repeat 1) - 8) :-)

10) If you were to come to the conclusion, after attempting to answer
these questions, that it is not realistic to use Outlook, etc. as an
input MUA to mixminion, what would your next favorite option be? Bundle
mixminion with an existing MUA that does provide the necessary hooks?
Which of the existing MUAs meets that requirement? Write your own MUA
and bundle that? Other options?

11) If the currently envisioned approach is infeasible on Windows, does
this make it less desirable for the entire system? Should there be one
approach for all platforms and MUAs or is it not an issue to have two
entirely different approaches for Windows and UNIX? If so, do approaches
follow MUAs or platforms for those MUAs that are available on both
Windows and UNIX (Netscape)?

11) Who will do all the work needed to create whatever the answers to
the above questions may require?

Anyway, these are just a handful of questions to help get the thinking
started.

--Lucky