Re: Visualising contents of a Maildir

[martin f krafft via Mutt-users]

Regarding the following, written by "Victor Goff" on 2022-08-18 at 20:09 Uhr 
-0400:
I have used https://tmate.io for those on Windows and those with a small 
amount of experience with computers in general.  Since you can share a 
browser, and they can either type with you or not, and they do not 
necessarily need to even generate ssh keys, this is a point of allowing 
that to happen easily.


Nice, but this isn't going to be a live presentation, so it really 
has to be a PDF.


--
@martinkrafft | https://matrix.to/#/#madduck:madduck.net
 
in the beginning was the word,

and the word was content-type: text/plain
 
spamtraps: madduck.bo...@madduck.net

Re: Visualising contents of a Maildir

[martin f krafft via Mutt-users]

Regarding the following, written by "Derek Martin" on 2022-08-18 at 15:23 Uhr 
-0500:
If this is all you need to do, then, do you really need to preserve 
the threading?


Excellent point, and the answer is no. It helps with:


enough info to demonstrate their uniqueness.


but I can just throw the Message-ID in there as well. Confuse them a 
bit ;)


Threading visualised would just make it visually more appealing and 
clearer. But it is certainly not required, and heck: most people in 
the Windows world don't even understand what it is. :rofl:


But damn you for mentioning formail. You know I'll now hack together 
a one-liner trial-and-error-style, rather than just to sit down and 
do it in Python, which might take longer, but will be infinitely 
better in the long run.


Thanks,
-m

PS: (signature randomly chosen)

--
@martinkrafft | https://matrix.to/#/#madduck:madduck.net
 
(on the statement print "42 monkeys"+"1 snake") btw,

both perl and python get this wrong.
perl gives 43 and python gives "42 monkeys1 snake",
when the answer is clearly "41 monkeys and 1 fat snake".
   -- jim fulton
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Visualising contents of a Maildir

[martin f krafft via Mutt-users]

Regarding the following, written by "Bastian" on 2022-08-18 at 14:48 Uhr +0200:
1981% mutt > /dev/shm/o 
 *blindly pressing q* 
bastian@t6l ~ 
1982% wc /dev/shm/o 
  1  599 6251 /dev/shm/o


```
lotus:/dev/shm% mutt > /dev/shm/mutt || echo $? 
  #(pts/3) 18 17:51:11.605
1
```

--
@martinkrafft | https://matrix.to/#/#madduck:madduck.net
 
why didn't noah swat those two mosquitoes?
 
spamtraps: madduck.bo...@madduck.net

Re: Visualising contents of a Maildir

[martin f krafft via Mutt-users]

Regarding the following, written by "Christian Brabandt" on 2022-08-18 at 13:15 
Uhr +0200:
I wonder if you can make use of public-inbox, which is e.g. used to 
create the git mailinglist archive. It's not pretty, but generates a 
threaded mail archive from a Maildir, IIRC. Not sure how easy enough it 
is to add date and from header


https://github.com/nojb/public-inbox


Also a good idea! Mail archivers!

--
@martinkrafft | https://matrix.to/#/#madduck:madduck.net
 
"when a gentoo admin tells me that the KISS principle is good for

 'busy sysadmins', and that it's not an evolutionary step backwards,
 i wonder whether their tape is already running backwards."
 
spamtraps: madduck.bo...@madduck.net

Re: Visualising contents of a Maildir

[martin f krafft via Mutt-users]

Regarding the following, written by "Bastian" on 2022-08-18 at 11:41 Uhr +0200:
--- paste: 
% LINES=10 COLUMNS=1 mutt $OPTIONS > maildir.out 
--- eop


This does not generate any output for me, i.e. the generated file is 
empty.


--
@martinkrafft | https://matrix.to/#/#madduck:madduck.net
 
chaos reigns within.

reflect, repent, reboot.
order shall return.
 
spamtraps: madduck.bo...@madduck.net

Re: Visualising contents of a Maildir

[martin f krafft via Mutt-users]

Regarding the following, written by "Marcus C. Gottwald" on 2022-08-18 at 09:53 
Uhr +0200:
So, if one of these output formats would be a step forward, and you 
found a way to make an xterm window enormously large,


Not a bad idea to use the screendump functionality of X terminals. 
But I am talking thousands of lines… doubt this will work, but if it 
does, I'll report back.


--
@martinkrafft | https://matrix.to/#/#madduck:madduck.net
 
fighting for peace is like screwing for virginity.

   -- the irish times, washington dc
 
spamtraps: madduck.bo...@madduck.net

Re: Visualising contents of a Maildir

[martin f krafft via Mutt-users]

Thanks for your responses so far!

The reason I need this index is that I have to provide evidence of 
"a huge volume of mails" on a given topic, without actually sharing 
the emails. So I need a PDF index. Hence I thought making an HTML 
table, and then printing that. Easiest.


A screenshot/bitmap approach would be very hard to turn into a 
useable PDF, I think.


Sam is right, threads are digraphs, but Mutt displays them in a 
table, and I think that's a good compromise.


I don't think it will be better or easier than what you've done.  But 
you could try using a '|' filter in $index_format to append some 
output to a file as a side effect.  It would still entail manually 
pgdn'ing through the index.


Not a bad idea, but unfortunately, the Unicode characters used to 
represent threads in mutt's index seem to be some sort of 
ncurses-special, and the whole thing would need parsing. But this is 
definitely an interesting approach, as I could probably craft an 
`$index_format` that generates HTML ``'s, and PgDn'ing over a 
thousand messages might be something the X repeat buffer can do. ;)


I knew why I'd ask here! ;)

Thanks,

--
@martinkrafft | https://matrix.to/#/#madduck:madduck.net
 
"i worked myself up from nothing to a state of extreme poverty."

 -- groucho marx
 
spamtraps: madduck.bo...@madduck.net

Visualising contents of a Maildir

[martin f krafft via Mutt-users]

Folks,

This isn't really a Mutt question, but you're the kind of people 
that most likely would have good answers on the following:


For reasons you don't want to know, I have to visualise a Maildir 
with a couple of thousand messages, i.e. essentially provide a 
mutt-style index with correspondents, dates, subjects, and 
threading, ideally in form of an HTML table.


Apart from the threading, Python's email module can do most of the 
work, and combined with e.g. Jinja templating, I should be able to 
get results quickly, but since I don't like reinventing wheels, I 
was wondering if maybe you had a better idea?


Is there a way to "screenshot" the Mutt index beyond the scroll 
window?


Or can you think of command-line tools that visualise threads? 
Notmuch, which I use, can very quickly list all the threads, 
including the count of messages, but I actually need to list to be 
*really big* and not condensed, for reasons you don't want to know. 

I can make notmuch output json with threading, and then process that 
with Python to create a list, but maybe there's a better tool?


Thanks for your time,

--
@martinkrafft | https://matrix.to/#/#madduck:madduck.net
 
"if one cannot enjoy reading a book over and over again,

 there is no use in reading it at all."
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net

Parsing URLs (was: Xterm/urxvt for mutt)

[martin f krafft]

Hey there,

Even with a good XTerm config, ncurses still gets in the way of long 
URLs, and the sidebar patch completely breaks them. I don't think 
this can be solved from the xterm, and requires either an external 
tool such as urlview/urlscan (which break the flow), or would need 
to be done within mutt, in similar ways to what plugins do for 
irssi:


1. internal pager scans content for URLs, marks them up with unique 
   identifiers, e.g. `[1]https://mutt.org` or similar;


2. mutt learns a command `view-url-by-id`, which prompts for a 
   number and spawns mailcap on the URL.


3. Additional or alternative commands could be:

   `view-urls`

   : Print a list of URLs from the current buffer, maybe with 
 navigation options like urlview


   `select-url`

   : Highlight the first URL in view, skip to prev/next on up/down 
 arrow, and invoke mailcap when enter is pressed.


Probably not too hard. But yeah, would need to be done… ;)

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"one should never allow one's mind

 and one's foot to wander at the same time."
  -- edward perkins (yes, the librarian)
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Xterm/urxvt for mutt (was: Rendering HTML as Markdown in mutt)

[martin f krafft]

Sorry, I have no specific advice -- I got my xterm set up years ago 
and haven't touched the settings in a long time.


I can recommend rxvt-unicode, which is basically xterm on steroids 
with a lot of useful extensions, such as allowing me to open URLs 
with the keyboard (ctrl-enter and ctrl-shift-enter), interactive 
clipboard/selection (ctrl-rightclick) manipulation, termshots 
(PrintScr), searching (alt-ctrl-s), and more.


If anyone is interested, my config is here: 
https://git.madduck.net/etc/xsession.git/blob/HEAD:/.Xresources


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
there are two groups of people in the world: those who believe that

the world can be divided into two groups of people, and those who
don't.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "Kurt Hackenberg" on 2019-11-03 at 00:11 
Uhr -0400:
Mutt runs an external text editor to 
compose plain text; it could do the same 
for this -- run some external composition 
program that would return both HTML and 
plain text.


There is nothing stopping you from setting `$editor` to a HTML 
editor, and defining `$content_type` to be `text/html`, and then 
using Kevin's `multipart/alternative` functionality to generate a 
`text/plain` part.


The only issue with this approach would be that you'd now have the 
`text/plain` part after the `text/html`, which means that dumb 
clients such as Gmail and Outlook and Thunderbird too would actually 
prefer the plain-text message over the HTML one.


Getting mutt to sort those into order might get really messy though, 
and while I think it it wouldn't be too hard to ensure that 
`text/html` always comes after `text/plain`, anything beyond that 
would require a new command, but `alternative_order` is already 
taken for something else, and cannot be reused, I don't think.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"no work of art ever puts forward views.

 views belong to people
 who are not artists."
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "martin f krafft" on 2019-11-02 at 23:40 
Uhr +1300:
How does this message fare? I’ve hacked up 
my script so that it actually keeps the ‘>’ 
even in the HTML, but uses CSS to hide it.


Yeah, so I am not convinced at all, because all the html2text 
converters won't ignore that extra '>', and it just gets really 
ugly.


Assuming that Thunderbird users are the only ones that actually know 
how to quote (and we can safely ignore Outlook/Gmail, who all 
top-quote anyway), maybe this is a bug to be taken up with 
Thunderbird devs?


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"es ist gut, eine sache doppelt auszudrücken und ihr einen

 rechten und linken fuß zu geben. auf einem bein kann die wahrheit
 zwar stehen; mit zweien aber wird sie gehen und herumkommen."
  -- friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "Martin Trautmann" on 2019-11-02 at 10:22 
Uhr +0100:
However, the usage of blockquote within HTML is something where 
there is not necessarily a proper way of handling this - 
Thunderbird does not do it properly, as you see above. How does 
handle html itself nested blockquote levels?


Oh, interesting corner case you spotted there. HTML does nesting of 
blockquotes just fine. The problem here seems to be that Thunderbird 
doesn't recognise blockquote as a quote, and needs the leading '>'.


How does this message fare? I've hacked up my script so that it 
actually keeps the '>' even in the HTML, but uses CSS to hide it. 
:grin:


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
in africa some of the native tribes have a custom of beating the

ground with clubs and uttering spine chilling cries. anthropologists
call this a form of primitive self-expression. in america they call
it golf.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "Stefan Hagen" on 2019-11-01 at 08:53 Uhr 
+0100:
While I was able to just write an email and send it, it is now a 
process of carefully "coding" an email, previewing, correcting, 
previewing, sending...


There's a lot of good things to be said about carefully crafting 
emails!


Regardless, to most of us who've been writing text/plain emails all 
of our lives, using ASCII characters for emphasis and hand-crafting 
numbered and itemised lists, Markdown will hardly even have a 
learning curve.


The only thing to watch out for is the "false positives", like I had 
the other day when part of an email of mine was interpreted by 
pandoc to be LaTeX math. I've since disabled the pandoc extension in 
[my script I use with mutt][1], though there remain quite a number 
of extensions allowing for funky corner case surprises, especially 
in quotes from other people! Fun times ahead!


[1]: https://git.madduck.net/etc/mutt.git/blob_plain/HEAD:/.mutt/markdown2html

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"america may be unique in being a country which has leapt

 from barbarism to decadence without touching civilization."
  -- john o'hara
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "Kevin J. McCarthy" on 2019-11-01 at 14:45 
Uhr +0800:
I've merged the branch into master.  For those who want to give it 
a try, please see the documentation under "MIME 
Multipart/Alternative" 
.


I've sent over 100 emails using this, and it's been working 
spotlessly.


If you want to quickly try it out, here's a [little script][1] I 
hacked up, which uses pandoc to create a `text/html` alternative by 
parsing your message as if it were Markdown.


[1]: https://git.madduck.net/etc/mutt.git/blob_plain/HEAD:/.mutt/markdown2html

Feedback welcome!

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"the word yellow wandered through his mind in search of something to

 connect with."
 -- hitchhiker's guide to the galaxy
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Formatting HTML content for colour-terminals (was: Rendering HTML as Markdown in mutt)

[martin f krafft]

Regarding the following, written by "Kevin J. McCarthy" on 2019-11-01 at 10:12 
Uhr +0800:
$allow_ansi can enable this, but I recommend reading the option 
description and thinking very carefully before doing this.


Great, I can confirm this works. So then the challenge becomes to 
filter out ANSI sequences from the `text/html` part *before* feeding 
it to the autoviewer, including HTML-encoded ANSI sequences, so that 
what the autoviewer prints *can* be interpreted as ANSI without 
fearing whatever malicious codes an attacker may choose to send.


Regarding the problem that the [--- BEGIN PGP ---] badge can get 
spoofed that way, I have often wondered if there wasn't a better way 
to make this information accessible, i.e. a status line indicator, 
combined with a new menu (similar to attachments), which I can 
invoke to inspect the actual verification of any signature etc.. 
This then becomes similar to how it's done in the browser. But 
that's a whole different beast…


Anyway, Akkana, there you have it: find a HTML dumper that can 
translate HTML to ANSI, and you've got it all, minus the security 
implications of allowing people to send you email that indirectly 
controls your terminal beyond just displaying characters.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
an egg has the shortest sex-life of all: if gets laid once; it gets

eaten once. it also has to come in a box with 11 others, and the
only person who will sit on its face is its mother.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Formatting HTML content for colour-terminals (was: Rendering HTML as Markdown in mutt)

[martin f krafft]

Regarding the following, written by "Akkana Peck" on 2019-10-31 at 18:55 Uhr 
-0600:
That sounds like it's all on the viewing side? I can't speak for 
Derek, but in addition to viewing HTML messages, I (and others who 
have added to this thread) would like a way to reply without losing 
the formatting.


You mean "losing the formatting" of the message sent to you?

This is going to get really hard very quickly. Either you convert 
the HTML into Markdown, blockquote it, and then hope that the 
Markdown to HTML conversion does it justice (probably your best bet 
to be honest), or you wrap the original HTML into a blockquote and 
include it verbatim. That is certainly the domain of an HTML editor, 
I'd say, and it'll get ugly really fast.


The viewing side isn't so hot either. Most terminal programs these 
days can display colors, italics, bold, underline and strikethrough 
(looks like urxvt doesn't do strikethrough and xterm doesn't do 
underline, but those might not be too hard to patch in). So why do 
most HTML->text conversion programs ignore styles and colors in 
--dump mode? Is there one that shows styles/colors?


This really is only a matter of outputting the right control 
characters. I don't know of any that can do it, but I cannot imagine 
it being hard work on top of Python `html2text`, i.e. I'd let that 
do the conversion to Markdown, and then see if I can replace the 
Markdown formatting with terminal control characters.


Helpful link: 
https://rosettacode.org/wiki/Terminal_control/Coloured_text


Sure, it's easy enough to bind a key to bring up a browser window 
showing the message. But then I have an extra GUI window that isn't 
part of mutt, and it breaks that nice fast keyboard-driven workflow 
that's a big part of why I use mutt in the first place. It would be 
so nice to have it all right there in the pager.


Step 1 to check: can mutt's pager handle terminal control characters 
for formatting, or is ncurses going to get in the way?


I just tried to make my HTML dumper output red text like so:

  tput setaf 1#red
  echo "Red"
  tput sgr0

but that didn't get the desired result. So I am thinking that 
ncurses actually gets in the way, and I am way outside my depth with 
that, but irssi can do it, and so it should also be possible with 
mutt.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"time flies like an arrow. fruit flies like a banana."

 -- groucho marx
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Rendering HTML as Markdown in mutt (was: Creating HTML emails with mutt)

[martin f krafft]

Regarding the following, written by "Derek Martin" on 2019-10-31 at 15:39 Uhr 
-0500:
And FWIW, I *was* discussing (very limited, completely text-based) 
support for HTML messages in Mutt.  I want it, have wanted it for a 
long time, because all of the available options for dealing with it 
have serious drawbacks at least some of the time.


Hey Derek,

Could you please elaborate a bit on what you're missing?

With `auto_view text/html` and adding 
[`~/.mutt/mailcap.htmldump`](https://git.madduck.net/etc/mutt.git/blob_plain/HEAD:/.mutt/mailcap.htmldump) 
to your `muttrc`'s `mailcap_path` setting, and then dropping 
[`~/.mutt/htmldump`](https://git.madduck.net/etc/mutt.git/blob_plain/HEAD:/.mutt/htmldump) 
in place, along with 
[`python-html2text`](https://pypi.org/project/html2text/), and you 
should get Markdown, more or less, which is precisely what it was 
designed for.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
i welcome your constructive criticism and corrections.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "John Long" on 2019-10-31 at 10:17 Uhr 
+:
The approach Kevin proposed is completely HTML-agnostic and leaves it 
up to the user to provide an external tool that provides the HTML. 
Mutt then just does the required MIME-handling, which is clearly 
within the domain of a MUA.


I thought there was already the capability in mutt to pipe email to 
another application?


Sure, you can filter your text/plain part through aspell. But you 
cannot currently create multipart/alternative emails.



There is no GUI requirement in any of this.


I meant to say that HTML email becomes much less useful and in some 
cases worthless without a GUI. You can't display pictures or see 
advertising links on the console. I have tried to use various console 
browsers like links and lynx and I'm unable to use them with almost any 
webpage.


So you'll have your client configured to prefer text/plain when 
given the choice between alternatives. Which mutt already supports.


Can we please move on?

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"der besitz der wahrheit ist nicht schrecklich,

 sondern langweilig, wie jeder besitz."
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "John Long" on 2019-10-31 at 10:30 Uhr 
+:
1. Commonly done != standard. There are standards for things like MIME, 
POP3, IMAP etc. I'm not aware of ANSI, ISO, IETF standards that say 
that HTML email is a thing.


Quoting the HTML RFC from 1995: "The Hypertext Markup Language 
(HTML) is a simple markup language used to create hypertext 
documents that are platform independent. HTML documents are SGML 
documents with generic semantics that are appropriate for 
representing information from a wide range of domains. HTML markup 
can represent hypertext news, **mail**, documentation, and 
hypermedia; …"


So yes, HTML was designed pretty much from the start to be used for 
mail.


And then "MIME" came along. Which is a standard, and RFC 2854 makes 
text/html a standard.


Anyway, none of this is relevant, because:


2. Mutt hasn't had HTML support


… and won't get HTML support. We're working on the ability to create 
multipart/alternative containers.


I am going to stop participating in this "HTML is good or bad for 
Email" debate, and I'd like to invite you all to consider doing the 
same.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
a Hooloovoo is a superintelligent shade of the color blue.

-- douglas adams, "the hitchhiker's guide to the galaxy"
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “John Long” on 2019-10-30 at 11:31 Uhr +:

From my point the issue is not only what I have to configure or what can be configured, but also how much code is behind doing that. Less code is easier to manage than more code. I can’t see the benefit of junking up mutt with HTML …

Fully agreed on all of the above.
The approach Kevin proposed is completely HTML-agnostic and leaves it up to the user to provide an external tool that provides the HTML. Mutt then just does the required MIME-handling, which is clearly within the domain of a MUA.
Also, mutt already does receiving/reading multipart/alternative, so it only makes sense to figure out how to properly add creation of such containers. After all, mutt can sign GPG signatures, not just verify them.

Remember, some of us use mutt on a console with no GUI.

There is no GUI requirement in any of this.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "all i know is that i'm being sued for unfair business practices by micro$oft. hello pot? it's kettle on line two."-- michael robertson spamtraps: madduck.bo...@madduck.net

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “Mark H. Wood” on 2019-10-30 at 08:22 Uhr -0400:

Even Outlook seems incapable of badly damaging blocks of text, indented blocks of text, emphasis, underscore/italics, or lists.

I think this is the perfect reason why mutt needs to learn creating multipart/alternative parts, and to do it right, so that it can continue to suck the least of all MUAs.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "nothing can cure the soul but the senses, just as nothing can cure the senses but the soul."  -- oscar wilde spamtraps: madduck.bo...@madduck.net

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “Dave Woodfall” on 2019-10-30 at 11:25 Uhr +:

When messages turn up with no plain text part to them at all, or one that’s completely useless, it’s wrong.

I’d guess we all agree on that point.
We’re currently discussing the creation of multipart/alternative containers, which place the HTML part as an alternative to the plain-text part, so you can freely choose which one to read. Nobody is suggesting mutt no longer sends text/plain by default.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net the only difference between a car salesman and a computer salesman  is that the car salesman knows he's lying. spamtraps: madduck.bo...@madduck.net

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “Dave Woodfall” on 2019-10-30 at 10:05 Uhr +:

I don’t think embracing wrong email practices is the way forward.

I don’t think this is about right and wrong, and not only because there is no objectivity. multipart/alternative is an accepted standard, and so is HTML. You might not like how things have developed, and neither do I, but that doesn’t make it wrong.
The fact that the vast majority have adopted HTML for emails means you cannot really ignore it anymore. Mutt already handles receiving/reading alternative parts quite well. Being able to produce those parts will mean it’ll suck less for those who need or want this functionality.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "to me, vi is zen. to use vi is to practice zen. every command is a koan. profound to the user, unintelligible to the uninitiated. you discover truth everytime you use it." -- reddy ät lion.austin.ibm.com spamtraps: madduck.bo...@madduck.net

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “Nuno Silva” on 2019-10-30 at 09:21 Uhr +:

There are users who don’t need text/html. It’s okay to want some way to use HTML for e-mail in mutt, but I’d say it’s not okay to say everybody needs it.

I’d love to see some statistics about the age of mutt users.
Just to be clear: any solution will be configurable, so nobody will be forced to use it.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "everyone has a little secret he keeps, i like the fires when the city sleeps."  -- mc 900 ft jesus spamtraps: madduck.bo...@madduck.net

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “Martin Trautmann” on 2019-10-30 at 00:14 Uhr +0100:

That’s such a strange thing.
[…]
since they never learned, how proper threading and quoting could have worked?

78 characters wide text/plain is just not the lowest common denominator anymore. I am not going to sing an ode to HTML email, but being able to use Markdown to create more expressive emails than using ASCII art is not something I find utterly offensive.
If you want someone to blame, shake your fist at Microsoft (for forcing HTML into email), and Google (for actively breaking threading and quoting rules). That said, Gmail is far easier to use if you want to refer back to content written earlier in a thread than mutt, where you either have to save a draft, or open a second instance, find the thread, and navigate around messages, or use clunky search.
Society has moved on, and we all risk sounding like grumpy old folks reminiscing at the times when everyone knew what netiquette was if we don’t embrace the progress that’s been happening around us. And text/html is part of that progress, whether you like it or not.
If we don’t embrace progress, then mutt will not have any users in a decade or two.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net fighting for peace is like screwing for virginity.   -- the irish times, washington dc spamtraps: madduck.bo...@madduck.net

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “Grant Edwards” on 2019-10-29 at 17:09 Uhr -:

Muttdown (a “sendmail” filter) which creates mutlipart alternative html/text messages is the only reason I’ve been able to continue to use mutt for the past 5-6 years.

Muttdown suffers from the same problems relating to attachments in signed messages as outlined in the initial post.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net for four-fifths of our history,  our planet was populated by pond scum.  -- j.w. schopf spamtraps: madduck.bo...@madduck.net

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “Kevin J. McCarthy” on 2019-10-29 at 12:58 Uhr +0800:

The part creation (and removal) will be in Mutt’s pipeline, and so will follow normal processing that Mutt does. That include encoding, delimiters, charset conversion, etc. So I would like the script to simply produce the HTML (or PDF, or whatever) output, without trying to “mailify” the output.

Makes perfect sense.
At the risk of overcomplicating things at this stage, I do want to put one more idea out there, which is that instead of the script returning content of a specific type, and thus always with the same content type (unless the filter script is interactive of sorts), what about a command or option that I can use to instruct mutt to generate an alternative of a given MIME type, which is then passed to the script, and the return data assumed as such.
Now, I could configure mutt to always add a text/html alternative, but also have a command from the compose menu allowing me to add e.g. text/enriched, or application/pdf.

Reusing as a template would be resolved if we kept a local record >of the messages without the generated content, similar to how >$fcc_attach removes the attachments before storing.
For this iteration, I didn’t plan on going here. $fcc_attach would still just remove attachments, the main content would be stored as it were generated (i.e. including multipart/alternatives). Maybe in the next iteration I could add an option to strip the alternative.

The more I think about this, the less I think this should be an option. Even $fcc_attach is already quite a problem, especially since it means that the message stored locally isn’t the same as the one you sent, with a different GPG signature and all.

Yes, this is one of the places I need to look at. My plan is the simplest, as you mentioned: discard the alternative when generating anything that goes through the compose menu.

… but not on messages that are being forwarded as attachments. Those don’t get touched, right?
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net who's general failure, and why's he reading my disk? spamtraps: madduck.bo...@madduck.net

Re: Opening URLs from mutt (was: Creating HTML emails with mutt)

[martin f krafft]

Regarding the following, written by “Dave Woodfall” on 2019-10-29 at 08:53 Uhr +:

I deal with very long links, or long lists of links where the context is lost, by opening the message in elinks, and then using elinks’ option to pass a link or current URL to an external application or command, if elinks can’t deal with it itself. That way it’s possible to copy the URL into /tmp/screen-exhange, then do something in screen.

Sounds like a lot of ifs and loose parts to a task that we all end up doing dozen times a day. A good tool would let me accomplish such a task without engaging my brain, and with one or two key presses, don’t you think?
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net the unix philosophy basically involves  giving you enough rope to hang yourself.  and then some more, just to be sure. spamtraps: madduck.bo...@madduck.net

Re: Opening URLs from mutt (was: Creating HTML emails with mutt)

[martin f krafft]

Regarding the following, written by “雨宫恋叶” on 2019-10-29 at 00:41 Uhr +:

For this, I think we should design a pager for that purpose.

Urlview could probably be extended accordingly. It’d still be disruptive. Imagine reading a long email, and 75% down you encounter a link you want to follow. If you now fire up the external pager, it won’t be scrolled to the right location in the email, so you’d first have to find that paragraph first…
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "literature always anticipates life. it does not copy it, but moulds it to its purpose. the nineteenth century, as we know it, is largely an invention of balzac."  -- oscar wilde spamtraps: madduck.bo...@madduck.net

Re: Opening URLs from mutt (was: Creating HTML emails with mutt)

[martin f krafft]

Regarding the following, written by "Dave Woodfall" on 2019-10-29 at 00:10 Uhr 
+:
Urlview handles long and short links just fine.  I've been using it 
for over 10 years.


Yes, it does. I think Chris' and José's points were more about 
requiring an external tool to provide functionality which has become 
so core to everyday email use that mutt could learn to do it.


Urlview also obstructs your view to context when using it. I've 
opened it a million times only to find myself staring at a list of 
tracking URLs that all look the same, now knowing which one appeared 
in the paragraph I was just reading. Mutt could do a much better 
job, with a UI/UX similar to what rxvt-unicode offers (but cannot 
due to ncurses…), i.e.:


1. enter URL selection mode;
2. use arrow keys to select the URL you want, while the message is 
  being shown;

3. press enter to fire up mailcap handler.

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

"never attribute to malice what can be
adequately explained by incompetence."
  -- mark twain

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Hi Kevin,

Thanks for sharing your thoughts and plans on this. This all reads 
really well, and I think it would go most of the way towards the 
ideal solution.


I have a couple of points/questions about some of the things you 
propose:


If there were an error sending, the alternative would be stripped 
before returning to the compose menu.  So it would not be exposed 
to the compose menu.  I *might* add a function to preview the 
output as raw text and via mime from the compose menu though.


The ability to preview sounds great, and I would greatly appreciate 
it.


Script output would be the content-type, a blank line, then the 
generated content.


This makes me itch, but I cannot really devise a better approach. I 
want to say that the script needs to return the complete MIME part, 
including Content-Transfer-Encoding and other headers, or are you 
confident that Mutt can deduce all these parameters from the 
generated content?


Anyway, that's my current plan.  The problem is cleaning up some 
other parts of mutt to deal with bouncing, reuse as a template, 
etc.


Reusing as a template would be resolved if we kept a local record of 
the messages without the generated content, similar to how 
`$fcc_attach` removes the attachments before storing.


However — and I just experienced this — forwarding a message as 
attachment now means that it'll be plain-text only.


Processing a message to be attached, or a message to be bounced, 
seems to me like a really bad idea, especially since it should only 
ever be applied to messages that were locally authored. Maybe this 
would mean storing with the locally recorded message a little bit of 
metadata suggesting that Mutt generated an alternative part for this 
message when it was sent?


Yeah, this can get ugly fast, and maybe the right way forward is 
instead to store the generated content when saving a message 
locally, but to teach Mutt to discard any multipart/alternative 
non-text/plain part when reusing a message as a template, similarly 
to how that part is discarded on error before it's returned to the 
compose menu?


Best regards,

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

the english take english for granted.
but if we explore its paradoxes,
we find that quicksand can work slowly.

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Opening URLs from mutt (was: Creating HTML emails with mutt)

[martin f krafft]

Regarding the following, written by "Chris Green" on 2019-10-28 at 22:40 Uhr 
+:
Isn't that handled by your terminal program?  Mine certainly allows 
one to right click on any URL to open it.


rxvt-unicode also has an extension ("matcher") that allows you to 
select and open URLs using the keyboard only.


However, when URLs wrap across lines, things often break, and 
especially when you have the sidebar shown, then your terminal 
emulator has no way to make sense of the URL anymore. Mutt, however, 
does know about message contents, and can interpret line breaks much 
better.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

"syntactic sugar causes cancer of the semicolon."
 -- epigrams in programming

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by "Matthias Apitz" on 2019-10-28 at 23:11 Uhr 
+0100:
Well, do you speak for you or for a 'lot of people'? Who they are? 
I speak only for my own interests (as I said: I do not need this).


Matthias, any such feature would of course be optional, and probably 
default to off for a long time, so you have nothing to worry about.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

"if they can get you asking the wrong questions,
they don't have to worry about answers."
  -- thomas pynchon

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Creating HTML emails with mutt

[martin f krafft]

Regarding the following, written by “Amit Ramon” on 2019-10-26 at 09:03 Uhr +0300:

A few years back I developed a simple filter that does, more or less, what you’re looking for.
[…]
https://github.com/amitramon/plainMail2HTML

Thanks for the pointer. If messages aren’t PGP/MIME-signed, then both muttdown and my own tool work just fine. The question is more about how it should be done properly, than it is about which tool can do this.
Thank you anyway, and I do wish I had seen your work (and muttdown) before writing it all up by myself.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net heisenberg may have been here. spamtraps: madduck.bo...@madduck.net

Re: Creating HTML emails with mutt

[martin f krafft]

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

Creating HTML emails with mutt

[martin f krafft]

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: Conditional configuration

[martin f krafft]

also sprach mutt-us...@rcdrun.com  [2016-01-30 21:07 
+1300]:
> The efforts to bring back some sources to the original mutt are to
> be made by those developers of the original mutt.

I disagree. The open-source ecosystem works best if you avoid forks
and try instead to move all improvements as far up the stream as you
can.

Anyway, I think this discussion is getting off-topic…

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"alas, i am dying beyond my means."
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Conditional configuration

[martin f krafft]

also sprach David Champion  [2016-01-30 14:51 +1300]:
> I should have thought of this one before, but your suggestions made me
> remember it:
> 
>   mutt -D | egrep '^some_variable='
> 
> That would tell you very simply whether that variable is in the
> configuration.

Presumably, strings will be faster…

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
fashions have done more harm than revolutions.
  -- victor hugo
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Conditional configuration

[martin f krafft]

also sprach David Champion  [2016-01-30 11:31 +1300]:
> I'm guessing you use kz on one machine and real mutt on the other.  Not
> showing what features are added beyond stock mutt is, I'm afraid, a kz
> issue.

Your analysis is spot-on.

It's a shame to hear that Karel doesn't do his work within the
community. mutt-kz is a nice piece of work and why not provide an
officially experimental mutt?

> Otherwise... you could strings the binary I guess? Or run mutt against a
> -F config file containing sidebar config options, and see if it errors
> out to test for feature presence?

Using -F would be nice, except I can't figure out a way to make this
check-only and non-interactive. I tried

  mutt -F .mutt/sidebar http://madduck.net/ | http://two.sentenc.es/
 
to err is human - to moo, bovine
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Conditional configuration

[martin f krafft]

also sprach Lukasz Szczesny  [2016-01-28 21:42 +1300]:
> I keep my sidebar configuration in a separate file and source it when
> sidebar is enabled with the following `source` command:
> 
> source `FILE=$HOME/.mutt/sidebar; mutt -v | grep -Fq sidebar || 
> FILE=/dev/null; echo $FILE`

Unfortunately, mutt-kz does not export this info in -v output:

  http://bugs.debian.org/812953

It's also quite a hack ;)

But thanks for sharing!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
time wounds all heels.
 -- groucho marx
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Conditional configuration

[martin f krafft]

Hi,

I have two machines with mutt, one has the sidebar patch, while the
other does not. I'd like to use the same config on both, but
obviously the one without the patch falls over the sidebar keywords,
e.g.:

  Error in /home/madduck/.mutt/sidebar, line 4: sidebar-prev: no
  such function in map

Short of writing a script to print out the sidebar config depending
on the output of mutt -v (ew!), I was wondering if there's another
way in mutt to support different versions from the same config, e.g.
a soft-fail mode, or a way to test for existence of certain
variables before starting a configuration block?

Thanks,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"if java had true garbage collection,
 most programs would delete themselves upon execution."
-- robert sewell
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

After jump to index end

[martin f krafft]

Hey there,

I have my mails sorted in mutt in increasing order of date-received,
so the latest are at the bottom, and I don't think I will ever
change that.

I also often use the  function, and after applying a ,
mutt has the first (oldest) message highlighted.

Is it somehow possible to have mutt automatically jump to the bottom
of the index after applying a limit? I can't really use a macro as
the jump would need to be executed after reading the pattern, and
I don't think mutt let's me suspend a macro to readline data from
the user, does it?

Thanks,

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
"i'm hot, and when i'm not, i'm cold as ice"
   -- ac/dc, "problem child"
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Invoking an alternative command on a MIME part

[martin f krafft]

also sprach Luis Mochan moc...@fis.unam.mx [2015-04-28 04:36 +0200]:
 What I do in similar situations is pipe the attachment to a helper
 (I call it muttfilter) that accepts as first argument a file name,

Oh, but now you need a different pipe depending on the file type,
e.g. for PDF and PNG. I don't really want that as mailcap already
handles this.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
love is a grave mental disease.
 -- platon
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

view-attach vs. view-mailcap (was: Invoking an alternative command on a MIME part)

[martin f krafft]

also sprach Cameron Simpson c...@zip.com.au [2015-04-28 04:17 +0200]:
 I do not properly understand view-mailcap versus view-attach.
 I would appreciate someone else chiming in here.

I think the difference is that view-attach tries to render inline
(e.g. text/plain) and only resorts to run-mailcap when it has not
internal viewer. view-mailcap skips the internal viewers and
always goes via mailcap.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
beware of bugs in the above code;
i have only proved it correct, not tried it.
-- donald e. knuth
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

[working hack found] Re: Invoking an alternative command on a MIME part

[martin f krafft]

also sprach Cameron Simpson c...@zip.com.au [2015-04-28 04:17 +0200]:
 Sounds like a job for a mutt macro. A first cut would be to write
 a macro which pointed $mailcap_path at a different mailcap file,
 then ran view-attach, then restored the old value.

Yes! This idea led me to a working solution^W hack:

  set mailcap_path=~/.mailcap-edit-wrapper

and that file then contains entries for all types such as:

  application/*; chmod +w %s  run-mailcap --action=edit %t:%s

Unfortunately, the main type (application) cannot be wildcarded,
but there's only a limited set of those, so no big deal. The chmod
is needed since mutt saves the temporary file read-only.

So now it's easy to create a macro as you describe above, allowing
me to map 'e' to editing an attachment.

Thanks for your help!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
the uncertainty principle:
  you can never be sure how many
  beers you had last night.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Invoking an alternative command on a MIME part

[martin f krafft]

also sprach Cameron Simpson c...@zip.com.au [2015-04-26 22:54 +0200]:
  Apphelper first asks whether to view the file, offering the
  supplied view command in [square brackets] as the default.  Pressing
  return or entering y or yes' accepts this default and runs the
  viewer.  Entering n or no skips running the viewer.  Other
  answers are taken to be the name (and optional arguments) of a
  viewing program.
 
 Superficially that sounds like exactly what you're asking for.

Yes, it does and thanks for being so persistent. I am sorry for
being finicky about this, but I know how things go and I don't want
to have to press enter 99% of the time just to accept a default so
that I can select a different viewer in 1% of the cases.

What I really want is view-attach to grow a sibling:
edit-attach, which would spawn run-mailcap --action=edit instead
of the default --action=view. And then I could view or edit at the
press of one of two button without having to engage in an
interactive session requiring me to react to prompts.

Alternatively, this could probably be solved even more generically
e.g. by allowing a sequence like '%' to appear in the shell-escape
command line, which, if present, causes a temporary file to be
written and injected into the command line. I bet there could be
plenty of use-cases for this. The advantage of letting mutt write
the temporary file is that mutt knows more about the file than
children commands. mutt could even substitute %n for the filename
and %t for the mime-type.

Does this make sense?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
seminars, n.:
  from semi and arse, hence, any half-assed discussion.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Invoking an alternative command on a MIME part

[martin f krafft]

also sprach Cameron Simpson c...@zip.com.au [2015-04-26 01:10 +0200]:
 So I go to the attachment view in mutt. Press enter on the attachment,
 which runs apphelper (from mailcap).
 […]
 so pressing enter ran apphelper which ran xv immediately. After quitting
 xv, I get the save prompt.

Right, this is nice. But I don't always want to run xv. Sometimes
I want to run Gimp.

 Entering !open % invokes the shell command open (standard Mac
 open this file/url with the default app command) with the temp
 filename replacing the %.

This would be exactly what I need, except…

 Obviously I could issue any command, not just open, with the
 filename specified by %.

mutt 1.5.23 does not seem to know about '%'. Running
shell-escapeless %return yields

  %: No such file or directory

What am I doing wrong?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
only by counting could humans demonstrate
their independence of computers.
-- douglas adams, the hitchhiker's guide to the galaxy
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Invoking an alternative command on a MIME part

[martin f krafft]

also sprach Cameron Simpson c...@zip.com.au [2015-04-26 12:26 +0200]:
 My mailcap makes apphelper the handler for most file types, and
 supplies apphelper the default end viewer. Apphelper runs the
 viewer (asking first by default) and offers to save the file, and
 accepts !shell command at its prompts.

 Basicly, apphelper is the save/view/whatever dialogue I wish all
 programs had:-)

This still won't solve my problem. I don't want to choose the viewer
every time. I always want the default, unless I press a different
button, e.g. 'e' instead of 'return'.

So again, I think this is a nice script you have there (you should
try to get it into Debian!), but it's not what I am looking for.

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
'the answer to the great question...'
 'of life, the universe and everything...' said deep thought.
 'is...' said deep thought, and paused.
 'is...'
 'forty-two,' said deep thought, with infinite majesty and calm.
 -- hitchhiker's guide to the galaxy
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: Invoking an alternative command on a MIME part

[martin f krafft]

also sprach Cameron Simpson c...@zip.com.au [2015-04-25 01:24 +0200]:
 I wrap all my mailcap commands with my apphelper script, which
 itself is wrapped in my shorter-named ah script. My mailcaps
 look like this:
 
  application/pdf; ah %s -1 xpdf; gui
  image/jpg; ah %s -1 xv; gui
  image/tiff; ah %s -1 gm display; gui
 
 and so forth. As you can see, the viewer is mentioned at the end.

Yeah, ah seems a nice addition to the toolchain and I might well
adopt it.

However, it does not solve the problem. I might have ah be the
default mailcap viewer, but occasionally I will want to open a PNG
file with Gimp, not the default viewer. Right now, this requires me
to save the file and invoke Gimp externally.

 You can also use a shell escape to run an arbitrary _other_
 command on the file.

How would you (a) get mutt to save a temporary file, using e.g. the
MIME filename or a MIME-type derived file name and then invoke some
_other_ command on the file?

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
the unexamined life is not worth living
 -- platon
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Invoking an alternative command on a MIME part

[martin f krafft]

Hey folks,

I am seeking the ability to invoke a command on a MIME attachment
which is not view-attach. Simple example: view-attach on a PNG
file might open xview with the temporary file, but sometimes I'd
like to load an attachment (the temporary file) in Gimp to be able
to edit and save-as to somewhere else.

Unfortunately, I cannot find a way to do this. Even the $editor hack
doesn't work, because the attach menu has no edit command.

Saving the file to /tmp and invoking Gimp on that file is getting
quite cumbersome and I am lazy…

Obviously I could write/use a helper to soak up stdin and invoke
a command on tmpfile, but then I am losing the MIME type and
filename extension information that mutt provides to view-attach.

Do you have an idea of how I could do what I am trying to do?

Thank you!

-- 
@martinkrafft | http://madduck.net/ | http://two.sentenc.es/
 
security here. yes, ma'am. yes. groucho glasses. yes, we're on it.
 c'mon, guys. somebody gave an aardvark a nose-cut: somebody who
 can't deal with deconstructionist humor. code blue.
  -- http://azure.humbug.org.au/~aj/armadillos.txt
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach Tim Gray lists+m...@protozoic.com [2012.08.17.1541 +0200]:
 I can confirm that running dovecot with a line in the conf file like
 the one above does work.  I use the following with dovecot when I
 want/need to access my mutt maildir store with clients that can't
 read directly from the file system.
 
 mail_location = maildir:~/mail:INBOX=~/mail/Inbox:LAYOUT=fs
 
 To be explicitly clear, my maildir structure has IMAP folders as
 directories on the file system and not encoded in the mailbox name
 with '.' or some other character:
 
 mail/Inbox
 mail/lists/mutt
 mail/lists/offlineimap
 etc.

Any idea how to migrate existing users, or how to enable this only
for a single user?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
la lune, c'est comme les canards
il faut aimer caresser les chats
pour avoir envie d'y aller.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach Cameron Simpson c...@zip.com.au [2012.08.16.2359 +0200]:
 I have a not very complex script; it uses the mutt tree as reference and
 makes symlinks for dovecot:
 
   https://bitbucket.org/cameron_simpson/css/src/tip/bin/mkdovecotmap

Mine (currently offline, so I cannot attach) does three things more:

  1. checks for new folders in both directions, so that if I create
 a new folder with mutt, it gets migrated to the IMAP hierarchy
 and symlinked back to mutt;

  2. checks for removed folders and removes them in both
 hierarchies;

  3. if .debian/ is a folder and .debian.mutt another, then debian
 itself won't be symlinked, but only cur,new,tmp will. Otherwise
 this would cause symlinks to be stored in a symlinked
 directory, meaning they would end up in the wrong hierarchy.

So yeah, it works, but I wanted to know if there is a better way.

  - IMAP to localhost is okay if configured properly, but it does
need a password that either needs to be entered on every start
of mutt, or stored somewhere. Also, tab-completion of folders
doesn't quite work as expected.

  - Andre suggested to use

   mail_location = maildir:%h/Maildir:LAYOUT=fs

in dovecot, which I have yet to try. If this does what a web
search suggests, then it will make dovecot use mutt's hierarchy
instead of the standard IMAP-hierarchy, and that would solve my
problem, I think: http://wiki2.dovecot.org/MailLocation/Maildir

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
the college students who are using lsd and marijuana today do not
 comprise a criminal class. they are not drug addicts seeking to
 escape. they're your best educated, your most creative, and your
 most couragious, young people. and like it or not, they might build
 you a new civilisation.   -- porcupine tree, voyage 34
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

Dear list,

our E-mail-Server uses dovecot, which delivers mail to and from
a folder containing subfolders names e.g.
~/Maildir/.lists.mutt-users.

There are good reasons to use mutt directly on the machine from time
to time. Unfortunately, these folder names aren't exactly suitable
for mutt use. It works, but the leading dot is a pain, and tab
completion only honours '/' as a delimiter for folders, not '.'.

I have a complex shell script to maintain a symlink farm, but it's
suboptimal and hackish.

Do you have alternative approaches? I do not want to use mutt's IMAP
for localhost access, nor do I want to set up offlineimap on
localhost.

How can I map the IMAP folder names to proper folder names arranged
in a proper hierarchy (~/Maildir/.lists.mutt-users
→ ~/mail/lists/mutt-users)?

Thanks for any comments,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
the duration of passion is proportionate
 with the original resistance of the woman.
   -- honoré de balzac
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach Nicolas KOWALSKI nicolas.kowal...@gmail.com [2012.08.16.1757 
+0200]:
 Is there a special reason to not use this combination?

I find it slow and cumbersome to work with.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
sobald man über niveau spricht
 ist man längst darüber hinweg.
  -- thomas krafft
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach Nicolas KOWALSKI nicolas.kowal...@gmail.com [2012.08.16.1823 
+0200]:
 For the slowness I activated the header cache feature (one file per 
 folder):
 
 set header_cache=~/.hcache
 
 With this setup, on this server (Athlon XP 1500, 512M RAM), opening a 
 15k mails folder takes from 3 to 5 seconds.

Hm, you are right, I just did

  set folder=imap://madduck@localhost/

and once I authenticated, it all seems to work.

What do you do about the password? I don't want to store that in
.muttrc!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
quidquid latine dictum sit, altum viditur.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach martin f krafft madd...@madduck.net [2012.08.16.1829 +0200]:
 and once I authenticated, it all seems to work.

(except for change-folder tab-completion)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
no, 'eureka' is greek for 'this bath is too hot.'
-- dr. who
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach Luis Mochan moc...@fis.unam.mx [2012.08.16.1850 +0200]:
 Would this be considered unsafe?

To store the password clear-text in a file? Yes.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
one should never do anything that
 one cannot talk about after dinner.
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach Christian Brabandt cbli...@256bit.org [2012.08.16.1937 +0200]:
  To store the password clear-text in a file? Yes.
 
 What exactly is the problem with entering the password manually?

I don't know my password. I use asymmetric authentication
everywhere, including IMAP, using a preauth-SSH-tunnel.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
a bachelor is a man who never made the same mistake once.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach Tim Gray lists+m...@protozoic.com [2012.08.16.2040 +0200]:
 Out of curiosity, how do you implement this?

http://git.madduck.net/v/etc/offlineimap.git/blob/HEAD:/.offlineimaprc#l45

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
consciousness: that annoying time between naps.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: mutt on an IMAP-Server (dovecot): folder names and structure

[martin f krafft]

also sprach Patrick Ben Koetter p...@state-of-mind.de [2012.08.16.2044 +0200]:
 Putting passwords in configs isn't something I like, so
 I pull them from the Gnome keyring:

Not a bad idea, but now an attacker with access to the filesystem
doesn't have to run 'cat ~/.muttrc' but 'gnome-keyring-query get mutt' instead.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
fitter, healthier, more productive
like a pig, in a cage, on antibiotics
  -- radiohead
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Using patterns in hooks

[martin f krafft]

Dear mutts,

I am seeking a technical solution to a PEBCAK¹ case routed in my
inability — at times — to think before I do. ;)

¹) http://en.wikipedia.org/wiki/Pebcak

Basically, I would like to instruct mutt to refuse sending a message
when any one (or both) of two cases is true:

a. a message is somehow marked as not-yet-ready
b. a message is addressed to a problematic correspondent and does
   not include a manual signed-off sentinel of sorts.

The furthest I got on my way to address (a) was to use send2-hook to
manipulate $sendmail:

  
http://git.madduck.net/v/etc/mutt.git/commitdiff/ea36eed7af5f5e0e28b8d60f55abda2997cb1a08
  (also see http://bugs.debian.org/584264).

I don't like this solution very much, because it abuses the
recipient list; apparently, one can only use a limited number of
patterns in a send2-hook, and using e.g. ~h yields the error:

  h: not supported in this mode

http://www.mutt.org/doc/devel/manual.html#pattern-hook says:

  Mutt allows the use of the search pattern language for matching
  messages in hook commands. This works in exactly the same way as
  it would when limiting or searching the mailbox, except that you
  are restricted to those operators which match information Mutt
  extracts from the header of the message (i.e., from, to, cc, date,
  subject, etc.).

It's a bit ironic that ~h is not usable in hooks, but so be it (see
http://bugs.debian.org/585764).

I am now turning to you because you might have better ideas. Can you
think of a sentinel that is usable in hooks which

a. matches if present, thus making the hook execute as long as it
   exists (e.g. X-Draft: yes)?
b. matches unless present, thus making the hook execute until I add
   it (e.g. X-Signed-off: yes)?

I was thinking of using X-Label, but that seems to get eaten
(http://bugs.debian.org/583251).

Ideally, the solution does not abuse the recipient list, the sender,
or the subject. What would you do?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
montag, why do you burn books?
it's a job like any other, pay is good and there is a lot of variety.
-- ray bradbury (f451)
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Using patterns in hooks

[martin f krafft]

also sprach Javier Rojas jeroja...@devnull.li [2010.06.13.2055 +0200]:
 The following is a tip to check if you attached a file to a message,
 triggered when you use the attach word in the text body.
 
 http://wiki.mutt.org/?ConfigTricks/CheckAttach
 
 It might be a good solution for your problem; it doesn't use mutt's
 patterns, though.

Thanks for taking the time to reply!

I am already using this approach (and found it to be quite useless
since it's just a reminder à la click enter to acknowledge, not an
enforcer). Also, it is implemented in the editor (or the sendmail
script), not inside mutt, as you say.

Cheers,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
it is impossible to foresee the consequences of being clever.
-- cristopher strachey
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: PGP/MIME for Outlook (was: mutt feeds more to gnupg than it

[martin f krafft]

also sprach Kyle Wheeler kyle-m...@memoryhole.net [2009.12.05.0146 +0100]:
 I haven't checked recently either; when I get some time, I'll fire up 
 the ole XP virtual machine to check it out.
 
 Unfortunately, all I have is MS Office 2000, which is too old to work 
 with GPG4Win.

I tried it, and GpgOL does indeed to proper MIME by now.

The major problem with GpgOL, despite its nice integration, is that
you can either enforce encrypt-to-all and require the users to
acknowledge unencrypted outgoing mails (which will be the majority),
or you can rely on them to encrypt mails manually. Since I don't
trust users and the first option will just train them to blindly
click away the dialogue, GpgOL is not suitable (although I will
write in to the team and suggest a policy-based approach).

I am now investigating GPGrelay[0], which has a few warts but looks
promising. It also does PGP/MIME and it has policy-based rules to
enforce encryption to certain recipients (when a key is known), plus
the ability to map wildcard addresses to keys.

0. http://sites.inka.de/tesla/gpgrelay.html

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
it usually takes more than three weeks
 to prepare a good impromptu speech.
 -- mark twain
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: mutt feeds more to gnupg than it needs, causes invisible/lost

[martin f krafft]

also sprach Michael Wagner michaeldeb...@web.de [2009.12.03.0847 +0100]:
 JFTR: Today was an upgrade of the 'mutt' package in Debian unstable and 
 now it works very well.

I know: http://bugs.debian.org/558813 ;)

Thanks for letting the list know!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
stupidity management for the superuser
is a user space issue in unix systems.
   -- alan cox
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: mutt feeds more to gnupg than it needs, causes invisible/lost

[martin f krafft]

also sprach Derek Martin inva...@pizzashack.org [2009.11.30.0811 +0100]:
 Yes, I mean with any MIME.  PGP predates MIME by about a year, as
 far as I can tell.  So-called traditional PGP was intended to be
 used entirely within the message body, because at the time it was
 created there was *only* a message body. :)  So as soon as you start
 adding MIME parts, you've sort of broken that model...

Note that my original message was not about MIME; adding text before
and after the /^-/ PGP-traditional sentinels does not create
MIME parts.

 Historically, any mailer I'd seen that had any PGP support built
 in would basically do the same thing you would do manually: punt
 the message to PGP, and hand you the results in its viewer or an
 editor. There never was any text outside the PGP portions --
 including text outside the PGP block would have broken replies for
 pretty much everyone -- so this problem was a non-issue.  Besides,
 mixing encrpyted and unencrypted data in an e-mail is probably
 a bad idea... it presents more opportunities for accidental
 leakage of secret data.

Of course, but we do have two perfectly normal cases now:

1. full quote of a signed message by a top-poster instead of doing
the right thing.
2. broken mailing list software attaching footers to non-MIME parts
instead of converting the message to MIME.

Yes, both cases would not occur in a perfect world, but since
there's a relatively easy fix, mutt can help for the time being.

 If you're going to use MIME (and you *should*), you should follow
 the standard for using PGP with MIME.  If you're going to include
 in-line PGP inside MIME messages, you should probably expect that
 your mailer might get confused, cuz it's the Wrong Thing (TM)
 (some mailers don't handle in-line PGP at all, IIRC Evolution is
 an example, or was for a while at least).  I should amend that by
 saying if you're going to include in-line PGP anywhere in
 a message, DON'T. ;-)  It might be nice if Mutt could handle this
 better, but it's not a bug, and basically amounts to incorrect
 user expectation.

I think we all use PGP-MIME because we agree with you.
Unfortunately, we failed to make E-mail a tool for clued people
only. Just like we have to put up with design faults in SMTP forever
(it'll take decades until a deprecated feature can be removed), we
need to be able to deal with the PGP-traditional hack, in
combination with the newer technology.

 If you take all that into consideration, I think it's the right
 call to leave it alone, and pressure your peers to stop doing
 things that are broken / obsolete.

The problem comes when they aren't your peers (but e.g. your boss),
or when you deal with Outlook+PGP people, because as far as I know,
there is no way to do PGP-MIME with Outlook.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
perl -e 'print The earth is a disk!\n if ( earth == flat );'
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

PGP/MIME for Outlook (was: mutt feeds more to gnupg than it needs, causes invisible/lost)

[martin f krafft]

also sprach Kyle Wheeler kyle-m...@memoryhole.net [2009.11.30.1638 +0100]:
 ...Or if you deal with (Al)Pine+PGP people, because (Al)Pine cannot 
 deal with PGP-MIME or any MIME format where one MIME component must be 
 interpreted differently based on the contents of another MIME 
 component.
 
 As for Outlook... I guess you haven't seen GPG4Win? 
 http://www.gpg4win.org/index.html It supports PGP/MIME, S/MIME, and a 
 few others.

This is going off-topic, but I'd appreciate a response. GpgOL might
be able to decipher PGP/MIME, which would be a grand step, but last
I checked, it couldn't create PGP/MIME, only inline. I don't have
systems to check, but if that has changed, I would call up the
service people of a client ASAP and tell them to have another go at
implementing it.

Cheers,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
seminars, n.:
  from semi and arse, hence, any half-assed discussion.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: mutt feeds more to gnupg than it needs, causes invisible/lost

[martin f krafft]

also sprach Derek Martin inva...@pizzashack.org [2009.11.30.1921 +0100]:
 My Mutt is Mutt 1.5.20hg (2009-06-23), only slightly newer than yours,
 but it clearly does have code to handle the case of pgp-mixed text
 bodies (in pgp_application_pgp_handler() in pgp.c).  So it would seem
 the discussion is moot.

Indeed. This is good news:

http://dev.mutt.org/trac/changeset/5908%3A7f37d0a57d83/pgp.c

Thanks for your patience in putting up with me. I did appreciate the
discussion and hope not to have annoyed anyone.

Thanks especially to Brendan for the easy fix!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
i doubt larry wall ever uses strict.
   -- frederick heckel
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: mutt feeds more to gnupg than it needs, causes invisible/lost

[martin f krafft]

also sprach David J. Weller-Fahy dave-lists-mutt-us...@weller-fahy.com 
[2009.11.28.2236 +0100]:
 * Todd Zullinger t...@pobox.com [2009-11-27 21:07 -0500]:
  If you call check-traditional-pgp on this message, is this text
  lost? It is for me and I would call it a bug.  It might also be
  some subtle difference between our configurations, gpg versions,
  etc.
 
 FWIW I copied your message into ~/test, and then opened it using
 the latest tip, and the following command-line.
 
 #v+
 mutt -n -F usr/share/doc/mutt/samples/gpg.rc -f ~/test
 #v-
 
 I then entered ':exec check-traditional-pgp' in mutt, and viewed
 the message.  The text preceding the digitally signed portion of
 the message was still visible.

If I do the same with mutt from Debian sid (1.5.20 (2009-06-14)),
then I definitely do not see the unsigned portions.

This *could* be due to gnupg. Do you see the unsigned portions of
the text if you run

  gpg  ~/test

?

 I seem to recall this being brought up previously on the mailing
 list, but can't find any reference (which may mean it is all in my
 head). I'll keep searching, but haven't found anything about this
 particular problem yet.

I could not find anything prior to opening this thread.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
however jewel-like the good will may be in its own right, there is
 a morally significant difference between rescuing someone from
 a burning building and dropping him from a twelfth-storey window
 while trying to rescue him.
   -- thomas nagel
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: mutt feeds more to gnupg than it needs, causes invisible/lost

[martin f krafft]

also sprach David J. Weller-Fahy dave-lists-mutt-us...@weller-fahy.com 
[2009.11.29.1631 +0100]:
 * Michael Wagner michaeldeb...@web.de [2009-11-29 07:59 -0500]:
  * martin f krafft madd...@madduck.net 29.11.2009
   This *could* be due to gnupg. Do you see the unsigned portions of
   the text if you run
  
 gpg  ~/test
 
 I do *not* see the text preceding the digitally signed portion of the
 message when I run `gpg  ~/test`.  Odd.

ro this means that your mutt 1.5.20 on Darwin correctly splits the
message and only passes to gnupg what it must, while our 1.5.20 on
Debian sid does not. Very strange indeed.

  @David: What version of gnupg do you have?
 
 gpg (GnuPG) 1.4.10

Same here, or at least I am not using gnupg2.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
when zarathustra was alone... he said to his heart: 'could it be
 possible! this old saint in the forest hath not yet heard of it, that
 god is dead!'
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: mutt feeds more to gnupg than it needs, causes invisible/lost

[martin f krafft]

also sprach Derek Martin inva...@pizzashack.org [2009.11.28.0314 +0100]:
 I have pgp_auto_decode set, and additionally I unset it and manually
 executed check-traditional-pgp, and I saw the above text in all cases.
 So unless I misunderstood you, it seems my Mutt behaves differently
 from yours...

Indeed, and I take curiosity in that. More below...

 But besides that, check-traditional-pgp is not intended to work
 with MIME messages...

(I know)

3.153. pgp_auto_decode
[...]
 So, you may not like the behavior, but it's not a bug.  The
 solution, as already noted, is to unset pgp_auto_decode.  It's
 neither appropriate nor required for MIME-based PGP mails, as mutt
 already does the right thing there without it if the messages are
 marked properly.  The option is probably obsolete or headed there,
 and probably should not be set by default.

I think the actual bug I am looking at is not with pgp_auto_decode,
since, as far as I understand, it only calls check-traditional-pgp
on *every* message.

The problem is with check-traditional-pgp. If you have a message
that is:

  unsigned content
  -- begin signed --
  signed content
  -- signature --
  OSCNLKSknsc..
  -- end signed --
  unsigned content

then check-traditional-pgp will feed all 7 lines to GPG, and GPG 
will swallow the first and the last lines.

Either gnupg needs to learn to emit unsigned content, and visually
distinguish signed from unsigned content, e.g

  unsigned content
  -- begin signed content --
  signed content
  -- end signed content --
  unsigned content

or mutt needs to learn to only pass the signed content (along with
the signature) to gnupg.

I /think/ that the latter is the better solution, because mutt
already uses visual markers to distinguish signed from unsigned
content:

  [-- The following data is signed --](that should be s/is/are/)

and re-using output from gnupg and reformatting it (e.g. to appear
bold) just seems a bit like a hack.

Also, it makes no real sense to filter unsigned content through
gnupg and expect it to return it verbatim, IMHO.

I think check-traditional-pgp needs to learn to only pass to gnupg
those parts of a message that are marked up as inline-signed, and
put the output between the aforementioned visual markers.

Everything else should be shown verbatim in the pager, and not
passed to the gnupg tool for verification.

Am I making sense?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
a farmer is a man outstanding in his field.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

mutt feeds more to gnupg than it needs, causes invisible/lost text

[martin f krafft]

You won't see this text if mutt automatically verifies signed text
(if pgp_auto_decode is set). Run ':exec
check-traditional-pgpreturn' if you see it to get the described
effect.

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Hey folks,

I sent this message clear-signed on purpose to illustrate what
I think is a bug in the mutt-gpg integration. There's a bit of text
preceding this mail, but if you configured mutt with
pgp_auto_decode, then it filters the entire message through gnupg,
which swallows all the unsigned text.

A similar case happens when a mailing list manager appends
a MIME-part with unsubscribe information, as was the case in the
attached message to debian-devel-announce; mutt does not display
this portion of the body, as it is unsigned. You need to edit the
message to be able to see what I mean, then search for
'UNSUBSCRIBE'.

I think that mutt should not do this, it should only filter through
gnupg precisely the stuff which is marked as PGP content (/^-/)
and pass everything else verbatim.

Is this doable? Should I file a bug report?

- -- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
one should never do anything that
 one cannot talk about after dinner.
-- oscar wilde
 
spamtraps: madduck.bo...@madduck.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAksPsAwACgkQIgvIgzMMSnV72wCeLIVFzQmBREMLcwEWvLJy1yxC
BJAAn2of52aM/XbnGXs68LrxXaly/ggp
=iwJ4
-END PGP SIGNATURE-
---BeginMessage---
Hello everyone,

Over the past year or two, lots of changes have been made to the mail
handling for user mail accounts, and there are plenty of other changes
planned for the future.  All the changes below do not affect liszt or
alioth.

Some notable changes:
 - A single mail configuration template for all d.o machines
 - The busier machines use clamav with 3rd party signatures for scanning
   mail
 - packages.d.o uses spamassassin on all mail at smtp time
 - The BTS uses greylisting
 - Most machines now route through a set of gateway MXes for inbound and
   outbound delivery, letting those machines spend more time doing what
   they're meant to and less time fighting spam.

 - Users can set the envelope for their mail
 - Users can decide whether a mail should be rejected, marked up, or 
   blackholed if it gets a 'hit' during content inspection

 - Teams can have group writable mboxes or not
 - Teams can use the same anti-spam techniques (RBLs, callouts,
   greylisting, etc) as regular user accounts.
 - Teams can have some aliases be only addressable from within the d.o
   estate

Things planned for the future:
 - Breaking up the conflation between @debian.org and @$machine.debian.org
   mail handling (more on this in a seperate mail)
 - BATV checking (there is support in ud-ldap, just not yet in the exim
   configuration)
 - Users can decide to opt out of the default anti-spam setup in place.

One of the happy side effects of this is a substantial reduction in spam
across the estate.  We've stopped accepting roughly half a million mails
a day that were obviously spam, although of course we can do better.
One way you can help yourself is to log in to db.debian.org and select
the anti-spam options you feel would be helpful for your account.
For DNSBLs and RHSBLs, you'll need to use the mail gateway, as there is
not yet support in the web interface.

More notes on what the various fields mean and how they will be used can
seen in the very meager documentation [0] and more accurately here [1].

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -
[0] http://db.debian.org/doc-mail-handling.html
[1] http://git.debian.org/?p=mirror/dsa-puppet.git;a=tree;f=modules/exim;h=HEAD


signature.asc
Description: Digital signature
---End Message---


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: mutt feeds more to gnupg than it needs, causes invisible/lost

[martin f krafft]

You won't see this text if mutt automatically verifies signed text
(if pgp_auto_decode is set). Run ':exec
check-traditional-pgpreturn' if you see it to get the described
effect.

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

Hello,

also sprach Michelle Konzack linux4miche...@tamay-dogan.net [2009.11.27.1538 
+0100]:
 It seems there is a misunderstanding from you of course the parser  from
 debian because normaly the Debian Signature Parser cut off  the  GPG
 signed message and packe it into a new one with the signature  attached,
 which mean, it change te Header from gpg-signed to multipart put the
 origial signed message body in the  first  part  and  then  the  Debian-
 Signature in the second one.

This has nothing to do with the case at hand. It is true that there
seems to be a problem with the Debian list servers, and I am
following up on that. For MIME messages, the list servers *must*
attach a new part for they cannot edit existing parts which might be
signed.

The actual problem remains though. For some reason, the last message
I sent was inline *and* PGP-mime signed, thus this one is simpler to
exemplify the problem.

There's a bit of text preceding the Hello, up top of this mail,
but if you configured mutt with pgp_auto_decode, then it filters the
entire message through gnupg, which swallows all the unsigned text.

- -- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
i always choose my friends for their good looks and my enemies for
 their good intellects. man cannot be too careful in his choice of
 enemies.
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEAREDAAYFAksP6YQACgkQIgvIgzMMSnXzWgCgrgSe40w2i1Qwc3jKNMbh1cbU
xysAoLerRS2pXJkT3E90TXAuH1l6KSr5
=Qt8M
-END PGP SIGNATURE-

Re: mutt no longer renders HTML or spawns browser on text/html

[martin f krafft]

also sprach Kyle Wheeler kyle-m...@memoryhole.net [2009.11.06.0518 +0100]:
  for a few weeks now, my mutt (version info below) renders HTML 
  messages as HTML, i.e. it does not run them through w3m, which is 
  configured in mailcap as the first copiousoutput text/html viewer. I 
  also have implicit_autoview on.
 
 No idea on this one.

I managed to fix it by adding text/html to auto_view. I think it
must have been set implicitly, or in /etc/Muttrc before.

  What's worse is that hitting enter on such attachments just places 
  the raw HTML into the internal pager. If I use view-mailcap ('m'), 
  then a browser is spawned.
 
 That's easy: mutt's default behavior changed. To return your original 
 behavior, just specify it in your muttrc:
 
 bind attachments enter view-mailcap

Okay. Thanks. Actually I'll leave it as is and try to memorise
enter and 'm'. Most of the times, enter should be all I need!

Cheers!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
remember, half the people are below average.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

decoding attachments, removing signatures

[martin f krafft]

Dear mutts,

At some point last year, I thought I spotted a bug in mutt and filed
it with Debian:

  http://bugs.debian.org/474506

Alain Bench replied, but I didn't see the reply until now. Anyway,
he said:

  If I decode-save or decode-copy a mail [...] the attachment are
  removed in the copy. The attachment should stay.
 
 The design is: Auto_viewed attachments stay. Or rather their text
 representation stays. Other attachments are removed, because they are
 not renderable as text, or just not rendered in current settings
 (auto_view/unauto_view, $implicit_autoview, mailcap, ...). Look at
 upstream closed bug #1072 for complete explanations.
 
 I can foresee your next question, and the replies are decrypt-copy
 and decrypt-save. Those keep all attachments in their original form.
 
 | decrypt-copy  make decrypted copy
 | decrypt-save  make decrypted copy and delete

He was almost right. The problem is that this does not work on
signed mail. Sometimes I get signed mail with huge attachments, and
I want to remove those attachments, since I prefer to store them
outside of my mailfolder instead.

Unfortunately, decrypt-save does not seem to do anything on
PGP-signed mail, and decode-save removes all attachments.

Can I somehow remove just the signature from an email to be able to
treat a mail with attachments like any other unsigned mail?

Also, sometimes I just want to decode a single attachment and store
the decoded version in the mail, e.g. replace an attachment with its
decoded version. Is that possible?

Thanks,

-- 
 .''`.   martin f. krafft madd...@d.o  Related projects:
: :'  :  proud Debian developer   http://debiansystem.info
`. `'`   http://people.debian.org/~madduckhttp://vcs-pkg.org
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

using urlview remotely (was: pager: avoid line breaks in URLs)

[martin f krafft]

also sprach Kyle Wheeler [EMAIL PROTECTED] [2008.11.16.0453 +0100]:
  And as long as urlview cannot deal with X (I read mail on my 
  mailserver, which has no X, and want to open URLs locally), it's of 
  little use...
 
 Eh? What's X got to do with it? urlview just runs whatever program you 
 want. It can run firefox if you want it to, and if your DISPLAY 
 setting is correct, firefox will display on your local system (even 
 though it's running on the remote system). That's not the issue, the 
 issue is sending the url from the remote system to firefox running on 
 your local system, and that's got *nothing* to do with X or with 
 urlview.

Alright, you busted me with your nitpicking. :)

What I mean is: I cannot fathom a way in which I could have the
remote urlview pop up pages on my likal firefox *without* installing
firefox (and thus half of X) on the remote machine (which just won't
happen).

So the rant is against firefox, though arguably I don't know how to
fix it. The clickable (and potentially tab-able) terminal links
seemed like an elegant way out.

 Personally, that's why I use mutt locally, reading email via IMAP.

I do most of the time too, but not always.

 But it shouldn't be too hard to set up a simple little URL
 launcher that you could tunnel over ssh. The local side would be
 something really simple, like this:
 
 #!/bin/bash
 while read url ; do
 firefox -a firefox -remote openurl($url)
 done

The problem is how to tell urlview where it can find this launcher,
which may sit behind a NAT box.

 The real trick to it would be setting up ssh to do the tunnel, 
 launching the local script, and ensuring that the remote side sends 
 the URL to the right place.

Of course, I could create a TCP tunnel with ssh -R and then simply
let urlview echo URLs to netcat to hit the launcher after passing
the tunnel, but that has major shortcomings:

  - URLs are opened on the machine which has the oldest connection,
not on the local machine (when using multiple machines)
  - If the connection goes down, this stops working until a new
connection has been established

It sounds like too much trouble for too little gain.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
it's time for the human race to enter the solar system.
  - george w. bush
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

pager: avoid line breaks in URLs

[martin f krafft]

Hi,

I know of smart_wrap, but it doesn't work for text (e.g. URLs) which
is longer than the width of each line ($wrap). On such encounter,
mutt still breaks the line (and uses $markers), which prevents the
terminal emulator from making the full URL clickable. Is there a way
to prevent the wrapping for long lines without any space (which
$smart_wrap suggests) and let the terminal emulator flow the rest of
the line into the next screen line?

Thanks,

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
we americans, we're a simple people...
 but piss us off, and we'll bomb your cities.
 -- robin williams, good morning vietnam
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: pager: avoid line breaks in URLs

[martin f krafft]

also sprach Kyle Wheeler [EMAIL PROTECTED] [2008.11.15.1941 +0100]:
 That's why I created extract_url.pl 
 (http://www.memoryhole.net/~kyle/extract_url/). Many times, long URLs 
 aren't even unbroken in the original email! Personally, though, I 
 prefer to be able to load up a URL without needing to use the mouse. 
 :)

I've sent an update to http://bugs.debian.org/127090.

 Well... you could use an external pager; that might do it. Otherwise, 
 no, there's no built-in way of telling mutt not to wrap things for the 
 terminal.

I don't want an external pager. And as long as urlview cannot deal
with X (I read mail on my mailserver, which has no X, and want to
open URLs locally), it's of little use...

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
i'd rather be riding a high speed tractor
with a beer on my lap,
and a six pack of girls next to me.
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: rerunning hooks

[martin f krafft]

also sprach Kyle Wheeler [EMAIL PROTECTED] [2008.09.23.1523 +0200]:
 Not really, because it's impossible to know which hooks apply.
 Hooks are associated with actions, not with states. The send-hook
 applies whenever you attempt to *send* a message, the message-hook
 applies whenever you attempt to *view* a message, and so forth. If
 you are currently sending a message, but are relying on a setting
 that was set by viewing a message (or perhaps are relying on the
 fact that the last message you sent triggered a hook), how is mutt
 to know?

It could pretend that it's reopening the folder, or reviewing
a message, or restarting the composing of an email, etc.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
there are lies, statistics, and benchmarks.
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

rerunning hooks

[martin f krafft]

After re-sourcing my config, all the colouring and similar stuff
I do in folder_hooks is overwritten. Is it somehow possible to rerun
all applicable hooks as part of the resourcing?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
seen on an advertising for an elaborate swiss men's watch:
  almost as complicated as a woman. except it's on time
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: changing subject of all messages in a thread

[martin f krafft]

also sprach David Champion [EMAIL PROTECTED] [2008.05.06.1919 +0200]:
 prompt would be handy.  Meanwhile, you might try something like:
 
 $ cat mutt-subject-edit
[...]
 :source mutt-subject-edit |
 [tag some messages]
 tag-prefixedit-message

http://git.madduck.net/v/etc/mutt.git?a=commitdiff;h=d215fb8c4bb24685149e374ced9ab2fa5c2fd21e

seems to work ok. Thanks, David!

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
wovon man nicht sprechen kann, darüber muß man schweigen.
   -- wittgenstein
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

changing subject of all messages in a thread

[martin f krafft]

We all know it: mailing list threads often go wild and
correspondents forget to amend the subject lines appropriately. This
makes it really hard to find stuff later.

mutt can join and break threads, beautifully sort them and otherwise
makes my life a lot easier.

But... can it help me change the subject line for messages that are
part of a subthread? I know how to set $editor to get it to do this
automatically, but how do I convince mutt to spawn the editor on all
tagged messages or messages of a subthread without manually
iterating?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
writing a book is like washing an elephant: there no good place to
 begin or end, and it's hard to keep track of what you've already
 covered.
-- anonymous
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: changing subject of all messages in a thread

[martin f krafft]

also sprach David Champion [EMAIL PROTECTED] [2008.05.06.1804 +0100]:
  part of a subthread? I know how to set $editor to get it to do this
  automatically, but how do I convince mutt to spawn the editor on all
  tagged messages or messages of a subthread without manually
  iterating?
 
 set editor=perl -pi -e 's/^Subject: .*/Subject: mwahaha/;' %s
 [tag some messages]
 tag-prefixedit-message

Okay, I fell prey to having 'e' rebound. But in any case, the
problem with this is that I'd like to provide a new subject line
once for all messages, but not really redefined $editor every time.

Ideally, I'd have a keybinding doing all this, and using e.g.
$response on the right-hand-side of the regexp. Now, how do I fill
$response sensibly?

/me wants mutt to have a prompt function.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
give a man a fish, and you'll feed him for a day. teach a man to
 fish, and he'll buy a funny hat. talk to a hungry man about fish,
 and you're a consultant.
  -- scott adams
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: toggle-old

[martin f krafft]

also sprach Michael Tatge [EMAIL PROTECTED] [2007.10.10.1140 +0100]:
 I'm confused. Do you want to remove the Old (and New) flag or set N for
 a messages that was previously Old?

Ideally, I want to press N to do any of the following, depending on
context:

  current  next
  ~
  !O  !N  O
  N!O  !N
  O!O  !N

Does that make more sense?

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
be careful of reading health books -- you might die of a misprint.
 -- mark twain
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: toggle-old

[martin f krafft]

also sprach Kyle Wheeler [EMAIL PROTECTED] [2007.10.10.1245 +0100]:
   current  next
   
   !O  !N  N   --- This is the crucial difference, right?

Almost, but yes. My argument is that this behaviour should depend on
$mark_old. If that's set, the result should be O; otherwise N.

   N!O  !N
   O!O  !N

This is also a difference. Pressing N on an O message makes it N.
That may be okay, but if $mark_old is set, I'd say it should rather
clear the O flag (and set !O  !N).

Sorry for not making myself clear in the first place.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
women who want to be equal to men lack ambition.
  -- timothy leary
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: toggle-old

[martin f krafft]

also sprach Kyle Wheeler [EMAIL PROTECTED] [2007.10.10.1305 +0100]:
 That doesn't make much sense to me. If I have a read message and I say  
 toggle-new, why would mutt assume that I really wanted to 
 toggle-old? Perhaps what's needed is a different function?

Sure. I am not talking about toggle-{new,old}, just about the
behaviour I expect. It makes no sense ever to mark a message new if
I already distinguish between new and old.

 Ahhh, right. I guess this gets down to exactly what toggle-new
 is supposed to mean. At the moment, obviously, it means if not
 new, make it new, else if new, make it not-new, which is a very
 straightforward use of the definition of the word toggle.

Except it's a tri-state and you cannot toggle tri-states. You only
rotate them. :)

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
if con is the opposite of pro, is congress the opposite of progress?
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

toggle-old

[martin f krafft]

Dear list,

It seems impossible to remove the O flag on messages without the use
of Wo, Wn, or NkN (assuming $resolve is set), which is 200% to 300%
of the work I am willing to put into this. Does anyone know of
a better way to approach this?

I came up with

  macro index,pager N :set my_resolve=$resolveenter:unset
resolveentertoggle-newclear-flago:set
resolve=$my_resolveenternext-message

but with that in place, I now have to use wn to mark messages as new
(the point of which is doubtful, as the messages aren't new anymore,
but many people use inboxes as todo lists, and I kind of still do
too).

So then I started wondering about the point of toggle-new,
especially with $mark_old set. Wouldn't it make more sense if
toggle-new toggled the O flag when $mark_old was set?

How do you do it?

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
syntactic sugar causes cancer of the semicolon.
-- epigrams in programming
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: changing the subject line of a thread

[martin f krafft]

also sprach Gary Johnson [EMAIL PROTECTED] [2007.08.31.0746 +0200]:
 Patch submitted to mutt-dev.

Muchas gracias!

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
it may look like i'm just sitting here doing nothing.
but i'm really actively waiting
for all my problems to go away.
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: changing the subject line of a thread / sed zen

[martin f krafft]

also sprach Kyle Wheeler [EMAIL PROTECTED] [2007.08.28.2158 +0200]:
 you just got really lucky). The way mutt determines whether a file is 
 modified is by comparing the mtime of the temp file it created to the 
 mtime of the temp file once the editor is done editing. The mtime is 
 stored in seconds. Sed, of course, executes in less than a second, so 
 the mtime is unchanged in all but the rarest of cases.

Perfect explanation, thanks Kyle!

 It would work if you'd piped it to a script like this:

You don't even need an editor:

  set editor=sleep 1  sed -i -e ...

works just as well. On that note, however, you probably want formail
instead, due to multiline headers, but formail cannot edit in-place.
Thus, you'll need a script. :(

Or well, maybe not. The following sed -rn snippet extracts
a multiline header (name stored in $1):

  :s;/^\$/q;/${1}/bj;d;:j;P;\$!n;/^[[:space:]]/bj;bs

It should not be too hard to come up with a sed recipe that replaces
the subject. My first try failed though (again, with -re):

  :s;/^$/be;/^Subject:/bj;P;:j;n;/^[[:space:]]/bj;=;bs;:e;p;:e2;n;p;be2

This correctly removes the subject. Where the = is, I wanted to
insert a new Subject line:

  :s;/^$/be;/^Subject:/bj;P;:j;n;/^[[:space:]]/bj;iSubject: new -e 
bs;:e;p;:e2;n;p;be2

but for some reason, that gets called after *every* header. And yet,
the script should never reach that except after encountering
/^Subject:/ in the header, when it spins in the j loop until the
next header is found. *Then* and only then should it insert the
Subject. I am not a sed guru, so if anyone has a clue, please let me
know.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
this message represents the official view of the voices in my head.
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

changing the subject line of a thread

[martin f krafft]

Hi mutts,

The world is full of people with email accounts, who have no idea
how to email; or well, what it's like to get hundreds of messages in
a day and try to stay on top of the information overload.

So someone might reply to a work-related message, asking whether we
should go to the cinema tonight. Usually I just delete such
messages, but in one case, a massively interesting discussion
evolved, and is now 25 messages long. I broke the thread ('#'), but
since I have $strict_threads=off (and need that off because other
correspondents use broken MUAs that don't generate I-R-T headers)
and the subject line is still the same, the cinema thread is still
listed as related to the work thread.

So I wanted to change the subject line on all thread mails. First,
I missed the pass (Maildir) files of tagged messages to external
command as *arguments* command in mutt, so I had to create a new
folder and put the files in there, then go to the shell and invoke
sed. An alternative would have of course been to set $editor to the
sed -i command, but I could not get this working. Even setting
editor=sed -i -e '/./d' just got me message not modified.

But then, and rather weird, after touching up the Subject: header in
all messages, mutt suddenly fails to verify the GPG signatures (and
still shows the old subject everywhere but in the pager).

So I tracked this down to the header_cache (can I tell mutt to
remake that?) and after I had deleted it, I got what I wanted.

Now my question simply is: is there a better way to change the
subject of messages in a thread, such that mutt is actually aware of
it and I don't have to coerce it to accept the change?

Cheers,

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
one morning i shot an elephant in my pyjamas.
how he got into my pyjamas i'll never know.
   -- groucho marx
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

only from pager: source: errors in .mutt/muttrc

[martin f krafft]

Hi, I receive the warning

  source: errors in /home/madduck/.mutt/muttrc

whenever I resource the muttrc from the pager:

  :source /home/madduck/.mutt/muttrc

It works fine from the index and the compose menu.

I checked the keybindings but I don't have any pager-only bindings,
and I cannot fathom what other reason there might be.

How can I figure out what's responsible here? Can I get mutt to give
me a line number? Of course, I could bisect my configuration, but
there has to be a better way to do this.

Thanks,

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
an avocado-tone refrigerator would look good on your resume.
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: CC'ing list people but not getting CC'd?

[martin f krafft]

also sprach Kai Grossjohann [EMAIL PROTECTED] [2007.08.21.2215 +0200]:
- Someone else replies to *my* mail in the same way, and his
  mailer honours MFT, so no *you* also get CC'd on the reply, even
  though the subject may have diverged and you're not interested
  anymore.
 
 I asked for Ccs, so I got what I deserved.
 
 If I subscribe to a list, then I get all postings, even though I might
 only be interested in part of the topics.  That's the same thing, isn't
 it?

No; from what I understand, M-F-T keeps growing, so when I reply to
your mail (which had your M-F-T on it), my M-F-T also includes your
address. That's a legitimate criticism, to be honest, or don't you
hate those ever growing CC lists, which are basically the same?

 It's not clear to me what Junio wants.  If we wants no Cc's, then
 he can just put in an MFT header that excludes himself.  Shouldn't
 he then be a great fan of MFT since it allows him to express what
 he wants?

He wants CCs.

 Also, my Gnus terminology might not map well to a Mutt audience.
 Apologies for this.  For example, I don't really know what is a
 list-reply, so the above could be wrong.

The manual describes it as:

  Reply to the current or tagged message(s) by extracting any
  addresses which match the addresses given by the lists or
  subscribe commands, but also honor any Mail-Followup-To header(s)
  if the $honor_followup_to configuration variable is set. Using
  this when replying to messages posted to mailing lists helps avoid
  duplicate copies being sent to the author of the message you are
  replying to.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
solange man nicht die moral des christentums
 als kapitalverbrechen am leben empfindet,
 haben dessen verteidiger gutes spiel.
 - friedrich nietzsche
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: CC'ing list people but not getting CC'd?

[martin f krafft]

also sprach Kai Grossjohann [EMAIL PROTECTED] [2007.08.18.0202 +0200]:
 Which email client does he use?  He claims that MFT is used for replies,
 but the name suggests that it should be used for followups, not replies.

User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Sure, MFT implies followup, but isn't that pretty much the same as
list-reply? I think his issue is with:

  - you like CCs to the list, so you set MFT on all your mails to
the list address as well as yours.
  - I see your mail and reply to it, mutt sees the MFT and preserves
it. It needs not add the list address, and I don't want it to
add mine, so it copies the MFT header with the list address as
well as yours to my mail.
  - Someone else replies to *my* mail in the same way, and his
mailer honours MFT, so no *you* also get CC'd on the reply, even
though the subject may have diverged and you're not interested
anymore.

I generally don't mind following threads to which I have posted,
even if they diverge (I have a good thread/subject blacklisting in
place). However, Junio doesn't, and at least wrt git, he's way more
active, so I ought to really respect his preferences.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
click the start menu and select 'shut down.'
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: CC'ing list people but not getting CC'd?

[martin f krafft]

also sprach Nicolas Rachinsky [EMAIL PROTECTED] [2007.08.17.1303 +0200]:
 If you do this bind in a message-hook, it should solve the problem, if
 you reply to a message from the pager. And you can bind L in the index
 to a macro that opens the message and does an L again. I haven't tried
 this, but I think it should work.

Okay, this does work as you say.

In the mean time, however, I found that Junio, the git maintainer,
really just dislikes M-F-T:

  http://marc.info/?l=gitm=113882569532399w=2

Thus, I better comply and *stop* setting the header altogether.

  send-hook . 'set followup_to'
  send-hook '~C [EMAIL PROTECTED]' 'unset followup_to'

I am also experimenting with another solution: if I use my procmail
filters to *add* the Mail-Followup-To header, including all
From/To/Cc addresses, but have followup_to unset as per the above,
I *should* get the desired effect: list-reply would honour M-F-T and
put everyone including the mailing list on To/Cc, but since mutt
does not add the header by itself, it is not on the outgoing
message.

I have yet to verify this and publish the solution to the git
mailing list. But if you have comments right now, I'd love to hear
them!

Cheers,

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
cs class at 8:30am. ugly. if you can wake up early enough to get
 good grades here, you need to develop hacker habits...
 -- jeff bailey on #debian-devel
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

CC'ing list people but not getting CC'd?

[martin f krafft]

Dear list,

on the git mailing list, people seem to prefer being CC'd on list
posts. After I trained myself for years to use list-reply instead
of group-reply, I am now faced by the challenge to meet their
desires while not offending the others (e.g.
[EMAIL PROTECTED]).

I realise that an easy solution would be for all *other* subscribers
(at least those who use mutt) to s/subscribe git/lists git/ in their
config, but I can hardly expect everyone to do so.

So I am trying to come up with a solution that fits the list policy
and also doesn't involve me to go out of my way. I could obviously
simply 'unsubscribe [EMAIL PROTECTED]', but that would have two
bad effects:

  - list-reply no longer works, forcing me to go back to
group-reply the hard way.
  - mutt won't add the M-F-T header to mail I send, which means
I'll get CC's to git list mail, which I don't want.

One solution would be to bind L to group-reply for the git
mailing list, but a reply-hook is too late for that, and I don't
have a special folder for git mail.

Is there another way, in which mutt could assist me with my quest?
I really don't want to get back into the habit of using
group-reply for mailing lists...

Thanks,

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
one has to multiply thoughts to the point
where there aren't enough policemen to control them.
   -- stanislaw jerzey lec
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: save-message from a reply-hook

[martin f krafft]

also sprach Michelle Konzack [EMAIL PROTECTED] [2007.08.08.1923 +0200]:
 reply-hook '~t [EMAIL PROTECTED]' \
'my_hdr Fcc: =.Peoples.Michelle_K/'

This saves the message I send to =.Peoples.Michelle_K/ whereas
I want to store the message to which I am replying. I'd use fcc-hook
for what your hook does.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
whatever you do will be insignificant,
but it is very important that you do it.
 -- mahatma gandhi
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

save-message from a reply-hook

[martin f krafft]

Hi list,

I file my sent and received mail in the same folder ('store') and
use mutt threading to keep track of conversations. When I receive
a mail, I might reply, which causes the reply to be written to
'store', and if I don't forget, I'll then file the received message
there too.

But I do occasionally forget. Thus I would like to automate the
saving and I thought to myself: reply-hook!

However, reply-hook regex 'save-message=store\n' does not work
and complains that save-message=store\n is an unknown command.

Short of rebinding the r/g/L reply keys to macros, can you think of
other approaches?

Thanks,

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
the mind of the thoroughly well-informed man is a dreadful thing.
 it is like a bric-à-brac shop, all monsters and dust,
 with everything priced above its proper value.
-- oscar wilde
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

replacing reply with savereply (was: save-message from a reply-hook)

[martin f krafft]

Thanks for your time and interest!

also sprach Rado S [EMAIL PROTECTED] [2007.08.04.1345 +0200]:
 c) In that case you could aswell use a macro to replace reply with
 save-message...enterreply

I have tried this now and it would do the work, but I am still one
step short from happiness. Right now I have the following macro for
list-reply:

  :set my_resolve=$resolveenter:unset resolveenter
   save-message=storeenter
   :set resolve=$my_resolveenter
   list-reply

The problem with this is that the message is filed even if I don't
actually reply then (if the machine crashes or I simply decide to
write later). Thus I tried:

  list-replysave-message=storeenter

but this has the problem that save-message is now executed in the
context of the compose view and thus tries to save the main
attachment to the mailbox, which is clearly not what I want.

I thus would like to achieve two things:

  1. only save the message when list-reply returns to the
 pager/index, but not if mutt says Message not sent.

  2. execute save-message only after returning to the pager/index
 from where the macro was called.

 See http://WIKI.mutt.org/?MuttGuide - /Syntax + /Actions (and all
 the rest, too ;), and also DebugConfig for clues about quoting and
 hooks.

I read up on those but have not really found an answer to either
question.

  Short of rebinding the r/g/L reply keys to macros, can you think of
  other approaches?
 
 mbox-hook, fcc-hook.

fcc-hook is for sent mail. Once a mail is sent, it goes to =store
anyway. I don't need any distinctions and thus no hooks here.

mbox-hook doesn't square with my workflow since I may read a message
and then keep it in my inbox until it's dealt with.

Now, if mbox-hook would actually let me use mutt patterns and
I could say things like '~Q !~N' as a condition to move messages to
=store, then I'd have almost exactly what I want, except for the
rare cases when I'd 'exit' mutt or e.g. the ssh session die, so the
mbox-hook would never be executed. I think I could live with those.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED]
 
... (ethik und ästhetik sind eins.)
   -- wittgenstein
 
spamtraps: [EMAIL PROTECTED]


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: Color mails which are a reply to a mail from me?

[martin f krafft]

also sprach Gerhard Siegesmund [EMAIL PROTECTED] [2002.01.05.2347 +0100]:
 I don't know if it is at all possible, but I loved this feature with
 crosspoint (in the old times of fido-net). Is it possible to color (in
 the index) a mail which is a reply to a mail from me? So that I can see
 very fast if someone answered me in a list? (Hope this is not a FAQ).

i only want this for folders in the lists subdirectory, so:

folder-hook . uncolor index \!(~N | ~G) \
  (~p | ~b 'martin|madduck|krafft' | ~s 'martin|madduck|krafft'\)
folder-hook . uncolor index \!~G ~N \
  (~p | ~b 'martin|madduck|krafft' | ~s 'martin|madduck|krafft'\)

folder-hook lists color index brightblack default \!(~N | ~G) \
  (~p | ~b 'martin|madduck|krafft' | ~s 'martin|madduck|krafft'\)
folder-hook lists color index brightred default \!~G ~N \
  (~p | ~b 'martin|madduck|krafft' | ~s 'martin|madduck|krafft'\)

these will simply make all mails somehow addressed to me, or mentioning
my name appear bold... red if new and black if read.

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; net@madduck
  
if I can't dance, i don't want to be part of your revolution.
- emma goldman



msg22367/pgp0.pgp
Description: PGP signature

Re: next/prev unread

[martin f krafft]

don't you just love people who GPG/PGP encrypt messages and send them to
a mailing list? especially mutt-users, given that mutt can handle
GPG/PGP just fine...

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^.*|tr * mailto:; net@madduck
  
someday we'll find it
the rainbow connection
the lovers, the dreamers,
and me!
 -- kermit



msg22292/pgp0.pgp
Description: PGP signature