Re: org-mime-htmlize: visual representation (thunderbird)

Re: org-mime-htmlize: visual representation (thunderbird)

[Uwe Brauer]

>> On Wed, 11 Apr 2012 00:23:54 -0400, Eric Schulte <eric.schulte@gmx.com> wrote:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> 
   >> Uwe 
   >> 

   > Hi Uwe,

   > Thanks for sending along this helpful review.  I've just pushed two
   > changes to org-mime so that it now (1) wraps html and images in a
   > multipart/related mime structure and (2) marks images as "disposition
   > inline" so that they don't show up as attachments.

Hi Eric, 

Thanks for your efforts. I have good and bad news. The bad
news is your changes make things worse in Thunderbird, for
reasons I don't understand the header of the resulting
messages reads:
Content-type: text/plain; charset=us-ascii
which is wrong and now png are displayed!

Which brings me to the good news. After I wrote to you I
received a message from  the TB developers  which emphasised
that, besides the information I have gave you, the main
point is the header, which should be 

  Content-type: multipart/related; boundary="=-=-="
 and the thunderbird developers insist that this is the 
 RFC 2387 standard.

Gnus actually generate  via the mml-generate-mime function
the header 
  Content-type: multipart/mixed; boundary="=-=-="
which is wrong.

I brought up the issue in the gnus mailing list and the
developers agreed that in the case of a html message with
png the Content-type should follow the RFC standard.

I checked this explicitly: your old code but with a different
mml-generate-mime function generates a message which is
correctly displayed in thunderbird and GMail and Ipod for
that manner. 

BTW I don't know how this issue, of the Content-type in the
header,  is treated in VM or Wanderlust.

Now the question is how to proceed:
I had the idea of introducing a new variable mml-mime-use-related and wrap it
into the mml-generate-mime code. Then org-mime-htmlize
should set this variable to t, and later a different
function should be added to the mail-send-hook setting the
variable to nil again.

Lars didn't like the idea and came up with a different
implementation. However I don't see how to use it easily. So
I include both solutions and let you decide which fits best
for org-mime-htmlize.
But as it is now you should undo your recent changes because
even with  the *new* mml-generate-mime function and your
*new* code the resulting mail is not displayed correctly in
TB.

I have now added lars and the ding mailing list to the CC.

Regards

Uwe 

My solution:
,----
| (defvar mml-mime-use-related t
| "*Variable to control whether to use `multipart/mixed' or `multipart/related'.")
| 
| (defun mml-generate-mime ()
|   "Generate a MIME message based on the current MML document."
|   (let ((cont (mml-parse))
| 		(mml-multipart-number mml-multipart-number))
|     (if (not cont)
| 		nil
|       (mm-with-multibyte-buffer
| 		(if (and (consp (car cont))
| 				 (= (length cont) 1))
| 			(mml-generate-mime-1 (car cont))
| 		  (if mml-mime-use-related
| 			  (mml-generate-mime-1 (nconc (list 'multipart '(type . "related"))
| 										  cont))
| 			(mml-generate-mime-1 (nconc (list 'multipart '(type . "mixed"))
| 										cont)))
| 	(buffer-string))))))
`----


Lars solution 

,----
| (defun mml-generate-mime (&optional multipart-type)
|   "Generate a MIME message based on the current MML document.
| MULTIPART-TYPE defaults to \"mixed\", but can also
| be \"related\" or \"alternate\"."
|   (let ((cont (mml-parse))
| 	(mml-multipart-number mml-multipart-number)
| 	(options message-options))
|     (if (not cont)
| 	nil
|       (prog1
| 	  (mm-with-multibyte-buffer
| 	    (setq message-options options)
| 	    (if (and (consp (car cont))
| 		     (= (length cont) 1))
| 		(mml-generate-mime-1 (car cont))
| 	      (mml-generate-mime-1
| 	       (nconc (list 'multipart (cons 'type (or multipart-type "mixed")))
| 		      cont)))
| 	    (setq options message-options)
| 	    (buffer-string))
| 	(setq message-options options)))))
`----

Re: org-mime-htmlize: visual representation (thunderbird)

[Eric Schulte]

[-- Attachment #1: Type: text/plain, Size: 956 bytes --]

Hi Uwe,

Uwe Brauer <oub@mat.ucm.es> writes:

>>> On Wed, 11 Apr 2012 00:23:54 -0400, Eric Schulte <eric.schulte@gmx.com> wrote:
>
>    > Uwe Brauer <oub@mat.ucm.es> writes:
>    >> 
>    >> Uwe 
>    >> 
>
>    > Hi Uwe,
>
>    > Thanks for sending along this helpful review.  I've just pushed two
>    > changes to org-mime so that it now (1) wraps html and images in a
>    > multipart/related mime structure and (2) marks images as "disposition
>    > inline" so that they don't show up as attachments.
>
> Hi Eric, 
>
> Thanks for your efforts. I have good and bad news. The bad
> news is your changes make things worse in Thunderbird, for
> reasons I don't understand the header of the resulting
> messages reads:
> Content-type: text/plain; charset=us-ascii
> which is wrong and now png are displayed!
>

OK, for my own edification I had changed the message body from
(I'm hoping these are sufficiently quoted to survive mailing)

,----[original]
| 

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

| 

[-- Attachment #2.2: Type: text/plain, Size: 26 bytes --]

|   text alternative...
| 

[-- Attachment #2.3: Type: text/html, Size: 26 bytes --]

[-- Attachment #3: Type: text/plain, Size: 75 bytes --]

|   images for html...
`----

to

,----[revised (and more broken in TB)]
| 

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

| 

[-- Attachment #4.2: Type: text/plain, Size: 26 bytes --]

|   text alternative...
| 

[-- Attachment #4.3: Type: text/html, Size: 2 bytes --]

[-- Attachment #4.4.1: Type: text/plain, Size: 49 bytes --]

|   html alternative...
|   images for html...
| 

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

| 

[-- Attachment #5: Type: text/plain, Size: 4520 bytes --]

`----

which wraps the html and images into a multipart/related type.

Why is this later structure illegal?  Are nested multi type parts not
allowed?  Also, it seems that everything I've tried works in gnus and in
most web user agents.  Is thunderbird simply a stickler for the letter
of the RFC law?

>
> Which brings me to the good news. After I wrote to you I
> received a message from  the TB developers  which emphasised
> that, besides the information I have gave you, the main
> point is the header, which should be 
>
>   Content-type: multipart/related; boundary="=-=-="
>  and the thunderbird developers insist that this is the 
>  RFC 2387 standard.
>
> Gnus actually generate  via the mml-generate-mime function
> the header 
>   Content-type: multipart/mixed; boundary="=-=-="
> which is wrong.
>

OK, I've just reverted my change, but I'm keeping the change of image
disposition to "inline".

>
> I brought up the issue in the gnus mailing list and the
> developers agreed that in the case of a html message with
> png the Content-type should follow the RFC standard.
>
> I checked this explicitly: your old code but with a different
> mml-generate-mime function generates a message which is
> correctly displayed in thunderbird and GMail and Ipod for
> that manner. 
>

OK.  Then I will assume that this issue is out of my hands and wait for
gnus to change its mime wrapping behavior upstream.

>
> BTW I don't know how this issue, of the Content-type in the
> header,  is treated in VM or Wanderlust.
>

I do my best to provide reasonable implementations for these other two
mailers and assume that if anything goes wrong then someone will submit
a bug report.

>
> Now the question is how to proceed:
> I had the idea of introducing a new variable mml-mime-use-related and wrap it
> into the mml-generate-mime code. Then org-mime-htmlize
> should set this variable to t, and later a different
> function should be added to the mail-send-hook setting the
> variable to nil again.
>
> Lars didn't like the idea and came up with a different
> implementation. However I don't see how to use it easily. So
> I include both solutions and let you decide which fits best
> for org-mime-htmlize.
> But as it is now you should undo your recent changes because
> even with  the *new* mml-generate-mime function and your
> *new* code the resulting mail is not displayed correctly in
> TB.
>
> I have now added lars and the ding mailing list to the CC.
>

While Lars' solution does look cleaner it is not clear to me how this
would be used from an external tool (such as org-mime) which does not
call `mml-generate-mime' explicitly, but rather relies on the normal
mailing process to handle these specifics.  Wouldn't it make the most
sense for the mailing process to inspect the email and set the
appropriate multipart type automatically.

Thanks,

>
> Regards
>
> Uwe 
>
> My solution:
> ,----
> | (defvar mml-mime-use-related t
> | "*Variable to control whether to use `multipart/mixed' or `multipart/related'.")
> | 
> | (defun mml-generate-mime ()
> |   "Generate a MIME message based on the current MML document."
> |   (let ((cont (mml-parse))
> | 		(mml-multipart-number mml-multipart-number))
> |     (if (not cont)
> | 		nil
> |       (mm-with-multibyte-buffer
> | 		(if (and (consp (car cont))
> | 				 (= (length cont) 1))
> | 			(mml-generate-mime-1 (car cont))
> | 		  (if mml-mime-use-related
> | 			  (mml-generate-mime-1 (nconc (list 'multipart '(type . "related"))
> | 										  cont))
> | 			(mml-generate-mime-1 (nconc (list 'multipart '(type . "mixed"))
> | 										cont)))
> | 	(buffer-string))))))
> `----
>
>
> Lars solution 
>
> ,----
> | (defun mml-generate-mime (&optional multipart-type)
> |   "Generate a MIME message based on the current MML document.
> | MULTIPART-TYPE defaults to \"mixed\", but can also
> | be \"related\" or \"alternate\"."
> |   (let ((cont (mml-parse))
> | 	(mml-multipart-number mml-multipart-number)
> | 	(options message-options))
> |     (if (not cont)
> | 	nil
> |       (prog1
> | 	  (mm-with-multibyte-buffer
> | 	    (setq message-options options)
> | 	    (if (and (consp (car cont))
> | 		     (= (length cont) 1))
> | 		(mml-generate-mime-1 (car cont))
> | 	      (mml-generate-mime-1
> | 	       (nconc (list 'multipart (cons 'type (or multipart-type "mixed")))
> | 		      cont)))
> | 	    (setq options message-options)
> | 	    (buffer-string))
> | 	(setq message-options options)))))
> `----
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/

Re: org-mime-htmlize: visual representation (thunderbird)

[Uwe Brauer]

>> On Wed, 11 Apr 2012 09:38:46 -0400, Eric Schulte <eric.schulte@gmx.com> wrote:

   > Hi Uwe,
   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> 

   > OK, for my own edification I had changed the message body from
   > (I'm hoping these are sufficiently quoted to survive mailing)

   > ,----[original]
   > | 
   > | 
   > |   text alternative...
   > | 
   > | html alternative... |

   > |   images for html...
   > `----

   > to

   > ,----[revised (and more broken in TB)]
   > | 
   > | 
   > |   text alternative...
   > | 
   > |

   > |   html alternative...
   > |   images for html...
   > | 
   > | 
   > `----

   > which wraps the html and images into a multipart/related type.

   > Why is this later structure illegal?  Are nested multi type parts not
   > allowed?  Also, it seems that everything I've tried works in gnus and in
   > most web user agents.  Is thunderbird simply a stickler for the letter
   > of the RFC law?


I cannot answer this. However I rechecked everything and the
issue is the following.
   >> 
   >> Which brings me to the good news. After I wrote to you
   >> I received a message from the TB developers which
   >> emphasised that, besides the information I have gave
   >> you, the main point is the header, which should be
   >> 
   >> Content-type: multipart/related; boundary="=-=-="
   >> and the thunderbird developers insist that this is the 
   >> RFC 2387 standard.
   >> 
   >> Gnus actually generate  via the mml-generate-mime function
   >> the header 
   >> Content-type: multipart/mixed; boundary="=-=-="
   >> which is wrong.
   >> 

   > OK, I've just reverted my change, but I'm keeping the change of image
   > disposition to "inline".


I own you an apology!  If I leave mml-generate-mime
untouched, that is I neither use my modification nor do I
use  use Lars new code, but  I use your *new* code then the
generated and sent message is displayed *correctly* in
thunderbird.

The resulting  message contains 

Content-type: multipart/alternative; boundary="=-=-="

Instead of 

Content-type: multipart/related; boundary="=-=-="

As it would in my case, but it seems that thunderbird is OK
with that.

The reason I wrote you earlier that your changes made things
worse was that I did make a mistake in my modification of
mml-generate-mime. I also thought I checked your code with
the old mml function but  for some reason the old version was
not used even after a restart.

Sorry for the trouble!

Uwe 

Re: org-mime-htmlize: visual representation (thunderbird)

[Eric Schulte]

Uwe Brauer <oub@mat.ucm.es> writes:

>>> On Wed, 11 Apr 2012 09:38:46 -0400, Eric Schulte <eric.schulte@gmx.com> wrote:
>
>    > Hi Uwe,
>    > Uwe Brauer <oub@mat.ucm.es> writes:
>    >> 
>
>    > OK, for my own edification I had changed the message body from
>    > (I'm hoping these are sufficiently quoted to survive mailing)
>
>    > ,----[original]
>    > | 
>    > | 
>    > |   text alternative...
>    > | 
>    > | html alternative... |
>
>    > |   images for html...
>    > `----
>
>    > to
>
>    > ,----[revised (and more broken in TB)]
>    > | 
>    > | 
>    > |   text alternative...
>    > | 
>    > |
>
>    > |   html alternative...
>    > |   images for html...
>    > | 
>    > | 
>    > `----
>
>    > which wraps the html and images into a multipart/related type.
>
>    > Why is this later structure illegal?  Are nested multi type parts not
>    > allowed?  Also, it seems that everything I've tried works in gnus and in
>    > most web user agents.  Is thunderbird simply a stickler for the letter
>    > of the RFC law?
>
>
> I cannot answer this. However I rechecked everything and the
> issue is the following.
>    >> 
>    >> Which brings me to the good news. After I wrote to you
>    >> I received a message from the TB developers which
>    >> emphasised that, besides the information I have gave
>    >> you, the main point is the header, which should be
>    >> 
>    >> Content-type: multipart/related; boundary="=-=-="
>    >> and the thunderbird developers insist that this is the 
>    >> RFC 2387 standard.
>    >> 
>    >> Gnus actually generate  via the mml-generate-mime function
>    >> the header 
>    >> Content-type: multipart/mixed; boundary="=-=-="
>    >> which is wrong.
>    >> 
>
>    > OK, I've just reverted my change, but I'm keeping the change of image
>    > disposition to "inline".
>
>
> I own you an apology!  If I leave mml-generate-mime
> untouched, that is I neither use my modification nor do I
> use  use Lars new code, but  I use your *new* code then the
> generated and sent message is displayed *correctly* in
> thunderbird.
>
> The resulting  message contains 
>
> Content-type: multipart/alternative; boundary="=-=-="
>
> Instead of 
>
> Content-type: multipart/related; boundary="=-=-="
>
> As it would in my case, but it seems that thunderbird is OK
> with that.
>
> The reason I wrote you earlier that your changes made things
> worse was that I did make a mistake in my modification of
> mml-generate-mime. I also thought I checked your code with
> the old mml function but  for some reason the old version was
> not used even after a restart.
>
> Sorry for the trouble!
>
> Uwe 
>

Hi Uwe,

No problem at all.  I just reverted by reversion in git, so if I read
this email correctly everything should be working now in TB.  Please let
me know if this is not the case.

Thanks,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/