Re: [OT-ish] Want command line program to selectively delete emails
Ed Blackman wrote (Fri 2023-Aug-04 14:34:44 -0400): > ... remove emails that were received more than X days ago, but can also > express "but don't delete if they're flagged". .. > I could give up on using the message headers to determine the message date, > learn how filenames are constructed in Maildir (to read the flags) and use a > shell script built around "find". That's what I'd probably do. It might be simpler than expected: find ~/mail/folder1/cur/ -maxdepth 1 -type f -not -name '.*' \ -mtime +30 \ -not -name '*:2,*F*' \ -delete The conditions in the first line are generic, the other three lines should match your example: received more than 30 full days ago && not flagged => delete. If you also want to delete mails that "have not yet been seen by any mail application" [1], let "find" also look at new/. Entries in new/ never contain an info part (the stuff after the colon), so you can drop the check for an unset "F" flag if you need to invoke "find" separately for new/ anyway. [1] https://en.wikipedia.org/wiki/Maildir Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: [ext] Apple displays flowed text
Ralf Hildebrandt wrote (Mon 2022-Oct-31 08:12:23 +0100): > * Kurt Hackenberg : .. > > The iPhone mail reader displays flowed text correctly: lines are filled and > > word-wrapped to fit the screen. It also rotates when you turn the phone > > sideways. > > > > The Macintosh mail reader also displays flowed text correctly, and rewraps > > on the fly when you change the size of the window. > > And the question is? I guess Kurt's message should have referenced another of Kurt's messages, . I still have that older message flagged, too. :-) Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: The way mutt handles long lines, seems odd/wrong to me
Chris Green wrote (Fri 2022-Sep-30 14:42:09 +0100): > So, when there is a long string of text in a message that is longer > than the width of the terminal and has no spaces in it mutt *always* > breaks the line at the RHS of the terminal window and displays the > rest of the line on separate continuation lines. .. > Have I missed a setting somwhere that affects this or is it just a > bug/feature? Can I ask if it might be fixed because it's one of the > few things i find really annoying about mutt - not being able to > easily select and use long URLs. Is the configuration variable called "markers" what you're looking for? Quoting from the manual: markers Type: boolean Default: yes Controls the display of wrapped lines in the internal pager. If set, a “+” marker is displayed at the beginning of wrapped lines. Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: Visualising contents of a Maildir
martin f krafft via Mutt-users wrote (Wed 2022-Aug-17 21:22:31 +0200): > Is there a way to "screenshot" the Mutt index beyond the scroll > window? xterm can create decent screenshots in HTML or SVG format. The HTML version essentially is one big using CSS and s for colors and other highlighting; the SVG version places characters at their pixel-position on the SVG canvas. I can reach those functions using Ctrl + left mouse button, "XHTML Screen Dump" and "SVG Screen Dump". The files are called something like "xterm.2022.08.18.09.23.33.xhtml"; not exactly sure where they get created (home dir? working dir?). So, if one of these output formats would be a step forward, and you found a way to make an xterm window enormously large, and you found a way to trigger xterm's "screen dump" function (if you don't want to do that manually), then you could use Mutt running in the xterm window... Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: ask-yes for sending?
bwalton.22...@leepfrog.com asked (Tue 2022-Jun-07 10:26:50 -0500): > Is there a way to configure my muttrc so that when I press "y" to send > the message, it will prompt for confirmation before actually sending? In order to avoid accidentally sending a message because of fat fingers, I moved from using "y" to "Y": bind compose y noop bind compose Y send-message Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: Slightly OT: I'm looking for a tool to merge maildirs
Chris Green wrote (Sun 2022-Jan-23 10:46:33 +): > Both hierarchies will be on the same computer so it isn't an IMAP > synchronisation tool I'm looking for. These are just directory trees > full of maildir mailboxes. How about copying files on disk? You could use "find" and/or "grep" to find the messages (= files); use hardlinks if you're sure that no message will be modified; use reflinks if the filesystem supports them; or simply copy from your current area to the archive again and again, if it's not too much data; use "fdupes" to remove duplicates (= identical content in differently named files) if there's a chance for duplicates being created. Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: How to create local label and enlist/see them
Bhaskar Chowdhury wrote (Sat 2021-Sep-18 10:05:57 +0530):
> ... if I put some text there and enter it says "Label created" but how to
> see those label???
I modified "index_format" to show the label string at the right-hand
edge of each line.
The default value for index_format is:
%4C %Z %{%b %d} %-15.15L (%?l?%4l&%4c?) %s
My .muttrc sets an extended version:
set index_format="%4C %Z %{%b %d} %-15.15L (%?l?%4l&%4c?) %s%* %?y? %y?"
If a message's label string is non-empty, it will be shown prepended
with five spaces and right-aligned, overwriting a long subject.
Cheers, Marcus
--
Marcus C. Gottwald ·· @mcg:cheers.de
Re: Assigning multiple labels (X-Label) to a message
David Champion wrote (Wed 2020-Dec-16 16:36:40 -0800): > As Kevin mentioned, I have some patches that work to resolve this > stuff. Thanks a lot for the info! > * The new code will permit X-Label keyword splitting on space or comma, Cool -- so I'll use either space or comma, depending on what looks better as part of %y in the index. :-) Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: Assigning multiple labels (X-Label) to a message
Kevin J. McCarthy wrote (Wed 2020-Dec-16 10:05:34 -0800): > Mutt's label handling is pretty basic right now. It expects > only a single X-Label header in the email. When editing the > label, Mutt only knows how to write a single X-Label header > back. Thanks for the explanation. I'll change my procmail recipes to modify an existing X-Label header line instead of adding additional ones. Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Assigning multiple labels (X-Label) to a message
Dear fellow Mutt users, I have incoming email messages which get multiple labels assigned by "procmail" piping through "formail -A", adding an "X-Label" header line for each label. Mutt fetches those email messages via IMAP and appears to be looking at only the last X-Label header line when (a) formatting the index using the "%y" selector in "index_format" and (b) limiting using the "~y" pattern. (I'm using Mutt from current Debian stable, i.e. version 1.10.1.) What's the recommended way to deal with multiple labels assigned to an email message? Can I make Mutt look at the values of all X-Label header lines? Should I change the procmail recipes to append (or prepend) additional labels to an existing X-Label header line instead of adding new lines? When using multiple labels in a single X-Label header line, are there any advantages in using a specific delimiter (space, comma, ...)? Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: Folding or weeding long lists of emails in To/CC fields, or skip to content key
Raphaël Fournier-S'niehotta wrote (Fri 2020-Nov-27 14:10:35 +0100): > I tried a few minutes too, and for whatever reason the following seems to work > (i.e., skip to the first blank line after the headers, then to the next blank > line): > > macro pager S \^\\s+\$ Thanks! I've been using that approach (bound to the "+" character) for the last few days, and it works fine for me. Lines consisting of only whitespace get highlighted (obviously), but that's no reason not to use the feature. Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: Folding or weeding long lists of emails in To/CC fields, or skip to content key
Francesco Ariis wrote (Thu 2020-Nov-26 22:27:20 +0100): > > > ... Or is there a key to "skip to the body of the email" quickly, in the > > > pager? .. > macro pager Q Sub Interesting, thanks! So if I use that approach for searching for an empty line, I should be able to first skip the email's header and then continue jumping down paragraph by paragraph using the same key? I could probably use some key located next to the Enter key on my keyboard for jumping down to the next empty line. And I might use the same key with Shift for jumping (up or down) to the beginning of the body, by prepending "" to the macro... A possible drawback for me is that using "" changes the youngest entry in the list of search terms that have been used; but I'd probably get used to it. But how do I search (in the pager) for an empty line? I can search for characters at the beginning of a line (using ^foo when entered at the search prompt and \^foo when interactively defining the macro after pressing ":") or at the end of a line ($) -- but a search for ^$ appears to match on every line, whether the line is empty or not. I'm using Mutt from current Debian stable, 1.10.1. Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: Folding or weeding long lists of emails in To/CC fields, or skip to content key
Raphaël Fournier-S'niehotta wrote (Thu 2020-Nov-26 15:54:26 +0100): > ... Or is there a key to "skip to the body of the email" quickly, in the > pager? +1 for adding such a function if it doesn't already exist. Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: mutt not showing transparency in xfce4-terminal
Trey Sizemore wrote (Mon 2020-Aug-10 09:58:48 -0400): > > [...] I'd suggest to start with the object called "normal". > > It looks like default is used in the majority of cases in my .muttrc: [This space intentionally left blank.] -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: mutt not showing transparency in xfce4-terminal
Trey Sizemore wrote (Mon 2020-Aug-10 07:53:17 -0400): > If I set xfce4-terminal to transparent, it works as expected. > > If I then start mutt from from xfce4-terminal, the only transparency are > messages highlighted in some way (new, from me, flagged) All other mails are > set against a black background. I can confirm at least part of what you have observed (using Debian buster). I believe the background color in Mutt is set to "black" for most things. Setting the background color to "default" makes it transparent in my case. You'll probably have to set the background color of several objects to "default" (in your muttrc). I'd suggest to start with the object called "normal". Cheers, Marcus -- Marcus C. Gottwald ·· @mcg:cheers.de
Re: Preferred way to get imap emails
Pankaj Jangid wrote (Sat 2019-Jul-27 20:58:20 +0530): > My 2nd question is - is there a way to pre-fetch all the emails in inbox. Fetch them as soon as new mail becomes visible or once after entering a folder? Maybe the latter can get achieved using a folder-hook (or a manually executed key press) triggering the execution of a macro along the lines of: ~N ~z <10K ~b whatever all The idea is that Mutt will need to look at the email bodies (~b) and will have to fetch them in order to be able to look at them. Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: Is there a way to record b[ounced] messages in sentmail?
Chris Green wrote (Wed 2018-Sep-19 17:31:44 +0100): > > > It would be nice if the b[ounced] message was recorded in my sentmail, > > > > Do you immediately need a copy of the bounced message in a specific > > or local mailbox? If not, adding your own email address to the list > > of recipients of the bounced message might work. > > > It won't get to my sentmail box then though will it, just appears in > my inbox ... That is true. An easy way (no Sieve, no procmail) to get your copy of the bounced email delivered into some other mailbox on the mailserver could be to use a special destination email address. > ... and doesn't really show that a message has been sent to the > other (intended) recipient. There should be a few extra headers in the bounced email, such as Resent-From (filled with $from) and Resent-To, so Mutt should be able to reliably identify these emails. You could get them highlighted in the index via "color index", use a save-hook for easy filing, etc. Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: Is there a way to record b[ounced] messages in sentmail?
Chris Green wrote (Wed 2018-Sep-19 15:41:01 +0100): > It would be nice if the b[ounced] message was recorded in my sentmail, Do you immediately need a copy of the bounced message in a specific or local mailbox? If not, adding your own email address to the list of recipients of the bounced message might work. Pre-filling the list of recipients with your own email address (plus a trailing comma) could be automated using a macro doing the typing for you, I guess. Or, if your Mutt is invoking a custom $sendmail program, you might be able to pass an extra parameter; and the temporary change to $sendmail around calling the function could be performed using a macro. Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: Clear subject field
Pétùr wrote (Mon 2017-Nov-20 12:19:10 +0100): > Is there a way to quickly clear the subject of an email? Pressing Ctrl+U while editing the field should do what you are looking for. Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: Open mutt with only messages from one person
Xu Wang wrote (Sat 2017-Jun-24 13:12:03 -0400): > mutt -e 'push "l~f'"Jian"'\n"' Note that this might not do what was expected, if your intention was to make sure that Mutt would see the double quotation marks around »Jian« (so »Jian« can contain spaces?). Your shell will see the opening single quote character ' and read exactly until the next such character, so it will see these five parts (of which some are separated by spaces and some are not): mutt -e 'push "l~f' "Jian" '\n"' The double quotation marks around part 4 »Jian« will get dropped just like the single quotation marks around parts 3 and 5 -- you might as well get rid of them: $ echo 'push "l~f'"Jian"'\n"' push "l~fJian\n" $ echo 'push "l~f'Jian'\n"' push "l~fJian\n" So in case of whitespace, Mutt should complain about the second part not being a pattern: $ echo 'push "l~f'"Ji an"'\n"' push "l~fJi an\n" A solution could be to drop the single quotation marks inside single quotation marks (so the shell will see one part instead of parts 3, 4, and 5) plus escaping the inner double quotation marks so that Mutt will read them as normal characters within the push command: $ echo 'push "l~f\"Ji an\"\n"' push "l~f\"Ji an\"\n" Mutt will also accept single quotation marks in the pattern, so if you create a shell command that will result in the following string (using single quotation marks instead of escaped double quotation marks), that should also work: push "l~f'Ji an'\n" Achieving that in a Bash is certainly possible, though not readable for normal humans: $ echo 'push "l~f'"'"'Ji an'"'"'\n"' In any case, this will break again if you intend to use a variable (instead of the fixed string »Jian«) whose value might not only contain spaces but also quotation marks, which could confuse Mutt while parsing the line; so using a generic approach might be best. Maybe using Bash's builtin "printf" with its "%q" might help, but I am not sure how Mutt reacts to backslash-escaped single quotes. I would suggest asserting that the value neither contains quotation marks nor spaces. :-) Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: Open mutt with only messages from one person
Xu Wang wrote (Sat 2017-Jun-24 13:12:03 -0400): > It almost work. But for a splitted second, the screen shows all emails > (because it takes time to process filter request). I know this sound > weird to all, but even in this splitted second I see all emails and I > get nervous with everything I must accomplish, and I cannot focus. > > Is there a way to ask mutt to wait until filter complete before show > the results, so mutt never shows all emails? How about a different approach: Set all colors to "black on black" using a config file, start Mutt the way you are already doing it, and then apply normal color settings (e.g. by sourcing a different config file)? I tried the following for a quick test, but it looks as if a redraw happens (using the default colors) before the has been fully applied; so this won't be good enough unless someone can add a hint on how to postpone the redrawing: mutt -e 'color index black black .' \ -e 'push "l~f'"Jian"'\n"' \ -e 'color index default default .' Also, setting the index colors to "black on black" via "-e" will be applied too late, so that will have to go into a config file. Keeping invisible all emails not from Jian might be a solution? If you don't need a command short enough to type (but sticking it into a shell script or similar is fine), this approach might work: mutt -F muttrc_index-black-on-black \ -e 'color index default default "~f Jian"' \ -e 'push "l~f'"Jian"'\n"' I did notice, however, that the indicator in the index will still highlight (= show) a single line for a short while if there is no match for your pattern. Not sure if this is acceptable -- if not, initially setting the indicator's colors to "black on black" might be required, too -- but setting them back to the default coloring must only happen after the has been applied... Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: strip of some filename chars in folder_format setting
Cameron Simpson wrote (Tue 2017-Apr-18 08:51:01 +1000): > ... and I stick the X-Label value on the right of the listing. Thank you for having mentioned this. I have been adding X-Label headers for years (via procmail, for many but not all incoming emails), mostly using them for "~y" in manually typed index limits and for a few save-hooks, but I never thought of getting them displayed in the index. My index_format has now been extended by "%* %?y? %y?": If there is an X-Label, it will be shown right-justified (prepended with two spaces for visual separation), and if there is no X-Label, the index row will look just like before. Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: best practices answering multiple mails (at once?)
Simon Ruderich wrote (Tue 2016-Nov-08 02:08:55 +0100): > To answer multiple mails at once tag them (t for a single mail) > and then use ;r to reply to all of them (this will quote all of > them in $EDITOR). That's what I've been doing for many years, too, and it seems to work fine, apart from one small issue: postponing and later recalling the email will lead to Mutt not marking the replied-to messages with the "r" flag. > However in the thread view the resulting mail will only appear as > reply to one of those mails (not sure if this is a limitation of > mutt or the in-reply-to header)... AFAIU, placing multiple entries (message ids) in the In-Reply-To header is perfectly valid; the difficult part is left for the user interface: Mutt has a one-dimensional index view using "threading by grouping and sorting within the group", and this will not easily allow showing a tree-like structure containing nodes that have more than one parent. It might be possible to create a well usable two-dimensional index view in a MUA in a (2D-)graphical environment when a "multi-parent" thread can be shown as a planar graph; but one can easily think of relations between emails that will not result in an easy-to-read drawing even in a graphical environment... Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: mutt deletes temporary HTML file before I can view it
Xu Wang wrote (Wed 2016-Jun-22 21:49:12 -0400): > ... Many solutions > involve preserving the .html file. But is it possible for .html file > to include images that were included in the email file? ... Somewhere within such a solution, you would need a piece of code parsing the email and probably store its MIME-parts as files (possibly using "munpack"? "mu extract"? Python "email.parser"? Perl "MIME::Tools"?). You will need to identify the HTML part(s) and possibly glue several of them together. You might need to modify references in the HTML code, then start the webbrowser, and clean it all up later, I guess. FWIW, here's my approach: Use a macro to copy the whole email into a file and fire up Icedove (= Thunderbird), which does a good job at displaying HTML email. macro index,pager I '\ set my_confirmcreate=$confirmcreate\ set confirmcreate=no\ rm -f ~/email-from-mutt.eml\ ~/email-from-mutt.eml\ icedove --no-remote ~/email-from-mutt.eml\ set confirmcreate=$my_confirmcreate\ ' 'invoke Icedove' You would probably want to modify the macro to start Icedove in the background. It might then be necessary to work around the race condition regarding the filename recycling. The solution might not suit you at all because it doesn't actually invoke a web browser of your choice; but maybe it does provide some inspiration. Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: quickly switching to an alternate for "from"
Xu Wang wrote (Fri 2015-May-22 08:59:01 -0400): > I understand that I can do "ESC + f" and then enter it manually. But > how can I switch quickly ... After having typed f, you can use Ctrl+u to delete the current value, and you can choose the new value from your aliases. The alias selection supports tab completion. I am using a few aliases starting with "_me_" (and no other aliases starting with "_") for exactly the purpose of being able to quickly select a new value for "From:" (and sometimes "Cc:" or "Reply-to:" or something else). > ... and limit the choice to just those email > addresses that I have set as alternates? alternates is a pattern, so which input would you like to get checked against that pattern? Cheers, Marcus -- Marcus C. Gottwald ·· https://cheers.de
Re: Mutt accepting expired, locally stored certificate as CA certificate?
Hello Mick, you wrote (Sun 2013-Dec-22 09:05:25 +): > On Saturday 21 Dec 2013 20:50:39 Marcus C. Gottwald wrote: .. > > The server admin generated a new self-signed certificate and installed > > it, and what surprised me was that Mutt immediately accepted the > > new certificate without prompting me. (I had expected to be asked > > "(r)eject, accept (o)nce, (a)ccept always", verify the fingerprint, > > then choose "a".) It took me a while to figure out that this behaviour > > probably was to be expected, because the new certificate was issued > > by the same issuer as the old certificate (same name, same key), and > > Mutt trusts the old certificate (in local storage) for use as a CA > > certificate. > > As I understand it, this is only a partially correct assumption. Mutt will > trust any certificates you have accepted by pressing (a)... Yes, unless such certificate has expired, as far as I have observed. (Since when that happened, Mutt started prompting me.) > ... If you had > accepted the old CA then any new certificates signed by it would be > automatically accepted too. > > A self-signed certificate is de facto a CA of itself. If it is used to sign > another certificate then it becomes a CA of the other certificate too. That appears to be the first half of the crux of the matter: Trusting a self-signed certificate C has the effect of trusting every certificate signed by certificate C. (The other half is that expired certificates are still trusted as signing certificates.) > For your scenario to be true the ISP would have to have used the old > certificate which you had accepted already, as the CA for the new > certificate. > It is unlikely that he would have done this, if the old certificate had > expired or was about to expire... My guess is that he simply repeated the last step performed during the creation of the previous self-signed certificate. I know that he had been given the typical explanation of »1. create a key; 2. create a CSR; 3. send the CSR to a CA trusted by your users and have it issue a certificate« and »instead of steps 2 and 3, "openssl req -x509" will generate a self-signed certificate (based on the key provided as "-key")«. I verified that on a personal mail server: A newly generated self- signed certificate created using "openssl req -x509 -key oldkey.pem -out newcert.pem -days 123 -new" was immediately accepted by Mutt which had a copy of an old certificate generated exactly the same way (= same "oldkey.pem" file, same value for subject/issuer) in its "mutt_certificates" file. (The admin's approach may not have been very clever on the crypto side, but (a) I can't change that but would like to be as cautious as possible and (b) the problem of Mutt trusting an expired (self- signed) certificate as signing certificate (for a certificate based on the same key) remains.) > ... A quick check using openssl or gnutls will > verify which certificate has been signed with what, before we drown in > erroneous assumptions. Looking at a textual representation of the two certificates' field values (using "openssl x509 -text"), I see differences in "Serial Number", "Validity", "serial" field of "X509v3 Authority Key Identifier", and the signature field. All other fields contain the same values, notably "Issuer", "Subject", subject public key, and "keyid" of "X509v3 Authority Key Identifier". We know that both certificates are self-signed, so the identity of subject and issuer must be machine-recognizable. Since the subject of the old certificate is purposely trusted as the issuer of the new certificate, I guess the behaviour is to be expected (ignoring the fact that the old certificate has expired). > the drive is stolen and the private key is kept in the same drive, the key > could be used with the unexpired CA certificate to sign other certificates > under the following scenarios: > > 1. The private key had not been encrypted. > 2. The passphrase is cracked by brute force, or is known because the sysadmin > left it unencrypted in the same drive - e.g. under "My Secrete passwords.txt" Let's assume that the server machine is supposed to be able to reboot on its own, and whatever secret is required is somehow available without manual interaction. The more interesting part actually is to assume that the admin or one of his helpers turns evil, I think. And even if they don't and always take great care, sh*t happens and a key (which was only ever used for a certificate that expired long ago, so there should be no need to make a big fuzz) may become available to someone who shouldn't have it. > ... If it only uses the loc
Mutt accepting expired, locally stored certificate as CA certificate?
Good morning! I am using Mutt (1.5.21 from Debian wheezy package 1.5.21-6.2+deb7u1) to access an IMAP server using an "imaps"-URL. That particular server is presenting a self-signed SSL certificate of which a copy is stored in "~/.mutt_certificates". A while ago, the certificate expired and Mutt started prompting me for "(r)eject, accept (o)nce" -- so far, so good. The server admin generated a new self-signed certificate and installed it, and what surprised me was that Mutt immediately accepted the new certificate without prompting me. (I had expected to be asked "(r)eject, accept (o)nce, (a)ccept always", verify the fingerprint, then choose "a".) It took me a while to figure out that this behaviour probably was to be expected, because the new certificate was issued by the same issuer as the old certificate (same name, same key), and Mutt trusts the old certificate (in local storage) for use as a CA certificate. However, I am now wondering whether the observed behaviour really is intended. Let's assume that the server admin does generate a new key for each new self-signed certificate and the old key is not supposed to be ever used again. What happens if the old key gets stolen or lost a few years later (think: hard drive with backup ends up on eBay)? Anybody could generate a new self-signed certificate and become a man-in-the-middle without me ever noticing. Should I regularly remove all expired certificates from "~/.mutt_certificates"? Should Mutt ignore all such certificates (or prompt for acceptance each time such a certificate becomes part of a verification chain)? Assuming my understanding of the "accept locally stored certificates as CA certificate"-feature is correct, a related question: Can I ask Mutt to never accept a locally stored certificate as a signing certificate? (I don't trust that server admin, but he could use the self-signed certificate (which I have to trust) to issue a certificate for some other subject, and Mutt would trust it, correct?) If I can't, would my best choice currently be to only add certificates issued by really trustworthy people to "~/.mutt_certificates", and to manually verify the fingerprint on each other connection? (Hm, using a specific "mutt_certificates" file per server would also help, I guess.) Thanks in advance, Marcus -- Marcus C. Gottwald ·· https://cheers.de
