Re: Muttzilla/altmail and Mozilla
[Sorry for the slow reply. It took me a while to find time to create the FAQ on this.] On Mon, Aug 13, 2001 at 03:21:29PM -0400, Michael Sanders wrote: On Mon, Aug 13, 2001 at 08:02:25PM +0200, Vincent Lefevre wrote: But does this work with Mozilla (the current version is now 0.9.3)? Has anyone tried netscape 6.1? I've heard from lots of people trying muttzilla with mozilla, and a few with netscape 6.x. None of them have reported success. For a more complete answer, check out the FAQ I just created: http://www.pteranodon.org/mutt/faq.html Brian -- Measure twice, cut once.
Re: Error when sending mail
On Fri, Jan 19, 2001 at 09:17:07AM +0100, Redak, Dorian wrote: Thanks for the hint. I'm using qmail's sendmail wrapper. The sendmail binary is executable and all qmail processes are running. Do you have dsn_notify or dsn_return enabled? If so, don't. qmail doesn't support DSN. Brian
Re: Mutt + Screen + Vim question
On Fri, Nov 03, 2000 at 03:19:30PM -0500, Steve Bankowitz wrote: (pretty standard stuff.) But every once and a while I would like to jump back to Mutt to check a message. Since I'm running screen I thought, ``Oh, I'll just spawn vim off in another screen and then jump back to mutt if need be.'' Why not leave your editor stuff alone, and spawn another mutt in another screen? Brian
Re: Mutt + Screen + Vim question
On Fri, Nov 03, 2000 at 07:07:28PM -0500, Steve Bankowitz wrote: Brian D. Winters [[EMAIL PROTECTED]] wrote: On Fri, Nov 03, 2000 at 03:19:30PM -0500, Steve Bankowitz wrote: (pretty standard stuff.) But every once and a while I would like to jump back to Mutt to check a message. Since I'm running screen I thought, ``Oh, I'll just spawn vim off in another screen and then jump back to mutt if need be.'' Why not leave your editor stuff alone, and spawn another mutt in another screen? How would I do that? Would I write a macro for `m`? And how would you invoke that 'm' macro from inside vim??? :) The solution I'm suggesting has absolutely nothing to do with mutt and everything to do with screen. Mutt can't do what you think you want it to do. You need to tell screen you want a new screen, and you want to run mutt in that new screen. The only way to interrupt composing a message and use mutt to browse e-mail is to postpone the current message (exit your editor, then invoke postpone-message, probably with the 'P' key), browse away, and then resume the postponed message (probably with 'R'). You can't "jump back to mutt" from your editor, because mutt is waiting for vim to terminate, and if I read your message correctly, you want to browse messages in mutt without exiting vim. That just won't work. Brian
Re: changing directories
On Thu, Oct 26, 2000 at 05:19:00PM +, Nollaig MacKenzie wrote: Actually, mutt is cute about this. If I'm reading =Lists/mutt-users [aka /home/nollaig/mail/Lists/mutt-users] and do :set folder=~/tmp mutt continues to show me =Lists/mutt-users, and typing I would guess that mutt figures out what folder it is in when you enter, and doesn't update the status line until you change to another folder. "c" then "?" gets me a listing of my mailboxes, all of which are in ~/mail; but when I save a message from As for "c?", for example with: mailboxes =Lists/mutt-users The = is expanded when that line in your muttrc is first processed. This is why you must set folder before anything which uses = or +. Changes to folder only affect subsequent uses of = or +. "[EMAIL PROTECTED]" the default filename offered is /home/nollaig/tmp/foo Yes, because now folder is different, so =foo is /home/nollaig/tmp. Brian
Re: muttzilla on freebsd
On Tue, Oct 10, 2000 at 04:04:13PM -0700, Peter Jaques wrote: has anyone gotten muttzilla working on freebsd? when i click a mailto link now, nothing at all happens, not even console complaints from netscape. First off, muttzilla now has its own mailing list: [EMAIL PROTECTED] Secondly, yes, I have received several reports of success using muttzilla under freebsd. I don't have any more specific info, though. (It didn't sound like any major changes were required.) Have you followed INSTALL faithfully? If not, go back to the beginning and try again. If so, I guess the next thing to check is which version of Netscape you are running. Some are known to have problems (see ERRATA). Brian
Re: Blocking Spam within the .muttrc?
On Thu, Sep 28, 2000 at 11:34:36AM -0500, Ben Beuchler wrote: On Thu, Sep 28, 2000 at 10:37:31AM -0500, Pete Robie wrote: Hello, I am kind of new to the list and was looking for information on blocking a domain (user level, not admin) within Mutt. We are running Qmail (as I know this is not a list for them) and I am using Mutt 1.0pre3i that is currently installed. Does anyone have any suggestions on how I can blacklist a domain for my account without having this done at the server level through badmailpatterns? I believe the mutt authors feel that that is not mutt's job. For that you will need either procmail or maildrop. I personally prefer maildrop. If you are using Maildir delivery instead of mailbox, you will HAVE to use maildrop. Recent versions of procmail (I believe =3.14) support maildirs. Depending on what you are trying to do, you may prefer to do this in your .qmail file without resorting to procmail or maildrop. Check out DJB's mess822 tools, and the man pages for bouncesaying and condredirect. (See http://cr.yp.to/qmail.html .) Brian
Re: muttzilla
On Mon, Sep 11, 2000 at 11:56:08AM -0700, Dale Morris wrote: Hi, I'm running debian 2.2 woody and I just did apt-get install muttzilla and sure enough there was a debian muttzilla package, which One of these days I should check out the various muttzilla packages I keep hearing about. Among other things, I wonder how the packagers choose to handle the compile-time decision of mail only, news only, or mail and news support. I also wonder if they bother to include all of the docs. Btw, my web page won't help you much directly, but it will let you download the full tar.gz, including all of the setup instructions. Anyway, there is now an archived support list for muttzilla: [EMAIL PROTECTED] If you have any further problems, please ask the folks there. Brian
Re: anyone using muttzilla
FYI: It looks like I may finally have the time to work on muttzilla
again. I'm setting up muttzilla with sourceforge. -users and
-announce mailing lists are up, but the CVS repository hasn't been
populated yet. Hopefully there will be a slightly more user-friendly
version available soon.
Anyway, Brad's questions...
On Fri, Jul 28, 2000 at 06:42:21PM -0500, Brad Cramer wrote:
Is anyone suing muttzilla with Eterm? I am having a heck of a time getting
I don't remember hearing from anyone who is using Eterm, but that
doesn't mean much.
it configured to work properly. I set mailterm=Eterm in my muttzilla.conf
file it starts and work but I get an error box (I think these errors have to
do With Eterm)
What does the error box say? My guess is that Eterm doesn't accept
the same arguments as xterm and clones (like rxvt), and is choking on
them.
I try to set mailterm=Eterm -t mutt which is how I normaly
call mutt but I get an error about expecting = but gettin -t instead. If
someone could give me some ideas I would be thankful.
That definitely won't work. To get the effect you desired from a
parsing standpoint, you would need to quote it like this:
mailterm="Eterm -t mutt"
However, please don't do that. You would find that the argument
handling doesn't behave the way you want it to behave. That mailterm
line will cause mzmail.{py,sh} to attempt to execute a program named
Eterm\ -t\ mutt. I doubt that is what you intend.
[Installing an Eterm rpm...`man Eterm`...]
Well, -t ("load theme") is definitely something normal xterm doesn't
do. You have stumbled upon the reason why muttzilla.so does as little
as possible, handing off most of the interesting work to a wrapper
script: it will be relatively easy for you to hack up mzmail.{py,sh}
to properly spawn your Eterm, or to ditch mzmail.{py,sh} entirely and
write your own simple wrapper script that just spawns mutt in an Eterm
for you.
Brian
Re: maildirs and Lines:
On Sat, Jul 01, 2000 at 01:48:26PM +0300, Mikko Hänninen wrote: Brian D. Winters [EMAIL PROTECTED] wrote on Fri, 30 Jun 2000: 2) Add an "auto_add_maildir_lines" option. ... I don't think this even needs to be an option, or is there some bad performance hit or something why the user might not want Mutt always to add a Lines header when writing a message to a Maildir? There is a performance hit. (I don't believe it is bad; see next paragraph.) You need to scan the whole message once in order to know how many lines it has, so you can write Lines:. In order to insert the header, you need to make a copy of the message, which means making two passes over the message or reading the entire message into memory while you count lines. (I believe the FAQ's procmail recipe reads the entire message into memory, but who can tell for sure exactly what it does. :) The python script I wrote yesterday to put in list-specific .qmail-... files also reads the entire message into memory and then outputs it after counting the lines.) Now, how do mboxes work again? :) The cost of rewriting an individual maildir message is nothing compared to the cost of adding a Status: header in a big mbox. I'd be happy to take the hit once per message in my maildir. In fact I already do, as it passes through the filter on delivery. I think that adding Lines: should be an option (I'm sure someone won't want it), but the default should be "yes". Brian
Re: Qmail success, no procmail
I am currently looking how to achieve procmail filtering via Qmail, but Have you tried: |preline procmail in your .qmail file? (I believe that this is in the qmail documentation somewhere.) in the mean time, why is there a (0) byte indication in the index of every message that comes in??? I assume you are using maildirs? Two solutions: 1) Go to www.mutt.org, and try reading the FAQ. (Assumes you get procmail to work.) 2) Read up on index_format, and change from displaying lines to bytes. For more details, search the mutt-users archives for "maildir" and "lines". Brian
Re: Qmail success, no procmail
On Fri, Jun 30, 2000 at 09:27:56PM -0700, Jason Helfman wrote: |preline -f /usr/bin/procmail I'm not sure about the -f. I don't use it in my .qmail, but based on the description in the man page I don't see why it would cause procmail to fail either. My guess would be that you are having procmail problems, not qmail problems. Have you tried turning on logging in procmail? Set this at the top of your .procmailrc: LOGFILE=/home/.../procmail.log Cool, i didn't know about this, and i do RTFM. When i ran inbox, it worked, now it doesn't. Thanks for the pointer. Those references are a little more obscure than just RTFM (although the FAQ isn't by much :), so you are forgiven. ;) I've already played with Lines: and maildirs some today. (See my next message.) Brian
maildirs and Lines:
(I checked the archives, and although this has been asked before, no one had a good answer. Hopefully someone will have a better idea this time around, or I missed the answer in the archives.) I use maildirs, but I prefer to see lines rather than sizes in the message index. I've been using the procmail recipe to add Lines: for a long time, and it works well on incoming mail. This doesn't implicitly deal with outgoing e-mail, but in most cases bccing myself works well enough. The problem with bccing myself is that I get two copies when I send to mailing lists which return a copy to me. The easy solution is to remove the Bcc header when I send to a list, except it isn't that easy. I have been removing the Bcc manually, which is a pain and sometimes I forget. A few days ago I decided to try to make it automatic (I am using mutt after all...), and remembered why I haven't set this up earlier. send-hooks take effect after all of the recipient headers are set. Bcc is a recipient header. fcc-hooks don't have that ordering problem, but there is no way to pipe the message through procmail or any other program to add Lines:. I see two obvious solutions: 1) Extend fcc-hooks to allow piping to a filter program. 2) Add an "auto_add_maildir_lines" option. Does anyone know of a reason other than, "No one has submitted a patch yet," why one of these hasn't been added, or is there a better solution which I'm missing? Brian
Re: those users (was Re: Reply to all???)
And etiquette requires that if you are fairly newbile you send your question to CoolSoftwareNewbies and wait a reasonable time before construing the absence of answer as an indication that you should send it to CoolSoftwareUsers? Wouldn't they have to read the docs for the lists to get that right? Isn't the difference between a newbie and a user, in this case, whether or not they read the docs before posting? Naive, I suppose.. Looks like the same problem, with one more list for Jeremy to skim to keep the web page current. ;) Brian
Re: procmail question
On Mon, Jun 19, 2000 at 07:46:42PM +0200, [EMAIL PROTECTED] wrote: On Sun, Jun 18, 2000 at 05:49:47PM -0700, Brian D. Winters wrote: Never, never, never filter a mailing list like mutt-users based on To:, Cc:, From:, Subject:, Reply-To: or Mail-Followup-To: if you can possibly help it. What happens the first time someone bcc's the list? Think about it. Well, precisely, what happens ? If they Bcc the list, then To, Cc, and From are almost certainly useless and it is very unlikely that they set MFT to something useful either. The other header that I listed is Reply-To. If you are relying on users to set Reply-To to include the list, you have the same problems as with the rest. The story with Reply-To is more complicated though, and is the reason why I qualified my statement with, "if you can possibly help it." Some mailing list software will rewrite the Reply-To on every message, assuming that the list subscribers are not competent enough to figure it out for themselves. (IMHO these servers are defective, since this sort of rewriting has drawbacks. As for user competence, I find that these sorts of lists typically have a high percentage of subscribers who are Windows users. ;) I am subscribed to a couple of these sorts of lists, and unfortunately I can't help but filter on Reply-To, since these servers don't add Sender or (X-)Mailing-List headers either. Reply-To isn't great, but it is still better than resorting to ^TO. Anyway, the end result is that the bcc'd message doesn't get filtered and ends up in your inbox rather than in your mutt box. Now, people probably shouldn't be bccing mailing lists, but why worry about it if there is a solution with no drawbacks which also doesn't rely on the competence of your peers? :) Oops, I almost forgot to mention why I object to filtering on Subject. That is almost as much philosophical as technical. Lists which add [list] to the subject typically do so because of whining from users who cannot filter except visually, cannot filter on arbitrary headers, or don't realize that other headers exist besides From, Date, To, Cc, and Subject. It should be clear from the recent thread about trying to match "Re: re: [list] Re: ..." for non-strict threading that list rewriting of Subject headers can cause problems. There are much better ways of marking list e-mail as such (see above and my previous post), and if your filter can't handle something of the form "Sender: owner-mutt" then you should get a better filter. If nothing else, the subject tag is a waste of screen space that could be used to show me more of the message's real subject. Brian
Re: procmail question
On Sun, Jun 18, 2000 at 12:53:08PM -0700, Dale Morris wrote: I'm trying to get procmail working on my rh 6.2 system, after reading the manual and banging my head on the keyboard for several hours, I'm thoroughly confused--a comfortable state, for me and linux.. my question ... What I want to do is have procmail transfer mutt-users messages /var/spool/mail/dlm to /home/dlm/Mail/mutt, correct? I have a mutt mbox, and here's how I've setup the .procmailrc recipe: #mutt :0: * (^Reply-To:.*|^TO_)mutt-users $MAILDIR/mutt But it doesn't work. I will attach my .procmailrc and .muttrc files if someone cares to take a look. First off, since this sounds like a delivery problem, mutt is not at all relevant. This is a MTA problem. For RH6.2, the default is for your MTA to be sendmail with local delivery handled by procmail. So far, so good. Procmail filtering basics: Procmail filters your incoming messages at time of delivery. If your mutt e-mail ever gets to /var/spool/mail/dlm, then your procmail recipe has already failed. E-mail which gets diverted to /home/dlm/Mail/mutt will never go anywhere near /var/spool/mail/dlm. First question: How is incoming e-mail getting to your system? If you are using fetchmail or it is being delivered directly via SMTP, you are looking good so far. If you are using fetchmail with an odd --mda setting or some other program which is writing it directly to /var/spool/... rather than delivering it to your local SMTP server, we have just identified one of your problems. Assuming that everything is ok to this point, it is time to consider the rule you are using. I am not a procmail guru, so the following advice may not be 100% right, but it works for me: Never, never, never filter a mailing list like mutt-users based on To:, Cc:, From:, Subject:, Reply-To: or Mail-Followup-To: if you can possibly help it. What happens the first time someone bcc's the list? Think about it. Filtering on headers written by the user is a sure recipe for failure. Any reasonable mailing list server will add a header identifying the list. The most common header is Sender:, but I've also had to resort to Mailing-List:, X-Mailing-List, and Delivered-To:. In the case of mutt-users, the header I use is Sender:. That gives a rule like this: :0: * ^Sender: owner-mutt $MAILDIR/mutt I bet that rule will work a lot better for you than your current one. Brian
Re: Slrn and Mutt
On Wed, Jun 07, 2000 at 10:38:16PM -0700, Jason Helfman wrote: Has anyone successfully integrated Slrn and Mutt together in use with netscape? Or just so these programs can be used hand in hand... Check out http://www3.telus.net/brian_winters/mutt/ . Brian
Re: Location of signature in replies
On Tue, May 23, 2000 at 07:30:23PM -0500, Corey G. wrote: By the way, where are you finding netiquette rules for email? I am curious. The standard reference is RFC 1855. (One place you can find this is http://www.faqs.org/rfcs/rfc1855.html .) As with most RFCs, this is rather long, and some common interpretations may not be obvious the first read through. You could view this thread as the edited highlights of RFC 1855. :) Brian
Re: metoo not removing my address
On Tue, May 23, 2000 at 07:23:30PM -0500, Corey G. wrote: I must be slow or something but here is 6.3.6 from the documentation. It only states addresses as alternates. I really do not want to debate what the definition of an "alternate" is but it's the same as an "alternative" or not the original. Thus, not the original which would be referring to your original or real email address. By reading this it would indicate that a user would set "$alternates" for alternative addresses and not your primary address. As far as I know this only applies to 1.1 and greater, but you are using 1.2, so it should be valid: If you only have one address, i.e. the one you have set $from to (you have set $from and $realname, right?), then you do not need to set $alternates. You only need to set $alternates when you get e-mail at alternate addresses, other than the one set in $from. Hence the name "alternates". Section 6.4.49 is irrevelant because I have "my_hdr" set and it did not matter in this situation. $alternates had to be set to work correctly. Mutt is not able to interpret every my_hdr you have set up (maybe inside of hooks, etc.) to try to guess what other e-mail addresses are you, besides your $from setting. $alternates exists to make up for the fact that mutt is not (and realistically cannot be) that smart, and because not every address you might receive mail at is necessarily going to be listed in a my_hdr. IMNSHO $alternates is correctly named, and the existing documentation is correct, as far as it goes. The only possible documentation change I can see might be a clarification on this specific point (my_hdrs being cosmetic only) so that future users don't make the same assumptions, get confused and annoyed, and then blame the docs for not being explicit enough (which, granted, they apparently weren't, or you wouldn't have needed to ask the question in the first place). I would suggest an additional sentence to be tacked onto the end of the existing $alternates entry, along the lines of, 'Note that if you use "my_hdr From: ...", you will need to specify that address in $alternates in order for Mutt to recognize that you are the sender that message," but that sentence needs a little work, and then I'd have to untar the original sources and create a patch, and submit the patch to mutt-dev, and I'm supposed to be leaving on vacation in a few hours. ;) Brian
Re: maildirs with both mail and other maildirs in them
On Fri, May 19, 2000 at 09:52:19AM +0100, Chris Green wrote: I have a maildir which has mail delivered to it directly (i.e. it has cur, new and tmp directories in it) but it also has other maildir folders in it. Mutt doesn't seem to be able to cope with this at all, am I missing something or is it just not possible to handle this with mutt? AFAIK you are not missing anything, although I'm not sure unable "to cope with this at all" is totally accurate. I expect that if you give mutt an explicit path to open it do so just fine. My guess is that your problem is when trying to browse to the subdirectories? Perhaps you (or anyone else reading this) can answer a related question I have been wondering about for quite a while. Why on earth would you want to put directories other than cur/new/tmp in a maildir? This seems really broken to me. My understanding is that maildirs are directories which contain cur/new/tmp, not directories containing cur/new/tmp plus N other unrelated directories to confuse things. My guess from past posts is that you are doing this because Courier IMAP forces you to do so. Personally I think Courier is defective in this regard, but the rest of my rant on that subject doesn't belong on this list. IIRC courier also insists on beginning those directories with a ".", which probably doesn't hurt mutt, but can't help. Back to trying to provide constructive suggestions, how well does Courier handle symlinks? I've never tried this, but could you move your subfolders elsewhere and symlink to them? Or could you symlink to those folders from elsewhere for mutt's benefit? IMAP servers may chose not to follow symlinks for security reasons, but mutt shouldn't have any trouble following symlinks. This isn't the most elegant solution, but I don't have any better suggestions. Brian
Re: attachment permissions on saving
On Fri, May 05, 2000 at 02:59:01AM +0300, Mikko Hänninen wrote: Corey G. [EMAIL PROTECTED] wrote on Thu, 04 May 2000: Would changing your umask work? Probably not, my umask is 022 and Mutt still creates new folders and saved files with mode 600. I think it's a security precaution and a good default, since usually you do not want other people reading your mail -- or by extension, the files you got via email. Still, having the choice to adjust this would be nice. I'm pretty sure Mikko is correct. A long time ago (at least a year I think), there was a discussion about this, probably on mutt-dev. Some felt very passionately about defaulting to 600, others that it should follow umask, and generally there was a lot of misunderstanding both ways. After the dust settled, AFAIK no one did the obvious thing and write the code to make this an option. (Or really two options, since one might wish different defaults for saving attachments vs creating new folders.) My guess is that if someone did write a patch, it could eventually get added to the main mutt source, but I really don't know. Brian
Re: mapping the `y' to enter in compose menu
On Thu, Apr 20, 2000 at 10:03:30PM +0200, Eric Smith wrote: I would like to be able to press just enter when I am in the compose bind compose enter send-message Brian
Re: gpg always downloading sigs for signed mail...
On Wed, Apr 05, 2000 at 10:45:15AM -0400, Sam Roberts wrote: I'd just like to have better control over when gpg tries to download keys, I wish it (or mutt) would ask "hey, do you want me to try and fetch this key from $keyserver?". =20 Have you tried hitting ^C if the fetch is taking too long? The policy when using gpg with mutt is effectively to assume yes, but allow an interrupt if the answer is no. I'll try, but my concern is mostly getting tons of total stranger's keys on my public ring, I just don't want them, even if its fast. I think the problem (if you can call it one) is two-fold. Looking at gpg, it looks like the keyfetching is a little *too* transparent, there doesn't seem to be an option to --verify that says just use the local keychain, and also doesn't seem to be any hooks in the co-processing protocol such that gpg can say verification failed, do you want me to ask a keyserver for a key? And since it doesn't exist, mutt doesn't support this. Anyhow. Feature request. Sam --
Bogus headers (was Re: gpg always downloading sigs for signed mail...)
Um, what's going on here? I did *not* write this message which is claiming to be from me. It is a copy of the message Sam Roberts sent a couple days ago, which included in the body some unquoted headers from my message. I believe the relevant header from this copy is: Received: (from cyrus@localhost) by paulbm.demon.co.uk (8.9.3/8.9.3) id TAA22019; Sun, 9 Apr 2000 19:29:35 +0100 Whatever happened, please don't let it happen again. Thanks, Brian On Sun, Apr 09, 2000 at 07:29:35PM +0100, Brian D. Winters wrote: On Wed, Apr 05, 2000 at 10:45:15AM -0400, Sam Roberts wrote: I'd just like to have better control over when gpg tries to download keys, I wish it (or mutt) would ask "hey, do you want me to try and fetch this key from $keyserver?". =20 Have you tried hitting ^C if the fetch is taking too long? The policy when using gpg with mutt is effectively to assume yes, but allow an interrupt if the answer is no. I'll try, but my concern is mostly getting tons of total stranger's keys on my public ring, I just don't want them, even if its fast. I think the problem (if you can call it one) is two-fold. Looking at gpg, it looks like the keyfetching is a little *too* transparent, there doesn't seem to be an option to --verify that says just use the local keychain, and also doesn't seem to be any hooks in the co-processing protocol such that gpg can say verification failed, do you want me to ask a keyserver for a key? And since it doesn't exist, mutt doesn't support this. Anyhow. Feature request. Sam
Re: gpg always downloading sigs for signed mail...
On Wed, Apr 05, 2000 at 10:45:15AM -0400, Sam Roberts wrote: I'd just like to have better control over when gpg tries to download keys, I wish it (or mutt) would ask "hey, do you want me to try and fetch this key from $keyserver?". Have you tried hitting ^C if the fetch is taking too long? The policy when using gpg with mutt is effectively to assume yes, but allow an interrupt if the answer is no. Brian
Re: .saves-{pid}-{machine} files
On Sat, Sep 25, 1999 at 10:28:21AM +0400, Alex Kapranoff wrote:
I don't use emacs and have those files in /tmp too. They look like
mutt-kapran-{pid-of-mutt}-15.
~/.saves-* files are from emacs. /tmp/mutt-* files are from mutt.
Brian
Re: A feature request
Also, does anybody know what `Content-Type: text/plain, charset="utf-7"' mean? I do know UTF-8, but I can only guess what UTF-7 is. AFAIK both Netscape and Internet Explorer support it. I recently received a couple of mails in this encoding (mailer: MS Outlook Express 5.00) and the only thing that looked strange was quoting string: `+AD4- '. Unfortunately, mutt does not support it. Based on responses (or lack thereof) the last two times I brought up the subject, I am the only other person on mutt-users who has ever seen UTF-7. ;) UTF-7 is a 7-bit clean version of unicode. It is described in rfc1642. UTF-8 is the more standard way of handling unicode. AFAIK, outlook express is the only program which sends UTF-7, and even then it seems that only some installs of outlook express do it. My solution was to find a program called u7tou8 which does conversion from UTF-7 to UTF-8, which is understood by mutt. Then I added the following to my .procmailrc: :0 f * ^Content-Type:.*charset="utf-7" | u7tou8 | formail -i "Content-Type: text/plain; charset=\"utf-8\"" This would of course break things like PGP/MIME signatures, but who's going to be sending you PGP/MIME from inside of Outlook Express? ;) I'm having a bit of trouble finding where you can get this conversion program. Last time I think I found it by searching through the Linux Chinese-HOWTO. Ah, here it is (the HOWTO comes through again): ftp://ftp.ifcss.org/pub/software/unix/convert/utf7.tar.gz Good luck. Brian
Re: IMAP folder path
On Wed, Sep 01, 1999 at 10:37:45AM -0400, Brendan Cully wrote: Now now. Sorry, shouldn't write e-mail when I'm tired and grumpy... This actually isn't a big deal if you are using a GUI client with a mailbox window separate from the message index window and one of those nifty tree-view widgets: +Folder -Subfolder -Subfolder I guess you are right there. Still room for them to screw it up by assuming too much about the server, but nothing wrong with the underlying paradigm. 1. The current solution: Display the folder twice. Choosing the first one shows you the messages in it, choosing the second one (with the trailing delimiter) shows you the folders in it. From a user's perspective, I don't like this one. When my friend and I got this running that display was very confusing to both of us. It also clutters things up a bit. 2. Somehow try to integrate the subfolder list into the message window. This will probably be messy and annoying, and very invasive into non-IMAP parts of the mutt code. Users might prefer it, even though as a developer I'd prefer to avoid this. 3. Present a new screen when a user selects a folder that contains messages and subfolders, clearing up the first screen at the expense of extra work navigating. I agree, neither of those are pretty. I'd be interested in other ideas. Currently I like (1) because: it's already there, it doesn't mess with non-IMAP code, and I don't have folders with subfolders and messages, so I don't have to deal with these ugly lists. Here is my take on this: We have a problem right now because mailbox selection and change directory are both mapped to the same key, typically enter. How about separating the two? enter still opens something as a mailbox, but a different key causes you to enter that directory. Actually, looking at the help for the folder browsing screen, it looks like the necessary hooks might already be there. How about maping view-file to open the mailbox and select-entry to "change context in the namespace" (or whatever the Cyrus folks want to call cd)? Do you think that would be a workable solution? Brian
Re: IMAP folder path
On Mon, Aug 30, 1999 at 03:22:42PM -0500, David DeSimone wrote:
I wonder, though, if our original poster, who used a setting like
folder="{imapserver}INBOX." was attempting to get Mutt to translate
"+folder" into "{imapserver}INBOX.folder", which means a folder
literally named "INBOX.folder" in the server's folder collection
for this user? Perhaps the server isn't using "." as the directory
delimiter after all... But these things are hard to guess. :)
There is no need to guess, this has been explained more or less
completely (and your memory is wrong about the exact folder=... line,
which might be part of your continuing confusion), but rather than try
to cover the whole thing again and not lose you this time around, let
me refer you to the definitive source:
http://andrew2.andrew.cmu.edu/cyrus/imapd/overview.html#mboxname
Perhaps the first sentence of the section "Mailbox Namespace" explains
it all:
The Cyrus IMAP server presents mailboxes using the netnews
namespace convention.
By netnews I believe they mean newsgroups as in usenet, etc. They
don't put things in terms like "directory" and "mailbox file", but one
of the things that is pretty clear is that '.' is their separator.
All users are under "user" (somewhat akin to /home), and "INBOX" is an
alias for "user.username". The last name found in a '.' delimited
list is treated as the mailbox, and the rest constitutes the path to
that mailbox. This leads to the strange (for IMAP) behavior that
Brendan mentioned about "mailboxes can also be directories".
Wow, this might be ingenious if it didn't go against the way every
IMAP client I know of works. I wish the people working on supporting
these servers in mutt the best of luck!
Also, since when I fully specified a path in mutt I was using '/', and
Cyrus clearly wants '.', mutt does appear to be doing proper
translation.
Brian
Re: IMAP folder path
On Fri, Aug 27, 1999 at 05:46:46PM -0500, David DeSimone wrote:
Brian D. Winters [EMAIL PROTECTED] wrote:
set spoolfile='{imapserver}inbox'
set folder='{imapserver}INBOX'
[lots of explanation from David as to why this doesn't make sense omitted]
I agree, my solution doesn't appear to make a lot of sense, and were
this UW IMAP or some other more typical server you would be completely
correct in telling me that I'm full of it. However, this is a Cyrus
IMAP server, and my observations suggest to me that Cyrus IMAP servers
use a somewhat different set of conventions.
My earlier post explains what it took to get mutt to work *in*
*practice* with the only Cyrus IMAP server I have ever run accross,
and except for changing the server name the above two lines were
copied directly from the .muttrc currently being used to access that
Cyrus server. The problems Mr. Shay is describing with his Cyrus IMAP
server seem to be the same ones I encountered, so my suspicion is that
the solutions will be the same as well.
Now, that said, I have to admit that I don't know much about Cyrus
IMAP, and their web server is currently giving "...Permission denied."
errors for the imapd section of their web site, which makes doing my
homework a bit difficult this evening. So, in the absence of hard
facts ;), how about a few potentially erroneous observations based on
my very limited experience:
* Cyrus servers seem to be set up for use on systems without any access
to the user's home directory. So "create a mail directory under
your home directory and store folders there" probably won't work.
* There doesn't seem to be any way to create a directory hierarchy, at
least not under mutt. Hard coding "INBOX." may be their answer to
the {server}/folder problem you mentioned, or it may just be
completely arbitrary. ("INBOX/" appears to be equivalent to
"INBOX.", either through magic on the server or magic in pine.)
* With my friend's server, using the folder browsing features in the
devel branch to browse = shows two lines for every folder. One line
is "=foldername", and the other line is "=foldername.". (This is
from memory, so the exact text leading up to "foldername" and
"foldername." may be more complicated.) It is the non-'.' folder
which contains actual e-mail. Attempting to change to the folder
ending in '.' results in nothing happening (I don't remember seeing
any error messages from mutt even, although it has been a couple
weeks so I may be mistaken). I have no idea what the '.' folder is
for.
OK, Google just turned up a mini-howto (of course, how silly of me,
anyything even remotely useful has some sort of howto):
http://metalab.unc.edu/LDP/HOWTO/mini/Cyrus-IMAP.html
It isn't overly enlightening, but it seems to support at least one of
my observations, and doesn't contradict any of the rest.
Brian
Re: IMAP folder path
On Fri, Aug 27, 1999 at 01:47:48PM -0400, Thomas Shay wrote:
I've recently switched to using a Cyrus IMAP server for mail, and can't
figure out how to specify the path to mail folders on the server. With
pine, the format seems to be {imapserver}INBOX.[] (this points at what
I ran across one of these servers recently while helping a friend who
is converting from pine to mutt. Through experimentation I discovered
that the . in {imapserver}INBOX.[] is a path separator and [] means
"insert actual folder name here", so this should do the trick in mutt:
set spoolfile='{imapserver}inbox'
set folder='{imapserver}INBOX'
This works with the devel branch, but I'm not sure about the stable
branch. I think that the stable branch has support for most folder
operations except browsing, but my I might be wrong.
Brian
Re: question: netscape mutt
On Sun, Aug 22, 1999 at 04:13:31PM -0500, Jeremy Blosser wrote:
You should all check out Brian Winters version, which is reportedly rather
stable and was written from scratch.
IMNSHO you should follow Jeremey's advice. ;) I can tell you from
experience that hacking on their elm.c example until it works isn't
worth the pain.
I wrote my version ("navmutt") from scratch in part because I got
tired of trying to seperate the bugs in the example elm.c from the
bugs in Navigator and Communicator. As of 4.61 Nav and Com are both
pretty clean in their support for the Mail half of the API, but
earlier versions had some major API noncompliance issues. Navmutt
works around those issues whenever it can, but sometimes there isn't
any way to tell what the user wanted done.
shameless plug
In addition to working around Netscape goofs, navmutt has working
support for more options than elm.c supported, like Nav/Com supplied
message bodies for instance. (Select "File:Send Link" in Nav 4.61, or
"File:Send Page" in Com 4.61 to see this in action.) AFAIK navmutt's
tempfile creation is safe, although if this is a concern for you
please don't take my word for it, check the source. navmutt has most
of the news API infrastructure written, although it falls short of
providing functional news url support. Configuration is fairly clean,
mostly a matter of commenting or uncommenting #defines. (Runtime
configuration support through an rc file is on the to do list.)
navmutt was written by me from scratch based on the API documentation,
so it should be free from any Netscape copyrights (unlike elm.c). I
have released navmutt under the LGPL.
/shameless plug
While I'm talking about navmutt, perhaps someone can help me out with
news URLs. My problem is that I'm not aware of any news readers which
allow you to specify starting nntp server and group on the command
line. The best idea I've come up with so far is to write a temporary
rc file, but I really, really don't like that solution so I haven't
attempted it yet. Any pointers in this area would be greatly
appreciated.
Also, if you would like to be notified when a new version of navmutt
comes out (so far about every 4-6 weeks or so) let me know and I'll
put you on my list.
Brian
Re: Mutt, GPG on Solaris
Mutt 0.95.6i (1999-06-03) gpg (GnuPG) 0.9.9a-snap1999-07-28 I think that version of mutt still expects gpgm, the features of which got rolled into gpg itself somewhere in the 0.9 sequence. Try making gpgm a symlink to gpg. Brian
Re: Filtering with maildir
On Sat, Jul 31, 1999 at 03:10:54PM +0700, m4v3r1ck wrote: I was hoping that the new procmail can direct mails to $HOME/Maildir (actually the file end up in $HOME/Maildir/new right?) in maildir format and re-direct all other mails specified by the procmail rules I've set up to $HOME/mail in mbox format. Unfortunately that version of procmail still tries to deliver mails to /var/spool/mail/$USER =( In your .procmailrc you need to set: DEFAULT=$HOME/Maildir/ The trailing slash is very important btw. It is how qmail and the patched procmail determine that you want messages in a qmail format. I've actually got that on two lines, and I can't remember why exactly: MAILDIR=$HOME DEFAULT=$MAILDIER/Maildir/ Either should probably work just fine for you. See the other response to your question for info on how to invoke procmail in your .qmail file. If you do this then you just need the entry in .qmail, and none of the others aliases are necessary. Brian PGP signature
Re: regexp highlighting
color body brightgreen black " [;=:]-*[)(|//\/]]" # :-) etc... ^^ I think that the added right square bracket probably needs to be escaped. Try this (untested): color body brightgreen black " [;=:]-*[)(|//\/\]]" # :-) etc... ^ Brian
Re: netscape and mutt (windows unix)...
On Sun, Apr 18, 1999 at 02:34:42PM -0700, Todd Strilchuk wrote: i have a related question about using mutt with netscape. currently i have a pc environment setup at work (windows nt) and have access to our unix box via exceed. is there any way to configure netscape (on my pc) to run a unix mail program (xterm +ls -e $HOME/bin/mutt) through exceed's xstart functionality? i always mount the unix box on the same drive letter at login so i should be able to hardcode the xstart program path (i.e. f:\xmail.xs). If you get the windows version of Netscape's third party mail and news API SDK (or whatever), you should be able to build in whatever command you want to invoke a mailer, including an xstart command, assuming xstart allows you to pass arguments. If xstart doesn't allow you to pass arguments then you are probably out of luck unless you want to get really creative. (I haven't used the windows version, I'm just assuming it works about the same as the unix version.) Most people who go looking for it (myself included) have found the SDK to be hard to track down, but I think if you start at developer.netscape.com you might stand a decent chance of finding it. I can't speak for the windows version, but I found with the unix version that their elm example had some trivial bugs that caused it to misbehave, so if you build everything and it doesn't seem to be working quite right, you may have to debug their code as well as your own. Brian
Re: netscape and mutt
On Thu, Mar 25, 1999 at 03:04:37PM +0100, Moritz Moeller-Herrmann wrote: Would you be able to provide an adapted version for mutt? I've packaged up my modifications to Netscape's files and posted(*) them on my web page: http://www.ugcs.caltech.edu/~brianw/email/ Check the READMEs. You may need to edit a few paths before compiling, but it is pretty straightforward and it should build cleanly under Linux. It works for me, but may not for you, YMMV... Brian (*) If anyone knows of any license provisions that I missed which prohibit redistribution of Netscape's example code or derivatives thereof, please let me know. I didn't find any, so I assume they don't care.
utf-7?
I'm getting e-mail from a friend encoded in character set UTF-7. (He is using Outlook Express.) I was able to find support for UTF-8 on my system (Linux/glibc), but nothing about UTF-7. I checked around some, and found where UTF-7 is defined by rfc2152, but haven't found anything about it as far as mutt or glibc are concerned. Is there are way to get mutt to decode these UTF-7 messages correctly? Brian
Re: replying to this list
On Wed, Feb 03, 1999 at 06:32:39AM -0500, David Thorburn-Gundlach wrote: Oh, wait a second... I guess I take that back; I tried to set "pgp_default_version" to "gpg" and when I selected "sign (a)s" from the pgp menu I got sh: gpg043m: command not found Can't open your secret key ring! Now, "gpg043" is the name of my gpg executable, but I don't know how I got the 'm' on the end. So, what do I need to do to use gpg? ;-) In a normal installation of gpg you will also have a gpgm executable. From the gpg man page: gpgm is a maintenance tool which has some commands gpgm does not have; it is there because it does not handle sensitive data ans therefore has no need to allocate secure memory. Apparently sign-as is something that wants (needs?) gpgm. Brian
Re: many questions
On Thu, Nov 18, 1999 at 05:43:31PM -0600, Dan Lipofsky wrote: On Thu, Nov 18, 1999 at 05:20:13PM -0600, David DeSimone wrote: I think it would be annoying if Mutt moved my cursor around while I'm trying to find a message, just because some new mail happened to arrive. Well, it could certainly be optional. Most of the time I am not in mutt, but doing other work. So I was wanting it to scroll the index for me so I could at just glance and see what the new mail was. Perhaps it should only do this when the index was already showing what was previously the last message, i.e. don't move it from message 1 to message 678. I've got to agree with David on this, I don't want mutt moving my cursor around automatically, ever. This sort of thing is what the next-new keybinding is for. (Usually bound to Tab I think.) Mutt already tells you when you have new mail, and even how many new messages you have. If you want you can even macro "TabEnter" so it automatically opens the message for you when it gets there, so it only takes one key. Besides providing very little benefit, making this automatic would add an incredible amount of unnecessary complexity. For example, how far is too far? One message away from the end? Five messages? "Make it an option." Ok...but wait, there's more. What about the people who aren't sorting primarily on date-received? For example, if someone sorts on thread first and a new message shows up as #207 out of 652 because that is where the thread it goes with is, how is mutt supposed to handle that one? It is the newest message, but nowhere near the end, and probably nowhere near where your current cursor is. To jump or not to jump? I could beat this example to death carrying it through two or three more steps, each of which shows a new problem which would need to be addressed, but hopefully you are getting the idea. Brian
