Re: using orgmode to send html mail?

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

David Maus <dmaus@ictsoc.de> writes:

[...]

> 1/
>
> But I still feel uncomfortable with the current solution: Even if the
> message created by current org-mail-htmlize is a valid MIME message (I
> think so) it is a rather complex MIME structure and I have no idea how
> other MUAs will display such a message.
>

Yes, but since it is valid MIME I'm personally very happy with it.  Also
both Gmail and Gnus both play well with these complex embedded multipart
structures.  Unless it actually becomes a problem I don't see any reason
not to use the standard to it's full power.

>
> Moreover, this complexity is unecessary if we make the assumption:
>
>   If substantial parts of your message require html markup do be
>   displayed by a some of your recipients, than send a html
>   representation of the entire message along with the plain text.[1]
>

I don't agree with that assumption :)

I often want only a table, list, or latex-heavy section of my email to
be converted to html.  I find that other parts of the email
(e.g. previous emails in the thread nested behind ">" characters,
signatures, etc...)  work better when sent as pure text.

>
> For a recipient who preferes html the result is the same: For him the
> substantial parts are displayed in a meaningful way.  People who
> prefer or depend on plain text get the plain text.  And we avoid
> uneccesary complexity.
>
> Thinking functional this might be the first function of
> org-mail-htmlize[1]: Create a html representation of message body if
> necessary or appropriate.
>

Oh, so this would be a slightly different issue,

So this function could be run *every* time an email is sent.  I agree
that in those cases running on the entire message would be the right way
to go.  Currently if `org-mail-htmlize' is called with no active region
then this is what happens.  So I believe the code as currently written
should satisfy the above points, resulting in a simple structure (only
one multipart/alternative section) which contains the entire email and
would be appropriate for running on every mail sent.

>
> 2/
>
> The second function: Attach external files that are referenced in the
> message.  This might be useful even if you don't send out html
> messages: All external files are stashed into a multipart/mixed
> container along with a Content-Id: header field.
>
> Than all references are changed accordingly to point to the attached
> files:
>
>   - for html use src/href with the cid: prefix
>
>   - for text: good question.  Maybe replace occurences of the file
>     with a customizable string saying: "see attached file foo.bar".
>

I'm not sure I understand, I'm currently happy with my mail agent's
method of attaching files to email, what else would this use of the
function add aside from a new attachment syntax.

>
> 3/
>
> For Wanderlust multipart/alternative is (replace "_" by "-")
>

Thanks, I've applied this to the `org-mail-multipart' function in the
code repository.  I'm not entirely sure if I got the full multipart
syntax correct, but if I did then hopefully this means that WL is now
supported.

>
> __<<alternative>>_{
>
> and closing
>
> __}_<<alternative>>
>
> 4/
>
> Detecting the plain text body should not just stop on end of buffer
> but also on the first occurence of a MIME delimiter: Maybe the user
> already added a attachment.
>

Good point, one open question here is how to treat that mime border, I'm
thinking it may be best to simply stash it in a

#+BEGIN_HTML
original mime content
#+END_HTML

block, so that it survives the Org-mode export unscathed, however maybe
it's simpler just to end the html alternative part at the first mime
border.

Either way this will require a mailer specific function to search for
the next multipart section.

>
> And, last not least: This has the potential for going into contrib.
> Maybe it should be renamed to org-mime -- it's neither just about
> mail, nor just about htmlizing.
>

Fair point.  I've just renamed the functions and the repository, and it
is now available at [1].  If there's a better place to host this to
encourage collaboration please let me know.

Thanks -- Eric

>
> HTH
>   -- David
>
> [1] This assumption may also address the concerns about sending html
> messages: From my perspective html message are not a problem in
> itself.  Sometimes people have to send html messages (organizational
> rules) and sometimes it is appropriate for content to render properly.
> As far as I read on the topic of html message they got their bad name
> because people where sending html messages implicitely assuming that
> all recipients /can/ read them in the same "fancy" format as they did.
> Such an assumtion is wrong because it does not take into account that
> information and it's representation are two different things and
> computers are create in processing and (re)formatting information.
>
> Anyway, what org-mail-htmlize really misses is a function that adds
> fance pictures (cats!), sounds and maybe even flash animations to the
> messages :D
>

:) agreed, blink tags around every noun

>
>
>
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber.... dmjena@jabber.org
> Email..... dmaus@ictsoc.de

Footnotes: 
[1]  http://github.com/eschulte/org-mime