Re: fetchmail - google certificate
* Joseph [2010-10-23 22:42 -0600]: It wasn't the certificate problem, I think it was fetchmail was missing some links or options. I re-compile fetchmail, openssl and the problem is solved. All is working, as it should. Problem solved. Congratulations. Breen -- Breen Mullins b...@sdf.org
Re: fetchmail - google certificate
* Joseph [2010-10-23 21:35 -0600]: What is causing the problem is the: sslcertck If I comment it out, it keep complaining about the certificate but connection goes through. So you can either comment out sslcertck and move on (perfectly reasonable, I think) or try to fix this. If you want to try to track it down, you can try stracing the job: strace -e trace=open fetchmail will tell you where fetchmail is looking for your cert. It should give you a clue for a place to park a cert. -- Breen Mullins b...@sdf.org
Re: fetchmail - google certificate
* Patrick Shanahan [2010-10-23 19:37 -0400]: why do you need it, ie: poll imap.gmail.com tracepolls with proto IMAP timeout 45 user '@gmail.com' there with password 'passwd' is '' here options fetchall stripcr ssl mda '/usr/lib/sendmail -i -oem -f %F %T' He's using sslcertck as recommended in many places on the web. Your invocation (which in fact I do too) doesn't check the google cert for validity. Breen -- Breen Mullins b...@sdf.org
Re: fetchmail - google certificate
* Joseph [2010-10-23 12:50 -0600]: I'm using command: openssl s_client -connect pop.gmail.com:995 -showcerts and it printed out: copy--- CONNECTED(0003) depth=1 C = US, O = Google Inc, CN = Google Internet Authority verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=pop.gmail.com i:/C=US/O=Google Inc/CN=Google Internet Authority -BEGIN CERTIFICATE- [...] -END CERTIFICATE- 1 s:/C=US/O=Google Inc/CN=Google Internet Authority i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority -BEGIN CERTIFICATE- [...] -END CERTIFICATE- [...] So I assume the first one is gmail.pem certificate the second was was equifax.pem certificate No. Both of those were sent by the Google server. The first is for the server, and was issued by Google's own signing authority. The second is the Google signing authority certificate, which is issued by Equifax. Note the s: and i: lines for each cert. (It's complicated but allowed by the standards.) If the server were allowed to send a copy of a certificate authority's cert as well as the server one, a bad guy could just forge the whole chain and you'd accept it and never be the wiser. You're supposed to get independent verification of the validity of the certificate chain. That usually means that you get the cert from your OS vendor at install time. Please don't leave the mailing list off replies. Breen -- Breen Mullins b...@sdf.org
Re: maillists
* Alex Huth [2010-06-06 16:25 +0200]: Is it possible to use two different sort variables for maillists? I want to use: set sort=threads set sort=reverse-date But when i use that, mutt sorts only for the last value. Are you looking for sort_aux ? Breen -- Breen Mullins b...@sdf.org
Re: reviving GPG with mutt
On Wed, Dec 23, 2009 at 17:14, Dale A. Raby wrote: >> > should be in your /home/username/.gnupg folder. if you are using a GUI, you > might have to go into "properties" and enable "show hidden files" in order to > see it. Assuming he came from and moved to a unix-like system. If either side of the move was on another OS, the files may not be where they're expected. Scott, I think we'll need some more information about your old and new systems. -- Breen Mullins
Re: Setting mutt on FC7
* Michael Kjorling <[EMAIL PROTECTED]> [2008-04-25 09:02 +]:
On 25 Apr 2008 16:50 +1000, by [EMAIL PROTECTED] (hce):
I am using vim on xterm, and I set up the editor at muttrc:
set editor="vim +':set textwidth=77' +':set wrap' +\`awk '/^$/ {print
i+2; exit} {i++}' %s\` %s"
For one thing, backticks are expanded at config parse time. Without
having tried, this would seem likely to cause problems in your
case.
I think that's right. My .muttrc has
set editor="vim +':set textwidth=72' +':set wrap' +\`awk '/^$/ {print
i+2; exit} {i++}' %s\` %s"
which works for me.
--
Breen Mullins
Menlo Park, California
Re: Recommended mail filters for use with mutt?
On 4/3/08, Christian Ebert <[EMAIL PROTECTED]> wrote: > > Also above rule is for Maildir, not mbox. For mbox, and your > naming scheme, it should be something like: > > :0: > * ^List-Post:.*mailto:\/[^>]+ > Lists/$MATCH/ Don't you need to omit the trailing slash for mbox? -- Breen Mullins Menlo Park, Calif.
Re: Replying to Email / Removing previous signature
* Kyle Wheeler <[EMAIL PROTECTED]> [2008-02-18 14:22 -0600]: Comma repeats the last f/t/F/T operation in the opposite direction. I don't know why you'd start macros with it either. :) Well, that's a good point even if I rarely use the reverse-sense search. Since my suggested mapping map ,ds :.,/^-- $/-1dO only makes sense if I'm editing a mail, I pulled it from my .vimrc and dropped it into ~/.vim/after/syntax/mail.vim . I almost never need to search within the body of a reply I'm editing so this will keep me from stepping on my own toes. Breen -- Breen Mullins Menlo Park, California
Re: Replying to Email / Removing previous signature
* Joseph <[EMAIL PROTECTED]> [2008-02-18 14:33 -0500]: Wow, that is really slick. But not original to me - I snarfed something similar a long time ago... For others who may want to try this, I had to make some changes to get it to work. You changed my definition. I actually do type comma-d-s to trim the message. (All of my macros tend to start with a comma. I forget now why that is...) Glad you found it helpful. -- Breen Mullins Menlo Park, California
Re: Replying to Email / Removing previous signature
* Joseph <[EMAIL PROTECTED]> [2008-02-18 13:08 -0500]: When replying to an email that you sent earlier, how would you go about removing the previous signature? I use vim as my editor - I have a macro defined in vimrc map ,ds :.,/^-- $/-1dO (ds for delete-to-sigdashes). It's not automatic, but it allows me to trim the leftover cruft at the bottom pretty easily. -- Breen Mullins Menlo Park, California
Re: Leopard Migration Hammered Mutt
* Eugene <[EMAIL PROTECTED]> [2008-01-27 21:18 -0600]: So basically add the line ". /sw/bin/init.sh" into your ~/.profile or ~/.bash_profile init files. This should add /sw/bin to your PATH, and set up other Fink-related environment variables as well. All the explanations have been helpful. The only thing I'd add is an explanation that the line . /sw/bin/init.sh is a shortcut telling the shell to execute the script /sw/bin/init.sh (which has to have execute permission). The shell commands in init.sh get executed and change your path. The leading '.' is easy to miss, but it's a common usage in shell scripts. Breen -- Breen Mullins Menlo Park, California
Re: browse mailboxes order
* Christian Ebert <[EMAIL PROTECTED]> [2008-01-17 00:26 +0100]: No. After hitting c, at the prompt, you can use to cycle through mailboxes that have new mail. You learn something every day! Thanks, Christian! -- Breen Mullins Menlo Park, California
Re: Procmail
* Nicolas Rachinsky <[EMAIL PROTECTED]> [2007-10-10 09:28 +0200]: * Breen Mullins <[EMAIL PROTECTED]> [2007-10-09 19:05 -0700]: MAILDIR by itself isn't special in procmail. You usually set it so that you can use it in your delivery recipes: It is special. Quoting procmailrc(5): Indeed, as Kyle pointed out last night. -- Breen Mullins Menlo Park, California
Re: Procmail
* Kyle Wheeler <[EMAIL PROTECTED]> [2007-10-09 21:23 -0500]: On Tuesday, October 9 at 07:05 PM, quoth Breen Mullins: MAILDIR by itself isn't special in procmail. On the contrary, MAILDIR *IS* special. Reread the procmail documentation. Specifically: Right, of course. Thanks. (I knew that, actually. Teach me to reply while the pasta is boiling...) -- Breen Mullins Menlo Park, California
Re: Procmail
* Rem P Roberti <[EMAIL PROTECTED]> [2007-10-09 16:37 -0700]:
My thanks again to both of you. Creating my .procmailrc recipe in the
manner suggested by Joseph did the trick. What I don't understand is
that since the variable MAILDIR=$HOME/Mail exists at the beginning of
.procmailrc why is it necessary to state the full path to the target mailbox in
the recipe?
MAILDIR by itself isn't special in procmail. You usually set it so that
you can use it in your delivery recipes:
# mutt-users
:0:
* ^TO.*mutt-users
${MAILDIR}/mutt
(It's worth looking at the ^TO macro in the procmailrc manpage, btw.
If you're going to be using procmail, that one and procmailex are the
ones to read. Very good stuff there.)
Breen
--
Breen Mullins
Menlo Park, California
Re: mutt manual encoding
On 10/8/07, Joseph <[EMAIL PROTECTED]> wrote: > When I copied mutt manual to my home directory (for printing) and open > it with nano or any other editor like openoffice all I got is a strange > characters: > file /usr/share/doc/mutt-1.5.16/manual.txt > /usr/share/doc/mutt-1.5.16/manual.txt: ASCII English text, with > overstriking The last is the key word. It's like a man page - it uses backspacing (the ctrl-h characters) to make a boldface effect. Pipe it through 'col -b' to remove the problem characters. Breen -- Breen Mullins Menlo Park, Calif.
Re: Mailing list reply
* Kyle Wheeler <[EMAIL PROTECTED]> [2007-10-05 14:10 -0500]: So, have you tried making it this: subscribe '[EMAIL PROTECTED]' That way the only address that is recognized as a list is the one the list specifies in the List-Post header. Unless something else is going on, that should prevent you from replying to [EMAIL PROTECTED] That's what I've decided to do for this one. Of course, you could always *force* the issue, by adding a send2-hook: send2-hook '~C [EMAIL PROTECTED] ~C [EMAIL PROTECTED]' \ 'push [EMAIL PROTECTED]' ;) If the smiley means that you think that solution is overkill, I agree... The question is, what's the best way to work around it in a generic way? I'm assuming the List-Post header was used for cases when a person is too lazy to add that mailing list to their list of mailing lists (e.g. with the subscribe or list commands). I suspect that it's a Mailman default - the box running the list is mail . The list is non-technical and nobody there would know what a subscribe command is. Perhaps a variable could be added to turn that off? Or change the behavior to only use the List-Post header when no other mailing list addresses have been found? That's the kind of thing I was thinking of, but it sounds a bit dicey in practice. If you're doing a list-reply to a message where there's a List-Post header, could you accidentally drop an intended recipient? P.S. I've often thought something like an addr-hook, that forces specific addresses to be treated as something else (akin to a charset-hook, kinda) would be pretty useful, and such a thing would solve the problem here, as long as mutt eliminates duplicate recipients. For example: addr-hook [EMAIL PROTECTED] [EMAIL PROTECTED] Now _that's_ an interesting idea! I tend to get mails addressed to collections of people - a church group, for example - where one recipient has changed her address. (Old directories take a long time to die.) With an addr-hook, I could make the change and a group reply would go to the new address even if the message had only the old address for that person. Breen -- Breen Mullins Menlo Park, California
Re: Mailing list reply
* Kyle Wheeler <[EMAIL PROTECTED]> [2007-10-05 12:44 -0500]: How are you specifying in your muttrc that you're subscribed to that list? If you're doing it like this: subscribe listname@ Then you may be being too general (that subscribe line matches both [EMAIL PROTECTED] and [EMAIL PROTECTED], so if mutt sees both of those available in your message, it will reply to both of them). Try this: subscribe '[EMAIL PROTECTED]' That way only the one address matches, so it'll only be sent to the one that matched. After more digging, I understand a bit more about what's going on. ChangeLog: 2004-07-20 08:17:21 Thomas Roessler <[EMAIL PROTECTED]> (roessler) * imap/message.c, mutt.h, parse.c, send.c, url.c: Use List-Post headers when doing list-reply. And indeed, there's a List-Post header present that specifies [EMAIL PROTECTED] I've changed my .muttrc as you suggested, to delimit the subscribed address properly. But the list-reply still picks up both versions of the list address when I try to reply. (The 'normal' one is in the address used by the person I was replying to.) There are no followup headers in the message. This looks like a bug: mutt usually gives us the flexibility to work around eccentric configurations by a listowner, but it doesn't seem to work here. Comments? Breen -- Breen Mullins Menlo Park, California
Mailing list reply
Where does mutt get the address for a mailing list reply? I've just been chided for replying twice to a mailing list, where I used the list-reply function. Replies went to '[EMAIL PROTECTED]' and to '[EMAIL PROTECTED]' - and I can't see where the mail. part comes from. Is it from the List-Id header? If so, how do I suppress that? Breen -- Breen Mullins Menlo Park, California
Re: GPG keyservers
* Todd Zullinger <[EMAIL PROTECTED]> [2007-10-03 14:48 -0400]: Anyway, I do recommend asking on gnupg-users if you don't get things worked out. There are some helpful folks there, much as there are on this list. I just reproduced Joseph's report here - OS X with gpg 1.4.7 . Joseph, I'd definitely take it to gnupg-users at this point. Breen -- Breen Mullins Menlo Park, California
Documentation (was: pgp_autosign=ask-no)
* Kyle Wheeler <[EMAIL PROTECTED]> [2007-10-02 16:25 -0500]: On Tuesday, October 2 at 02:33 PM, quoth Joseph: You mean crypt_autosign (pgp_autosign is a deprecated synonym for crypt_autosign)? Yup; the documentation says it's just a boolean, not a quad-option. I tripped on one of these variables a while back. (It was crypt_verify_sig in my case but the point is the same.) I'd actually dug through the manual trying to figure out where I'd gone wrong. I was setting crypt_verify_sig=no, but I had an old entry for pgp_verify_sig which was set to yes. I'd have had a better chance of catching my mistake myself if the mutt manual (from 1.5.16) mentioned pgp_verify_sig. The option may be deprecated, but if it's still effective in muttrc, I think it should be mentioned. Breen -- Breen Mullins Menlo Park, California
Re: Mutt stopped sending emails
* Jerome Fong <[EMAIL PROTECTED]> [2007-10-01 14:24 -0700]: Sorry, kind of new with Mutt, I got is working and didn't really explore much further. What is MTA? When I run mutt -version, this is the output I get: MTA = Mail Transfer Agent. It's the program that actually moves mail between one computer and another. My /c/cygwin/var/log directory doesn't have a mail.log file. My .muttrc file is as follows: [...]> set sendmail = "/usr/sbin/ssmtp.exe" The 'set sendmail' config option tells mutt which MTA to use to send mail. It's trying to talk to a program called ssmtp.exe . Is that program there? Is it exactly where .muttrc says it is? Look at ssmtp's config file and see if it's logging somewhere. Breen -- Breen Mullins Menlo Park, California
Re: fetchmailrc - polling local mail
* Joseph <[EMAIL PROTECTED]> [2007-09-30 21:48 -0600]: On my system all local mail: from root, warnings from UPS, hylafax are being forwarded to me: joseph so I have a mail box in /var/mail/joseph In evolution all I had to do is to configure it to pull mail as: "local delivery" and magically all these emails were being forwarded to me. The mutt way to do this is to tell mutt where your system mail is located: set spoolfile=/var/mail/joseph mailboxes /var/mail/joseph and your normal inbox will appear in the mailbox list. No need to go to the effort of moving it somewhere else. Breen -- Breen Mullins Menlo Park, California
Re: fetchmailrc - polling local mail
* Joseph <[EMAIL PROTECTED]> [2007-09-30 21:07 -0600]: What I'm straggling with is what to put in .fetchmailrc to get the mail out (the is no password) fetchmail is used to receive mail, not to send it. You can put a password into .fetchmailrc or into .netrc. It sounds like you may be confusing different functions. Can you explain exactly what you're trying to do? -- Breen Mullins Menlo Park, California
Re: Subject üî
* Alain Bench <[EMAIL PROTECTED]> [2007-09-18 22:52 +0200]: On Thursday, September 6, 2007 at 15:34:16 -0700, Breen Mullins wrote: superficially it looks like it was in the linker? | #0 0x93c10d7c in dyld_stub_unctrl () Or like some Ncurses thinggy bellow waddnstr(), and specific to the linker? I don't know. This should probably be reported to Thomas on bug-ncurses at gnu org. Okay - I'll update ncurses and see if the problem persists, and report there if necessary. Thanks for the help. Breen -- Breen Mullins Menlo Park, California
Re: "charset" perls into wiki
* Rado S <[EMAIL PROTECTED]> [2007-09-02 16:31 +0200]: Can some kind benificiary of Alain's tutorials recapture all the good advice and convert it (last and older ones from archives) into a nice document at http://WIKI.mutt.org/ -> MuttGuide -> Charsets? Has somebody picked this one up yet? If nobody's working on it I'll make a start this weekend. (Having been one of the beneficiaries...) Breen -- Breen Mullins Menlo Park, California
Re: mutt configuration: problem with getting mail
On 9/11/07, Kumar Appaiah <[EMAIL PROTECTED]> wrote: > > I think getmail marks messages as read once you receive them. In fact, > it may so have happened that of your 582 messages, only 417 were new > (unread), but getmail's claim to have delivered everything beats me. The OP's getmailrc calls procmail. Does .procmailrc contain the standard recipe for deleting duplicates? Checking that (and your procmail log, if you're using one) will be helpful. Breen -- Breen Mullins Menlo Park, Calif.
Re: Subject üî
* Alain Bench <[EMAIL PROTECTED]> [2007-09-06 19:19 +0200]: Hi Breen, Which library? Last backtrace I saw of such a MacOS freeze pointed to Ncurses waddch_nosync(). But I'd tend to suspect more something in the libc, called by Ncurses. Ugh. I'm not sure I know how to read this - superficially it looks like it was in the linker? Core was generated by `mutt'. #0 0x93c10d7c in dyld_stub_unctrl () (gdb) bt #0 0x93c10d7c in dyld_stub_unctrl () #1 0x93beec54 in wechochar () #2 0x93beeb60 in _nc_waddch_nosync () #3 0x93bef010 in waddnstr () #4 0x0003409c in print_enriched_string (attr=256, s=0xbfffe78e " ���üîå���", do_color=0) at menu.c:138 #5 0x000345f8 in menu_redraw_index (menu=0x0) at menu.c:252 #6 0x00016cbc in mutt_index_menu () at curs_main.c:558 #7 0x00031bb8 in main (argc=682056, argv=0x0) at main.c:989 Breen -- Breen Mullins Menlo Park, California
Re: Subject üî
* Alain Bench <[EMAIL PROTECTED]> [2007-09-05 00:01 +0200]: On Monday, September 3, 2007 at 15:22:31 -0400, [EMAIL PROTECTED] wrote: All seems well in body. Subject is "[]üîå[]", meaning "uia" flanked by 2 U+FFFD replacement characters (in my font they look like empty squares). That seems to be what you described sending. Next question is: What added those U+FFFD chars?? As it happens, the U+FFDD this morning caused mutt to freeze on me, as we discussed a couple of weeks ago. It's probably still tripping on iconv somewhere. I got a backtrace this time, if it's helpful. Looks like it's in the library. Breen -- Breen Mullins Menlo Park, California
Re: Message-hook problem
* Alain Bench <[EMAIL PROTECTED]> [2007-08-21 13:39 +0200]: | set config_charset=utf-8 # muttrc's charset | | message-hook ."unset display_filter" | message-hook pattern 'set display_filter="sed s/¹/\\\047/g"' That's done it. Thanks! While at it, Breen could sed it to the original curly apostrophe (HTML's "’"). Make it maximally portable would then need some help from the iconv //TRANSLIT feature: I'm going to stay with what's working at the moment, and take up //TRANSLIT some other time. Thanks, Alain. Kyle too. -- Breen Mullins Menlo Park, California
Re: Message-hook problem
* Kyle Wheeler <[EMAIL PROTECTED]> [2007-08-20 20:21 -0600]: Heh, OSX's sed can handle the character directly. For example: /usr/bin/sed "s/¹/'/g" Huh. So it can. Now all I have to do is sort out the quoting in the message-hook... Thanks again! -- Breen Mullins Menlo Park, California
Re: Message-hook problem
* Kyle Wheeler <[EMAIL PROTECTED]> [2007-08-20 09:50 -0600]: Aha! :) It's pretty obvious when you think about it. Let me guess, you use a UTF-8 locale? Yep. The tr program, knowing only bytes, finds the 0xB9 byte and transforms it into 0x27, just like you told it to, leaving 0xC2 0x27. Because 0x27 does not fit the form 10zz, this is an invalid UTF-8 character, and so Mutt does its best to show it to you. (0xC2 == \302) Ah. Very clear. Thanks. The best way to fix this is with sed, rather than tr: sed "s/\o302\o271/'/g" (That's for GNU sed; other sed's use different syntax for specifying bytes.) Yeah. OS X here doesn't have gsed. Time to hit the books. Breen -- Breen Mullins Menlo Park, California
Re: Message-hook problem
* Kai Grossjohann <[EMAIL PROTECTED]> [2007-08-20 17:36 +0200]: Type Ctrl-E on the message and replace the charset iso-8859-1 with Windows-1252. If the message has multiple parts, hit v then choose the part that is displayed wrongly, then do Ctrl-E as described above. Does it help? Nope. Still displays the superscript 1. Breen -- Breen Mullins Menlo Park, California
Re: Message-hook problem
* Kyle Wheeler <[EMAIL PROTECTED]> [2007-08-20 07:42 -0600]: On Sunday, August 19 at 12:41 PM, quoth Breen Mullins: I've wrestled with this one for a few days and I'm not getting anywhere. It should be simple (and probably is!) but I'm not seeing it. Could you post an example message so that we can examine it? Sure. Here's a trimmed version, full thing available too. (I'm pretty sure I've got everything relevant...) === User-Agent: Microsoft-Entourage/10.1.4.030702.0 From: <[EMAIL PROTECTED]> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3269936535_216437" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3269936535_216437 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Who=B9s coming? Are you bringing a friend? Please let us know! [...] --B_3269936535_216437 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Ladies at Lunch Who&= #8217;s coming? Are you bringing a friend? Please let us know! [...] --B_3269936535_216437-- -- Breen Mullins Menlo Park, California
Message-hook problem
I've wrestled with this one for a few days and I'm not getting anywhere. It should be simple (and probably is!) but I'm not seeing it. I've got a correspondent whose version of Entourage is sending oddly broken messages. When she types an apostrophe, MS converts it to a curly one. That's correctly rendered in the text/html version of the message. But in the text/plain portion, the same character is coded as a 0xb9 - a superscript 1. And that's what mutt displays. Not the end of the world - I can fix it easily enough in a reply with a vim mapping. But it's annoying and I'd like to fix the display. I tried this message-hook: message-hook "~f \"[EMAIL PROTECTED]"" \ "set display_filter='tr 271 047'" The hook starts off out right - it fires on her emails and attempts the replacement at the right spot. But the replacement isn't what I'm looking for: " Who\302's coming? Are you bringing a friend? " I can't figure out where the \302 is coming from. I'm on a Mac (10.3.9); Mutt 1.5.16 (2007-06-09) System: Darwin 7.9.0 (Power Macintosh) ncurses: ncurses 5.2.20020209 (compiled with 5.2) libiconv: 1.9 Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK -USE_INODESORT -USE_POP +USE_IMAP -USE_SMTP -USE_GSS +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL +HAVE_GETADDRINFO -HAVE_REGCOMP +USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/sw/share/mutt" SYSCONFDIR="/sw/etc" EXECSHELL="/bin/sh" -MIXMASTER charset-hook ^unknown-8bit$ cp1252 charset-hook ^x-unknown$ cp1252 charset-hook ^x-user-defined$ cp1252 charset-hook ^us-ascii$ cp1252 charset-hook ^iso-8859-1$ cp1252 charset-hook ^iso-8859-8-i$ iso-8859-8 charset-hook ^gb2312$ gb18030 set assumed_charset="cp1252" tr (GNU coreutils) 5.96 Can somebody tell me what I'm missing? Thanks, Breen -- Breen Mullins Menlo Park, California
Re: Change into an mbox - like chdir
* David Woodfall <[EMAIL PROTECTED]> [2007-07-10 18:35 +0100]: Sorry it's hard to explain what I mean. Basically, I have some keybinds set up like this: macro browser l "^u/home/dive/mail/lists" I have some macros like this: macro index ,m =mag which work for me. Breen -- Breen Mullins Menlo Park, California
Re: mutt freezes when fed high character in header
* Breen Mullins <[EMAIL PROTECTED]> [2007-07-04 10:03 -0700]: Thanks for the hints on charset-hooks - I tried them but it didn't help. Aargh. Cancel that - I just checked my work, corrected the error - and the problem message opened with no problems. Thanks again! Breen -- Breen Mullins Menlo Park, California
Re: mutt freezes when fed high character in header
* Christian Ebert <[EMAIL PROTECTED]> [2007-07-04 18:00 +0200]: Unfortunately there's nothing that tells an unexperienced user that it is iconv's fault. See the message that started this thread. amavis told him about an undeclared header. And some people don't run amavis, or are not as obsessed as I am about Mutt, and will just say: oh, Mutt freezes, without telling me anything, I'll just use that other mailer which doesn't freeze. I agree - you have to be determined in a case like this one. It took a bit of work to isolate the message that was causing the hang. Not something you can expect most users to bother with. Thanks for the hints on charset-hooks - I tried them but it didn't help. For now, since I'm only seeing this problem with a single user on a single mailing list, I've written a sed one-liner to correct the From: line in his messages, and I'll drop it into cron until I have the chance to try a new libiconv. Breen -- Breen Mullins Menlo Park, California
mutt freezes when fed high character in header
I had mutt freeze (again) while opening an mbox today. It gets to the point where it prints 'sorting mailbox' and hangs. I finally tracked it down to a message containing a From: header in which an 8-bit character wasn't properly encoded: X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char E6 hex): From: "Danny Kj\346r..." (Nice of amavis to point that out.) Remove the message from the mbox and it opens just fine. Here's my mutt -v: Mutt 1.5.16 (2007-06-09) System: Darwin 7.9.0 (Power Macintosh) ncurses: ncurses 5.2.20020209 (compiled with 5.2) libiconv: 1.9 Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK -USE_INODESORT -USE_POP +USE_IMAP -USE_SMTP -USE_GSS +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL +HAVE_GETADDRINFO -HAVE_REGCOMP +USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/sw/share/mutt" SYSCONFDIR="/sw/etc" EXECSHELL="/bin/sh" -MIXMASTER and my charset configuration: LANG=en_US.utf-8 LC_CTYPE=en_US.UTF-8 Any advice on avoiding a repeat? The list in question has a lot of international users. Thanks - Breen -- Breen Mullins Menlo Park, California
Re: Invalid domain name
* Luis A. Florit <[EMAIL PROTECTED]> [2007-07-02 21:29 -0300]: This problem is very strange since it works when I close and open mutt again. Does not seem to be related to configuration (?). It's probably related to configuration. Look through your config files for anything containing 'hook'. Comment out any such lines and see if it resolves the problem. Breen -- Breen Mullins Menlo Park, California
Re: crypt_verify_sig
* Kyle Wheeler <[EMAIL PROTECTED]> [2007-06-18 23:15 -0600]: On Monday, June 18 at 08:38 PM, quoth Breen Mullins: Chances are, you have it set to yes somewhere, like the /etc/Muttrc. It's important to realize that pgp_verify_sig is a synonym for crypt_verify_sig. Yeah, I had pgp_verify_sig set. I actually woke up in the middle of the night with the belated understanding. If I had a nickel for every time I understood something only _after_ posting to a public list... Thanks for the reply. Breen -- Breen Mullins Menlo Park, California
crypt_verify_sig
I'm using mutt 1.5.16 and it doesn't appear to be noting the setting set crypt_verify_sig=no in my .muttrc. mutt always starts with crypt_verify_sig set to yes, although I've a macro that successfully toggles it to no. I realize I'm probably missing something elementary, but I'm not seeing it. Mutt 1.5.16 (2007-06-09) System: Darwin 7.9.0 (Power Macintosh) ncurses: ncurses 5.2.20020209 (compiled with 5.2) libiconv: 1.9 Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK -USE_INODESORT -USE_POP +USE_IMAP -USE_SMTP -USE_GSS +USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL +HAVE_GETADDRINFO -HAVE_REGCOMP +USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/sw/share/mutt" SYSCONFDIR="/sw/etc" EXECSHELL="/bin/sh" -MIXMASTER If someone can point me to what I'm doing wrong, I'd appreciate it. b. -- Breen Mullins Menlo Park, California
Re: gpg inline signed sig incorrect
* Rocco Rutte <[EMAIL PROTECTED]> [2007-06-10 13:17 +]: Hi, * Patrick Shanahan [07-06-10 07:44:38 -0400] wrote: Why is the signature indicator not display properly in inline gpg signed posts, ie: . This is so that no software deletes the mail's signature including the gpg signature even by accident. I don't know if it's the official reason but at least it makes sense... :) It's required by RFC2440 (the OpenPGP standard). See section 7.1 therein. Breen -- Breen Mullins Menlo Park, California
