org-msg

org-msg copied to clipboard

Hi, I'm having a problem when I forward a message. the message appears to be ok, with the properties and options, etc.. and at the end there are the parts of the attachments. But when you send it, no attachs are recived.

<#part type="application/vnd.openxmlformats-officedocument.wordprocessingml.document" filename="/tmp/mu-1000/f2d52db4/3/No preselecci\303\263n.docx" disposition=attachment>
<#/part>
<#part type="application/vnd.openxmlformats-officedocument.wordprocessingml.document" filename="/tmp/mu-1000/f2d52db4/4/Preselecci\303\263n.docx" disposition=attachment>
<#/part> 

If I toggle the org-msg-mode and activate the mu4e:compose mode all works.

Any ideas?

Mu version is 1.4.15

SYSTEM  info       (Linux Mint 20.1 . Linux 5.4.0-65-generic x86_64)
        shell      /bin/bash
        path       (~/.nvm/versions/node/v14.15.4/bin ~/.config/vifm/scripts ~/.emacs.d/phpactor/vendor/bin ~/.cargo/bin ~/.cargo/bin ~/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin /opt/mssql-tools/bin /usr/bin/php ~/.local/bin /snap/bin /usr/lib/emacs/27.1/x86_64-linux-gnu/)
EMACS   dir        ~/.emacs.d/
        version    (27.1 Sep 19, 2020)
        buildopts  --build=x86_64-linux-gnu --prefix=/usr '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp --program-suffix=27 --with-modules --with-file-notification=inotify --with-mailutils --with-harfbuzz --with-json --with-x=yes --with-x-toolkit=gtk3 --with-lcms2 --with-cairo --with-xpm=yes --with-gif=yes --with-gnutls=yes --with-jpeg=yes --with-png=yes --with-tiff=yes --with-xwidgets 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/emacs27-bifpWT/emacs27-27.1~1.git86d8d76aa3=. -fstack-protector-strong -Wformat -Werror=format-security -no-pie' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -no-pie'
        features   XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS XWIDGETS LIBSYSTEMD JSON PDUMPER LCMS2 GMP
        traits     (gui server-running envvar-file)
DOOM    dir        ~/.doom.d/
        version    (2.0.9 HEAD -> develop 5e8a66831 2021-02-14 21:14:07 -0500)
        font       #<font-spec nil nil Mononoki Nerd Font nil nil nil nil nil 15 nil nil nil nil>
        theme      doom-gruvbox
        modules    (:completion company ivy :ui deft doom doom-dashboard doom-quit hl-todo indent-guides modeline ophints (popup +defaults) treemacs vc-gutter vi-tilde-fringe workspaces :editor (evil +everywhere) file-templates fold multiple-cursors snippets :emacs dired electric undo vc :term eshell vterm :checkers syntax (spell +flyspell) :tools (eval +overlay) (lookup +devdocs +docsets) lsp magit pass pdf :lang common-lisp data emacs-lisp javascript ledger markdown (org +export) (php +lsp) (python +lsp) sh web yaml :email (mu4e +gmail) :config (default +bindings +smartparens))
        packages   ((org-super-agenda) (org-mime) (org-fancy-priorities) (rainbow-mode) (todotxt) (phpactor) (php-cs-fixer) (helm-bibtex) (org-ref) (org-noter-pdftools) (telega :recipe (:host github :repo zevlg/telega.el)) (w3m))
        unpin      (n/a)
        elpa       (n/a)

It seems to me that the problem is that org-msg does not handle the MML declarations. The easy workaround is not to activate org-msg is this case. A better solution (but requiring a lot more coding) is to transform the MML that is present to org-mode. Another one is to localize org-msg to a MML <#part > ... <#/part> (leaving untouched those already present).

@cnoceda and @Chris00, I have pushed some patches on the experimental branch to support MML tags. It works for me when I forward an email with gnus. Could you give it a try?

Hi, first of all, thanks for the patch. I use doom-emacs, so I replace de org-msg.el in the doom repo for the experimental version. The problem persisit, in the forward window the attachments appear, but not in the destination mailbox.

From: Carlos Noceda <[email protected]>
To: 
Date: Wed, 05 May 2021 07:21:14 +0200
Subject: Fwd:  PRESENTACIÓN Avaya SpacesT - Solución Videollamada
--text follows this line--
#+OPTIONS: html-postamble:nil toc:nil author:nil email:nil d:nil
#+STARTUP: inlineimages
:PROPERTIES:
:reply-to: ("/tmp/[email protected]")
:attachment: nil
:alternatives: (html text)
:END:

This is a test mail.

--citation follows this line (read-only)--
Iel Goez <[email protected]> writes:

⚠ EXTERNAL EMAIL   

Hola Carlos:

Somos Avaya, empresa internacional especializada en Telefonía IP y expertos en soluciones de Comunicaciones Unificadas y Contact Centers que ayudan a optimizar los resultados de pequeñas y medianas empresas. 

Estamos contactando con empresas como la suya para dar a conocer  Avaya Spaces™ , Una solución de video en la nube para conectar  personal de manera remota, segura y efectiva.

Nuestra robusta aplicación de reuniones y colaboración basada en la nube integra chat, voz, video, reuniones en línea y el intercambio de contenidos, de modo que los equipos puedan coordinar el trabajo y reunirse de forma segura utilizando un navegador web o una
aplicación móvil. 

Características:

Esperamos tu respuesta 

Recibe un cordial saludo
Isabel González Dpto. Marketing  | Avaya  | |+346
,*

[4. application/pdf; BR-VIDEO-CONSULTING-CL15568ES-V2.pdf]...

<#part type="image/jpeg" filename="/tmp/mu-1000/100ea1a8/3/image002.jpg" disposition=attachment>
<#/part>
<#part type="application/pdf" filename="/tmp/mu-1000/100ea1a8/4/BR-VIDEO-CONSULTING-CL15568ES-V2.pdf" disposition=attachment>
<#/part>

I delete some text.

As you see the attachment seems to be there, but not in destination.

Sorry and thanks again

I am not convinced you are running the experimental branch version. Could you double check?

On Tue, May 4, 2021, 10:28 PM cnoceda @.***> wrote:

Hi, first of all, thanks for the patch. I use doom-emacs, so I replace de org-msg.el in the doom repo for the experimental version. The problem persisit, in the forward window the attachments appear, but not in the destination mailbox. `From: Carlos Noceda @.*** To: Date: Wed, 05 May 2021 07:21:14 +0200 Subject: Fwd: PRESENTACIÓN Avaya SpacesT - Solución Videollamada --text follows this line-- #+OPTIONS: html-postamble:nil toc:nil author:nil email:nil d:nil #+STARTUP: inlineimages :PROPERTIES: :reply-to: @.***") :attachment: nil :alternatives: (html text) :END:

This is a test mail.

--citation follows this line (read-only)-- Iel Goez @.*** writes:

⚠ EXTERNAL EMAIL

Hola Carlos:

Somos Avaya, empresa internacional especializada en Telefonía IP y expertos en soluciones de Comunicaciones Unificadas y Contact Centers que ayudan a optimizar los resultados de pequeñas y medianas empresas.

Estamos contactando con empresas como la suya para dar a conocer Avaya Spaces™ , Una solución de video en la nube para conectar personal de manera remota, segura y efectiva.

Nuestra robusta aplicación de reuniones y colaboración basada en la nube integra chat, voz, video, reuniones en línea y el intercambio de contenidos, de modo que los equipos puedan coordinar el trabajo y reunirse de forma segura utilizando un navegador web o una aplicación móvil.

Características:

Esperamos tu respuesta

Recibe un cordial saludo Isabel González Dpto. Marketing | Avaya | |+346 ,*

[4. application/pdf; BR-VIDEO-CONSULTING-CL15568ES-V2.pdf]...

<#part type="image/jpeg" filename="/tmp/mu-1000/100ea1a8/3/image002.jpg" disposition=attachment> <#/part> <#part type="application/pdf" filename="/tmp/mu-1000/100ea1a8/4/BR-VIDEO-CONSULTING-CL15568ES-V2.pdf" disposition=attachment> <#/part> ` I delete some text.

As you see the attachment seems to be there, but not in destination.

Sorry and thanks again

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jeremy-compostella/org-msg/issues/86#issuecomment-832421442, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMACBEIKIP7AI4NI4UGHCLTMDJQVANCNFSM4X2IARFA .

You were rigth! The attachments are sent, but now the read only part is not good, you see:

From: C <[email protected]>
To: 
Date: Wed, 05 May 2021 08:13:39 +0200
Subject: Fwd: Propuesta Mic
--text follows this line--
#+OPTIONS: html-postamble:nil toc:nil author:nil email:nil d:nil
#+STARTUP: inlineimages
:PROPERTIES:
:reply-to: nil
:attachment: nil
:alternatives: (html text)
:END:
Test
Aojie <[email protected]> writes:

> Hola,

Before Aojie, and the message in destination is in wrong dformat.

Test Aojie <[email protected]> writes:

> Hola, > > > > Os paso los precios PVP que nos ha facilitado M. > > > > Saludos > > > > Aojie  > > DPTO. COMPRAS CORPORATIVAS - COMPRADOR ESPECIALISTA > > CORPORATE PURCHASING DEPARTMENT – SPECIALIST BUYER > > > > cid:[email protected] > > > >

The attachments are good.

The "forward" content generated by mu4e seems odd to me. It should generate a message/rfc822 type attachement. It seems like you were expecting some sort of top-posting reply including the attachment of the email you are forwarding. Try the following hack which I believe should work for you:

modified   org-msg.el
@@ -1132,8 +1132,7 @@ address or tweak the signature when replying with plain text
 email."
   `((style . ,(when (and (eq type 'reply-to-html)
 			 (memq 'html alternatives)
-			 (not (= (point) (point-max)))
-			 (not (org-msg-has-mml-tags)))
+			 (not (= (point) (point-max))))
 		org-msg-posting-style))
     (greeting-fmt . ,org-msg-greeting-fmt)
     (signature . ,org-msg-signature)))

By the way I noticed that you have the alternatives set to (html text). It should usually (text html) as the high priority should be given to the richest format. Also, your org mode configuration seems to not keep the line break of the message. Have a look at my default configuration in the documentation (README.org).

Hi Jeremy, using the default configuration works perfect.

Thank you very much for your time.

using the default configuration works perfect.

I suppose that you mean the mu4e default configuration right ?

@Chris00 could you also give it a try ?

Hi @jeremy-compostella I test the last code change too and work perfect

thanks again!

I can confirm that the issue is fixed when running the experimental branch on Doom Emacs. Thank you very much, @jeremy-compostella.

@Chris00 could you also give it a try ?

I'll try to do that this weekend.

With commit 97b3ae2, OrgMsg was hanging when a citation such as

On 17 May 2021 at 09:32 +02, x <[email protected]> wrote: > Citation

is present. It seems to be OK with commit 5392995 but I'm just starting experimenting with it, I'll report if I encounter problems.

Replying to iCal events works (from my simple testing; text mode is used). Note however that the first line in

<#/part>

is not properly highlighted.

P.S. With commit 5392995, #+begin_example ... #+end_example is transformed into #+begin_quote0 ... #+end_quote0 which is left in the HTML message.

BTW, being able to insert attachments with mml-attach-file is convenient as I just needed to attach a Matlab file and specifying the type x-matlab with OrgMsg does not seem possible.

@Chris00,

P.S. With commit 5392995, #+begin_example ... #+end_example is transformed into #+begin_quote0 ... #+end_quote0 which is left in the HTML message.

I don't reproduce this issue. Do you reproduce with a fresh emacs ?

I don't reproduce this issue. Do you reproduce with a fresh emacs ?

Well, it must have been an effect of my experimentation because I cannot reproduce it anymore.

Composing this message, I realized that the following situation — while fairly rare — leads to unexpected results (with “⟨” replaced with “<” and “⟩” with “>”). The highlighting suggests that it will be quoted but it is actually interpreted as MML.

#+begin_example ⟨#part type="text/calendar; method=REPLY; charset=utf-8" buffer="CAL"⟩ ⟨#/part⟩ #+end_example

IMHO, giving MML highlighting higher priority and implementing MML quoting (https://www.gnu.org/software/emacs/manual/html_node/emacs-mime/MML-Definition.html) <#! solves the problem.

@Chris00 I just pushed two patches on the experimental branch which should address these two minor issues.

I think this can be closed; inline MML parts seem to work for me on master.

For me too. The only thing is that their order is reversed during their processing (not a big deal but may be annoying).