Re: using orgmode to send html mail?

[David Maus <dmaus@ictsoc.de>]

[-- Attachment #1.1.1: Type: text/plain, Size: 602 bytes --]


Okay, took a look on the specs and attached is a memo on how an
implementation of org to MIME could be done.  The MIME delimiters of
SEMI and mml are quite similar so there's already a generic function
that creates representation of a MIME message for both.

I've published this memo on Worg, too, occupying some space in

http://orgmode.org/worg/org-devel.php

The tasks at hand would be: find the functions that attach a file in
mime-edit-mode and mml-mode and look who they can be utilized.

Best
 -- David

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


[-- Attachment #1.1.2: Type: text/plain, Size: 8340 bytes --]


Author: David Maus <dmaus@ictsoc.de>
Date: 2010-03-25 21:56:50 CET


Table of Contents
=================
1 Representing a MIME internet message
2 MIME delimiters of SEMI and mml
3 Generic function
4 Open questions
    4.1 How to handle charset information?
    4.2 How to attach files?
5 Quotes from the specs
    5.1 MIME multipart: Notion of structured, related body parts
    5.2 MIME multipart: order of entities inside a multipart


1 Representing a MIME internet message
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   A MIME internet message consists of one or more MIME entities. Each
   MIME entity is of a distinct type and subtype, has a body and
   optional MIME headers related to it's content.

   A MIME entity is represented as a list:

   (TYPE SUBTYPE BODY CONT-HEAD)

   TYPE: Symbol of MIME media type (e.g. text, video, audio).

   SUBTYPE: Symbol of MIME media subtype (e.g. plain, html).

   BODY: String with entity body -or- list of other MIME entities.

   CONT-HEAD: List of cons with content related MIME header
                  fields.  The name of the header field without the
                  prefix "Content-" is car, the value cdr.

   Example:


  '(text html "<h1>Headline</h1>" ((disposition . inline)))

   For messages of type multipart the body consists of a list of one
   or more MIME entities.

  '(multipart alternative
              '((text plain "* Headline")
                (text html "<h1>headline</h1>")))

2 MIME delimiters of SEMI and mml
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   The MIME delimiters are defined in an association list with a
   symbol of the library's name as key and delimiter format strings as
   values.  For each library there are three formatstrings.

   (SYMBOL DELIM-SINGLE DELIM-SINGLE-CONT DELIM-MULTI)

   DELIM-SINGLE: Denoting a single MIME entity.

                     Strings are passed in this order:

                     1. type

                     2. subtype

                     3. content header

                     4. body

   DELIM-SINGLE-CONT: Format of content header strings.

        Strings are passed in this order:

        1. header field name

        2. header field value

   DELIM-MULTI: Enclosing parts of a multipart entity.

                    Strings are passed in this order:

                    1. subtype

                    2. body

                    3. subtype


  (setq org-mail-htmlize-mime-delimiter-alist
        '((semi "\n- -[%s/%s%s]\n%s" "\ncontent-%s: %s" "\n- -<<%s>>-{\n%s\n- -}-<<%s>>")
          (mml "\n<#part type=\"%s/%s\"%s>\n%s" " %s=\"%s\"" "\n<#multipart type=\"%s\">\n%s\n<#/multipart>")))

3 Generic function
~~~~~~~~~~~~~~~~~~~

   This generic function returns a string representation with MIME
   delimiters depending on the variable =org-mail-htmlize-mime-lib=.


  (setq org-mail-htmlize-mime-lib 'semi)


  (defun org-mail-htmlize-mime-entity (type subtype body
                                            &optional cont-head)
    "Return string representation of MIME entity.

  TYPE is the type of entity body.
  SUBTYPE is the subtype of body.
  BODY is the body of the entity.  Either a string with the body
  content or a list with one ore more MIME entities.
  Optional argument CONT-HEAD is a list of cons with content
  specific headers, name in car and value in cdr."
    (let ((delimlst (assoc org-mail-htmlize-mime-lib
                           org-mail-htmlize-mime-delimiter-alist)))
      (if (eq type 'multipart)
          (format (nth 3 delimlst) subtype
                  (mapconcat '(lambda (b)
                                (apply 'org-mail-htmlize-mime-entity
                                       (car b) (cadr b) (cddr b)))
                             body "")
                  subtype)
        (format (nth 1 delimlst)
                type subtype
                (mapconcat '(lambda (h)
                              (format (nth 2 delimlst) (car h) (cdr h)))
                           cont-head "")
                body))))

4 Open questions
~~~~~~~~~~~~~~~~~

4.1 How to handle charset information?
=======================================

4.2 How to attach files?
=========================

    The generic function expects BODY either be a string or a list.
    Attaching binary file (image, etc.) requires to encode it so the
    message will pass the message system.  So we /might/ use kind of a
    encoder (e.g. base64) on our own.

    Or, what seems a cleaner solution: Use attachment function of the
    respective MIME mode.  To achive this: Introduce third possibility
    for BODY: A cons with the filename in car and symbol of the
    function in cdr.

    (FILENAME . FUNCTION)


  '(image jpeg ("/path/to/image" . org-mail-htmlize-add-attachment))

    The function =org-mail-htmlize-add-attachment= is called with file
    name as argument and calls the appropriate function depending on
    =org-mail-htmlize-mime-lib= and returns a string

       - with the encoded body

         -or-

       - the complete MIME entity

    Side effect: The user might be prompted for attachment settings
    (e.g. encoding).  But, on the other hand: We delegate the job of
    creating the attachment to the library that is responsible for
    mime.

5 Quotes from the specs
~~~~~~~~~~~~~~~~~~~~~~~~

5.1 MIME multipart: Notion of structured, related body parts
=============================================================

  -  [RFC2046, 5.1.1]

ORG-BLOCKQUOTE-START
NOTE:  Conspicuously missing from the "multipart" type is a notion of
structured, related body parts. It is recommended that those wishing
to provide more structured or integrated multipart messaging
facilities should define subtypes of multipart that are syntactically
identical but define relationships between the various parts. For
example, subtypes of multipart could be defined that include a
distinguished part which in turn is used to specify the relationships
between the other parts, probably referring to them by their
Content-ID field.  Old implementations will not recognize the new
subtype if this approach is used, but will treat it as
multipart/mixed and will thus be able to show the user the parts that
are recognized.
ORG-BLOCKQUOTE-END

[RFC2046, 5.1.1]: http://tools.ietf.org/html/rfc2046.html#section-5.1.1

5.2 MIME multipart: order of entities inside a multipart
=========================================================

  - [RFC2046, 5.1.3]

ORG-BLOCKQUOTE-START
5.1.3.  Mixed Subtype

   The "mixed" subtype of "multipart" is intended for use when the body
   parts are independent and need to be bundled in a particular order.
   Any "multipart" subtypes that an implementation does not recognize
   must be treated as being of subtype "mixed".

ORG-BLOCKQUOTE-END

  - [RFC2046, 5.1.4]

ORG-BLOCKQUOTE-START
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.
ORG-BLOCKQUOTE-END

ORG-BLOCKQUOTE-START
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.
ORG-BLOCKQUOTE-END

[RFC2046, 5.1.3]: http://tools.ietf.org/html/rfc2046.html#section-5.1.3
[RFC2046, 5.1.4]: http://tools.ietf.org/html/rfc2046.html#section-5.1.4

[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode