Re: using orgmode to send html mail?

["Eric Schulte" <schulte.eric@gmail.com>]

Hi David,

David Maus <dmaus@ictsoc.de> writes:

[...]

> 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.
>

Ah thanks, I will look to see if there is such a function distributed
with the core Emacs, else a simple alist should suffice.

>
> 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.
>

I should have been clearer here.  I *am* using the multipart/alternative
appropriately.  When a chunk of org-mode text is converted to html I am
adding a single multipart/alternative block with two alternatives, both
the plain org-mode text, and the html, so that users like me who prefer
to see plain text can do so, and users of web clients like gmail can see
nice markup.

>
> 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:

And the limits of user email to discuss email have been reached :)

gnus seems to have mangled some of the following examples, but I have
tried to flesh out the 'semi portions org-mail-htmlize given what I was
able to salvage (see the latest commit).  I still can't figure out the
SEMI multipart/alternative syntax.  Please let me know if you have the
syntax at hand, feel like submitting a patch, or you would like commit
permission to the git repo.

Much Thanks! -- Eric