Re: fastmail and ssl?
Tom Fowle wrote: > Am trying to get mutt 1.5.2 to connect to fastmail.fm using ssl. Hopefully you mean 1.5.21? > I've set everything in .muttrc I can find to use ssl E.G. > set folder=imaps://mail.messagingengine.com:993/ssl/inbox/ I use fastmail, and have the settings: set imap_user=xxx set imap_pass=xxx set folder=imaps://mail.messagingengine.com/INBOX That should be all you need (for the imap part). > If I try > #set imap_force_ssl = YES Check the doc at http://www.mutt.org/doc/devel/manual.html. At least in 1.5.21 there isn't any such option. > Looked in the manuals and wikki, found nothing that seemed to relate > specifically to fastmail. You're welcome to look at my settings at http://www.8t8.us/mutt/muttrc.local.fastmail.txt > Am using esmtp for send authentication, perhaps old prog doesn't do ssl, but > should work at least for receive. Mutt now has built-in smtp, and you may also want to check out msmtp. -Kevin
Re: mailing list subject line tags
Derek Martin wrote: > Bizzare. The only factor which is obvious to me as a possible > differentiating factor is that the first is quoted printable, and the > second is plain text. I'm assuming that the first was QP because > there was a line that started with "from", whereas the second had > none. I can't for the life of me figure out why that would be happening > though... I thought it might be because I was not setting my charset > (in gnupg options), and using UTF-8 (the default of iso-8859-1 is > assumed, according to the docs). The quoted-printable is indeed the issue, because trailing whitespace in your non-encoded emails are causing the failure. Looking at https://tools.ietf.org/html/rfc3156 (section 5, list item (4)) the contents of a signed email are not allowed to having trailing whitespace. Mailers usually first encode in Quoted-Printable or Base64 MIME before signing to preserve any trailing whitespace (and protect lines starting with "From".) Your non-validating emails are not being encoded for some reason, and have trailing whitespace. Interestingly if I manually strip the whitespace and canonicalize line endings, the signature passes. So somehow you are correctly generating the signature (with trailing whitespace removed), but are sending the email out with the whitespace added back on. Now, I'm not sure *why* mutt would be doing this. Perhaps someone more knowledgeable will have suggestions. Do you have any strange hooks or non-default gpg settings in your muttrc that would turn off QP? -Kevin signature.asc Description: Digital signature
Re: mailing list subject line tags
Kevin J. McCarthy wrote: > Now, I'm not sure *why* mutt would be doing this. Perhaps someone more > knowledgeable will have suggestions. Do you have any strange hooks or > non-default gpg settings in your muttrc that would turn off QP? Sorry to reply to myself. Looking at the mutt source, the pgp_strict_enc option seems like a likely culprit for this behavior. Mutt won't QP encode trailing space emails unless this is set. Do you by chance have this option turned off? -Kevin signature.asc Description: Digital signature
Re: mailing list subject line tags
Derek Martin wrote: > On Fri, Nov 02, 2012 at 02:37:01PM -0500, Derek Martin wrote: > > > Sorry to reply to myself. Looking at the mutt source, the > > > pgp_strict_enc option seems like a likely culprit for this behavior. > > > Mutt won't QP encode trailing space emails unless this is set. > > > > > > Do you by chance have this option turned off? > > > > That looks to be it. Odd though, this part of my muttrc hasn't > > changed in uh, like 12 years or something (I originally copied it from > > somewhere, so there's a reason it's there, I just can't remember why). > > Strange that it's only been an issue in the last one or two. This did seem to be it. The last two emails both verify correctly for me. Perhaps this option did other things 12 years ago, or there were strange compatibility issues at that time. > And stranger still is that the copy of the message that I receive from > the mailing list ALWAYS VERIFIES CORRECTLY on my end. Perhaps there is some option or version difference with gpg. Maybe something in your settings is automatically trimming trailing whitespace when verifying signatures. Are you using gpgv1 or v2? What is your pgp_verify_command set to? -Kevin signature.asc Description: Digital signature
Re: mailing list subject line tags
Kevin J. McCarthy wrote: > Derek Martin wrote: > > And stranger still is that the copy of the message that I receive from > > the mailing list ALWAYS VERIFIES CORRECTLY on my end. > > Perhaps there is some option or version difference with gpg. Maybe > something in your settings is automatically trimming trailing whitespace > when verifying signatures. Are you using gpgv1 or v2? What is your > pgp_verify_command set to? Replying to myself again. You appear to be using gpg v1.4.5. Version 1.4.8 introduced many changes to default functionality (with the release of RFC-4880). I think that is the reason some people are verifying your signatures and others are not. If I add the flag '--rfc2440' gpg reverts to the old behaviour and successfully validates the signatures to your emails with trailing whitespaces. -Kevin signature.asc Description: Digital signature
Re: What use is the mbox variable?
Chris Green wrote: > So, what good is it? If one sets spoolfile then there's nothing more to > do is there and mbox is redundant. Or am I missing something obvious? Having an mbox in your home directory was more useful on shared systems with quotas. Typically the spoolfile quota was fairly small compared to the home directory quota. Quotas aside, it can also be useful for archiving read mail. > ... or does it mean that mail will actually be *moved* from my spoolfile > to mbox as I read it? The $mbox setting is used by $move or by mbox-hooks, and allows you to move read messages out of your $spoolfile when changing to another folder or exiting mutt. > My mail is delivered by a custom script to ~/Mail/In/inbox and various > other places which are specified in the mailboxes setting in muttrc. > Does even spoolfile add anything to this? Setting $spoolfile is a good idea. It controls the directory mutt looks in when it first starts, and sets the "!" mailbox shortcut. -Kevin signature.asc Description: Digital signature
Re: gpg integration
Florian Lohoff wrote: > i am a long time mutt and gpg user but still the gpg integration is kind > of lacking. > > - I'd like to define recipients including their gpg key id to use. > - Better - Mutt/Procmail could help by looking out for signed mails > which tell the recipient has a mail setup which is gpg enabled > - On sending email mutt automatically checks if the recipients are _all_ > gpg enabled and encrypts automatically with all necessary keys if > possible. Hi Florian, I like your idea. Sorry I don't have a solution, but just a general suggestion. At first I thought you might be able to execute a script in a send-hook or send2-hook that would make more intelligent decisions based on the recipients: send-hook . 'source check-for-encryption.sh |' but there doesn't seem to be an obvious way to get at the current message inside the script. Perhaps another solution would be to create a vim/emacs script that could add a 'Pgp: E' pseudo header to the message, based on the To and Cc headers. You would need to turn on $edit_headers for that to work. -Kevin signature.asc Description: Digital signature
Re: mutt && sending inline attachments
Matthias Apitz wrote: > I want to send out an e-mail with an inline JPEG attachments... > > I set (based on some hint) in my .muttrc > > set attach_format="%u%D%I %t%4n %T%.40d%> [%.7m/%.10M, %.6e%?C?, %C?, %s] " > > which seems to be the default in any case if I look into muttrc(5) > and I use from the cmd line: > > $ mutt -s "mail test" -a file.jpg test.html -- g...@unixarea.de < test.txt > > But the Content-Disposition remains "attachment". I think you can only toggle the content-disposition from inside mutt, in the compose menu (ctrl-d). I don't think there's a way to do it if you're just sending directly from the command line. The attach_format you set only controls how attachments are displayed in the compose menu. It doesn't have any effect on the behavior of mutt with respect to attachments. -Kevin signature.asc Description: Digital signature
Re: Config Files, and Remaining Confusion with html-mail
Alan McConnell wrote:
> Re "Race Conditions". Unless I am mistaken, mutt is
> written as a single, un-threaded process; I believe that
> 'me' is (justly) proud of this achievement. So I do
> not understand how "two processes" can be involved here.
I see you posted an email about this back on December 19th too.
Although I thought Patrick Shanahan explained it clearly then, and just
now Mark H. Wood did again, I'll take a shot and try to (even) more
verbosely explain what is going on and why it's causing you a problem.
The normal view attachment process for mutt is:
1. Create temp file
2. Launch viewer process
3. Wait for viewer to exit
4. Delete temp file
Assuming you already have a main firefox window running, when you
invoke "firefox -new-tab %s", it does not block. It simply notifies
your main running firefox process to open a tab pointing to %s and then
exits right away. There is now a "race condition". Does mutt delete
the temp file before or after your main firefox process creates the new
tab pointing to it?
Here are two (simplified) tables showing the basic ways this can play
out:
mutt firefox -new-tabmain firefox
1. Create temp file
2. Launch ff -new-tab %s
3. Notify main firefox
process to create a
new tab %s
4. Exit
5. Creates new tab
pointing to %s
6. Wait for ff -new-tab
to exit
7. Delete temp file %s
-or-
mutt firefox -new-tabmain firefox
1. Create temp file
2. Launch ff -new-tab %s
3. Notify main firefox
process to create a
new tab %s
4. Exit
5. Wait for ff -new-tab
to exit
6. Delete temp file %s
7. Creates new tab
pointing to %s
8. Error - No such
file
Which one happens depends on which process gets control after step 4:
the main firefox process or mutt. In the first case, main firefox is
able to find the file and read it in. In the second case, main firefox
can't open the file, and you get an error message. In either case,
though, if you go look for the file in /tmp, the file will be gone
because mutt has already deleted it.
There is no completely clean way to fix this, because there is no way to
know how long the main firefox will need %s to be around. If you only
intend to quickly view the file and then close the tab, the best way is
to have mutt sleep after invoking "firefox -new-tab". Try modifying
your .mailcap invocation to:
text/html; firefox -new-tab '%s' & sleep 10; test=
^^^
add this
The idea is that even if the second scenario happens, mutt will just
sleep instead of deleting the temp file. Hopefully the main firefox
will have a chance to run and read that file in before the sleep ends
and mutt deletes the file.
Race conditions are complicated, and this explanation is not complete,
but I hope this helps.
-Kevin
signature.asc
Description: Digital signature
Re: SASL authentication failed
Mehturt wrote: > Yes, I'm using this already. > The question is - is there an equivalent of Thunderbird's "Normal > Password" and "SSL/TLS"? > > I'm using: > set smtp_url="smtps://user:pass@host:465" > > And I tried smtp_authenticators set to "plain" and "login", but it did not > work. > I can post .muttdebug* if required. Just a few random things to try. First off, comment out smtp_authenticators in your muttrc and let mutt try all the methods. Try out port 587 and TLS (note the smtp:// instead of smtps://) set smtp_url="smtp://user:pass@host:587" If you are on Debian/Ubuntu, make sure you have the libsasl2-modules package installed. -Kevin signature.asc Description: Digital signature
Re: Why sign every message? (was Re: Sending attachments without crypt_autosign
Will Fiveash wrote: > The why is that you are adding needless bloat to most messages you send. One person's "needless bloat" is another's digital signature, I guess. > Take for example the message you sent that I'm responding to. Does > anyone care that it actually came from you and wasn't tampered with? I > doubt it. Mark cares. I care too. Perhaps you'll consider that your opinion on the appropriate use of signatures is just that. -Kevin signature.asc Description: Digital signature
Re: Why sign every message? (was Re: Sending attachments without crypt_autosign
Florian Lohoff wrote: > I my wet dreams i' encrypting every single message. But mutt is not very > helpful in this. Yes - it can encrypt but i'd like mutt to decide > automatically when it's capable of encrypting the mail (remember > multiple To:, Cc:, Bcc). It would be okay to encrypt a mail if i have a > key for all recipients. I've just sent a (6 part) patch to mutt-dev that implements this. If you're up for it, I'd appreciate people trying it out and providing feedback. http://marc.info/?l=mutt-dev&m=136340705622283&w=2 -Kevin signature.asc Description: Digital signature
Re: "set include=yes" bypasses Compose Menu
rj wrote: > I'm finding that if I set > > set include=yes > > when I finish writing a reply in vim, the message gets sent *instantly* > upon my hitting the command to exit the editor. The Compose Menu doesn't > appear at all. > > If I unset include=yes, I no longer have that problem, but then of course > I get the > > Include message in reply? ([yes]/no): > > prompt. Any ideas what might be causing this? I've been unable to duplicate this. Can you duplicate this with a clean config? (use the -n and -F options - see http://dev.mutt.org/trac/wiki/DebugConfig) My guess would be a send-hook or reply-hook is causing this. Perhaps when include=ask-yes is set, mutt has a chance to chomp some extra characters your hook is generating (e.g. 'y') that otherwise cause the message to send without the prompt. -Kevin signature.asc Description: Digital signature
Re: "set include=yes" bypasses Compose Menu
rj wrote: > On Sat 13 at 07:28 PM -0700, "Kevin J. McCarthy" wrote: > > My guess would be a send-hook or reply-hook is causing this. > > send-hook.'unmy_hdr From:' > send-hook '~Chfha-members' 'my_hdr From: rj ' > # send-hook '(~Czsh-users| ~Cmutt-users| ~Cvex)' 'set crypt_autosign; my_hdr > From: rj ' I'm not super familiar with the details of send-hook but I suspect multiple commands may not be allowed. Try breaking the last line into two parts and see if that helps: send-hook '(~Czsh-users| ~Cmutt-users| ~Cvex)' 'set crypt_autosign' send-hook '(~Czsh-users| ~Cmutt-users| ~Cvex)' 'my_hdr From: rj ' It may be that the "y" in my_hdr following the ";" is triggering the send mail action, if mutt stops parsing for the command at ";" and sends the rest as literal keyboard commands. -Kevin signature.asc Description: Digital signature
Re: [SOLVED] "set include=yes" bypasses Compose Menu
rj wrote:
> On Mon 15 at 12:04 AM -0400, rj wrote:
>
> > That would mean that although this line cures the problem, something else
> > is causing it.
>
> What was causing it was this key binding:
> bind index,pager { reply# Restored to 'r' in macro below.
>
> combined with this macro:
> macro index,pager r ":set editor='vim +10'^M{^M" "reply with quoting"
Great news that you figured it out!
I don't know if you are using the "{" binding too, or have done that
just to use inside your macro. In case it's the latter, note that you
can actually use and inside the macro instead:
macro index,pager r "set editor='vim +10'"
"reply with quoting"
-Kevin
signature.asc
Description: Digital signature
Re: [SOLVED] writing macros correctly
rj wrote: > # List-reply w/quoting, put cursor on line 10: > macro index,pager p "set editor='vim +10'" > "list-reply with quoting" > > # List-reply w/out quoting, put cursor at line 10: > macro index,pager _R "set editor='vim +10'" > "list-reply without quoting" Did you intend to use instead of for the two macros above? Otherwise, nice job cleaning them up. They look much more readable and less likely for a stray character to sneak into them. -Kevin signature.asc Description: Digital signature
Re: writing macros correctly
rj wrote: > Yes! I did, thank you. But the second one is identical to the first. > I tried the following for "reply without quoting," and it works, but > after using it, if I want to reply *with* quoting, using "r", I get > no-quoting again, so this can't be right: The settings you change are not local to the macro. So when you turn off include, it will stay off even after you finish replying. If you have other macros where you want it on, you'll have to turn it back on for each of those. By the way, you can combine various setting changes into a single set command to make your macro less lengthy: macro index,pager r "set include=yes editor='vim +10'" "reply with quoting" macro index,pager R "set include=no editor='vim +10'" "reply without quoting" macro index,pager p "set include=yes editor='vim +10'" "list-reply with quoting" macro index,pager _R "set include=no editor='vim +10'" "list-reply without quoting" -Kevin signature.asc Description: Digital signature
Re:
Tim Gray wrote: > What exactly does the command do? The manual > states 'get a temporary copy of an attachment' but it's unclear to > me what the use case might be. It looks like it takes an existing attachment (e.g. ~/foo.txt) and makes a copy of it to your $tmpdir. The attachment is then replaced with your tmpdir copy (/tmp/foo.txt). Perhaps if you wanted to grab a snapshot of a file that may change, you would use this command. Others may have a better ideas for the use case. -Kevin signature.asc Description: Digital signature
Re: TO: header
Robert Holtzm wrote: > What file does mutt source to generate the TO: header? Compare the one > in this post to the last name in the sig. It appears that the problem > started around Aug 16 as far as I can tell. Going back to earlier posts > in my outbox it's correct. I believe you're referring to your last name being misspelled in your From header. First mutt consults $from for a name (unless you've turned off $use_from). If $from is empty, it checks your $EMAIL environment variable. It will then check $realname. Finally, it grabs the information out of getpwuid() (which usually reads from your /etc/passwd file). -Kevin signature.asc Description: Digital signature
Re: Setting message priority levels
John Niendorf wrote: > How can I add something like "Low, Normal, Medium, High" priority to > a mail right before sending? You could, for example, add the following to your muttrc: # Set message priority macro index ,mph 'my_hdr Priority: High' macro index ,mpm 'my_hdr Priority: Medium' macro index ,mpn 'my_hdr Priority: Normal' macro index ,mpl 'my_hdr Priority: Low' macro index ,mpd 'unmy_hdr Priority' Then, hitting the key sequence ",mph" will add a high priority header to all subsequent emails. ",mpd" will delete the priority header from all subsequent emails. It may be helpful to have $edit_headers set so you can see the added header when you compose the email. (Of course, you could just directly add the header yourself while in your editor too.) > If I understood at least partially correctly, using this macro I can > write a priority level to the header. Although this is a non-standard > header and the recipient may or may not see it depending on the > receiving MUA. Is that correct? Yes, that's correct. -Kevin signature.asc Description: Digital signature
Re: TO: header
Robert Holtzman wrote: > Why didn't I see those were .muttrc > entries! My only remaining question is since these settings aren't shown > in .muttrc, and since prior to ~16 August the problem didn't exist, what > changed and why. Most likely, it was a typo in your /etc/passwd file. Mutt will read your name from there if it isn't in $from, $realname, or $EMAIL. Sorry my earlier email was too cryptic! -Kevin signature.asc Description: Digital signature
Re: mutt and msmtp -- better error handling?
Óscar Pereira wrote: > One of the accounts I use mutt with is setup with offlineimap to > download the email, and msmtp to send it. Yesterday, the smtp server > I use with that account (gmail's smtp) was unavailable during the > afternoon. However, when I sent an email from mutt, neither mutt nor > msmtp reported an error. In fact, mutt displayed the familiar "Mail > sent" message in the lower left corner. And what's worse, the mail I > was just composing was *gone*! Not sent to the recipient, but also > not stored anywhere locally. This scenario was reproducible, and the > behaviour was always the same. Do you have $sendmail_wait set to < 0? Looking at the source, if the value is < 0, mutt will return an EX_OK right away, resulting in the "Mail sent" message. The docs say a value other than 0 will put the output in a temporary file and you will be informed in the event of an error. But the source shows that's only for $sendmail_wait > 0 and for the case that the process finishes while mutt is still waiting for it. For the (default) case where $sendmail_wait == 0, it should be pretty bullet proof. I myself have used msmtp for a while and it _has_ returned an error message in the case where the mail could not be sent. -Kevin signature.asc Description: Digital signature
Re: Writing a wrapper for the editor: mutt aborts in-between
Karl Voit wrote: > After renaming, I want to invoke my editor, make my manual changes > to the email body and after quitting the editor, mutt should take > over again. > > However, when I rename TMPFILENAME to muttfilename, mutt takes over > the process again. This skips the editor part completely. Mutt > complains that the muttfilename is missing: > > "Can't stat /tmp/mutt-grmlvrs-1002-5074-359: No such file or > directory" Hi Karl, Mutt doesn't attempt to stat the file until after the "editor" process exits. My guess is that your os.rename() command (or some other line in the script) is failing and python is aborting. You may want to take a look at https://pthree.org/2011/03/24/hashcash-and-mutt/ for an example python wrapper and see if that helps. -Kevin signature.asc Description: PGP signature
Re: Encrypting postponed messages
Óscar Pereira wrote:
> The subject seems pretty self-explanatory. Use case, you're writing
> an email, which is already marked as to be sent encrypted, but you
> have to postpone it. In the meantime offlineimap runs and syncs you
> mailboxes, and thus your mail which is to be sent encrypted ends up
> in (say) Gmail's remote folder -- UNencrypted.
>
> Googling yielded only a question with no answer [1]. The only
> work-around I have to this is to disabled sync'ing the drafts folder
> altogether. Is there another way?
Sorry to resurrect an old (and somewhat heated) thread, but I'd like
some feedback on the interface for a patch I'd like to push (attached,
or see ticket #3665). The patch was based off the one submitted by
Christian Brabandt, so thank you Christian!
The patch adds two options: postpone_encrypt (boolean) and
postpone_encrypt_as (string).
If postpone_encrypt is set, and the message has the encryption
flag set, mutt will encrypt the message using the key specified in
postpone_encrypt_as. Currently, the interface is as simple as that.
I'm wondering if that is sufficient for people interested in the patch,
or whether a quadoption for postpone_encrypt would be more useful. For
a quadoption, I would keep the behaviour the same: the quadoption would
only be consulted if the message encryption flag was set.
Would it be useful to be able to encrypt, even if the message encryption
flag is not set? If so, I could use some opinions, because defining the
interface for that starts to get complicated.
Thanks,
-Kevin
# HG changeset patch
# User Kevin McCarthy
# Date 1383772024 28800
# Wed Nov 06 13:07:04 2013 -0800
# Node ID 4d4cee6396e31f67324b23d05054b55f5c5a8ed8
# Parent cd57f8893b43a1d62e6cbf2488d399e97a66a0b2
Add option to encrypt postponed messages. (closes #3665)
This patch is based on Christian Brabandt's patch sent
to mutt-users.
Add two new configuration variables: $postpone_encrypt and
$postpone_encrypt_as. When $postpone_encrypt is set and a message is
marked for encryption, the message will be encrypted using the key
specified in $postpone_encrypt_as before saving the message.
In this patch, $postpone_encrypt_as must be specified. I experimented
with passing safe_strdup( NONULL (PostponeEncryptAs)) when unspecified,
but although gpg.conf has a default-key setting, I could not get it to
work properly. (pgpclassic gave an error message and gpgme sefaulted.)
Although not necessary, this patch turns off signing during encryption
of the postponed message (and turns it back on before saving), since
there is no need to sign the message yet.
diff --git a/globals.h b/globals.h
--- a/globals.h
+++ b/globals.h
@@ -103,16 +103,17 @@
WHERE char *PopAuthenticators INITVAL (NULL);
WHERE short PopCheckTimeout;
WHERE char *PopHost;
WHERE char *PopPass INITVAL (NULL);
WHERE char *PopUser INITVAL (NULL);
#endif
WHERE char *PostIndentString;
WHERE char *Postponed;
+WHERE char *PostponeEncryptAs;
WHERE char *Prefix;
WHERE char *PrintCmd;
WHERE char *QueryCmd;
WHERE char *QueryFormat;
WHERE char *Realname;
WHERE short SearchContext;
WHERE char *SendCharset;
WHERE char *Sendmail;
diff --git a/init.h b/init.h
--- a/init.h
+++ b/init.h
@@ -2116,16 +2116,31 @@
/*
** .pp
** Mutt allows you to indefinitely ``$postpone sending a message'' which
** you are editing. When you choose to postpone a message, Mutt saves it
** in the mailbox specified by this variable.
** .pp
** Also see the $$postpone variable.
*/
+ { "postpone_encrypt",DT_BOOL, R_NONE, OPTPOSTPONEENCRYPT, 0 },
+ /*
+ ** .pp
+ ** When \fIset\fP, postponed messages that are marked for encryption will be
+ ** encrypted using the key in $$postpone_encrypt_as before saving.
+ ** (Crypto only)
+ */
+ { "postpone_encrypt_as", DT_STR, R_NONE, UL &PostponeEncryptAs, 0 },
+ /*
+ ** .pp
+ ** This is the key used to encrypt postponed messages. It should be in
+ ** keyid form (e.g. 0x00112233 for PGP or the hash-value that OpenSSL
+ ** generates for S/MIME).
+ ** (Crypto only)
+ */
#ifdef USE_SOCKET
{ "preconnect", DT_STR, R_NONE, UL &Preconnect, UL 0},
/*
** .pp
** If \fIset\fP, a shell command to be executed if mutt fails to establish
** a connection to the server. This is useful for setting up secure
** connections, e.g. with \fCssh(1)\fP. If the command returns a nonzero
** status, mutt gives up opening the server. Example:
diff --git a/mutt.h b/mutt.h
--- a/mutt.h
+++ b/mutt.h
@@ -401,16 +401,17 @@
OPTNARROWTREE,
OPTPAGERSTOP,
OPTPIPEDECODE,
OPTPIPESPLIT,
#ifdef USE_POP
OPTPOPAUTHTRYALL,
OPTPOPLAST,
#endif
+ OPTPOSTPONEENCRYPT,
OPTPRINTDECODE,
OPTPRINTSPLIT,
OPTPROMPTAFTER,
OPTREADONLY,
OPTREFLOWTEXT,
OPTREPLYSELF,
OPTRESOLVE,
OPTREVALIAS,
diff --git a/send.c b/send.c
--- a/send.c
+++ b/send.c
@@ -1550,16 +1550,38 @@
goto cleanup;
}
else if (i == 1)
{
/* postpone the message until later
Re: Encrypting postponed messages
Rejo Zenger wrote: > To me, that is of no particular use. > > Against what version is the patch you have provided? Thanks for the feedback. The patch should apply against the tip of the default branch. It may take a little bit of wiggling to get it to apply to something older because of changes in options. But as as long as you get the changes to globals.h, init.h, and mutt.h _somewhere_ in those files it should still work. :-) -Kevin signature.asc Description: PGP signature
Re: Encrypting postponed messages
Kevin J. McCarthy wrote: > Sorry to resurrect an old (and somewhat heated) thread, but I'd like > some feedback on the interface for a patch I'd like to push (attached, > or see ticket #3665). The patch was based off the one submitted by > Christian Brabandt, so thank you Christian! I've just pushed this patch upstream, with a binary postpone_encrypt option. Thanks everyone for your feedback! -Kevin signature.asc Description: PGP signature
Re: gpg2 "no secret key" error
Hi Will, Will Yardley wrote: > However, I'm having a problem similar to the one described here: > http://permalink.gmane.org/gmane.linux.arch.general/52889 > > namely, if I don't set $GPG_AGENT_INFO, mutt complains that gpg-agent > isn't running on startup. Does anyone know whether having it defined is > required, since some of the comments in the post above seem to imply it > shouldn't be. This one is a known issue. I removed the check in http://dev.mutt.org/hg/mutt/rev/df55f14f4585, so you may want to build from the latest tree version if you're using with gpg2.1. However, I'm not familiar with the "gpg: decryption failed: No secret key" error you're getting. I haven't actually played with gpg2.1 yet, so something else may need to be fixed in the mutt source. I do know that version 2.1 always uses an agent now, so it's possible it just doesn't support direct passphrase input anymore, and that's why you're getting an error. If you could run mutt with the "-d 5" and capture the exact gpg command it's executing, that might be helpful. -Kevin signature.asc Description: PGP signature
Encrypting when possible
I've been working on this patch series for a while, and finally committed it to the repository yesterday. For those of you who would like to "encrypt by default" and don't mind compiling from the repository, please check it out. To use it, just put "set crypt_opportunistic_encrypt" in your muttrc. Caveats: - If something else, e.g. $crypt_autoencrypt or $crypt_replyencrypt, enables encryption, this option will be disabled for that message. It can be manually turned back on in the pgp menu. - An unverified (not in your web of trust) key will be used as a candidate to possibly enable encryption. However, when you send the message, Mutt will still prompt to confirm whether you want to use the key. -Kevin signature.asc Description: PGP signature
Re: Encrypting when possible
Rejo Zenger wrote: > ++ 31/03/15 11:47 -0700 - Kevin J. McCarthy: > >I've been working on this patch series for a while, and finally > >committed it to the repository yesterday. For those of you who would > >like to "encrypt by default" and don't mind compiling from the > >repository, please check it out. > > To get a copy of your code, I just need to clone the "default" branch from > the Mercurial repository? Yes, it's in the default branch in the Mercurial repository. > I haven't had a look at the code yet, but can you explain how it does work > (e.g. how does it determine when there's a key for a recipient on the > keyring and encrypting is feasable and when it is not)? It uses the same routines that Mutt uses when you go to send a message, but it takes away any prompting. It looks for an email-address match (or crypt-hook with a key) for each recipient. If all recipients have a key, it enables encryption. Otherwise it disables encryption. This happens whenever the To, Cc, or Bcc list is edited, or when the message is edited if $edit_headers is set. A word of caution though, this patch series significantly changed the code that ticket 3727 applies to, so I doubt that patch will apply without some re-working. > Additionaly, may I draw your attention to these two tickets: > > - <http://dev.mutt.org/trac/ticket/3727>, which is patch to allow for > encryption to multiple keys based on a single recipient (which isusefull > when sending encrypted mail to mailinglist with a static setof > subscribers) > > - <http://dev.mutt.org/trac/ticket/3728>, which is a bugreport for a > case in which users are not able to read application/pgp-encrypted >attachments (unless the user saves the attachments and runs gpg and > openssl manually on the saved message part) Thanks for opening the tickets. I can't guarantee a timeline, but I'll put those on my radar to look at. -Kevin signature.asc Description: PGP signature
Multiple crypt-hook behavior
I'm cleaning up and looking into committing the multiple crypt hook patch, but need some feedback from people who use it. The current behavior (without that patch) is to prompt whether to use the crypt-hook value if one is found. If the user answers "no" then Mutt will use the original address for key selection instead. Since there can be at most one crypt-hook, this makes sense. With this patch, it's less clear what the correct behavior should be if the user user says "no". The current patch will use the original address and perform key selection with it, but doing this multiple times doesn't seem right. Would it be better for "no" to completely skip key selection *unless* it's the last crypt-hook and they haven't selected a key yet? As an example, let's say there are 5 crypt-hooks for an address. If you chose "yes" for the first crypt-hook, then you could say "no" to the next four and it wouldn't perform any key selection for those four. If you said "no" all five times, then for the first four, it wouldn't perform key selection, but the fifth "no" would cause Mutt to perform key selection on the original address. Does that sound reasonable, or would a different behavior be more useful? -Kevin signature.asc Description: PGP signature
Re: Two private SMIME certificates conundrum
David J. Weller-Fahy wrote: > After much frustration I discovered why mutt wouldn't work with the > SMIME keys issued at work: there are two of the private keys (one for > signature, one for encryption), and a single public key. As I have an > employer that is more than willing to let me use mutt (if I can get it > to work properly) I am inclined to do whatever I can to get signing and > encryption functional! > > I've always used GPG for email encryption and am not familiar with SMIME > use in mutt, so I have some questions: > > Is this a supported configuration? If so, does anyone have an example > configuration they'd like to share? Hi David, I don't use S/MIME either, so I hope you'll pardon me if this isn't helpful. To start, my impression was that (like GPG) encryption usually uses the recipients key, not your own key. You'll usually use your own key just for signing and decryption. That said, I would suggest looking into customizing the $smime_encrypt_command, $smime_sign_command, and $smime_decrypt_command options inside your .muttrc. By default, they use the placeholders shown in http://dev.mutt.org/doc/manual.html#smime-decrypt-command for specifying the default key (%k) or recipient keys (%c). But nothing stops you from hardcoding values in your muttrc. Sample values for smime are usually packaged with mutt, but you can also refer to http://dev.mutt.org/hg/mutt/file/tip/contrib/smime.rc -Kevin signature.asc Description: PGP signature
Re: Multiple crypt-hook behavior
Rejo Zenger wrote: > ++ 04/04/15 16:33 +0200 - Rejo Zenger: > >I have specificaly selected and configured a number of key ID's for a > >mailinglist. This is a deliberate action, and if a key is not available > >there is no need to select an alternative. Keys are always > > So, actually, the current situation where mutt asks whether it should use > the key specified with the crypt-hook is superflucious in my setup. If I > have designated a specific key for a specific user using the hook, there is > no need to ask me for a verification. Yes, I can understand what you are saying. With even a small encrypted mailing list, being prompted for each crypt-hook could be annoying. However, I'm a little nervous to take away the prompt from everyone. It would be great if other crypt-hook users could chime in here. Is the prompt universally annoying? Is this worth an option? -Kevin signature.asc Description: PGP signature
Re: deleting attachments in signed emails
David J. Weller-Fahy wrote: > * Brian Salter-Duke [2015-04-05 16:35 -0400]: > >While you are fixing these problems, could one of you look at a problem > >I reported a few weeks ago. > > Hrm... what's the ticket number? I just checked and couldn't find the > bug report. > > > http://www.kurokatta.org/hacks/src/mutt-1.5.13-rmattach.patch > > > >It was meant for PGP-encrypted messages; hopefully it works for S/MIME as > >well. > > I looked at the patch, which seems to be trivial, but I'm not familiar > enough with the code to divine the side-effects of the single change. > > Kevin, thoughts? Yes, that patch was forwarded onto mutt-dev. There was some discussion and a few different ideas from the other committers. It's still on my list, but I may have to poke the thread a bit to see if we can reach a consensus. -Kevin signature.asc Description: PGP signature
Re: Multiple crypt-hook behavior
Rejo Zenger wrote: > ++ 04/04/15 11:54 -0700 - Kevin J. McCarthy: > >However, I'm a little nervous to take away the prompt from everyone. It > >would be great if other crypt-hook users could chime in here. Is the > >prompt universally annoying? Is this worth an option? > > If you are asking me, most definately yes. And, I am pretty sure I'm not the > only one: <http://www.woolridge.ca/mutt/confirm-crypt-hook.html>. The above patch looks pretty straightforward: it adds a boolean $crypt_confirmhook, that if unset turns off prompts for the crypt-hooks. Another option could be something like: $crypt_use_hooks as a quadoption: - yes means all crypt-hooks are used without prompting - ask-yes/ask-no prompt for each hook - no disables all crypt-hooks. This could provide a way to disable the crypt-hooks in certain circumstances. I don't know if something like that is useful or is overkill. -Kevin signature.asc Description: PGP signature
Re: Multiple crypt-hook behavior
Rejo Zenger wrote: > ++ 17/04/15 14:53 -0700 - Kevin J. McCarthy: > > > >Another option could be something like: $crypt_use_hooks as a > >quadoption: > > - yes means all crypt-hooks are used without prompting > > - ask-yes/ask-no prompt for each hook > > - no disables all crypt-hooks. > >This could provide a way to disable the crypt-hooks in certain > >circumstances. I don't know if something like that is useful or is > >overkill. > > Not sure. I would set it to yes, as I have these well-defined and defined > with the purpose that these particular should be used. For me, there is not > a real added value, but then again, it doesn't hurt I think. I've just pushed the multiple crypt hook patch along with Dale's $crypt_confirmhook option. Please let me know if there are any issues. Thanks, -Kevin signature.asc Description: PGP signature
Re: Unmailboxes crash
Filippo Panessa wrote: > I'm a new mutt user. I use Mutt 1.5.23 (2014-03-12) from Ubuntu 15.04 > (patched version). I wrote a double configuration and it should be > good if I could use unmailboxes when I switch between configuration, > but it makes crash mutt. > > I know that it's a knowed issue. Is there any solution? I don't think this is a known issue. The link you provided (http://dev.mutt.org/trac/ticket/3273) is an official patch that is already in 1.5.23. Can you provide some more details about what you are doing that causes this? -Kevin signature.asc Description: PGP signature
Re: Unmailboxes crash
Filippo Panessa wrote: > On Sat, Apr 25, 2015 at 04:31:27PM -0700, Kevin J. McCarthy wrote: > > > Can you provide some more details about what you are doing that causes > > this? > > I wrote multi configuration for Gmail and UZH. You can switch between > them using and keys. Everything works correctly, but I > cannot use *unmailboxes* function to purge previous configuration during > the switch. It simply generate a core dump. > > You can find complete configuration on GitHub: > > https://github.com/filippopanessa/muttrc I'm unfortunately unable to duplicate the problem. I've pulled down all your configs and am switching between the accounts using F2 and F3 without issue. It may be a patch in your version causing the problem. -Kevin signature.asc Description: PGP signature
Re: Unmailboxes crash
Filippo Panessa wrote: > On Sun, Apr 26, 2015 at 12:27:14PM -0700, Kevin J. McCarthy wrote: > > > I'm unfortunately unable to duplicate the problem. I've pulled down > > all your configs and am switching between the accounts using F2 and F3 > > without issue. It may be a patch in your version causing the problem. > > Yes, you're right. I tried out with not patched version and it doesn't > crash anymore. So it should be definitely something in *sidebar.patch*. > > In Debian 1.5.23 package (and also Ubuntu) there're those patches: > > - multiple-fcc.patch > - sidebar-compose.patch > - sidebar-dotpathsep.patch > - sidebar.patch > - nntp.patch > - sidebar-delimnullwide.patch > - sidebar-newonly.patch > - sidebar-utf8.patch > > I tried to remove *nntp.patch* and recompile, but it still crashes. Well, the sidebar is definitely hooked into the mailboxes list. My guess is that's what is causing the problem. The sidebar is unsupported, so you may have to either abandon the "unmailboxes" command or else switch to the standard mutt package. Sorry, -Kevin signature.asc Description: PGP signature
Re: sending from mutt to fastmail back from the dead?
Tom Fowle wrote: > set imap_user=$my_user > set imap_pass = $my_pass > # > # SMTP server to relay to > # NOTE: to get this to work, I had to install the libsasl2-modules > package > set smtp_url =smtps://$my_user:$my_pass@$my_smtp_server:465 > #set sendmail = /usr/sbin/sendmail > #set sendmail = "/usr/local/bin/esmtp > #set sendmail_wait = 0 > #set dsn_notify = "" > #set dsn_return = "" I don't know what the problem is, but perhaps something in your password is confusing the parsing of smtp_url. Try setting smtp_pass and removing $my_pass from smtp_url. Also, since you say you aren't using the system /etc/Muttrc file, do you have ssl_ca_certificates_file set? set ssl_ca_certificates_file=/etc/ssl/certs/ca-certificates.crt I've been using mutt with fastmail for quite a while, so don't give up. -Kevin signature.asc Description: PGP signature
Re: Exact semantics of ignore?
Ian Zimmerman wrote: > The part of the documentation about the "ignore" command talks about > "patterns". As far as I can see it never precisely says what kind of > patterns these are - regexps, shell globs, fixed substrings, or what. It's a case-independent prefix match against the header. "*" is recognized special-case to mean everything. The function used is mutt_matches_ignore() inside muttlib.c. You can see the invocation at mutt_copy_hdr() inside copy.c: if (!((flags & CH_FROM) && (flags & CH_FORCE_FROM) && this_is_from) && (flags & CH_WEED) && mutt_matches_ignore (buf, Ignore) && !mutt_matches_ignore (buf, UnIgnore)) continue; > The reason I ask is I had "x-" as one of the patterns, precisely as the > documentation suggests (in an offhand example). But Mario's posts from > today have an X-URL header and it was not weeded. It is when I add > "x-url" to the ignore. What gives? Maybe it also matched something in an unignore? My quick testing shows "x-" is working for me. Try emptying out your ignore list: "unignore *" and then do an "ignore x-". -Kevin signature.asc Description: PGP signature
Re: folder-hook for postponed messages
Xu Wang wrote: > I would like set a folder hook for postponed messages, which I hope is > run when I do "R" to change to the postponed folder. When you use "R" you aren't really changing to the postponed folder. If there is more than one postponed message, it will provide a list to choose from, however it's not the same as the message index and so folder-hooks are not run. You may want to try using macros instead (these are untested): macro index,pager R "set editor=vim" "recall macro" macro index,pager m "set editor=emacs" "mail macro" macro index,pager r "set editor=nano" "reply macro" macro index,pager g "set editor=ed" "group reply macro" macro index,pager L "set editor=pico" "list reply macro" Note that editor stays set after each macro, which is why I've created it for all the other mailing commands. -Kevin signature.asc Description: PGP signature
Re: File browser oddity
Ian Zimmerman wrote: > On 2015-06-07 17:23 -0700, Ian Zimmerman wrote: > > Ian> When I start the file browser view explicitly, either by hitting > Ian> the y key or by passing -y on the shell command line, it comes up > Ian> in the "mailboxes only" submode, i.e. things like my header cache > Ian> directory are hidden. (They can be shown by activating the > Ian> toggle-mailboxes function, bound to Tab by default). But when I > Ian> start by hitting c and then ?, so as to show the browser merely as > Ian> a temporary menu of mailboxes to switch to, it comes up with all > Ian> files visible and the toggle key hides the non-mailboxes. > > Ian> I find this a very annoying inconsistency. Is there some setting I > Ian> can turn on to make it behave the same in both situations? I'd > Ian> prefer the non-mailboxes always hidden by default, but even always > Ian> shown would be better than the current way. > > I think this is in fact a flea, a very small one, to be sure. Patch > attached, relative to 1.5.21; if needed I can certainly rebase it on a > different version. I think you're right. Let me just test it and I'll push the patch out. Thank you for investigating and writing up a patch! -Kevin -- 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
Re: File browser oddity
Kevin J. McCarthy wrote: > Ian Zimmerman wrote: > > On 2015-06-07 17:23 -0700, Ian Zimmerman wrote: > > > > Ian> When I start the file browser view explicitly, either by hitting > > Ian> the y key or by passing -y on the shell command line, it comes up > > Ian> in the "mailboxes only" submode, i.e. things like my header cache > > Ian> directory are hidden. (They can be shown by activating the > > Ian> toggle-mailboxes function, bound to Tab by default). But when I > > Ian> start by hitting c and then ?, so as to show the browser merely as > > Ian> a temporary menu of mailboxes to switch to, it comes up with all > > Ian> files visible and the toggle key hides the non-mailboxes. > > > > Ian> I find this a very annoying inconsistency. Is there some setting I > > Ian> can turn on to make it behave the same in both situations? I'd > > Ian> prefer the non-mailboxes always hidden by default, but even always > > Ian> shown would be better than the current way. > > > > I think this is in fact a flea, a very small one, to be sure. Patch > > attached, relative to 1.5.21; if needed I can certainly rebase it on a > > different version. > > I think you're right. Let me just test it and I'll push the patch out. > Thank you for investigating and writing up a patch! After looking and thinking this through, it may be somewhat controversial to make this change. I've made a couple modifications and will mail the patch to mutt-dev, but really need more feedback before I consider pushing it. -- 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
Re: File browser oddity
Ian Zimmerman wrote: > On 2015-06-08 15:55 -0700, Kevin J. McCarthy wrote: > > Kevin> After looking and thinking this through, it may be somewhat > Kevin> controversial to make this change. I've made a couple > Kevin> modifications and will mail the patch to mutt-dev, but really > Kevin> need more feedback before I consider pushing it. > > Would you care to explain what your concerns are? The biggest one is changing long-standing behavior of a very often used function. Mutt users can be a conservative bunch, and this change could goof up macros or who knows what. My days could be numbered if I pushed it without entertaining any feedback first. :-) Also, the file browser didn't even work if no mailboxes were defined. I've changed it to not abort and display an empty list, but this could still be confusing to newish users, or even users who define no mailboxes and for whom it "just worked" in the past. > You can redirect me to another forum if mutt-users is not appropriate. I've Cc'ed you on the post to mutt-dev. (Sorry about that if you're subscribed; I do see your signature). As I mentioned there, I *do* think the patch makes sense, but it may not be much liked by others. -- 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
Re: save and reply
Jon LaBadie wrote: > As I'm configured, a save deletes the message and > moves to the next unread message. This is reasonable > behavior. But if I want to reply to that same message, > before hitting "r", I must return to the now deleted > message, possibly stepping over other deleted messages. Perhaps the resolve setting could help? -- 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
Re: save and reply
Jon LaBadie wrote: > > Perhaps the resolve setting could help? > > No, the bulk of email gets either a "d" or "s" and moving > to the next message is fine. Except in the case where I > would like to reply. Setting resolve to no would create > extra steps for the ones to which I don't reply. I was thinking something like: macro index,pager ,dr "unset resolveset resolve" -- 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
Re: Swedish chars in attached gpg-encrypted message fails
jonas hedman wrote: > "Content-Type: text/plain; charset=iso-8859-1 >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >Secret =E5=E4=F6 =C5=C4=D6" As the header shows, the =E5 characters are quoted-printable encoding. Mutt is encoding the characters because the PGP/MIME RFC (3156) says all 8-bit characters for pgp/signed message MUST be encoded. (I am guessing you are both signing and encrypting the messages.) Email clients should generally deal with this correctly, and decode the content before displaying it. If for some reason, the recipients are viewing the content outside of a MUA, they may want to use the qprint utility to decode and view the content. > 2. Why doesn't this problem show up when encrypting inline style? Inline style has no such mandate. If allow_8bit is set and you are also encrypting the message (which ascii-armors the output), then Mutt allows the 8-bit encoding. -- 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
Re: Order of hook execution
Ian Zimmerman wrote: > From this behavior it is clear that the "second" hook in fact runs > first, and vice versa. Actually, the folder-hooks are run in the order listed in your .muttrc. However, each invocation of exec or push adds to the *front* of the input buffer. Hence the contents of the second exec/push will be executed before the first one (after all the hooks are evaluated and input starts processing). It's possible to put multiple functions in a single exec, so folder-hook . "exec collapse-all current-bottom" may be clearer. -- 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
Re: Sort by newest in thread?
Ian Zimmerman wrote: > There seems to be no way in vanilla mutt to sort the index view such > that the latest message appears last, when threading is on. So when I > open a folder with a long active thread, I keep landing in the middle > of old inactive threads. Does 'set sort_aux=last-date-received' do what you want? -- 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
Re: header_cache for mbox
Eric Smith wrote: > So is this indeed supported for mbox? Sorry, hcache is only implemented for pop, imap, maildir, and mh. > What is the reason for this? I think the hcache helps to alleviate network latency (pop/imap) and for opening and closing thousands of files (maildir/mh). With mbox, I guess the designers thought there wouldn't be that much of a speed improvement because it's just a sequential read of a single file. -- 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
Re: folder-hook pattern param
Ian Zimmerman wrote: > What I ended up doing (after spending several days patching the source > with debug prints just to understand WTH was happening) was: > > folder-hook .*^/home/itz/foo/.* "my_hdr X-itz-real-home-foo: yes" Another workaround which might be less distasteful would be to use parenthesis: folder-hook (^/home/itz/foo/) "my_hdr X-itz-real-home-foo: yes" > I feel this thicket of gotchas really deserves a few paragraphs in the > manual. I agree. I will work on adding a section to the docs. -- 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
Re: Reading encrypted mail remotely
Ian Zimmerman wrote: > Is there any hook or crook by which I could read encrypted mail with > mutt without my private key being installed on the host where mutt runs? > Some agent forwarding magic, pretty please? I really, really don't want > to put my key on my mail server. And no, please don't suggest IMAP :-( I haven't done anything more than search, but there is a thread about this here: http://www.gossamer-threads.com/lists/gnupg/users/68713 Looks like they are referring to a new OpenSSH 6.7 feature combined with a new GPG 2.1 feature. -- 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
Re: Exiting Mutt from browser menu
joe.on.l...@gmail.com wrote: > Is there a way to quit mutt immediately when I'm in browser menu? uppercase "Q" is bound to . This will save changes to the mailbox and quit mutt. -- 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
Re: Exiting Mutt from browser menu
Joe wrote: > On 24.08.15 18:09, Kevin J. McCarthy wrote: > > joe.on.l...@gmail.com wrote: > > > Is there a way to quit mutt immediately when I'm in browser menu? > > > > uppercase "Q" is bound to . This will save changes to the mailbox > > and quit mutt. > > Perhaps this should work from "index menu", when you are within a mailbox, > but "Q" doesn't seem to be assigned when I press it from "browser menu". I'm 0 for 2 this week... Sorry for some reason I misread and thought you meant "pager" menu. -- 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
Re: mutt 1.5.24 released
On Wed, Sep 02, 2015 at 01:50:20AM +0100, Ken Moffat wrote: > On Tue, Sep 01, 2015 at 12:08:34PM -0700, Brendan Cully wrote: > I happened to try building manual.pdf using this year's texlive, and > was slightly apprehensive to see : > > LaTeX Warning: There were undefined references. > > On a very quick look through the resulting PDF, I don't see any > obvious problems. But I'll attach a gzipped copy of the tex log in > case anybody cares. Possibly this is nothing new (last time I did > this I knew nothing about TeX, now I know that much of what is its > logs can safely be ignored). Hi Ken, Thanks for reporting the warnings. The undefined references seem to correspond to the id attribute values in various sections of the manual. I know very little about LaTeX, but I think these warnings can be safely ignored - the xml documents seem to be okay. -- 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
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
Re: mutt-1.5.23_9 && gnupg-2.1.6
On Thu, Dec 24, 2015 at 08:58:55AM +0100, Matthias Apitz wrote: > I got off-list some hints (thanks for them); after setting a bunch of > pgp_* values in ~/.muttrc I run into some GnuPG 2.1.x related problems; > it turned out, after bringing them up in the GnuPG mailing-list, that > one pnly need one(!) single value in .muttrc; and this works very > nicely; I'm attaching the hint from this mailing list; Alternatively, you could try set pgp_use_gpg_agent With that set, the classic interface should work fine with gpg 2.1. -- 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
Re: mutt-1.5.23_9 && gnupg-2.1.6
On Sat, Dec 26, 2015 at 06:32:03AM +0100, Matthias Apitz wrote: > El día Friday, December 25, 2015 a las 06:57:05PM -0800, Ian Zimmerman > escribió: > > > On 2015-12-25 08:11 +0100, Matthias Apitz wrote: > > > > > In the mutt' terminal (a uRxvt) the screen is a bit mangled: > > > ... > > > i.e. the \n at the end of each line is not interpreted anymore as \n+\r; > > > also the ENTER key sends only a \r to the STDIN of pinentry which is not > > > understood either as the end of the keyed-in passphrase; it took me some > > > time to figure out that I have to use Ctrl-j to end the passphrase; with > > > this all is fine, apart of the mangeled message above; > > > > Looks like raw vs. cooked mode issue. Should be fixable with stty. > > Ofc, but I think, this must be done inside mutt itsef, which hands over > the tty in this state; Mutt uses cbreak mode, but doesn't toggle raw/cooked mode anywhere as far as I can tell. In this case, the "Invoking PGP..." message is output before starting to display an encrypted message. It's generated by a mvaddstr() and refresh(). For gpgme, mutt is just making gpgme function calls, e.g. gpgme_op_decrypt_verify(), and then setting a flag to do a redraw afterwards. I don't see the code doing anything much different between decrypt/verify and signing. Werner, can you see anything different between gpgme_op_decrypt_verify() and gpgme_op_sign() and how they invoke pinentry if needed? -- 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
Re: mutt-1.5.23_9 && gnupg-2.1.6
On Sat, Dec 26, 2015 at 07:57:09PM +0100, Matthias Apitz wrote: > El día Saturday, December 26, 2015 a las 08:34:58AM -0800, Kevin J. McCarthy > escribió: > > > For gpgme, mutt is just making gpgme function calls, > > e.g. gpgme_op_decrypt_verify(), and then setting a flag to do a redraw > > afterwards. I don't see the code doing anything much different > > between decrypt/verify and signing. Ah... I was wrong. For signing/encrypting when we're about to send an email, mutt exits curses mode (calls endwin()). But when displaying a message, we stay in curses mode the whole time. From your example, it looks like you are using the TTY-based pinentry program, which probably would behave rather goofily when mutt is still in curses mode. Would you mind trying the curses enabled version? -- 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
Re: mutt-1.5.23_9 && gnupg-2.1.6
On Sun, Dec 27, 2015 at 07:11:04PM -0800, Will Yardley wrote: > On Sun, Dec 27, 2015 at 07:06:37PM -0800, Will Yardley wrote: > > Some are annoying, but haven't been able to articulate them well enough > > to file a bug. > > So one issue involves redraw, but the easier one to reproduce is that > when invoking gpg-agent the first time, after entering my passphrase for > the first time, I still have: > Invoking PGP... > > in the status bar while viewing the message, even after the message has > been successfully decrypted. > > This should be with the curses, vs. tty, interface to pinentry. Okay thanks Will, I will take a look at this. (I'm in the middle of a few other mutt-things, but I'll get to it as soon as I can.) Matthias, I'll also take a look at the decrypt TTY-mode issue too. Perhaps it's possible to wrap an endwin/refresh inside the decryption handler or somewhere in that sequence. -- 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
Re: How does Ian do the "name >" quoting?
On Sat, Jan 09, 2016 at 06:45:37PM +1100, Cameron Simpson wrote: > My current practice is: leave this alone, and use format=flowed for my > messages. This actually _requires_ the standard quote indent, and lets me > write messages (like this one) which will reflow nicely to fit the reader's > screen, yet look ok in a purely dumb pager like less because it is > physically folded around 72 characters. This is somewhat tangential, but I wanted to mention a new option in hg, $reflow_space_quotes, which converts the squished ">>>" ff quotes into "> > > " in the pager, and also in the editor for non-ff users. If any of you happen to feel brave and want to try hg tip, I'd appreciate any feedback about it. The option is on by default, and there is some documentation at <https://dev.mutt.org/doc/manual.html#ff> under "6.4.4. Reformatting". -- 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
Re: mutt-1.5.23_9 && gnupg-2.1.6
On Sun, Dec 27, 2015 at 07:11:04PM -0800, Will Yardley wrote: > On Sun, Dec 27, 2015 at 07:06:37PM -0800, Will Yardley wrote: > > Some are annoying, but haven't been able to articulate them well enough > > to file a bug. > > So one issue involves redraw, but the easier one to reproduce is that > when invoking gpg-agent the first time, after entering my passphrase for > the first time, I still have: > Invoking PGP... > > in the status bar while viewing the message, even after the message has > been successfully decrypted. > > This should be with the curses, vs. tty, interface to pinentry. I finally was able to install a KVM instance of FreeBSD 10.2. This has gpg 2.1.8, and I set up to use pinentry-curses. With the latest mutt tip built there, I'm not seeing any problems after decryption. The pinentry-curses completely clears the screen when it shows the prompt, and then afterwards the status bar shows "PGP message successfully decrypted." Now, that said, my testing is limited by the fact that I'm ssh'ing into the instance from my Debian testing computer. Perhaps there are some terminal issues I'm not hitting this way. -- 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
Re: mutt-1.5.23_9 && gnupg-2.1.6
On Wed, Feb 10, 2016 at 10:09:54PM -0800, Will Yardley wrote: > On Tue, Feb 09, 2016 at 06:52:29PM -0800, Kevin J. McCarthy wrote: > > With the latest mutt tip built there, I'm not seeing any problems after > > decryption. The pinentry-curses completely clears the screen when it > > shows the prompt, and then afterwards the status bar shows "PGP message > > successfully decrypted." > > > > Now, that said, my testing is limited by the fact that I'm ssh'ing into > > the instance from my Debian testing computer. Perhaps there are some > > terminal issues I'm not hitting this way. > > I've got 1.5.23 from ports, and using Apple Terminal, though don't think > that's the issue. $TERM is xterm-256color (though xterm behaves the same > way). > > System: FreeBSD 9.3-RELEASE-p33 (amd64) > ncurses: ncurses 5.7.20081102 (compiled with 5.7) > > Are you using: > set crypt_use_gpgme=yes > or are you using manual gpg commands? Thanks for the suggestion - that was the problem: I forgot to try it with gpgme! With gpgme, I can reproduce "Invoking PGP..." being stuck in the message after decryption. I'll get a patch in for that. Please let me know if there are other issues you see. -- 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
Re: mutt-1.5.23_9 && gnupg-2.1.6
On Mon, Feb 15, 2016 at 10:35:35PM -0800, Will Yardley wrote: > (without passphrase already cached by GPG), use 'limit' to find an > encrypted, *traditional* (not pgp-MIME) message in a folder. In some > cases, not completely reproducible, I then only see the 'S' in the index > lines that show up (when $pager_index_lines is set), and I see artifacts > of the pinentry page, sometimes sticking around for a while. The > screenshot here should show the behavior. > > Additionally, after this problem comes up, the up arrow in the 'limit' > pattern doesn't work (I get, e.g., [A for up-arrow), though I can still > type in there Ok. Just to help me track this: do you have $pgp_auto_decode set, or are you typing Esc-P inside the pager? It sounds like we need to trigger a hard redraw (which also turns keypad back on) on whatever path this is following. Also, does this only happen when you limit? > One other question -- it looks like $pgp_create_traditional doesn't work > with the $crypt_use_gpgme backend. The docs do kind of imply that, but > maybe it should also generate a startup warning if you have > $crypt_use_gpgme and $pgp_create_traditional both set?, Okay I'll look into this too. -- 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
Re: gpgme: ambiguous specification of secret key
On Tue, Mar 01, 2016 at 11:45:50PM +0100, Gregor Zattler wrote: > Dear mutt users, I use mutt on debian stretch with gpgme and > recently gnupg2 was upgraded to version 2.1 > > Now when I want to send an signed and encrypted email mutt is > configured to > > sign as: 0xB557830478789E7B98D7FEABF2EB825AD25307CA > > and says so in the send menu. But in the last line of the screen > it states: > > ambiguous specification of secret key > `0xB557830478789E7B98D7FEABF2EB825AD25307CA'? Mutt is seeing more than one result when querying for secret keys matching that fingerprint. When it gets the second result back from gpgme, it's aborting with that error. What does `gpg2 --list-secret-keys 0xB55` show? Also, are you seeing the problem with the classic interface? -- 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
Re: mutt-1.5.23_9 && gnupg-2.1.6
On Tue, Feb 16, 2016 at 11:43:16PM -0800, Will Yardley wrote: > On Tue, Feb 16, 2016 at 04:32:34PM -0800, Kevin J. McCarthy wrote: > > On Mon, Feb 15, 2016 at 10:35:35PM -0800, Will Yardley wrote: > > > (without passphrase already cached by GPG), use 'limit' to find an > > > encrypted, *traditional* (not pgp-MIME) message in a folder. In some > > > cases, not completely reproducible, I then only see the 'S' in the index > > > lines that show up (when $pager_index_lines is set), and I see artifacts > > > of the pinentry page, sometimes sticking around for a while. The > > > screenshot here should show the behavior. > > > > > > Additionally, after this problem comes up, the up arrow in the 'limit' > > > pattern doesn't work (I get, e.g., [A for up-arrow), though I can still > > > type in there Ok. > > > > Just to help me track this: do you have $pgp_auto_decode set, or are you > > typing Esc-P inside the pager? It sounds like we need to trigger a hard > > redraw (which also turns keypad back on) on whatever path this is > > following. > > I don't have $pgp_auto_decode set, but because the messages were created > via mutt (with older GPG and $pgp_create_traditional), there's an > x-header, so I don't have to explicitly hit esc-p. > > > Also, does this only happen when you limit? > > It seemed to be easier to reproduce that way, I'll try it the other way > with some non-pgp-MIME messages. After tracing through, it does turn out the GPGME code was missing a hard redraw call for application/pgp handling. I've added this and pushed it up. It should take care of the artifact and keyboard issues. Please let me know if it does not. I also added a note to the $pgp_autoinline and $crypt_use_gpgme options about gpgme not supporting creating inline pgp. -- 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
Re: gpgme: ambiguous specification of secret key
On Wed, Mar 02, 2016 at 11:52:22PM +0100, Gregor Zattler wrote: > * Kevin J. McCarthy [01. Mar. 2016]: > > Mutt is seeing more than one result when querying for secret keys > > matching that fingerprint. When it gets the second result back from > > gpgme, it's aborting with that error. > > > > What does `gpg2 --list-secret-keys 0xB55` show? [output from two different keyrings] > Urghs! The secret key is in public keyring!? I believe that's normal for gpg2 output (although is certainly confusing). What's probably causing the problem is the matches in both "pubring.gpg" and "import-zu-sortieren-keyring.gpg". Are you intentionally using both keyrings? If so, one solution would be to (carefully) remove your key from one of those keyrings. -- 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
Re: How to send a pre-written full email with mutt's built-in smtp
On Sun, Apr 03, 2016 at 07:38:41PM -0400, Xu Wang wrote: > Unfortunately, > mutt -H - < email_file > does not work when email_file has embedded attachments. To see this > use mutt to write an email, attach two PDF files, and then use the > above command on that email file. > > Send the email to yourself. You should see that the attachments were > not sent correctly. > > Is this a bug or is this a known limitation to mutt -H? This should work in the latest mercurial versions (or in 1.6, coming out tomorrow). It doesn't work in 1.5.24. -- 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
mutt 1.6.0 released
Hi Mutt Users, I'm pleased to announce the release of 1.6.0, available at ftp://ftp.mutt.org/pub/mutt/mutt-1.6.0.tar.gz. As with 1.5.24, please note the tarball is signed with my key [1]. This release is dedicated to the memory of Rocco Rutte (pdmef) , who helped Mutt's community and development tremendously during his years as a contributor and as a maintainer. 1.6.0 contains a few new features, along with a slew of bug fixes. Please take the time to read the UPDATING file, and review the sample gpg.rc and smime.rc files for changed and added options. We have started a wiki page at https://dev.mutt.org/trac/wiki/UpgradingTips and encourage the community to contribute tips and suggestions. Given the amount of time that has passed since the last stable release, the team has decided to move away from the odd/even numbering scheme for development/stable releases. Going forward, we will increment version numbers according to release significance. Thanks to everyone who helped make this happen, and to all our dedicated users. -Kevin [1] http://www.mutt.org/kevin.key GPG fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 1.6.1 released
Hi Mutt Users, We've just released version 1.6.1, available at ftp://ftp.mutt.org/pub/mutt/mutt-1.6.1.tar.gz. This is a bug fix release, dealing with three issues found in 1.6.0. There are no other changes besides those bug fixes. Thanks to everyone who submitted bug reports and helped us test these fixes. -Kevin signature.asc Description: PGP signature
Re: mutt does not decrypt gpg messages (anymore)
On Mon, May 09, 2016 at 09:06:37PM +0200, mhk wrote: > I can't decrypt any messages. Debug log shows the following (I hope I > pasted the relevant part): > > [2016-05-09 20:40:10] pgp_check_decryption_okay: " "Mathias > Hablützel "" doesn't match regexp. pgp_check_decryption_okay() is checking with value of $pgp_decryption_okay against the output from gpg. I believe this relies on '--status-fd=2' being in your $pgp_decrypt_command. If you don't have it there, you'll need to add it, or else unset $pgp_decryption_okay. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: 1.6.1 doesn't seem to use mailcap in the same way as 1.5.23 did - how to fix?
On Fri, May 13, 2016 at 02:53:03PM +0100, Chris Green wrote: > Version 1.6.1 doesn't call /home/chris/bin/muttfox (a script which > handles getting the HTML mail to firefox), version 1.5.24 did. So > what do I need to change to get 1.6.1 to work the way that 1.5.24 used > to? With 1.5.24 the first line of .mailcap was used when you hit 'v' > in mutt. Try hitting m (by default bound to ) in the attachment viewer. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Another 1.5.24 to 1.6.1 migration question
On Fri, May 13, 2016 at 02:57:03PM +0100, Chris Green wrote: > I have another question regarding 1.6.1 differences from 1.5.24. In > my index replies to message don't show their subject line correctly, > for example:- > > 18 r + 10-May-16 Jane Chevous( 83) Reshapers > 19 + 10-May-16 Jane Chevous( 179) M-b~T~TM-b~T~@> > > That M-b~T~TM-b~T~@> should be the ASCII graphics 'tree' to the next > message in the thread. > > I guess this is some sort of build configuration issue but I'd be > pleased for any pointers. It might be you didn't compile against a curses version with wide character support (libncursesw). https://dev.mutt.org/trac/wiki/MuttFaq/Charset has some info about this under "UTF-8 chars are displayed fine, but the screen is garbled". -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: 1.6.1 doesn't seem to use mailcap in the same way as 1.5.23 did - how to fix?
On Fri, May 13, 2016 at 05:10:59PM +0100, Chris Green wrote: > On Fri, May 13, 2016 at 08:58:45AM -0700, Kevin J. McCarthy wrote: > > On Fri, May 13, 2016 at 02:53:03PM +0100, Chris Green wrote: > > > Version 1.6.1 doesn't call /home/chris/bin/muttfox (a script which > > > handles getting the HTML mail to firefox), version 1.5.24 did. So > > > what do I need to change to get 1.6.1 to work the way that 1.5.24 used > > > to? With 1.5.24 the first line of .mailcap was used when you hit 'v' > > > in mutt. > > > > Try hitting m (by default bound to ) in the attachment viewer. > > Ah! Thank you, that works. Did the default get changed or what? Yes, it did, but earlier than I was involved, so I don't know the history of it. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Neomutt packages available
On Thu, Jun 23, 2016 at 10:58:25PM +0200, Elimar Riesebieter wrote: > I am pleased to announce the availability of neomutt [0] packages for > Debian. Hints for installation you'll find at [1]. I'm pretty sure you have emailed the wrong lists. Would you mind directing future emails about this to the neomutt mailing lists? Thank you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 1.6.2 released
Hi Mutt Users, I've just released version 1.6.2, available at ftp://ftp.mutt.org/pub/mutt/mutt-1.6.2.tar.gz. This is a bug-fix only release, fixing two issues found in 1.6.1: * Fix infinite loop when help is bound to a named key combination. * Check $pgp_autoinline and $pgp_replyinline if oppenc is set. Thanks to everyone who submitted bug reports and helped test the fixes! -Kevin signature.asc Description: PGP signature
Re: / l ~b has become extremely slow
On Fri, Jul 08, 2016 at 12:14:58PM +0200, Andre Majorel wrote:
> After upgrading from Mutt 1.5.21 to 1.5.23, trying to on
> the contents of the bodies of emails ("l ~b some-string") has
> become shockingly slow. It goes through about 10 messages per
> second, taking minutes to filter a medium-size mailbox.
There was a regression that was fixed in 1.5.24:
https://dev.mutt.org/hg/mutt/rev/755a18da99bc
I would suggest upgrading to at least 1.5.24 and even better to 1.6.2.
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: mbox problem on new system
On Thu, Jul 07, 2016 at 10:19:44PM +0100, Ken Moffat wrote: > When I open mutt on the old machine, I get a list of all the > mailboxes for the current month. But on the new machine I get > > /home/ken/Mail is not a mailbox. How do you invoke mutt? Do you have an alias? What is the value of $spoolflie? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: gpg groups or encrypt to multiple recipients (mailing list)
On Thu, Jul 14, 2016 at 03:40:39PM +0200, Steve Schmerler wrote: > Are there other workarounds in use? The solution above can't be the only > one. Starting in 1.5.24, you can use multiple crypt hooks with the same regex, and can turn off confirmation prompting with $crypt_confirmhook. See https://dev.mutt.org/doc/manual.html#crypt-hook So instead, you can just: # muttrc crypt-hook mailing.l...@company.com key1 crypt-hook mailing.l...@company.com key2 crypt-hook mailing.l...@company.com keyN unset crypt_confirmhook -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: crypt-hook: truncated list of gpg recipients passed to pgpewrap
On Tue, Jul 26, 2016 at 03:43:41PM +0200, Steve Schmerler wrote: > * stops at the third[**] key 74464897317CDA88 (length 16) and > * passes a truncated version 74464897317CDA (length 14) to pgpewrap > > which then gives me a "gpg: skipped: Invalid user ID". The related pgp > setting is > > set pgp_encrypt_sign_command="/usr/lib/mutt/pgpewrap gpg2 > %?p?--passphrase-fd 0? --batch --quiet --no-verbose --textmode > --output > %- --encrypt --encrypt-to --sign %?a?-u %a? --armor > %--always-trust -- -r %r -- %f" > > Does anybody know what's going on here (Debian, Mutt 1.6.0 > (2016-04-01))? Any hint is appreciated. Thank you very much! Hi Steve, I think I see the problem. Mutt is using a fixed buffer of size 1024 when expanding the %r parameter. I think when the system was designed, no one anticipated expanding 50+ keys in a single gpg invocation. :-) Right now, the best I can suggest is trying gpgme instead. I'll work on a solution for a future release. -Kevin -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: crypt-hook: truncated list of gpg recipients passed to pgpewrap
On Thu, Jul 28, 2016 at 11:12:52AM +0200, Steve Schmerler wrote: > On Jul 27 19:19 -0700, Kevin J. McCarthy wrote: > Thanks! I'll give gpgme a spin. I didn't find that much documentation, > though. I only need to set > > crypt_use_gpgme > crypt_use_pka You only really need to set crypt_use_gpgme, unless you specifically want to use PKA. > instead of defining the various pgp_* variables (usually shipped in > gpg.rc)? Do they have any effect, then? Thanks, again. When you are using the gpgme backend, those variables don't have any effect. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Attachment saving has lost a '/' and so fails
On Tue, Aug 16, 2016 at 10:49:45AM +0100, Chris Green wrote: > Just recently (maybe after an upgrade of my system to xubuntu 16.04) > when I save attachments from mutt it fails because it has lost the '/' > after the 'tmpdir' directory. Vanilla mutt does not prepend $tmpdir when saving attachments. > So what's gone wrong? Sounds like XUbuntu has an external patch that has a problem. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: broken date with LANG=xx_XX.UTF-8
On Wed, Aug 17, 2016 at 11:24:00AM +0200, Matthias Apitz wrote: > This is with mutt 1.5.24 (2015-08-30) on FreeBSD 11-CURRENT. > > $ LANG=es_ES.UTF-8 date > 17 de agosto de 2016, 11:14:48 CEST > > i.e. with this LANG the month name is 'agosto' (or short 'ago'); when > you start mutt with this the first 2 New mails look like this: > > $ LANG=es_ES.UTF-8 mutt > > q:Salir d:Sup. u:Recuperar s:Guardar m:Nuevo r:Responder g:Grupo > ?:Ayuda > 352 N ago. 17 Apitz,Matthias ( 13) test 1 > > 353 N Aug 17 Apitz,Matthias ( 13) test 2 Hi Matthias, What's the value of $locale (specified in the .muttrc)? Does it make a difference if you set locale="es_ES.UTF-8"? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 1.7.0 released
Hi Mutt Users, I've just released version 1.7.0, available at ftp://ftp.mutt.org/pub/mutt/mutt-1.7.0.tar.gz. This release contains several new features, including the sidebar and trash folder. (Note the sidebar is a compile time option: --enable-sidebar). Please read the UPDATING file for more details. Thanks to all the bug reporters, testers, translators, and patch submitters who helped make this release happen. Also, thanks to our dedicated community and support group on the mailing lists and irc. -Kevin signature.asc Description: PGP signature
Re: broken date with LANG=xx_XX.UTF-8
On Fri, Aug 19, 2016 at 07:39:06AM +0200, Matthias Apitz wrote:
> El día Thursday, August 18, 2016 a las 05:35:22PM -0500, Derek Martin
> escribió:
>
> > On Thu, Aug 18, 2016 at 09:48:31AM +0200, Matthias Apitz wrote:
> > > I have had in my ~/.muttrc file
> > > set locale="es_ES"
> >
> > DO NOT SET MUTT'S LOCALE, unless you really, really know what you're
> > doing. Let your operating system set it for you, unless you really,
> > really know what you're doing. It causes silly problems exactly like
> > this one... unless you really, really know what you're doing.
>
> If I unset it in ~/.muttrc and run
>
> $ LANG=es_ES.UTF-8 LC_ALL=es_ES.UTF-8 LC_TIME=es_ES.UTF-8 mutt
>
> it gives the month name as 'Aug', which is not correct.
I'm a bit confused by the mutt source code here. The default value of
$locale is "C", and the code around the index date formatting is calling
if (do_locales && Locale)
setlocale (LC_TIME, Locale);
strftime (buf2, sizeof (buf2), dest, tm);
if (do_locales)
setlocale (LC_TIME, "C");
(a leading '!' in the %{...} disables locales, thus the do_locales check).
Some other parts of the code are (more correctly) calling:
setlocale (LC_TIME, "");
strftime (p, sizeof (p), _(" (current time: %c)"), localtime (&t));
setlocale (LC_TIME, "C");
The documentation for setlocale() says a value of "" will cause the
locale to be modified by environment variables, so it seems like this is
what we would want in the index, isn't it?
Shouldn't $locale default to ""?
--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
Re: mutt 1.7.0 released
On Fri, Aug 19, 2016 at 04:45:20PM +1000, Erik Christiansen wrote: > Many thanks for your effort to keep us flea-free. > This time I do plan to upgrade. My pleasure. :-) 1.7.0 had a bit more internal changes than usual, so it could be a few fleas snuck in. As always, I appreciate feedback and bug reports. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: broken date with LANG=xx_XX.UTF-8
On Fri, Aug 19, 2016 at 01:03:40PM -0500, Derek Martin wrote: > On Fri, Aug 19, 2016 at 09:43:22AM -0700, Kevin J. McCarthy wrote: > > > The documentation for setlocale() says a value of "" will cause the > > locale to be modified by environment variables, so it seems like this is > > what we would want in the index, isn't it? > > Yes. But moreover, why is setlocale being called more than once, in > different ways? I'm guessing the LC_TIME setting might have an effect on other operations in Mutt, so it keeps it at "C" except when it needs to generate visible output. I think the first call should always be something like: setlocale (LC_TIME, NONULL (Locale)); and that Locale ($locale) setting should default to "", so that Mutt by default will respect the users's environment. I'll play with this and post something on mutt-dev. Let's continue the conversation there. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: weird behaviour unaliasing/sourcing aliases in folder-hooks
On Wed, Oct 05, 2016 at 11:38:28PM +0200, nfb wrote: > folder-hook "some_folder" "\ > unalias *; set alias_file=/path/to/alias/file; source $alias_file" TL;DR: $alias_file is expanded at muttrc parsing time, not when the folder-hook is run. One workaround is to defer evaluation of $alias_file by using \$alias_file (see https://dev.mutt.org/doc/manual.html#set-myvar). Alternatively, you can just spell out the file in both the set and the source. (literally, or perhaps by using a user-defined variable to reduce duplication). Details: Since $alias_file defaults to the value of the muttrc, essentially each of your hooks initially will set $alias_file and re-read the muttrc. They are equivalent to: folder-hook "foo_folder" "unalias *; set alias_file = +foo_alias; source muttrc" folder-hook "bar_folder" "unalias *; set alias_file = +bar_alias; source muttrc" folder-hook "last_folder" "unalias *; set alias_file = +last_alias; source muttrc" Lets say you enter foo_folder first. This will run the first hook above, resourcing the muttrc and creating three new folder hooks. So all the folder hooks will look like this: folder-hook "foo_folder" "unalias *; set alias_file = +foo_alias; source muttrc" folder-hook "foo_folder" "unalias *; set alias_file = +foo_alias; source +foo_alias" folder-hook "bar_folder" "unalias *; set alias_file = +bar_alias; source muttrc" folder-hook "bar_folder" "unalias *; set alias_file = +bar_alias; source +foo_alias" folder-hook "last_folder" "unalias *; set alias_file = +last_alias; source muttrc" folder-hook "last_folder" "unalias *; set alias_file = +last_alias; source +foo_alias" Note that mutt will not create exact duplicate folder-hooks. So subsequently entering foo_folder will not create any more folder hooks when sourcing the muttrc. But, when you enter bar_folder, it will add a third folder hook to every folder (sourcing +bar_alias), and last_folder will add a forth hook when entered. After that, whichever folder you enter, the last folder hook will "win". -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: can't read sent encrypted mail
On Fri, Oct 07, 2016 at 07:46:10PM +0200, Peter P. wrote: > Hi list, > > I am having a strange problem with mutt (NeoMutt 1.7.0 on debian > testing) and gpg (GnuPG) 2.1.15 Debian switched to using GPGME by default. GPGME does not look at the various $pgp_* commands, so your changes made in your muttrc are not taking effect. Add 'unset crypt_use_gpgme' to your muttrc, to start using your pgp_encrypt_sign_command again. Unfortunately, emails you've already sent with gpgme enabled will not be readable by you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: [SPAM?] some elements keep solid black background
On Sat, Oct 08, 2016 at 12:09:10AM +0200, nfb wrote: > There are, however, some parts that preserve a solid black background, > like the "[-- Attachment ... --]", "[-- appication/zip ... --]", > "[-- Type ... --]", "[-- Autoview using ... --]" strings, Those should be covered by the 'attachment' color object. Have you tried setting the background for that to default? > or the empty bottom of the mail body when you scroll al the way down > (even after the signature, if any). This should be covered by the 'tilde' color object. > And shouldn't the directive "color normal default default" (which i > obviously have in my rc file) already cover this? No, that won't change the default for all the different color objects. Normal just represents "everything else" not covered by the other color objects. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: can't read sent encrypted mail
On Sat, Oct 08, 2016 at 02:46:42AM +0200, Peter P. wrote: > Interesting! man muttrc tells me that the default for crypt_use_gpgme is no. Yes, but I believe they changed the system muttrc to enable it (likely in /etc/Muttrc.d/gpg.rc. Your own muttrc is read afterwards and so can override that setting. > Nevertheless when I > unset crypt_use_gpgme > or > set unset crypt_use_gpgme=no > the problem remains. Which problem are you speaking of? This will not magically allow you to read emails encrypted in the recent past using gpgme (that therefore were not also encrypted to you). It should make emails sent henceforth be encrypted to you again. > How could I debug this further? Well, first I am assuming that this is a recent change in behavior, and that prior to the mutt upgrade in Debian you had no trouble reading your encrypted emails sent to others. You might check that those older sent emails are still readable by you. To make sure the option is off, type :set ?crypt_use_gpgme and mutt should echo back 'crypt_use_gpgme is unset' Also note that this option needs to be (un)set in your muttrc and mutt must to be restarted; you can't change it interactively to effect. > Btw, is there any advantage of switching to gpgme? The classic interface has some built-in size limits to the number of recipients. It also requires setting $pgp_use_gpg_agent appropriately depending on if you are using gpg 1.4, 2.0, or 2.1. However, the classic interface is better tested. There's a lot of gpgme code that I haven't looked at in detail, and there will likely be more bugs that need to be shaken out of it. > How would I add my own key to the encryption in gpgme? You could try adding an 'encrypt-to' setting in your ~/.gnupg/gpg.conf file. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 1.7.1 released
Hi Mutt Users, We've just released version 1.7.1, available at ftp://ftp.mutt.org/pub/mutt/mutt-1.7.1.tar.gz This is a bug fix release, fixing an imap segfault along with several other small issues found in 1.7.0. Details can be found in the ChangeLog file. Thanks to everyone who contributed bug reports, patches, and helped with testing. -Kevin signature.asc Description: PGP signature
Re: fetching mails with mutt/imap
On Sun, Dec 04, 2016 at 10:36:50AM +0100, Matthias Apitz wrote: > This works fine and fast. The only issue is: when there is no mail to > read, mutt says "No mail" and does not end by itself. One has to used > 'q' to end it. Why? Mutt has some standard checks in front of various operations. For the tagging, they check if the mailbox is empty or if nothing is visible. In those cases, they give an error message and flush the input buffer. So the is never run. This is not ideal, but I don't have any immediate ideas how to fix this. (The checks are there because some of the code assumes there is a "current" message, or at least one message.) -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 1.7.2 released
Hi Mutt Users, We've just released version 1.7.2, available at ftp://ftp.mutt.org/pub/mutt/mutt-1.7.2.tar.gz This is a bug fix release, primarily fixing build issues with OpenSSL 1.1 and GPGME 1.8. Please note that as part of the OpenSSL fixes, versions less than 0.9.6 are no longer supported. Thanks to everyone who submitted bug reports, patches, and helped test this release! -Kevin signature.asc Description: PGP signature
Re: Long delays when mailbox gets modified externally
On Wed, Feb 01, 2017 at 02:53:46PM -0800, Greg Hurrell wrote: > set mail_check = 60 > set mail_check_stats = yes > set mail_check_stats_interval = 300 > set sleep_time = 0 > set time_inc = 250 > set timeout = 0 > > Of these, I'm most suspicious of `mail_check_stats`. It sounds likely that the stats check is causing these brief hangs, given the amount of mail you mentioned having. It isn't very useful to have $timeout set so low. I would bump that up to >= $mail_check (60). That might help a little. However, if it isn't super important to list the number of messages in the sidebar or folder browser, you may want to just turn $mail_check_stats off. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Missing N(ew) indicator for maildirs
On Wed, Feb 08, 2017 at 05:21:27PM +0100, Jörg Sommer wrote: > in the mailbox overview, I'm missing the new message indicator for a > maildir. My folder_format contains %N which gets substituded by N of the > mailbox contains new messages. When I open a mailbox in maildir format and > leave some messages unread, the indicator isn't shown in the folder > overview. What might be wrong? Hi Jörg, Try unsetting $mail_check_recent. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: color line in compose menu?
On Sat, Feb 11, 2017 at 04:29:01PM +0100, ilf wrote: > I am trying to color the "Security:" line in the compose menu. Is that > possible? Sorry ilf, that part is not currently colorable. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: color line in compose menu?
On Sun, Feb 12, 2017 at 06:22:20PM +0100, ilf wrote: > Kevin J. McCarthy: > > > I am trying to color the "Security:" line in the compose menu. Is > > > that possible? > > Sorry ilf, that part is not currently colorable. > > Okay, that's what I assumed. > > What do you think of this idea? Does it sound useful to you? > > I for one would really like a color setting there, especially for the > Security:" line. We're just about to freeze for 1.8, but I'll put this on my list to look at for a future release. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: sendlib variable "privacy"
On Sun, Feb 19, 2017 at 04:07:11PM +0100, ilf wrote: > 1. Does that mean that if "privacy" is set, the "User-Agent:" header is not > set? Yes. It can also be turned off using the $user_agent configuration setting. > 2. Does "privacy" do anything else? The privacy parameter is set when using Mixmaster. See more at https://dev.mutt.org/doc/manual.html#sending-mixmaster > 3. I can't find "privacy" anywhere else in the repository and the > documentation. Is this on purpose? Or was it somehow forgotten and we should > document it? It's just the name of the C function parameter, and is documented above mutt_write_rfc822_header(). This isn't something meant to be visible to, or configured by, the end user. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Changing the reply address.
On Tue, Feb 21, 2017 at 05:27:55PM +1100, Erik Christiansen wrote: > Way back on 27.04.09 16:57, Kyle Wheeler wrote: > > > send2-hook '~C helpdesk@mycompany' \ > > 'helpdesk@mycompany' > > to: > > reply-hook '~f x...@yyy.asn.au' \ >'z...@bigpond.com' You'll want to use the "push" command: reply-hook '~f x...@yyy.asn.au' \ 'push z...@bigpond.com' *However*, this kind of thing is very delicate. Any prompts that occur after the hook is set will try to read from the pushed input, for example $include should either be set to yes/no or you'll need to add a "y" at the beginning of the push string for that prompt. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
