Re: urlscan called the wrong browser
On Tue, Jun 29, 2010 at 02:36:00PM -0700, Robert Holtzman wrote: > Not sure if this is the appropriate list for this but I couldn't find a > urlscan list. > > I'm running Ubuntu 8.04 with their version of Mutt 1.5.17, urlscan > 0.5.6, and Firefox 3.6.6 just upgraded from 3.0.x. Prior to the upgrade > ctl-b called firefox. After the upgrade it called a text based browser > that I thought was Lynx except that Lynx isn't installed on my system. Maybe it's elinks. > The urlscan README says to set the environment variable > > export BROWSER=/usr/bin/x > > Which makes sense and works but leaves the question: why is it > neccessary all of a sudden? It wasn't when I ran FF 3.0.x. I'm not sure how it's handled by Ubuntu (I only know Debian), but it looks like urlscan calls sensible-browser, which calls the "correct" browser. You should be able to change it with update-alternatives --config x-www-browser Another possibility could be, that $DISPLAY is not set, thus sensible-browser thinks it can't launch a X based browser (I'm not entirely sure, I'm no expert regarding sensible-browser). Hope this helps, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 pgp2nHtbcqOxI.pgp Description: PGP signature
Mutt v GPG: 'public key already present' and other questions
Dear colleagues, I would be grateful if someone could confirm if I've done everything right: a). I'm using Mutt 1.5.18 on Mac OS X 10.5.8 with gpg (GnuPG) 1.4.9 b). Here is a fragment from my .muttrc: --- set pgp_decode_command="/opt/local/bin/gpg %?p?--passphrase-fd 0? --no-verbose --quiet --batch --output - %f" set pgp_verify_command="/opt/local/bin/gpg --no-verbose --quiet --batch --output - --verify %s %f" set pgp_decrypt_command="/opt/local/bin/gpg --passphrase-fd 0 --no-verbose --quiet --batch --output - %f" set pgp_sign_command="/opt/local/bin/gpg--no-verbose --batch --quiet --output - --passphrase-fd 0 --armor --detach-sign --textmode %?a?-u %a? %f" set pgp_clearsign_command="/opt/local/bin/gpg --no-verbose --batch --quiet --output - --passphrase-fd 0 --armor --textmode --clearsign %?a?-u %a? %f" set pgp_encrypt_only_command="pgpewrap /opt/local/bin/gpg--batch --quiet --no-verbose --output - --encrypt --textmode --armor --always-trust -- -r %r -- %f" set pgp_encrypt_sign_command="pgpewrap /opt/local/bin/gpg --passphrase-fd 0 --batch --quiet --no-verbose --textmode --output - --encrypt --sign %?a?-u %a? --armor --always-trust -- -r %r -- %f" set pgp_import_command="/opt/local/bin/gpg --no-verbose --import -v %f" set pgp_export_command="/opt/local/bin/gpg --no-verbose --export --armor %r" set pgp_verify_key_command="/opt/local/bin/gpg --verbose --batch --fingerprint --check-sigs %r" set pgp_list_pubring_command="/opt/local/bin/gpg --no-verbose --batch --quiet --with-colons --list-keys %r" set pgp_list_secring_command="/opt/local/bin/gpg --no-verbose --batch --quiet --with-colons --list-secret-keys %r" set pgp_autosign = yes set pgp_autoencrypt = yes set pgp_sign_as=0xEC0E4D22# This is my the only one public key, which is paired with my the only one private key set pgp_show_unusable = no <...> my_hdr Cc: # I email a copy of every letter to my other address --- c). Now, I compose an email To: s...@address (and Cc: my-ot...@address is automatically added). I see in the letter's window that 'PGP' is set to 'Sign, Encrypt (PGP/MIME)' and 'sign as' is set to '0xEC0E4D22' -- so, everything looks nice, exactly according to the .muttrc. d). Then I press 'y', and Mutt asks me to 'Enter keyID for s...@address: '. And here goes question No. 1: Why? I have the only one key, which is listed in .muttrc, so, shouldn't Mutt just take it automatically? e). However, I press Enter, Mutt shows me my pubic key, I do select it by pressing Enter again (and, actually, I have no other choice), and then the history repeats, and Mutt asks me for the key for 'my-ot...@address' (which is listed in Cc:). 6. So, I do press Enter-Enter once again, Mutt asks me for PGP passphrase, I enter it, and then gpg says 'gpg: 0xEC0E4D22: skipped: public key already present', and that is my question No. 2: what does this phrase mean, why does it appear, and how can I avoid it? 7. After it my email flies encrypted to both addresses, so, there seems to be no error, but just to many additional keypresses :). And I would be very grateful if you could help me avoid [some of] them :). Sincerely yours, -- dsjkvf
Re: Mutt v GPG: 'public key already present' and other questions
Sorry :) As I see, I was quite stupid, unfortunately. My email should be encrypted not with my public key, of course, but with public keys received from addressees. That's why I was suggested to select keys (question No. 1) , and that's why I gpg has told me that the key was already present (there should be two different public keys) (question No. 2). Am I right? If so -- then, please, forgive me for disturbing you :). Sincerely yours, -- dsjkvf On Sun, Jul 4, 2010 at 13:15, dsjkvf wrote: > Dear colleagues, > > > I would be grateful if someone could confirm if I've done everything right: > > a). I'm using Mutt 1.5.18 on Mac OS X 10.5.8 with gpg (GnuPG) 1.4.9 > b). Here is a fragment from my .muttrc: > --- > set pgp_decode_command="/opt/local/bin/gpg %?p?--passphrase-fd 0? > --no-verbose --quiet --batch --output - %f" > set pgp_verify_command="/opt/local/bin/gpg --no-verbose --quiet > --batch --output - --verify %s %f" > set pgp_decrypt_command="/opt/local/bin/gpg --passphrase-fd 0 > --no-verbose --quiet --batch --output - %f" > set pgp_sign_command="/opt/local/bin/gpg --no-verbose --batch > --quiet --output - --passphrase-fd 0 --armor --detach-sign > --textmode %?a?-u %a? %f" > set pgp_clearsign_command="/opt/local/bin/gpg --no-verbose --batch > --quiet --output - --passphrase-fd 0 --armor --textmode --clearsign > %?a?-u %a? %f" > set pgp_encrypt_only_command="pgpewrap /opt/local/bin/gpg --batch > --quiet --no-verbose --output - --encrypt --textmode --armor > --always-trust -- -r %r -- %f" > set pgp_encrypt_sign_command="pgpewrap /opt/local/bin/gpg > --passphrase-fd 0 --batch --quiet --no-verbose --textmode --output > - --encrypt --sign %?a?-u %a? --armor --always-trust -- -r %r -- %f" > set pgp_import_command="/opt/local/bin/gpg --no-verbose --import -v %f" > set pgp_export_command="/opt/local/bin/gpg --no-verbose --export --armor %r" > set pgp_verify_key_command="/opt/local/bin/gpg --verbose --batch > --fingerprint --check-sigs %r" > set pgp_list_pubring_command="/opt/local/bin/gpg --no-verbose > --batch --quiet --with-colons --list-keys %r" > set pgp_list_secring_command="/opt/local/bin/gpg --no-verbose > --batch --quiet --with-colons --list-secret-keys %r" > set pgp_autosign = yes > set pgp_autoencrypt = yes > set pgp_sign_as=0xEC0E4D22 # This is my the only one public key, > which is paired with my the only one private key > set pgp_show_unusable = no > <...> > my_hdr Cc: # I email a copy of every letter to my > other address > --- > c). Now, I compose an email To: s...@address (and Cc: my-ot...@address > is automatically added). I see in the letter's window that 'PGP' is > set to 'Sign, Encrypt (PGP/MIME)' and 'sign as' is set to '0xEC0E4D22' > -- so, everything looks nice, exactly according to the .muttrc. > d). Then I press 'y', and Mutt asks me to 'Enter keyID for > s...@address: '. And here goes question No. 1: Why? I have the only > one key, which is listed in .muttrc, so, shouldn't Mutt just take it > automatically? > e). However, I press Enter, Mutt shows me my pubic key, I do select it > by pressing Enter again (and, actually, I have no other choice), and > then the history repeats, and Mutt asks me for the key for > 'my-ot...@address' (which is listed in Cc:). > 6. So, I do press Enter-Enter once again, Mutt asks me for PGP > passphrase, I enter it, and then gpg says 'gpg: 0xEC0E4D22: skipped: > public key already present', and that is my question No. 2: what does > this phrase mean, why does it appear, and how can I avoid it? > 7. After it my email flies encrypted to both addresses, so, there > seems to be no error, but just to many additional keypresses :). And I > would be very grateful if you could help me avoid [some of] them :). > > > Sincerely yours, > > > -- > dsjkvf >
Re: return reciepts
On Sat, Jul 03, 2010 at 03:12:49PM +0200, lee wrote: > [snip] > > Let me add that you just got me to the idea that a simple yes/no for a > combination of recipients won't suffice: It would have to be > always/once/no/never, meaning that for the combination of recipients > in question, the requesting of reciepts would either always be enabled > or for that particular message only or no reciept for the particular > message will be requested or reciepts are never requested. > > No doubt that the kind of support for reciepts I have in mind could be > used otherwise, but how someone makes use of a feature is always up to > them. The simplest thing (as others have already mentioned) is still using $edit_headers and implement that in your editor. Either directly or in a wrapper script (which could even be in C, but I would use something faster to develop, like Shell, Perl, Python, ..) used in $editor. It would check the mail after you exit the editor, and then ask you - based on a configuration file - if you want to add a request, and if yes add the necessary header. > [snip] > >> Wasted effort compared to an editor macro to add some line like >> "please acknowledge receipt and respond ASAP". > > What makes you think that the recipient would bother to write an > answer? It would involve even more overhead for them to manually write > and send a response than it is to use a feature of their MUA that > reduces the overhead to just pressing a single key --- or doesn't > involve any overhead at all for them because they have chosen to > always automatically send reciepts when requested. But if the recipient doesn't care about your mail, then how does adding a receipt request help? >> Practice has shown that it is not best practice. > > Because of poor support, maybe :) Or because it's a bad idea. Regarding the support of requests in mutt, adding it can (or should be; I haven't tried it and probably never will, I don't like them) easily be done with $display_filter. Just add a wrapper script which checks the mail for the header and if it contains one, displays a message in the mail. Then use a macro which pipes the mail to another script which sends the answer to the recipient. Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 pgpIkxIKkBahQ.pgp Description: PGP signature
Re: return reciepts
On Sun, Jul 04, 2010 at 12:33:22PM +0200, Simon Ruderich wrote: >On Sat, Jul 03, 2010 at 03:12:49PM +0200, lee wrote: > >But if the recipient doesn't care about your mail, then how does >adding a receipt request help? > >>> Practice has shown that it is not best practice. >> >> Because of poor support, maybe :) > >Or because it's a bad idea. > >Regarding the support of requests in mutt, adding it can (or >should be; I haven't tried it and probably never will, I don't >like them) On the flip, return receipts might be a good thing for keeping track of the wife or kids? We should stop thinking about what we dislike or like, and start thinking of others for a change. -- Roger http://rogerx.freeshell.org/
Re: return reciepts
On Sun, Jul 04, 2010 at 12:33:22PM +0200, Simon Ruderich wrote: > > Either > directly or in a wrapper script (which could even be in C, but I > would use something faster to develop, like Shell, Perl, Python, > ..) used in $editor. It would check the mail after you exit the > editor, and then ask you - based on a configuration file - if you > want to add a request, and if yes add the necessary header. Yes, other programming languages than C would be better suited for this, but I'd have to learn them first. > But if the recipient doesn't care about your mail, then how does > adding a receipt request help? In this case, I started to request them because they don't answer --- and guess what, I got a reciept. That way they can't claim they didn't get my mail. It's extremely useful. Besides, do you seriously trust in that every admin involved has set up their mailservers correctly? Do you seriously trust in that email never gets lost? Do you seriously trust in that you will always get an error message sent back to you in case something goes wrong? I've seen servers at ISPs set up so that they don't even accept error messages sent to them ... In this case, the alternative would be to print the message on paper to deliver it in person and have them certify that they recieved it. I like return reciepts better for now. > >> Practice has shown that it is not best practice. > > > > Because of poor support, maybe :) > > Or because it's a bad idea. It's still way better than the alternative. > like them) easily be done with $display_filter. Ah, that's cool :) Now I have the pieces I'd need to interface with mutt, thanks.
Re: return reciepts
On Sat, Jul 03, 2010 at 09:51:03AM -0400, Patrick Shanahan wrote: > * lee [07-03-10 09:13]: > > On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: > > > > > Practice has shown that it is not best practice. > > > > Because of poor support, maybe :) > > Or, more likely, requests for features that most do *not* want presented > in a haughty manner What's haughty about this? > which would require coding and where work-a-rounds > have been presented. Just look at the replies, ppl told me at first that a feature I have use for is useless, troublesome and pointless and that they don't want it because they don't like it. How haughty is that? And keep in mind that nobody would be forced to use this feature if they don't like it. Just look at your own comment and how haughty that is: Apparently the idea that implementing a feature would require some work is horrible to you, so you're telling me that everyone who has use for it should "implement" the feature by doing the necessary steps for each message manually. "Do it manually" was the only workaround presented, but that's silly considering that I already said in my OP that I can do it manually but am wondering if there's a better solution available. Besides, it has probably escaped you that there's a difference between "solution" and "workaround". Isn't it amazing that ppl can't say something like "hey I don't have use for this feature and I don't like it and I don't know of any implementation, but it would sure be great if you were to come up with a solution everyone could use"? You know, I've already been asking myself if I should make such a solution available for everyone who wants it if I ever implement it after seeing the rude comments I got here. Don't be surprised when at some time, you'll find yourself out of free software because you finally managed to piss off everyone who was willing to provide some.
Mailbox closed
Mutt seems to be unable to keep an IMAP connection open for long. I use several versions of mutt on several different computers, with several different IMAP accounts. In all cases, I frequently come back to an instance of mutt to find it saying "Mailbox closed". My muttrc has `set imap_keepalive=450`. Maybe I should reduce the keepalive time even further? But 450 is already twice as often as the IMAP standard requires.
Re: Mailbox closed
Вск, 04 Июл 2010, chombee писал(а): > Mutt seems to be unable to keep an IMAP connection open for long. I > use several versions of mutt on several different computers, with > several different IMAP accounts. In all cases, I frequently come back to > an instance of mutt to find it saying "Mailbox closed". > > My muttrc has `set imap_keepalive=450`. Maybe I should reduce the > keepalive time even further? But 450 is already twice as often as the > IMAP standard requires. This may help: set imap_idle=yes -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Re: urlscan called the wrong browser
On Sun, Jul 04, 2010 at 12:11:08PM +0200, Simon Ruderich wrote: snip > I'm not sure how it's handled by Ubuntu (I only know Debian), but > it looks like urlscan calls sensible-browser, which calls the > "correct" browser. You should be able to change it with > > update-alternatives --config x-www-browser > > Another possibility could be, that $DISPLAY is not set, thus > sensible-browser thinks it can't launch a X based browser (I'm > not entirely sure, I'm no expert regarding sensible-browser). All this is well and good but my question was why is setting the browser environment variable necessary with FF 3.6.6 when it wasn't with 3.0.x? I'm beginning to think it's a FF problem. The devs may have broken a compatibility with urlscan. > > Hope this helps, > Simon > -- > + privacy is necessary > + using gnupg http://gnupg.org > + public key id: 0x92FEFDB7E44C32F9 -- Bob Holtzman Key ID: 8D549279 "If you think you're getting free lunch, check the price of the beer"
Re: Mailbox closed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sunday, July 4 at 01:36 PM, quoth chombee: > My muttrc has `set imap_keepalive=450`. Maybe I should reduce the > keepalive time even further? But 450 is already twice as often as > the IMAP standard requires. For what it's worth, many IMAP servers ignore the IMAP standard for things like timeouts. Though the IMAP standard(s) say(s) that autologout timers MUST be at least 30 minutes, it's not uncommon to find IMAP servers that will disconnect if you're idle for more than 5 minutes. Unless you have the power or influence to get the server operators to behave according to the standard, you've gotta configure your IMAP client to deal with it. I will say that mutt is a bit unusual in that it makes it explicit when the connection dies. Most (if not all) GUI IMAP clients hide re-establishing connections so that most people never notice that their connections died. As a final piece of advice, I'd suggest that you read up on the interaction between all the various mutt timeouts (particularly $timeout and $mail_check), and consider that $imap_timeout is similar to $mail_check in how it interacts with $timeout. The way this works is somewhat counter-intuitive. http://wiki.mutt.org/?MuttFaq/Folder ~Kyle - -- The means of defense against foreign danger historically have become the instruments of tyranny at home. -- James Madison -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJMMPElAAoJECuveozR/AWe8ggQAIvqO7xseL9DDhqScdrcD2Bm wv2+k06VXQu2iDuNVzGiQTPNPtyUne4JDvG0ip/nIq//Q20u1EODMrNQy5CzMG+7 GlRGG9RV2JRjQvFLccJ85PeDrv44Y8OoGYUjgnoCKQepHi639P70tXYO32QyyzQ3 EoSEv9MW5SZS/slOeJX2rbu9323Z2Nbg4MoYTbYTc1gMR/wDv8cMSCM/Sj7Lqr4v lRRTF9z0KrdsFpF49mJ4ZnHDctvMLiJvOIkHGTNv7WmQAMEFYAZ1ykfbbNAGb3Ua lv7YgbnPRSr7yBBCOH3PxIqFadgmdsQaDbGWdwnlkBjC63FEmuOl9EPU2Q74UPAi 1FTUZr4YkgIsTD3QsLxULVeXpDZjfmZcu/EflVKzXG3NfYFhl7HvsyYMMqzTA0Ji bX7PtibDg6a1IITFnh9iqb/UNKmy/7CW5M39DaOR41WDBTRsm62A4bTE/fyDKnUy tbMGUmZ4o9uXfqDFoNBnVK6ZxWtkQN3DJmJf/pBKNFhCNFnlAkhfzYLJtXhZGO2H GH6hPXzTc/dVaR7t/87dHUVSn5fFhxw/TII4EZfZtY4dtl4SXaICJDD5Hf3EA8Jc Nywz66Hzi6lZF9dh9uIQuopJj/UxkmrjUdXbsdER96PrBdZ/2PkOW2XS9zf619Xg Qi0WP2zIKxc56unD+wQv =covi -END PGP SIGNATURE-
Re: return reciepts
=- lee wrote on Sat 3.Jul'10 at 15:12:49 +0200 -= > > Wasted effort compared to an editor macro to add some line like > > "please acknowledge receipt and respond ASAP". > > What makes you think that the recipient would bother to write an > answer? What's so much harder for the recipient to hit 'r' rather than any other key you assign to your r-r? > It would involve even more overhead for them to manually write > and send a response than it is to use a feature of their MUA that > reduces the overhead to just pressing a single key You can have that already, as advice given. > --- or doesn't involve any overhead at all for them because they > have chosen to always automatically send reciepts when requested. Interception via $editor or $sendmail takes care of this. > > Practice has shown that it is not best practice. > > Because of poor support, maybe :) No. Even worse: good support for bad habits establishes bad habits, see ToFu posting/replies. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
A need for a "new-hook"?
Hi guys, I've got Mutt configured to use two Maildir accounts, synced using offlineimap. This is done using folder hooks. Part of this setup is as follows: # --- Begin set mbox_type = Maildir set folder = ~/.maildb set spoolfile = +/SitePoint/INBOX folder-hook +SitePoint.* set from = "adam.bo...@sitepoint.com" folder-hook +SitePoint.* my_hdr From: Adam Bolte set smtp_url= "smtp://smtp.server/ folder-hook +GMail.* set from = "otherm...@gmail.com" folder-hook +GMail.* my_hdr From: Adam Bolte folder-hook +GMail.* set smtp_url = "smtp://othersmtp.server/" # --- End I use more folder-hooks and options than shown above, but you get the idea. Now my problem: I want my SitePoint signature to be automatically inserted into my editor whenever I send mail or reply to a message in my SitePoint folder, but not when sending from the other personal account. I also don't want to have the signature inserted if replying to an e-mail thread that already has my signature. It saves me manually deleting it. To accomplish this, I've tried the following: # --- Begin # Signatures are set by default for new messages folder-hook +SitePoint.* "set signature = "~/.mutt/signature-SitePoint"" folder-hook +SitePoint.* "reply-hook \"! ~b '^[[:space:]\>]*Adam Bolte$'\" set signature = \"~/.mutt/signature-SitePoint\"" # But we don't use them if it appears it's been posted before. folder-hook +SitePoint.* "reply-hook \"~b '^[[:space:]\>]*Adam Bolte$'\" unset signature" folder-hook +GMail.* "unset signature" # --- End I'm making the assumption that if my full name appears on any line by itself in part of the thread, my signature has been previously included. This search works as expected over 99% of the time. The real problem with the above comes from the following usage scenario: 1. Reply to a mail that has already had my e-mail signature used, thus having my signature unset. 2. Writing a new mail in the same folder. Since I did not change folders, the folder-hook doesn't run and the signature remains unset. Ideally, I would be able to set a hook when creating a new mail from scratch - something like "new-hook". I've tried investigating send-hook, but it only runs after folder-hook, not before (thus clobbering folder-hook). Further, I still need folder-hook for when replying to messages since ~b doesn't exist in send-hook (presumably because if sending a new message, no message body would already exist). I don't see a way to make this work. Does anyone have any idea how I can trigger a hook *only* when writing a new message? Maybe there's a patch floating around that I should know about? Thanks, Adam -- Adam Bolte SitePoint Pty. Ltd. www.sitepoint.com
