Re: highlighting *bold* and _underline_ in mutt
[33;1m[-- PGP output follows (current time: Wed Sep 2 11:15:01 2015) --][0m gpg: Signature made Wed Aug 19 22:17:44 2015 CEST using RSA key ID 0312C726 gpg: Good signature from "mwnx " Primary key fingerprint: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726 [33;1m[-- End of PGP output --][0m [33;1m[-- BEGIN PGP SIGNED MESSAGE --][0m On Wed, Sep 02, 2015 at 07:49:08AM +1000, Cameron Simpson wrote: > >>I'm not sure there's really any security risk in allow_ansi. [...] > >>it seems to allow only colors and text attributes (bold, > >>underline, etc). It doesn't appear to do anything with the more > >>dangerous sequences. [...] > >it isn't passing the ANSI >sequences _through_ to the display. It is > >parsing a few and setting the various markup features in the output, which > >are then rendered in the normal curses highlighting/colouring processes. > > As an illustrative example, the "_through_" above is displayed on my > terminal in cyan, _not_ underlined. This is because my muttrc says: > > color underline $colour_hl1 default > > and $colour_hl1 is currently cyan. This illustrates that the source ANSI > sequence is not passed through. > > Cheers, > Cameron Simpson > > No, I haven't read 'Illuminatus' myself, although I do know of it. Perhaps I > might find some _more_ information in this book to back up these claims. >- j...@ibis.dsto.gov.au (James Marcus) Well my concern is with the possibility of faking PGP related messages, as mentioned in the manual: Messages containing these codes are rare, but if this option is set, their text will be colored accordingly. Note that this may override your color choices, and even present a security problem, since a message could include a line like [-- PGP output follows ... and give it the same color as your attachment color (see also $crypt_timestamp). Oh, by the way, if you're using the default (I think it's default) bold yellow coloring for GPG messages, you might not have noticed that this message isn't actually GPG signed if you didn't bother to check the timestamp. I know I don't usually bother to. -- mwnx GPG: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726 [33;1m[-- END PGP SIGNED MESSAGE --][0m
[Macro] Control index menu with arrows
Hi, all I asked some question yesterday about how to redefine the same key using a macro. Subject title was: [Macro] Redefine the same key ( key) Finally I had found a way to make it work "almost" as expected: my not working old macro needed sequence to be enclosed in single quotes instead in double ones. Now I've upgrade yesterday macros to control index menu better. So I decided to share them here so that you can comment, add ideas and so on... Expected behaviour when arrow keys are pressed: 1. When I enter in a mailbox I'm in front of mutt index menu: I've configured it to show one thread per line, all threads collapsed whit %M flag in index_format, so I can distinguish single message by multi message threads. 2. I want to close current mailbox by type "left" key and return to browser menu with all mailboxes listed one per line. 3. When I'm selecting a multi messages thread I want to view it expanded in a clean screen by pressing "right" key. The other threads will be hidden. If I'm selecting a single message thread I want that same "right" key just display that message (so entering in pager menu). I have not found a solution for this conditional behaviour. To summarize: --- if thread has just one message display it else hide other threads expand current thread endif --- 4. When I'm in front of screen that contains just one multi message thread expanded, I want to return to my all thread screen by pressing "left" key. And I want to open selected message by pressing right key. Here a scheme: enter in mailbox (from browser menu, I use right key to enter in selected mailbox). --- left key ---> quit mailbox and return to browser menu right key ---> display message if single message thread is selected | --> show expanded multi messages thread alone | --> right key ---> open selected message --> left key ---> return to all threads (collapsed) view --- And here we have my macros from my muttrc: --- set hide_top_limited=yes macro index onethr "~T\n" macro index allthr "all\n" macro index st1lft ' push allthr; \ macro index \ defrgt; \ macro index \ deflft' macro index defrgt ' push onethr; \ macro index \ ; \ macro index \ st1lft' macro index deflft '?' macro index defrgt macro index deflft --- As I said, the only thing missing is the conditional behaviour of key: with my above macro if I open a single message thread, mutt first shows that "thread" alone in one screen, and then I've to press again to display the only message contained. It's not a great problem, but if mutt had conditional actions support I would have solved also this point. So, If you have any hints, suggests, comments, welcome! Hope this message will be useful. :)
Archived messages, where do they go?
I have a FastMail account and have set up a macro to send messages to the Archive: macro index,pager y "Archive" "Archive" However when I do this and then check in the webmail they are not in the Archive (and not in the Inbox). Where are they going?
Re: Archived messages, where do they go?
I'm using FastMail with mutt, though I'm not using macros to save messages. I'm not sure what your other config looks like, so I'm not sure how useful this will be to you. I'll post below my FastMail-specific muttrc settings for reference, but I'm just using the default "s" keybinding to (optionally tag and) save to Archive or elsewhere. Works on my machine, as they say... set folder = imaps://$my_usern...@mail.messagingengine.com:993/ set spoolfile = imaps://$my_username:$my_p...@mail.messagingengine.com:993/INBOX set postponed = "=INBOX.Drafts" set record = "=INBOX.Sent" mailboxes =INBOX Hope that helps. JM On Wed, Sep 02, 2015 at 08:19:12AM -0400, Matthew Phillips wrote: I have a FastMail account and have set up a macro to send messages to the Archive: macro index,pager y "Archive" "Archive" However when I do this and then check in the webmail they are not in the Archive (and not in the Inbox). Where are they going? signature.asc Description: Digital signature
Re: Archived messages, where do they go?
On 2015-09-02 08:19 -0400, Matthew Phillips wrote: > I have a FastMail account and have set up a macro to send messages to > the Archive: > > macro index,pager y "Archive" "Archive" > > However when I do this and then check in the webmail they are not in the > Archive (and not in the Inbox). Where are they going? Have you checked for a local file named Archive? -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: Archived messages, where do they go?
On Wed, Sep 02, 2015 at 08:06:24AM -0700, Ian Zimmerman wrote: > On 2015-09-02 08:19 -0400, Matthew Phillips wrote: > > > I have a FastMail account and have set up a macro to send messages to > > the Archive: > > > > macro index,pager y "Archive" "Archive" > > > > However when I do this and then check in the webmail they are not in the > > Archive (and not in the Inbox). Where are they going? > > Have you checked for a local file named Archive? > > -- > Please *no* private copies of mailing list or newsgroup messages. > Rule 420: All persons more than eight miles high to leave the court. > Indeed, there is a local file named Archive! So that's where they've been going. So, I got it to work by prefixing everything with INBOX: macro index,pager y "=INBOX.Archive" "Archive" I admit I don't fully get what is going on here. I don't know what this magical "INBOX" is or how mutt knows that it means store it on the imap server. I don't know what a spoolfile is or what mailboxes is (mine is =INBOX). Oh, and I don't know why so much configuration is prefixed by =. But it works! And that's a start.
Re: mutt mail archives
On Tue, Sep 01, 2015 at 04:49:16PM +0200, bastian-muttu...@t6l.de wrote: > The mutt homepage [1] links to the mutt mailing list archives for -users > [2] and -dev [3]. Both are not reachable (at least right now). Thanks for the report, we've just updated the website. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA http://www.8t8.us/configs/gpg-key-transition-statement.txt signature.asc Description: PGP signature
BADSIG with 1.5.24.
I do not have a lot of use for encrypting my mail, but it is (sometimes) interesting to look at the signatures of signed mail on the lists - and using signed git tags for anything which I release sounds like a good idea. >From time to time I have seen mails on lkml which gpg reports as BADSIG, but not been too worried about it. But today I tried sending myself (at a different address) a signed mail. The sent copy shows: [-- PGP output follows (current time: Wed 02 Sep 2015 16:25:09 BST) --] gpg: Signature made Wed 02 Sep 2015 15:42:35 BST using RSA key ID 3043C26D [GNUPG:] SIG_ID W56zzth79uXoGGJlCnNbs4NSh70 2015-09-02 1441204955 [GNUPG:] GOODSIG 78930DB93043C26D Ken Moffat (ntlworld address) gpg: Good signature from "Ken Moffat (ntlworld address) " [GNUPG:] VALIDSIG 08AA8A7D1D980359F39DACEA78930DB93043C26D 2015-09-02 1441204955 0 4 0 1 2 01 08AA8A7D1D980359F39DACEA78930DB93043C26D [GNUPG:] TRUST_ULTIMATE [-- End of PGP output --] But when I received it (via a .forward file) it was unimpressive: [-- PGP output follows (current time: Wed 02 Sep 2015 16:25:39 BST) --] gpg: Signature made Wed 02 Sep 2015 15:42:35 BST using RSA key ID 3043C26D [GNUPG:] BADSIG 78930DB93043C26D Ken Moffat (ntlworld address) gpg: BAD signature from "Ken Moffat (ntlworld address) " [-- End of PGP output --] Comparing the files, the sent-mail copy was in two parts with boundaries starting --bg... : text/plain us-ascii for the text, application/pgp-signature; name="signature.asc" for the GnuPG v1 signature. And the received was 8bit utf-8 with no indication of the signature. I had pasted some of the output (after showing the headers), and been able to see the signature in the sent mail, but not in what I received. But now when I try that I cannot see the signature even in the sent mail. This is *really* doing my head in ;) Searching for a straw to pull on (google mostly finds posts about bad signatures in apt-get), I took a look at some of today's signed posts on lkml. First, a good one: Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" for this one, there is no Content-Disposition Next, two bad ones: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KUplgXDa5OCjEs8pbWXqfHVv1o4NnLftB" and for my own bad one: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline Is the fact that bad signatures are showing up with "random" boundary identities (i.e. not =-=-=) and Content-Disposition: inline an indication of a problem, or am I flailing randomly in the dark ? Help! Please. ĸen -- Il Porcupino Nil Sodomy Est! (if you will excuse my latatian) aka "The hedgehog song"
Re: BADSIG with 1.5.24. - not solved, but not mutt
On Wed, Sep 02, 2015 at 06:47:53PM +0100, Ken Moffat wrote: > I do not have a lot of use for encrypting my mail, but it is > (sometimes) interesting to look at the signatures of signed mail on > the lists - and using signed git tags for anything which I release > sounds like a good idea. > Snipping most of this, it is not mutt. But any suggestions are still welcome. I tried putting 1.5.23 in /usr/local for testing - and that shows the exact same results. All my mail is on my "server" (the machine which serves up sources, my notes, media files to my local network). The only things which have been updated there this year (and I did not seem to have a problem until recently) are the linux kernel and openssl. Oh, and I updated smartmontools yeaterday, but that is not likely to be relevant. But a small update on my theory - > Searching for a straw to pull on (google mostly finds posts about > bad signatures in apt-get), I took a look at some of today's signed > posts on lkml. > > First, a good one: > > Content-Type: multipart/signed; boundary="=-=-="; > micalg=pgp-sha1; protocol="application/pgp-signature" > > for this one, there is no Content-Disposition > > Next, two bad ones: > > Content-Type: multipart/signed; micalg=pgp-sha256; > protocol="application/pgp-signature"; > boundary="d6Gm4EdcadzBjdND" > Content-Disposition: inline > > Content-Type: multipart/signed; micalg=pgp-sha256; > protocol="application/pgp-signature"; > boundary="KUplgXDa5OCjEs8pbWXqfHVv1o4NnLftB" > > and for my own bad one: > > Content-Type: multipart/signed; micalg=pgp-sha1; > protocol="application/pgp-signature"; > boundary="bg08WKrSYDhXBjb5" > Content-Disposition: inline > > Is the fact that bad signatures are showing up with "random" > boundary identities (i.e. not =-=-=) and Content-Disposition: inline > an indication of a problem, or am I flailing randomly in the dark ? Using 1.5.23, I looked at signed mails on this list. That showed my theory is wrong : the mail from Brendan Cully announcing 1.5.24 has the non =-=-= boundary with inline disposition but is good, whereas that from Kevin J. McCarthy is similar but bad. Any ideas, please ? ĸen -- Il Porcupino Nil Sodomy Est! (if you will excuse my latatian) aka "The hedgehog song"
Re: BADSIG with 1.5.24. - not solved, but not mutt
On 2015-09-02 19:50 +0100, Ken Moffat wrote: > Using 1.5.23, I looked at signed mails on this list. That showed my > theory is wrong : the mail from Brendan Cully announcing 1.5.24 has > the non =-=-= boundary with inline disposition but is good, whereas > that from Kevin J. McCarthy is similar but bad. FWIW, my mutt (1.5.21) successfully verifies both. I would suspect GnuPG first. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: highlighting *bold* and _underline_ in mutt
On 02Sep2015 11:31, mwnx wrote, with embedded ANSI escapes: ^[[33;1m[-- PGP output follows (current time: Wed Sep 2 11:15:01 2015) --]^[[0m gpg: Signature made Wed Aug 19 22:17:44 2015 CEST using RSA key ID 0312C726 gpg: Good signature from "mwnx " Primary key fingerprint: AEC9 554B 07BD F60D 75A3 AF6A 44E8 E4D4 0312 C726 ^[[33;1m[-- End of PGP output --]^[[0m [...] As an illustrative example, the "_through_" above is displayed on my terminal in cyan, _not_ underlined. [...] This illustrates that the source ANSI sequence is not passed through. [...] Well my concern is with the possibility of faking PGP related messages, as mentioned in the manual: Messages containing these codes are rare, but if this option is set, their text will be colored accordingly. Note that this may override your color choices, and even present a security problem, since a message could include a line like [-- PGP output follows ... and give it the same color as your attachment color (see also Oh, by the way, if you're using the default (I think it's default) bold yellow coloring for GPG messages, you might not have noticed that this message isn't actually GPG signed if you didn't bother to check the timestamp. I know I don't usually bother to. You're right, I had not noticed. Disturbing. On this issue, I have commented out my "color" and "mono" directives for "bold" and "underline", which at least gets me bold and underline ANSI sequences transcribed as the terminal's bold and underline. [ Aside: I discovered that I had to comment these out; I couldn't say "colour underline underline default" - mutt rejects "underline" as a colour! ] Still, I can see that allowing ANSI through conflicts with mutt's coloured markup of boundaries (signatures, attachment markers etc). What is a sensible approach here? Cheers, Cameron Simpson
