Re: Creating HTML emails with mutt
Regarding the following, written by “José María Mateos” on 2019-10-25 at 18:32 Uhr -0400: If you want to accomplish this, wouldn’t it be enough not to wrap the text? That way the client/screen will do its own wrapping, no need to go the HTML way. That would indeed take care of the extraneous line breaks. However, when I wrote “given how email has evolved”, I’m also talking about the kind of information that is being conveyed, which often isn’t plain-text anymore. For instance, being able to send links, some markup, and tables, in an email (rather than having to resort to an attachment) has its benefits. -- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net the reason that every major university maintains a department of mathematics is that it's cheaper than institutionalizing all those people. spamtraps: madduck.bo...@madduck.net
Re: Creating HTML emails with mutt
On Sat, 26 Oct 2019 11:16:25 +1300 martin f krafft wrote: > In any case, given how email has changed in the last 20 years, and how > text/plain messages are causing display issues across different device types > (e.g. they are not “responsive”) If you want to accomplish this, wouldn't it be enough not to wrap the text? That way the client/screen will do its own wrapping, no need to go the HTML way. Cheers, -- José María (Chema) Mateos || https://rinzewind.org/
Creating HTML emails with mutt
Folks, I need to start sending out text/html alternative parts to my messages with mutt. However, this is a rabbit hole, so if you’re afraid of those, stop reading now. My requirements are, in decreasing order of priority: Compatible with all Gmail, Outlook, Hotmail, Apple Mail, Thunderbird, and whatever else many people are using these days. Markdown processing of text/plain multipart/alternative result, MIME compliant Attachments Sensible integration with mutt PGP signatures Inline images and after surveying the field, and spending hours with the solutions I found during various web searches, I am writing in to you for some feedback, input, guidance, psycological help, and maybe even some hugs. Since I expect (hope) there to be some insights gained from our discussion, I am going to keep updating an online version of this text. The main question for me is: when and how is the best way to add that HTML part such that messages can be signed, encrypted, and attachments are available to all viewers? What is the problem I’m trying to solve? My current solution1, which runs as part of the $sendmail pipeline and thus converts the message as sent by mutt to a message with a MIME tree as follows: I 1[multipa/alternativ, 7bit, 111K] I 2 ├─>[multipa/signed, 7bit, 110K] I 3 │ ├─> [multipa/mixed, 7bit, 109K] I 4 │ │ ├─>[text/plain, quoted, utf-8, 0,4K] A 5 │ │ └─>Brochure.pdf[applica/pdf, base64, 108K] I 6 │ └─>PGP signature [applica/pgp-signat, 7bit, 1,1K] I 7 └─>[text/html, quoted, utf-8, 0,7K] This works fine with mutt, obviously, and Gmail also seems to be okay with it, but Thunderbird doesn’t give access to the attachments, and in a way that makes sense, because I am advertising the text/html part that contains no attachments as a better alternative (better because later in the tree, cf. RFC 1341) to the whole multipart/signed container. The reason for that, rather than wrapping the text/plain part in a multipart/alternative container, and slap the text/html part into there is simply that then the PGP signature would be invalidated. The signature also gets invalidated, if I moved the attachments out like this: multipart/mixed ├─>multipart/alternative │ ├─>multipart/signed │ │ ├─>text/plain │ │ └─>application/pgp-signature │ └─>text/html └─>application/pdf So in order to make the text/html part a true alternative, it needs to be converted into a multipart/mixed part encompassing the text/html, as well as the attachment. But given that MIME doesn’t have pointers or “symlinks”, allowing me to reference other parts of the tree, the only way to do this from here on (without rethinking how I’m approaching this, more on that below) would be to duplicate the attachments into a multipart/mixed part wrapping the text/html alternative. And that’d be a terrible waste of resources, and would hit max-size limits on SMTP transactions a lot more often. What are some other solutions you’ve considered? Converting text to HTML prior to sending There are plenty of solutions that filter the text/plain part once created in mutt, and turn it into HTML, replacing the text/plain part with a text/html part. This is not good enough, because I often remember something to change at the very last minute, and I also don’t want to keep just-HTML mails in my sent-mail, because I often use commands like resend-message, which would then fire up Vim on the text/html content in my setup. Not signing/encrypting messages If I do not sign messages, my tool does the right thing. However, this comes with the price tag that I no longer get to sign my messages, which I’ve done pretty consistently for 25 years. This is not really an option. Obviously, encrypting messages in mutt also won’t work, because then the Markdown processor cannot actually obtain the text/plain part. Signing/encrypting messages after post-processing Conceivably, I could convert a multipart/alternative into a signed or encrypted message after my script processes the text/plain part and adds the text/html alternative. It’s even conceivable that I use mutt’s pgp_sign_command not to sign, but instead add metadata that I can use later in the pipe to do the actual PGP operation non-interactively, but I suspect that this will get messy very quickly. What does the ideal solution look like? It would of course be ideal if mutt gave me a means to post-process an entire message after writing it to the $record folder, and before it invokes the interactive PGP stuff on it. This probably won’t be terribly hard to implement, but I haven’t even looked at the source code yet. A central question is whether mutt should save the multipart/alternative message, i.e. including the text/html part to the sent folder ($record), or whether the auto-generated text/html part should only be added to the outgoing message. This probably needs to be made configurable, as some people will want it one way, and others another. On this note,
Re: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 10:42:28AM +0100, Chris Green wrote: mutt_dotlock is failing when I try and lock the file across the sshfs file system:- The last time I looked, sshfs's hard link support was insufficient for dotlocking. I believe the hard link count is not increased, (in addition to creating a new inode number for the link). Even if it were implemented, I personally wouldn't risk my mbox files over sshfs. Mutt 1.11.0 added a hard link fix for Maildir over sshfs. If you do try Maildir you'll want to either upgrade or disable hardlink support in the sshfs mount. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: File locking on sshfs file system, possible?
October 25, 2019 5:42 PM, "Chris Green" wrote:
> Even more information!
>
> mutt_dotlock is failing when I try and lock the file across the
> sshfs file system:-
>
> chris@t470$ mutt_dotlock /home/chris/Mail/folder/test/fred
> chris@t470$ echo $?
> 1
> chris@t470$
>
> (The folder Mail is an sshfs mount)
>
> There is no permission problem for me to create files:-
>
> chris@t470$ ls -al /home/chris/Mail/folder/test
> total 8
> drwxrwxr-x 1 chris chris 4096 Oct 25 10:38 .
> drwxrwxr-x 1 chris chris 4096 Oct 25 10:35 ..
> -rw-rw-r-- 1 chris chris 0 Oct 25 10:25 fred
> chris@t470$ touch /home/chris/Mail/folder/test/fred.lock
> chris@t470$ ls -al /home/chris/Mail/folder/test
> total 8
> drwxrwxr-x 1 chris chris 4096 Oct 25 10:40 .
> drwxrwxr-x 1 chris chris 4096 Oct 25 10:35 ..
> -rw-rw-r-- 1 chris chris 0 Oct 25 10:25 fred
> -rw-rw-r-- 1 chris chris 0 Oct 25 10:40 fred.lock
> `
> So how do I diagnose what the actual error is? Is mutt_dotlock trying
> to run as 'mail' rather than 'chris'?
I wonder if strace(1) could help you
('Cause it was suggested for finding Why Evince couldn't read files like
~/.mutt/file.pdf in this mailing list.)
--
旋转少女
Re: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 10:14:28AM +0100, Chris Green wrote: > On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote: > > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main > > mail directory ~/Mail using sshfs and running a local copy of mutt. > > This makes handling attachments and HTML E-Mail much faster and easier > > than running mutt on the remote system via ssh. > > > > However when I try and save E-Mails into the ~/Mail hierarchy it > > complains that it can't lock the mbox file. I guess that there's some > > sort of incompatibility between mutt's default locking method and > > sshfs. > > > > Is there anything I can do about this? I.e. can I build mutt with a > > different locking method (or more the point the dotlock program I > > suppose) or am I basically stuck? I know I could move to maildir but > > I'd prefer not to really and that would likely slow things down across > > an sshfs connection. > > > A little more information:- > > I'm running mutt 1.10.1 on xubuntu 19.04 > > The actual error I'm seeing is "Couldn't lock > /home/chris/Mail/folder/test" > (Obviously changes according to name of destination mbox) > > So is it not a locking problem, rather a permission problem? My UID > on both systems is the same so files in the ~/Mail directory are all > owned by me on both systems. > Even more information! mutt_dotlock is failing when I try and lock the file across the sshfs file system:- chris@t470$ mutt_dotlock /home/chris/Mail/folder/test/fred chris@t470$ echo $? 1 chris@t470$ (The folder Mail is an sshfs mount) There is no permission problem for me to create files:- chris@t470$ ls -al /home/chris/Mail/folder/test total 8 drwxrwxr-x 1 chris chris 4096 Oct 25 10:38 . drwxrwxr-x 1 chris chris 4096 Oct 25 10:35 .. -rw-rw-r-- 1 chris chris0 Oct 25 10:25 fred chris@t470$ touch /home/chris/Mail/folder/test/fred.lock chris@t470$ ls -al /home/chris/Mail/folder/test total 8 drwxrwxr-x 1 chris chris 4096 Oct 25 10:40 . drwxrwxr-x 1 chris chris 4096 Oct 25 10:35 .. -rw-rw-r-- 1 chris chris0 Oct 25 10:25 fred -rw-rw-r-- 1 chris chris0 Oct 25 10:40 fred.lock ` So how do I diagnose what the actual error is? Is mutt_dotlock trying to run as 'mail' rather than 'chris'? -- Chris Green
Re: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote: > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main > mail directory ~/Mail using sshfs and running a local copy of mutt. > This makes handling attachments and HTML E-Mail much faster and easier > than running mutt on the remote system via ssh. > > However when I try and save E-Mails into the ~/Mail hierarchy it > complains that it can't lock the mbox file. I guess that there's some > sort of incompatibility between mutt's default locking method and > sshfs. > > Is there anything I can do about this? I.e. can I build mutt with a > different locking method (or more the point the dotlock program I > suppose) or am I basically stuck? I know I could move to maildir but > I'd prefer not to really and that would likely slow things down across > an sshfs connection. > A little more information:- I'm running mutt 1.10.1 on xubuntu 19.04 The actual error I'm seeing is "Couldn't lock /home/chris/Mail/folder/test" (Obviously changes according to name of destination mbox) So is it not a locking problem, rather a permission problem? My UID on both systems is the same so files in the ~/Mail directory are all owned by me on both systems. -- Chris Green
File locking on sshfs file system, possible?
I just tried running mutt 'remotely' by mounting ~/.muttrc and my main mail directory ~/Mail using sshfs and running a local copy of mutt. This makes handling attachments and HTML E-Mail much faster and easier than running mutt on the remote system via ssh. However when I try and save E-Mails into the ~/Mail hierarchy it complains that it can't lock the mbox file. I guess that there's some sort of incompatibility between mutt's default locking method and sshfs. Is there anything I can do about this? I.e. can I build mutt with a different locking method (or more the point the dotlock program I suppose) or am I basically stuck? I know I could move to maildir but I'd prefer not to really and that would likely slow things down across an sshfs connection. -- Chris Green
