Re: Command/Macro to show new messages via IMAP?
On (19:37 03/02/13), s. keeling put forth the proposition: Incoming from David Woodfall: On (18:41 03/02/13), s. keeling put forth the proposition: > >Mine works fine with just this: > > mailboxes =Inbox > >... however, I'm also using offlineimap, fwiw. My config doesn't >define "imap-check-subscribed". I'm guessing that Mutt is reading downloaded headers then? (0) infidel /home/keeling_ grep -i header .muttrc set header_cache="~/mutt/cache/headers" set edit_headers fwiw. Why would anyone not want to? Mutt's just a program. I'm the one doing the reading here. :-) What I mean is - your Mutt is not accessing IMAP directly. Offlineimap is downloading the mail and Mutt is reading it locally? I've never tried offlineimap myself so I'm guessing that that's how it works. (The warnings about deleting mail on the server are putting me off using it).
Re: Command/Macro to show new messages via IMAP?
--> David Woodfall [2013-02-04 01:27:32 +]: > I'm still no closer to solving this. It seems that mutt just ignores > folder format for IMAP completely. Hi David, I'm not absolutely clear what your setup is but seems like you may be using a similar setup to mine - reading mail on the server which receives mail and also using imap to remotely read the mail on that server, however, in case you are using a similar set up to me perhaps if I describe it, it might help you. I generally read my mail on the mx host server which also has Dovecot imap setup. When I'm reading mail using mutt on the server, I don't bother using imap to the localhost, the imap server is purely for when I'm reading mail using mutt on another machine. So, I have to setup my mailboxes for mutt on the server in a slightly different way because Dovecot LDA creates my mailboxes with a leading '.' in ~/.maildir. This appears to me to be how your mailboxes are created? I've also set up the imap server to automatically allow/make MUA's subscribe to the mailboxes, so I don't need to put $check_imap_subscribed in my muttrc file. So I've set the $MAIL environment variable to ~/.maildir in my shell's configuration file ( OpenBSD's version of ksh ), then I've set $folder in my muttrc as $MAIL: set folder=$MAIL set mask=. ... ... and my mailboxes are set up like so: mailboxes ! mailboxes =.foo mailboxes =.bar ... Note, this is only when using mutt with direct Maildir++ access on the server When using imap, I use pretty much the normal method for accessing imap folders: set tunnel="ssh -q -C kontrol '/usr/local/libexec/dovecot/imap'" set folder=imaps://kontrol.kode5.net/ set spoolfile=+inbox set header_cache=~/.header_cache ... Obviously, you needn't use the tunnel method. I find it helps, though, when I'm accessing mail from another computer in my LAN as there's not much point in letting mutt find the server through the internet and setting $folder to imaps://hostname or using the internal ip makes mutt complain about the ssl cert which of course has been created using the FQDN. Jamie -- Primary Key: 4096R/1D31DC38 2011-12-03 Key Fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
Re: SSL/TLS - fingerprint and certificate checking
>> I'm looking through the manual and I'm not seeing where I can: >> >> 1) Specify, in the fixed muttrc configuration, a sha1 certificate >> fingerprint that must match on a per host basis before continuing >> with the connection. > > This is not supported directly, but here is what you can do: > > $certificate_file contains the certs that you have accepted permanently via > the SSL/TLS dialog. This would like to be a option for per host $certificate_file so rogue host cannot present any other cert that just happens to be in this bundled file leading to unwanted acceptance. > So if you verify the certificate fingerprint during the > initial connection, that cert will go into your certificate store. This would like to be a option for hardcoded FP in config per host so as not to risk human compare or 'y' typo error in GUI leading to unintended acceptance. Bonus here is that no $certificate_file for host certs is needed, or need be managed, it's just live FP comparison at that point. Backed secondarily with an optional [per host] chain check as below. Good user will set up config offline with openssl tools. > However, this will not prevent the cert chain from validating with a > *different* certificate. So if you need that feature, after you have > accepted the cert as described above, you want to make sure to prevent mutt > from using any other certs: > > unset ssl_ca_certificates_file > unset ssl_usesystemcerts > >> 2) Additionally, and optionally, validate the cert presented by any >> ssl/tls (or starttls upgraded) connection back to the respective >> root ca using a per host cert/bundle file linked to from a muttrc. > > You could do this probably with an account-hook and setting > $ssl_ca_certificates_file and ensuring that $ssl_usesystemcerts is unset. The 'per-host' basis is pretty important because you don't want a file full of host, intermediate, or CA cetificates to end up validating other hosts for which you mean to employ fully compartmented checking. Commonly as resistance to MITM, stolen certs, and CA's which aren't doing what people think they do. And the fingerprint is the critical item today for final and best control over actual security, not CA games. (Along with the needed secure DNS and transport tomorrow). I should say 'per-host' could just as better be 'per-account' as most mail setup is thought of as an on account basis. You might want to review some of the certificate checking and static configuration models in fetchmail, fdm, msmtp, mpop, etc. Particularly in regards to fingerprints, which are the most secure. Then as to storage of certs in separate files, or in bundles for the less concerned and convenience oriented. In the meantime, yes, I will go see further from the hints above how well Mutt can currently handle fingerprint checking and cert storage. The account_hook may help for some of these cases but enhancment would be needed to cover others. There is this for people to use as well... https://github.com/agl/extract-nss-root-certs
Re: Command/Macro to show new messages via IMAP?
On (10:16 04/02/13), James Griffin put forth the proposition: --> David Woodfall [2013-02-04 01:27:32 +]: I'm still no closer to solving this. It seems that mutt just ignores folder format for IMAP completely. Hi David, I'm not absolutely clear what your setup is but seems like you may be using a similar setup to mine - reading mail on the server which receives mail and also using imap to remotely read the mail on that server, however, in case you are using a similar set up to me perhaps if I describe it, it might help you. I'm only reading remotely via imap. I generally read my mail on the mx host server which also has Dovecot imap setup. When I'm reading mail using mutt on the server, I don't bother using imap to the localhost, the imap server is purely for when I'm reading mail using mutt on another machine. So, I have to setup my mailboxes for mutt on the server in a slightly different way because Dovecot LDA creates my mailboxes with a leading '.' in ~/.maildir. This appears to me to be how your mailboxes are created? Right, I'm using dovecot too, with the leading '.' I've also set up the imap server to automatically allow/make MUA's subscribe to the mailboxes, so I don't need to put $check_imap_subscribed in my muttrc file. Not sure how to do that, but it sounds useful. When using imap, I use pretty much the normal method for accessing imap folders: set tunnel="ssh -q -C kontrol '/usr/local/libexec/dovecot/imap'" set folder=imaps://kontrol.kode5.net/ set spoolfile=+inbox set header_cache=~/.header_cache ... I have spoolfile set to same as folder, and no tunnel. Does it show the normal $folder_format attributes? Example: Using plain local mutt: Jun 12 20:21 slackbuilds Using imap: slackbuilds Note: no atime/mtime, no new mail notification.
