Eric Schulte wrote:
>So I believe inline LaTeX images are working in gnus, see here
>[cid]    and immediately below

>[cid]

>This turned out to be fairly easy, and didn't require any encoding or
>explicit mime function calls.

>I've also re-structured the code so that it should be easy to apply the
>appropriate mime markup for WL and VM. There are now two mime-library
>dependent functions `org-mail-file' and `org-mail-multipart' each of
>which contains a `case' block for library-specific behavior, e.g.

>(case org-mail-mime-library
>  ('mml (format (concat "<#multipart type=alternative><#part type=text/plain>"
>                        "%s<#part type=text/html>%s<#/multipart>\n")
>                plain html))
>  ('semi "?")
>  ('vm "?"))

>everything is available at http://github.com/eschulte/org-html-mail

>I'd love to hear feedback, suggestions, or expansion of the missing WL
>and VM portions of the two functions mentioned above.

Two remarks:

1st/

,----
| (add-to-list 'html-images
|              (org-mail-file (concat "image/" ext) path id))
`----

Using the file extension as subtype is not in compliance with the
specs.  For instance the MIME type of "filename.jpg" is image/jpeg,
not image/jpg (cf. RFC 2046, 4.2).

What you need is kind of a function or software that returns MIME type
of a file name.  In SEMI it's `mime-find-file-type'.  Or maybe don't
set the type, maybe mml will pick a type for you.

2nd/

The usage of multipart/alternative is not in compliance with the
specs, too.  There it reads:

RFC2046, 5.1.4

,----
| 5.1.4. Alternative Subtype
|
| The "multipart/alternative" type is syntactically identical to
| "multipart/mixed", but the semantics are different. In particular,
| each of the body parts is an "alternative" version of the same
| information.
|
| Systems should recognize that the content of the various parts are
| interchangeable. Systems should choose the "best" type based on the
| local environment and references, in some cases even through user
| interaction. As with "multipart/mixed", the order of body parts is
| significant. In this case, the alternatives appear in an order of
| increasing faithfulness to the original content. In general, the best
| choice is the LAST part of a type supported by the recipient system's
| local environment.
|
| In general, user agents that compose "multipart/alternative" entities
| must place the body parts in increasing order of preference, that is,
| with the preferred format last. For fancy text, the sending user agent
| should put the plainest format first and the richest format
| last. Receiving user agents should pick and display the last format
| they are capable of displaying. In the case where one of the
| alternatives is itself of type "multipart" and contains unrecognized
| sub-parts, the user agent may choose either to show that alternative,
| an earlier alternative, or both.
`----

So if you attach *only a part* of the plain text message body, you
should not use multipart/alternative: Because

  1. a part of a message is not "an 'alternative' version of the same
     information."

  2. if recipients user agent prefers html messages it will display
     only the html'ized part.

Better use multipart/alternative for plain text and html of the entire
body and additional multipart/mixed for snippets.  If the html output
should contain images, than maybe use a multipart/mixed with type
text/html beneath the text/plain, so the receiving MUA might pick it
up when prefering html.

With regards to SEMI the delimiters are (inserted a space between two
succeeding dashes):

 - single entity: