From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: using orgmode to send html mail? Date: Fri, 26 Mar 2010 10:32:10 -0600 Message-ID: <874ok311t9.fsf@gmail.com> References: <878w9krtyn.wl%dmaus@ictsoc.de> <871vfa24qo.fsf@gmail.com> <87pr2uww2d.fsf@columbia.edu> <87tys5zrwm.fsf@gmail.com> <87sk7pzk02.fsf@stats.ox.ac.uk> <87tys5r3q6.fsf@gmail.com> <87ocid7cuj.wl%dmaus@ictsoc.de> <874ok5qxp9.fsf@gmail.com> <87vdckksnj.wl%dmaus@ictsoc.de> <874ok33zje.fsf@gmail.com> <87zl1vf4ru.wl%dmaus@ictsoc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvCSV-0007jL-7E for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 12:32:31 -0400 Received: from [140.186.70.92] (port=33290 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvCSS-0007iY-Qv for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 12:32:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvCSN-0002t2-Lo for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 12:32:28 -0400 Received: from mail-qy0-f182.google.com ([209.85.221.182]:63614) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvCSN-0002sM-Bb for emacs-orgmode@gnu.org; Fri, 26 Mar 2010 12:32:23 -0400 Received: by qyk12 with SMTP id 12so7087828qyk.5 for ; Fri, 26 Mar 2010 09:32:22 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: David Maus Cc: Dan Davison , emacs-orgmode@gnu.org Hi David, David Maus 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