Re: Option to disable S/MIME signature check?
I asked on gnupg-users. Adding "disable-dirmngr" to gpgsm.conf disbles the use of the Dirmngr and thus expensive online checks that can take a long time to timeout. This is a viable workaround. I still believe it would be great to have an option in Mutt not to use GPGME for S/MIME in the first place. But it's not urgent any more. Kevin J. McCarthy: Also, is there a way to shorten the time that SMIME signature verification needs before timing out? 25 seconds sounds much too long to me. I don't know what it's doing that takes so long to time out, and have no idea how to adjust that. Maybe others who use s/mime with GPGME have ideas. -- ilf If you upload your address book to "the cloud", I don't want to be in it.
Re: Option to disable S/MIME signature check?
Done, thanks: https://gitlab.com/muttmua/mutt/-/issues/450 Kevin J. McCarthy: Yes, please go ahead. I don't have a current timeline for starting master development again, but when I do, it will be good to have the request there. -- ilf If you upload your address book to "the cloud", I don't want to be in it.
Re: Option to disable S/MIME signature check?
Do you think I should file a feature request for this in the tracker? Kevin J. McCarthy: There seem to be quite a few users with this issue. Do you think a boolean option like "crypt_verify_smime" that explicitly works even with GPGME would be feasible? From a user POV, it sure sounds logical and useful. Yes, that may be possible although it might be better to then deprecate $crypt_verify_sig and just have the separate pgp and smime config vars (which should be quadoptions). It certainly wouldn't go in a stable release. -- ilf If you upload your address book to "the cloud", I don't want to be in it.
Re: Option to disable S/MIME signature check?
I have never used "message-hook" before. That looks like a workable workaround. I have also never used "spam" before. I wonder if this feature is really correct for my use-case, which has nothing to do with spam. It might do the job, but it doesn't feel clean. There seem to be quite a few users with this issue. Do you think a boolean option like "crypt_verify_smime" that explicitly works even with GPGME would be feasible? From a user POV, it sure sounds logical and useful. Also, is there a way to shorten the time that SMIME signature verification needs before timing out? 25 seconds sounds much too long to me. Thanks a lot! Kevin J. McCarthy: So: How can I disable the S/MIME signature check while still using GPGME for OpenPGP? The option $crypt_verify_sig is shared between PGP and S/MIME, so you'll have to be creative if you are using GPGME. Maybe something like: spam content-type:.*pkcs7 smime message-hook ~A 'set crypt_verify_sig=yes' message-hook '~H smime' 'set crypt_verify_sig=no' # or '=ask-no' -- ilf If you upload your address book to "the cloud", I don't want to be in it.
Re: Option to disable S/MIME signature check?
Hi I would also like to disable the S/MIME signature check. I have no use for it. And "Invoking S/MIME..." takes 25 seconds before failing with "S/MIME signature could NOT be verified." I do use OpenPGP. So disabling "crypt_use_gpgme" is not an option for me, same for changing "crypt_verify_sig". In the old thread from 2018, Kevin J. McCarthy proposed this: However, you could try set smime_verify_command="" (along with smime_verify_opaque_command and smime_decrypt_command). But this does not work. According to muttrc(5) the default value for these three options is already "", and I am not setting them anywhere. So: How can I disable the S/MIME signature check while still using GPGME for OpenPGP? Thanks W. Martin Borgert wrote 2018-05-15: once in a while I get emails with S/MIME signatures. This is on public mailing lists, where I seldomly care about signatures, and I open the email only to read one or two lines to be sure I can actually press 'd' :~) Mutt says "Invoking S/MIME..." which takes too long for my taste (some seconds just to open one email which I will delete anyway) and then usually: "S/MIME signature could NOT be verified." I would like to disable this signature check altogether, because all my real contacts use either PGP or no signature at all. Is there an option in mutt to do this? Hopefully a run time option, not a compile time option... -- ilf If you upload your address book to "the cloud", I don't want to be in it.
macro to retreive openpgp certificate?
Sometimes I view mails with an OpenPGP signature without having the corresponding certificate, then I get the error: Can't verify due to a missing key or certificate Does anyone have a good macro to retrieve that specific OpenPGP certificate and re-check the signature? Something along the lines of "^K" "extract-keys" "extract supported public keys". -- ilf If you upload your address book to "the cloud", I don't want to be in it.
Re: macro/prompt to trigger mailcap?
Darac Marjal: If you have one entry for the mime-type with the "copiousoutput" flag, and you put that AFTER one without, then mutt will use the copiousoutput program to auto_view the attachment, but it will invoke the other one when you "view-mailcap". Nice. But I'd like to *parse* the attachment only after I pressed a key, but then all attachments at once. -- ilf If you upload your address book to "the cloud", I don't want to be in it. signature.asc Description: PGP signature
macro/prompt to trigger mailcap?
How do you handle attachments? Currently, I use "auto_view text/html" and "implicit_autoview" with mailcap. However, I would like to not display attachments via mailcap automatically on opening a mail, but only after pressing another key. (Never trust attachments…) Is there any way one could implement this in mutt currently? Maybe with some kind of macro? -- ilf If you upload your address book to "the cloud", I don't want to be in it. signature.asc Description: PGP signature
sendlib variable "privacy"
In sendlib.c, there is a variable named "privacy".
* privacy != 0 => will omit any headers which may identify the user.
* Output generated is suitable for being sent through
* anonymous remailer chains.
https://dev.mutt.org/hg/mutt/file/tip/sendlib.c#l1933
if (mode == 0 && !privacy && option (OPTXMAILER) && !has_agent)
{
/* Add a vanity header */
fprintf (fp, "User-Agent: Mutt/%s (%s)\n", MUTT_VERSION, ReleaseDate);
}
https://dev.mutt.org/hg/mutt/file/tip/sendlib.c#l2072
My C is bad.
1. Does that mean that if "privacy" is set, the "User-Agent:" header is
not set?
2. Does "privacy" do anything else?
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?
Thanks, and keep up the good work!
--
ilf
Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung
signature.asc
Description: PGP signature
Re: color line in compose menu?
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. -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: PGP signature
color line in compose menu?
I am trying to color the "Security:" line in the compose menu. Is that possible? In the manual, I cannot find "compose" in "object": http://www.mutt.org/doc/manual/#color So, something like this does not work: color compose red default "None" color compose yellow default "Sign" color compose green default "Encrypt" Could anyone point me in the direction how to achieve this? Thanks, and keep up the good work! -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: PGP signature
Re: Multiple accounts at same privider
On 07-01 00:59, J. Prendick wrote:
macro index f1 source ~/.mutt/isp_1.cnf
macro index f2 source ~/.mutt/isp_2.cnf
This is far too obvious ;)
Since there seems to be some interest, I'll gladly share my setup. This:
- switches to this account with Alt+3
- keeps account-rcs small by adding another generic one
- adjusts $compose_format and $status_format to display the current
account. Others ITT do this with colors.
Feedback is of coure welcome.
#
# snip from ~/.mutt/muttrc
#
macro generic \e3 :source ~/.mutt/accounts/i...@zeromail.orgenter
i...@zeromail.org
#
# ~/.mutt/accounts/i...@zeromail.org
#
set realname=ilf
set from=i...@zeromail.org
set hostname=zeromail.org
set pgp_sign_as=0x87C0AECC
source ~/.mutt/accounts/generic.rc
#
# ~/.mutt/accounts/generic.rc
#
# send
set sendmail=/usr/bin/msmtp --account $from
# compose
set signature=~/.mutt/sigs/${from}
my_hdr OpenPGP: id=${pgp_sign_as}\; preference=signencrypt
my_hdr Cc:
# format
set compose_format= $from | size: %l | attachments: %a
set status_format= %r | %f | mails: %?M?%M/?%m%?n? new: %n?%?o? old: %o?%?d?
deleted: %d?%?F? flagged: %F?%?t? tagged: %t?%?p? postponed: %%p?%?b? incoming: %b?%?l? |
${from}?%* %P
# override these two from /etc/Muttrc.d/gpg.rc
# always also encrypt to self
set pgp_encrypt_only_command=/usr/lib/mutt/pgpewrap gpg --batch --quiet
--no-verbose --output - --encrypt --textmode --armor --always-trust --encrypt-to
$pgp_sign_as -- -r %r -- %f
set pgp_encrypt_sign_command=/usr/lib/mutt/pgpewrap gpg %?p?--passphrase-fd 0?
--batch --quiet --no-verbose --textmode --output %- --encrypt --encrypt-to $pgp_sign_as
--sign %?a?-u %a? --armor %--always-trust -- -r %r -- %f
--
ilf@jabber.berlin.ccc.de
Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg!
-- Eine Initiative des Bundesamtes für Tastaturbenutzung
signature.asc
Description: Digital signature
Re: Multiple accounts at same privider
On 06-30 08:57, J. Prendick wrote: If now a equals b we do have a problem. I could for example change the macro-lines to macro index f1 change-folderimaps://user1:passwo...@a.com macro index f2 change-folderimaps://user2:passwo...@a.com which enables me to switch between the accounts, but e.g. from=, pgp_sign_as=, ... are not beeing set correctly. Does anyone have any idea how to solve that problem? How about this? macro index f2 change-folderimaps://user2:passwo...@a.comreturnset from=user2returnpgp_sign_as=0xDEADBEEFreturn -- ilf@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: Stripping bad ^M for plain/text
On 06-14 10:26, David Woodfall wrote: Is there a way of getting mutt to auto-strip these from plain/text? set display_filter=fromdos -- ilf@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: mailcap -- file not found
On 06-01 09:13, Peter Stoddard wrote: What is the proper mailcap entry to view html attachments? text/html; w3m -I 'iso-8859-15' -T text/html -dump; copiousoutput :) -- ilf@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: Authenticating in the clear?
On 06-01 09:31, Peter Stoddard wrote: set smtp_url=smtps://p...@stoddard.us@host144.hostmonster.com:465/ set smtp_pass=** ... and I think the port number and the smtps mean I am sending encrypted. Am I really authenticated in the clear? Most likely your password is sent in PLAIN over the encrypted connection, as opposed to sending a hash like DIGEST-MD5 or CRAM-MD5. It should therefore be as safe as the SSL/TLS connection. -- ilf@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: [PATCH] Re: handling List-Id header
On 04-12 14:20, Michael Elkins wrote: Attached is a patch which implement an auto-subscribe feature. When you load a mailbox, Mutt will parse the List-Post header field and add it to the 'subscribe' list automatically, unless it matches something on the 'unlists' or 'unsubscribe' list. Thanks, this is awesome. Why did you not push it into the mainline code? -- ilf@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: hex colors?
On 04-11 17:09, Michael Elkins wrote: You can use colorN where N is up the maximum number of colors your terminal supports. For example, I just tested this with rxvt-unicode: color indicator color63 color34 This indeed works directly in rxvt-unicode, but it doesn't work in screen :( -- ilf@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: handling List-Id header
On 04-11 20:32, Michael Elkins wrote: On Sat, Apr 10, 2010 at 01:38:19AM +0200, ilf wrote: I would like a workaround to use Regex in 'lists' and 'subscribe', but that feels dirty. Why doesn't Mutt allow 'lists'/'subscribe' to lists based on the List-Id: header? The List-ID header is not necessarily a valid email address. All that the RFC requires is that it be a unique value for each list. As such, it's not terribly useful for figuring out where to reply. I never proposed using List-Id to figure out where to reply, List-Post is the right field for that and it's being done nicely. But I think Mutt could display messages as from a list (in index with %L and %Z) automatically, if a List-Id header is present. Then I would not need lists/subscribe at all. The problem with not using the subscribe command in Mutt is the very common case where your address appears on the To or CC line in addition to the mailing list address. In this sitation you will receive two copies of the email: one directly from the message sender, and another from the mailing list software. That's a user error in my view and not something Mutt should care about. People should use list-reply instead of reply-all. On 04-11 20:22, Michael Elkins wrote: The reason for the distinction between lists/subscribe is that just because you received an email that was addressed to a list doesn't mean that you are subscribed to said list. But if there's a List-Id header, I am subscribed. -- ilf@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
hex colors?
I'm using Mutt in rxvt-unicode and I'm wondering why I can't assign hex values to Mutts color attribute. Mutts manual sais, the color values can be the eight ANSI colors, default and colorx: http://www.mutt.org/doc/manual/manual-3.html#ss3.7 rxvt-unicode also knows additional 72 colours, a 4*4*4 RGB colour cube and 8 more shades of gray. In addition, rxvt-unicode can even use hex values like #00ff00, hex values with opaquenes percentage like [95]#00ff00 and values like rgba:///: http://pod.tst.eu/http://cvs.schmorp.de/rxvt-unicode/doc/rxvt.1.pod#COLORS_AND_GRAPHICS Yet, Mutt only lets me specify color0-color7. Everything above gives an error, also hex values and RGB specifications. Why is that so? Why does Mutt not allow hex (or other) values for colors? -- ilf@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Re: handling List-Id header
On 04-09 01:21, Brian Ryans wrote: See above: concerns you raise, indirectly, in the remainder of this post seem to be addressed above to the best of my ability. Please let me know if that's not the case. Thanks for your hints. But I am still confused :) Manual section 4.8 Handling Mailing Lists sais, Mutt can do things with mailing lists once Mutt knows what [my] mailing lists are. It can: 1. show mailing list in index with - listname with $index_format including %L - message status flag 'L' with $index_format including %Z 2. use list-reply 3. use $followup_to Section 3.9 Mailing lists sais that use $followup_to is only for subscribed lists. I have not tried this. Using list-reply apparently works based on listsed lists and with the List-Post: header. Cool with me. But the first feature, showing mailing lists in index only works with subscribed lists. It does not work with listsed lists. Why? Also, it seems intuitive to me, that Mutt should show mailing lists in index not only with listsed lists, but also automatically based on the List-Id: header. And that's what I assume this Ticket is also about: http://dev.mutt.org/trac/ticket/3160 What do you think? -- ilf i...@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
handling List-Id header
I'm confused by Mutts handling of mailing lists. First, I do not understand the difference of known lists (lists) and subscribed lists (subscribe). If Mutt handles mail from a known list, I'm probably subscribed, no? Secondly, I find having to manually maintain a list of subscriptions in my config unreasonable. Why doesn't Mutt automatically lists/subscribe to lists based on the List-Id header? That's what it's for: By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available. http://www.ietf.org/rfc/rfc2919.txt This has been mentioned here before by Kyle Wheeler on 20 Jun 2007: Now, it's probably fair criticism if you want to say that mutt should also check List-Post and/or List-ID headers (if they exist), but for good or ill, it does not currently (file a bug report). http://www.mail-archive.com/mutt-users@mutt.org/msg32989.html The only related Bug on Trac is Ticket #3160, renamed support for more mailing list headers to detect list mail by pdmef on 2009-01-27. Has there been any discussion on this? What do you think? Thanks, and keep up the good work! -- ilf i...@jabber.berlin.ccc.de Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
