Re: send hooks again .. not working
At 15:18 +0200 12 Oct 2002, Sven Guckes [EMAIL PROTECTED] wrote: * David Champion [EMAIL PROTECTED] [2002-10-12 00:06]: I thought that you need to use set from= in send-hooks instead of using my_hdr, but I might misremember. No, it's the other way around. By the time send-hooks are applied to a message $from has already been fetched and it won't be looked at again for that message. my_hdr on the other hand can still override the From: header that mutt generates. yep - the From: as set by reverse_name feature will be overridden by all From: lines as set with my_hdr. 9yet another entry for the faq...) This is correct, except for the first word. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ [It is] best to confuse only one issue at a time. -- KR
Re: Bad Encoding?
At 17:54 -0400 30 Sep 2002, PeterKorman [EMAIL PROTECTED] wrote: My mutt viewer shows: N^X¬µìm\212Ç^Z¹^u¼¦ºÛÿ²ø\236ÁêÿZ^\ÿÿÿ_^Aô^M;^D@u^LPúì^N¶^WÝE The text/plain version of the message is specified as being sent base64 encoded, even though it actually isn't. So mutt and evolution will do base64 decoding on the actual text, resulting in garbage. The distribution was encoded by a Mozilla 4.76 mailer. There are 2 attachments. The second 1 was an html copy. Ximian Evolution reads it ok if the second attachment is present, but he garbles the text as well if I remove the html attachment. I guess Evolution just goes straight for the html rendering. Yes, the proper thing to do is to display the bottom-most alternative that can be displayed, so evolution just displays the html version which isn't broken. Maybe the iso-8859-1 is just encoded improperly. Or maybe I have my linux character set stuff set up wrong. This doesn't have anything to do with character sets or any setup issue. Any mailer that generates a message like this (even if the operator tries to do it) is severely broken. It's also possible that the message was generated correctly, but mangled in transit (the most likely place for this to occur would be the virus scanner shown in the Received: headers). --18B9A07BEB1DFD67A62F91F3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 This this text is garbled in my mutt viewer. Why? -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ When you're dealing with like crazy aggressors like Libya or Iran or Microsoft, you are talking about people who could do anything. -- Bill Maher
Re: looking for a better send-hook
At 16:55 -0500 25 Sep 2002, Eugene Lee [EMAIL PROTECTED] wrote: : * Eugene Lee [EMAIL PROTECTED] [2002-09-25 12:33]: : : The command send-hook '~h address' command : causes Mutt to generate an error h: not supported : in this mode that isn't documented anywhere. I'm looking at the header Received: and trying to find a match within send-hooks match against the message which was just started, and thus they don't have Received: headers. My parent match patch allows parts of send-hooks to match against the message to which you are replying, but at this time ~h isn't supported for send-hooks even when matching against the parent message. Changing this would require changes to mutt's internals that I haven't yet had time to do. It would also likely require that the patch be updated more frequently as other parts of mutt change. http://www.schrab.com/aaron/mutt/patch-1.3.24.ats.parent_match.1 I know message-hook supports ~h, but it only activates when I view the current message. And I don't want to remember to view a message to activate the hook. This wouldn't be a such problem with your standard message-hooks are also applied when you begin a reply, before send-hooks are applied. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ I dunno, I dream in Perl sometimes... --Larry Wall
Re: looking for a better send-hook
At 10:05 -0500 26 Sep 2002, Eugene Lee [EMAIL PROTECTED] wrote: I've tried this. Several times. The message-hook isn't applied when I select a message in index mode. It's applied only after I view the currently selected message and then reply to it. Of course message-hooks aren't applied when a message is simply selected in the index, but they are applied when you start a reply to a message even from the index. I tried it before sending my previous message, and it worked for me. I've now tried it with 1.4, just to make *sure* that this wasn't something that's been changed in the 1.5 development version, and it works for me there as well. Do you have a send-hook that's overriding the setting from the message-hook? -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ [It is] best to confuse only one issue at a time. -- KR
Re: pattern question
At 12:03 +0200 12 Sep 2002, René Clerc [EMAIL PROTECTED] wrote: is it possible to use patterns to specify a message that is directed to [EMAIL PROTECTED], but not to someone else and not cc'ed to someone else either? ^~C ^[EMAIL PROTECTED]$ The ^ modifier specifies that all addresses must match rather than succeeding if there's at least one match. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? -- Larry Wall
Re: QP/base64 issues
At 17:57 +0100 04 Sep 2002, Jonathan Perkin [EMAIL PROTECTED] wrote: Basically, I want mail sent with foreign chars such as £ å é etc to *not* be sent as QP or base64. Now, with % /usr/sbin/sendmail -t From: me To: you Subject: blah £ñ÷åòôùïéõ±²³´ . Here, not only are you missing the blank line between the headers and the body, you're also sending unlabeled 8bit data. it works *perfectly*. I get a nice clean mail, which hasn't been I wouldn't call something that violates the standards clean. Unfortunately, no matter how I configure mutt, I cannot seem to get it to behave. I believe the matter is due to the allow_8bit Mutt is behaving fine. My guess is that you have sendmail's EightBitMode option set to pass, which tells it to just pass unlabeled 8bit data through, even though this violates the standards. But when mutt sends 8bit data, it labels it as such with a header like: Content-Transfer-Encoding: 8bit So sendmail will always encode it into 7bit if the receiving smtp server doesn't announce that it will accept 8bit messages. There may be a way to configure sendmail to blindly send 8bit data, but I'm not going to do research on how to violate the standards for you. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ When we write programs that learn, it turns out we do and they don't.
Re: QP/base64 issues
At 16:00 +0100 05 Sep 2002, Jonathan Perkin [EMAIL PROTECTED] wrote: Incidentally, how do you set Content-Transfer-Encoding: 8bit? All my mails are either QP or base64. set allow_8bit will cause mutt to do that, except in some cases related to crytpographically signed messages. Whether or not the message arrives that way at the destination depends on the configuration of the various mail servers the message passes through on the way. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ There are two ways to write error-free programs; only the third one works.
Re: QP/base64 issues
At 21:05 -0700 04 Sep 2002, David Ellement [EMAIL PROTECTED] wrote: I noticed this in the headers to your message as received on my end: X-Mime-Autoconverted: from 8bit to quoted-printable by inet34.rd.bbc.co.uk So it seems your machine won't allow 8bit out, It's more likely that the machine it's sending to doesn't announce that 8bit messages are acceptable, so that machine encodes it as 7 bit. X-MIME-Autoconverted: from quoted-printable to 8bit by hpsdlfsa.sdd.hp.com while mine won't allow qp in. Here it's probably not so much that it doesn't allow it, but that it removes the encoding for the convenience of software that's too lame to handle a simple standard that is over 10 years old. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ The data for most coffee URIs contain no caffeine. -- RFC 2324
Re: threading question
At 15:03 -0400 30 Aug 2002, Ken Weingold [EMAIL PROTECTED] wrote: I find something odd about the threading tree. Imagine you have two messages one under the other in a thread three. In one set of those the child message is a direct reply to the parent. In the second set they are both replies to a message that is gone, so they are both tied together in a tree, but at the same level basically. The thread tree looks exactly the same for both sets. Does this make sense? If so, shouldn't the trees look a little different, as in the child of the parent that was a direct reply be indented slightly, or at least somehow differentiated? I'm not entirely convinced that I understand what you're saying, but does setting the hide_missing option help? -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ To err is human, to forgive, beyond the scope of the Operating System.
Re: threading question
At 15:28 -0500 30 Aug 2002, I wrote: I'm not entirely convinced that I understand what you're saying, but does setting the hide_missing option help? That should read unsetting the hide_missing option. The option is set by default. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ Avoid the Gates of Hell. Use Linux
Re: threading question
At 16:40 -0400 30 Aug 2002, Ken Weingold [EMAIL PROTECTED] wrote: On Fri, Aug 30, 2002, Aaron Schrab wrote: That should read unsetting the hide_missing option. The option is set by default. No, my comments have nothing to do with limiting. I'll draw out an The hide_missing option doesn't have anything to do with limiting either. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ He's not dead, he's electroencephalographically challenged.
Re: threading question
At 17:03 -0400 30 Aug 2002, Ken Weingold [EMAIL PROTECTED] wrote: On Fri, Aug 30, 2002, Aaron Schrab wrote: No, my comments have nothing to do with limiting. I'll draw out an The hide_missing option doesn't have anything to do with limiting either. Really? I didn't know what hide_missing was, so I looked in the manual and this is what it says: Yes, really. hide_missing Type: boolean Default: yes When set, mutt will not show the presence of messages that are hidden by limiting, in the thread tree. Documentation bug. The explanations for hide_missing and hide_limited are switched. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development. -- [EMAIL PROTECTED]
Re: overriding the charset for headers
At 21:23 +0300 27 Aug 2002, Baurjan Ismagulov [EMAIL PROTECTED] wrote: message, how can one have Mutt set To: and/or Cc: fields automatically (Mail-Followup-To: contains both sender and list addresses)? r and L set To: list only. Let me guess, you're trying this with a message you sent? You can fix this with: set metoo reply_self -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ live fast, die young, leave a big core file... -- Ben Low in 7rk70e$j3i$[EMAIL PROTECTED]
Re: send-hook and subject
At 16:39 -0300 20 Aug 2002, Fernan Aguero [EMAIL PROTECTED] wrote: Is it possible to use a send hook to set the subject? No. To quote the manual: ] Note: the send-hook's are only executed ONCE after getting the initial ] list of recipients. Adding a recipient after replying or editing the ] message will NOT cause any send-hook to be executed. Also note that ] my_hdr commands which modify recipient headers, or the message's ] subject, don't have any effect on the current message when executed ] from a send-hook. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ Besides, including std_ice_cubes.h is a fatal error on machines that don't have it yet. Bad language design, there... :-)--Larry Wall
Re: [RFE] Pattern to apply to the parent message
At 16:24 +0200 01 Aug 2002, Vincent Lefevre [EMAIL PROTECTED] wrote: I'd like to be able to apply a pattern on a parent message. For instance, if we define ~^ to do that, then ~^~P will match any message that is a reply of one of my messages (note: they are in the same mailbox). http://www.schrab.com/aaron/mutt/patch-1.3.24.ats.parent_match.1 Finding replies to your own messages is even what I use for the example. Although the patch was originally done against 1.3.24, it works fine with 1.4 and the current CVS. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ You must realize that the computer has it in for you. The irrefutable proof of this is that the computer always does what you tell it to do.
Re: Mutt 1.3.28 internal pager, Screen 3.09.11: right-padded spaces
At 21:04 -0700 10 Jul 2002, Rick Moen [EMAIL PROTECTED] wrote: :r! ls -l .terminfo/s/ total 0 lrwxrwxrwx1 rick rick 37 Jul 10 17:13 screen - ../../usr/share/terminfo/s/screen-bce At 17:41 -0700 11 Jul 2002, Rick Moen [EMAIL PROTECTED] wrote: [rick@uncle-enzo] ~ $ infocmp # Reconstructed via infocmp from file: /etc/terminfo/s/screen It looks like your symlink isn't being used for some reason, is going up two directory levels enough? So you're getting the normal terminfo entry for screen, rather than the one that advertises bce support. Perhaps you should try it out with TERM=screen-bce. Using the bce support in the debian screen packages (along with TERM=screen-bce) has indeed fixed this problem for me. The main difference would be that I'm using a mutt that I built rather than the debian package. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ ...if you are lifeform that is not based on chemistry, I apologize in advance. -- Larry Wall http://www.perl.com/pub/1999/08/onion/talk1.html
Re: bouncing w/ mutt-1.3.28i
At 13:30 +0200 11 Jul 2002, Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Jul 10, 2002 at 01:54:33PM -0500, Aaron Schrab wrote: Not that I recall. It's always pretty much just resubmitted the message as is, but with new envelope recipients. Shouldn't it add a Resend-To: header? It does, along with various other Resent- headers. My main point was that the bounce command hasn't really changed, and that (for the most part) it doesn't alter the message. The addition of a few headers is outside the scope of what I was commenting on. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ If you consistently take an antagonistic approach, however, people are going to start thinking you're from New York. :-) --Larry Wall to Dan Bernstein
Re: bouncing w/ mutt-1.3.28i
At 17:19 +0200 10 Jul 2002, Dominik Vogt [EMAIL PROTECTED] wrote: Problem: With said mutt release I can't bounce messages anymore. Actually, the message *is* bounced, but unlike earlier releases, it leaves both, the From: and Cc: headers untouched. So, if I That's how it's always worked, at least for as long as I've been using mutt (since somewhere around 0.42). Check out the resend-message command (bound to Esce by default). But that's not the only problem you're having with spam filters. One of the mail servers handling your outgoing mail appears to have gotten itself blacklisted: SPAM: Start SpamAssassin results -- SPAM: This mail is probably spam. The original message has been altered SPAM: so you can recognise or block similar unwanted mail in future. SPAM: See http://spamassassin.org/tag/ for more details. SPAM: SPAM: Content analysis details: (5 hits, 5 required) SPAM: Hit! (2.0 points) Received via a relay in relays.osirusoft.com SPAM:[RBL check: found 148.224.20.195.relays.osirusoft.com., type: 127.0.0.4] SPAM: Hit! (3.0 points) DNSBL: sender is Confirmed Spam Source SPAM: SPAM: End of SpamAssassin results - See http://relays.osirusoft.com/cgi-bin/rbcheck.cgi?addr=195.20.224.148 -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ [Samba] enables open-source fans to stealth their Linux boxes so they look like Microsoft servers that somehow miraculously fail to suck. -- Eric S. Raymond
Re: Set from shows no affect
At 08:42 -0400 11 Jun 2002, darren chamberlain [EMAIL PROTECTED] wrote: send-hook gets executed when you send the message, not when you start a message. Thus, you see the results for the next message. No, send-hooks get executed before a message is composed, but only after mutt has generated it's own From: header based on $from and possibly $reverse_name. This can be replaced using my_hdr From:, as has already been noted. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ [Samba] enables open-source fans to stealth their Linux boxes so they look like Microsoft servers that somehow miraculously fail to suck. -- Eric S. Raymond
Re: IMAP uses SSL even when not requested
At 23:25 -0700 03 Jun 2002, Jeremy Lin [EMAIL PROTECTED] wrote: I'm connecting to a server that supports both imap and imaps, and even though I'm setting mutt to connect via imap, it asks me about the certificate and then seems to connect with SSL anyway. Is this a feature, or is something mixed up on my end? If it's a feature, I don't think it's a good one. This is a feature, and I suspect that you'd be in a minority for thinking that having security is a bad thing. Also, this feature is needed for connecting securely to servers that don't accept connections on the imaps port, but instead support the STARTTLS extension on the normal imap port. You can likely disable this feature with set ssl_starttls=no. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ ... who knows how many AI projects are reading slashdot these days? -- Larry Wall http://www.perl.com/pub/1999/08/onion/talk1.html
Re: reply-to problem - check $reply-to!
At 19:49 -0300 16 May 2002, Eduardo Gargiulo [EMAIL PROTECTED] wrote: Return-Path: Delivered-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] and when I hit 'r' mutt shows To: [EMAIL PROTECTED] I have verified (thanks Sven) that reply_to=ask-yes and 'r' is reply to a message key binding (default). This behaviour is not for all messages. How can I fix this? Try unset reply_self. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ It is easier to write an incorrect program than understand a correct one.
Re: reply-to problem - check $reply-to!
At 12:32 -0500 16 May 2002, I wrote: At 19:49 -0300 16 May 2002, Eduardo Gargiulo [EMAIL PROTECTED] wrote: Return-Path: Delivered-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] and when I hit 'r' mutt shows To: [EMAIL PROTECTED] I have verified (thanks Sven) that reply_to=ask-yes and 'r' is reply to a message key binding (default). This behaviour is not for all messages. How can I fix this? Try unset reply_self. Ack! That should be set reply_self. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development. -- [EMAIL PROTECTED]
Re: PGP signature verification
At 21:15 +0200 14 Apr 2002, Alain Bench [EMAIL PROTECTED] wrote:
But in other cases, he has not done it. In the last 3 mails (the
first mail is not QP encoded, so it's normal) some dots *not* beginning
a line were rejected at beginning of next one, because of QP soft
cutting long lines... And Mutt didn't notice it should have encoded it.
I guess it's a bug. Or an only half working feature... ;-)
Yeah, I'd say it's a bug. The attached patch fixes it.
or even better in this case, but difficult to generalize, it could
have decided to insert it's line cut one char before:
| % For many people that would be tricky but fortunately for you it's just =
| l.
I haven't done that for my patch, although it wouldn't be all that
difficult to do it would require some larger changes to the relevant
code. I don't think it's worth it just to save a couple bytes in a
situation that should be fairly uncommon.
--
Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/
I dunno, I dream in Perl sometimes... --Larry Wall
--- sendlib.c.dist Sun Apr 14 17:24:22 2002
+++ sendlib.c Sun Apr 14 17:25:20 2002
@@ -185,8 +185,16 @@
line[linelen] = 0;
fputs (line, fout);
fputc ('\n', fout);
-line[0] = savechar;
-linelen = 1;
+ if (savechar == '.')
+ {
+ strfcpy (line, =2E, sizeof (line));
+ linelen = 3;
+ }
+ else
+ {
+ line[0] = savechar;
+ linelen = 1;
+ }
}
}
msg27164/pgp0.pgp
Description: PGP signature
Re: NFS problems
At 02:20 +0200 13 Apr 2002, Rocco Rutte [EMAIL PROTECTED] wrote:
The situation so far is that sending mail doesn't work because mutt
does not show up again after returning from the editor (saving works).
I've done that. Using 'strace' just give me:
[...]
stat(/tmp/mutt-ganymed-9155-1, {st_mode=S_IFREG|0600, st_size=115, ...}) = 0
open(/tmp/mutt-ganymed-9155-1, O_RDWR) = 4
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x2aad2000
unlink(/tmp/mutt-ganymed-9155-1) = 0
write(4, \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0..., 2047) = 2047
The last line is printed about 50.000 times within a couple of
seconds. Before this exerpt, to me it seems that the editor
command was sucessful (mutt reports that the child has quit).
Could someone explain/interpret the last line? I have
absolutely no idea what this could be and how to solve it.
Mutt is trying to overwrite the temporary file to provide some
protection against someone trying to recover the private data. But in
your case it is looping over that. This is happening in the mutt_unlink
function in lib.c:
while (sb.st_size 0)
{
fwrite (buf, 1, sizeof (buf), f);
sb.st_size -= sizeof (buf);
}
I don't know why this would happen with glibc, but with dietlibc the
st_size element of struct stat is unsigned, so unless it hits 0 exactly
the test will always succeed.
I think the attached patch should fix this problem.
--
Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/
When we write programs that learn, it turns out we do and they don't.
--- lib.c.dist Sat Apr 13 11:39:40 2002
+++ lib.c Sat Apr 13 11:46:51 2002
@@ -184,6 +184,8 @@
while (sb.st_size 0)
{
fwrite (buf, 1, sizeof (buf), f);
+ if (sb.st_size sizeof (buf))
+ break;
sb.st_size -= sizeof (buf);
}
fclose (f);
Re: NFS problems
At 20:48 +0200 13 Apr 2002, Rocco Rutte [EMAIL PROTECTED] wrote: * Aaron Schrab [04/13/02 19:31:32 CEST] wrote: I think the attached patch should fix this problem. Yes it does. Thanks! Where to send the money to? ;-) Cool. I have a paypal account under the address in my .sig. :) Since my $tmpdir is ~/tmp with drwx--, are there any security issues when working with this patch? The patch shouldn't affect security in any way. Temporary files are still overwritten, I just added a test for when the entire file has been overwritten that will work properly on systems where the size returned by the stat system call is unsigned. So it should work exactly like before except without the infinite loop. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ Disraeli was pretty close: actually, there are Lies, Damn lies, Statistics, Benchmarks, and Delivery dates.
Re: Tag or delete by date or age - pattern ~d
At 23:51 +0100 27 Mar 2002, Sven Guckes [EMAIL PROTECTED] wrote: * Charles Gagnon [EMAIL PROTECTED] [2002-03-27 20:07]: or even tag/delete everything older than number of days, whatever is easier. this is not included - sorry. Wrong. T~d5d will tag all messages older than 5 days. w(eek), m(onth), and y(ear) can also be used in place of the second d. See the section on Searching by Date (4.2.3 in my copy), especially the Relative subsection for more info. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ ...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh
Re: Tag or delete by date or age - pattern ~d
At 00:18 +0100 28 Mar 2002, Sven Guckes [EMAIL PROTECTED] wrote: * Aaron Schrab [EMAIL PROTECTED] [2002-03-27 23:14]: At 23:51 +0100 27 Mar 2002, Sven Guckes [EMAIL PROTECTED] wrote: * Charles Gagnon [EMAIL PROTECTED] [2002-03-27 20:07]: or even tag/delete everything older than number of days, whatever is easier. this is not included - sorry. Wrong. T~d5d will tag all messages older than 5 days. yes - but this is only relative to the *current* date. I understood that in the context of the given question Older than x days, to me means relative to the current day, no ambiguity at all in my mind. this date shall be relative to a given day - no? Mutt supports that as well. See the bit about Error margins, right before the bit about relative dates. -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ /earth is 98% full ... please delete anyone you can.
Re: Converting mbox to Maildir
At 13:08 -0500 20 Mar 2002, David T-G [EMAIL PROTECTED] wrote: There are also MMDF and MH folders, and they are of the one-file-per variety but don't have the tmp, new, and cur subdirs of Maildir. True for MH, but not MMDF. MMDF has all the messages in one file, like mbox, but uses \001\001\001\001\n as the separator rather than ^From_ . -- Aaron Schrab [EMAIL PROTECTED] http://www.schrab.com/aaron/ What kind of head of security would I be if I let people like me know things that I'm not supposed to know?-- Garibaldi
Re: mailbox notification
At 20:38 -0500 06 Mar 2002, Michael P. Soulier [EMAIL PROTECTED] wrote: So I'm making use of the compressed folders patch now, but it seems that Mutt is no longer telling me when new mail arrives in my gzipped folders. Is there a way to enable this again? I rely on it quite a bit. You should not have mail delivered to compressed folders. If you do so, you are almost sure to lose mail eventually. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ In general, if you think something isn't in Perl, try it out, because it usually is. :-)--Larry Wall
Re: mailbox notification
At 23:01 -0500 06 Mar 2002, Michael P. Soulier [EMAIL PROTECTED] wrote: On 06/03/02 Aaron Schrab did speaketh: You should not have mail delivered to compressed folders. If you do so, you are almost sure to lose mail eventually. I don't understand why it's any different than standard procmail delivery. Procmail should still synchronize via a lockfile, yes? Please explain. Even with the compressed folder patch, mutt can't really deal with compressed folders. The patch simply tells mutt how to uncomress a mailbox into a temporary file and (if necessary) recompress it when done. If mutt needs to write back any changes that you have made to the temporary file it will blow away any new messages that have been written to it. Even if mutt would put a lock on it for the whole time you're using the compressed folder, after about 15 minutes procmail would consider the lock to be stale and remove it. Locking a mail file is not appropriate to cover this type of situation, it should only be done while a program is actively using the mailfile. The only other alternative would be for mutt to detect that the compressed version of the mailbox had changed and give you the opportunity to either save the uncompressed version or lose any changes that you had to that and just go with the compressed version. The compressed folders patch is really only intended to be used on archival mailboxes. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ ...if you are lifeform that is not based on chemistry, I apologize in advance. -- Larry Wall http://www.perl.com/pub/1999/08/onion/talk1.html
Re: My Mutt Won't Bark
At 21:26 -0800 02 Mar 2002, Jerry Van Brimmer [EMAIL PROTECTED] wrote: Mutt newbie here, starting to be a frustrated Mutt newbie. The docs say that Mutt should work out-of -the-box. Well, mine don't. I installed the one off of the SuSe DVD, which doesn't create me a .muttrc file. So, I went to the Mutt home page, then to the muttrc file generator page and got my initial muttrc file. I have entered my personal data into the file. But, I cannot get mutt to read my mail. In my home directory I have: /home/jerry/Mail /home/jerry/Mail/inbox /home/jerry/Mail/suse-linux Try adding the following to your .muttrc file: set spoolfile=~/Mail/inbox mailboxes ! +suse-linux -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ ...this does not mean that some of us should not want, in a rather dispassionate sort of way, to put a bullet through csh's head. -- Larry Wall
Re: quote_regexp occasionally ignored
At 22:02 -0500 28 Feb 2002, Andrew Pimlott [EMAIL PROTECTED] wrote:
I have quote_regexp set in my .muttrc:
set quote_regexp=^[[:blank:]]*([[:alnum:]]{0,10}|[]|:}#);+]|- )
This should match (among other things) any line with a leading .
The attached message has several such lines, but none of them appear
highlighted when I view the message. Also, the toggle-quoted and
skip-quoted commands don't work on this message. However if I
search (/) for that regexp, the leading s are found, as
expected.
Content-Type: text/plain; charset=us-ascii; format=flowed
quote_regexp is ignored for format=flowed messages since RFC 2646, which
describes that format, mandates that only characters at the very
beginning of a line are to be considered quote characters. In the
message you attached, the lines that mutt displayed as starting with a
actually started with , the sending mailer space-stuffed those
lines to indicate that they shouldn't be treated as quoted.
In other words it's a (common) bug in the program that sent the message,
mutt is correctly following the format=flowed standard.
You could possibly work around this with a procmail rule:
:0
* ^Content-type:[ ]*text/plain[ ]*;.*format=flowed
* -5^0
* 1^1 B ?? ^ +
{
CT=`formail -zcxContent-type: | sed -e 's/;[ ]*format=flowed//'`
:0fhw
| formail -IContent-type: $CT
}
That will remove the claim of RFC 2646 compliance for any message that
has more than 5 lines that start with some spaces followed by a .
This should work OK, since format=flowed was designed to degrade
gracefully.
--
Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/
When we write programs that learn, it turns out we do and they don't.
Re: locale for Sun
At 14:15 -0800 20 Feb 2002, Mun Johl [EMAIL PROTECTED] wrote: I tried another test and fired up mutt in dtterm instead of rxvt. dtterm displayed the umlauts correctly, so I don't understand why the characters get messed up in rxvt when I use the same locale settings. Sounds like rxvt is using a font for a different character set than that specified by your locale settings. BTW, here's the complete locale settings used in this experiment (but LANG takes precedence, right?): No, LANG is given the least precedence, but that shouldn't matter here. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ [Samba] enables open-source fans to stealth their Linux boxes so they look like Microsoft servers that somehow miraculously fail to suck. -- Eric S. Raymond
Re: incorrect date for attribution
At 11:48 +0100 12 Feb 2002, Stefan Alfredsson [EMAIL PROTECTED] wrote:
As my attribution string, I have a simple
set attribution=Quoting %n %a [%(%d %b-%y %H:%M)]:
However, the date and time seems to be taken from the mbox From
(no, not From:) header, instead of the Date: header field.
This is documented behaviour. The section of the manual on $index_format
(6.3.79), to which the documentation for the $attribution setting refers says
in part:
%(fmt)
the local date and time when the message was received.
See the documentation for %{fmt} and %[fmt] in the same section.
--
Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/
Been there, done that, didnt like it threw it out -- Alan Cox
Re: killing dupes
At 15:00 -0500 22 Jan 2002, cruciatuz [EMAIL PROTECTED] wrote: i fetched my mail and in the meanwhile my computer crashed during a hd-error. now i fetched again and i got many dupes (in the mbox-file). mutt is intelligent as usual and shows me the dupes with = in the threads, but: is there an integrated function for cleaning the mbox-file? Not in 1.3.24, but with 1.3.26 or above you could use the new ~= pattern to match the duplicates and delete them. Assuming you have delete-pattern bound to D (the default): D~= -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ As a computer, I find your faith in technology amusing.
Re: rejected mail
At 03:20 -0800 18 Jan 2002, Todd Kokoszka [EMAIL PROTECTED] wrote: ... while talking to mail-exchange.domino.iht.com.: MAIL From:[EMAIL PROTECTED] SIZE=392 554 Mail from [EMAIL PROTECTED] rejected for policy reasons. At 01:39 + 19 Jan 2002, Prahlad Vaidyanathan [EMAIL PROTECTED] wrote: On Fri, 18 Jan 2002 Todd Kokoszka spewed into the ether: [-- snip --] The original message was received at Fri, 18 Jan 2002 12:22:22 +0100 from kokoszka@localhost ^ Maybe that is the reason. No, that's just his local MTA listing where it got the message from. There's likely no way to change the value there, since it would likely always use the login name of the invoking user, and localhost since it's getting the message from a pipe rather than via SMTP. This value would not be passed to the recipient's mail server in anyway. Actually, it might be sent in a Received: header, but the message is rejected before the local MTA has a chance to send any of the headers. Try setting 'envelope_from' in your muttrc. The envelope from is already being set fine (at least it's not obiously wrong, and is in a domain that exists). See the MAIL From: line quoted in the original message. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The data for most coffee URIs contain no caffeine. -- RFC 2324
Patch dependent configuration
My usual mutt config contains uses some features that are only found in
patched versions of mutt. Attempting to use them with a mutt that
doesn't have the relevant patches can have results varying from ugly to
potentially destructive. In spite of this, I occasionally want to test
things out with an unpatched mutt, so I came up with this scheme of
having my mutt config vary based on what patches have been applied to
the current mutt.
In my .muttrc I have this line:
source dynamic_muttrc |
And here's my dynamic_muttrc script:
#!/bin/sh
MUTT=/proc/${PPID}/exe
if $MUTT -F /dev/null -v | grep date_optional /dev/null 21
then
echo 'set index_format=%4C %Z %?[?%[%H:%M]%[%m/%d]? %-15.15L (%5l) %s'
else
echo 'set index_format=%4C %Z %[%m/%d] %-15.15L (%5l) %s'
fi
if $MUTT -F /dev/null -v | grep mark_old /dev/null 21
then
echo 'set see_old'
else
echo 'set mark_old read_only'
fi
The exact implementation (running mutt from /proc) is pretty much
specific to Linux, but other OSes may provide a different way to find
the copy of mutt that's currently reading the config; lsof may be useful
for this. One nice thing about this method is that it seems to work
even if the currently running mutt was deleted after being started,
which may be useful if bits of the config are sourced long after
starting (possibly from some kind of hook or macro).
--
Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/
Standards are crucial. And the best thing about standards is:
there are so _many_ to choose from!
Re: message-hook
At 14:31 -0800 14 Jan 2002, Will Yardley [EMAIL PROTECTED] wrote: i'd like to use some message hooks to deal with setting / unsetting p_c_t when replying to messages but i'd like to set a default send-hook for composing new messages regardless of the message-hook. any suggestions? i'm doing stuff like this: message-hook. 'set pgp_create_traditional' message-hook'~h ^X-Mailer: Microsoft Outlook Express' 'set pgp_create_traditional' message-hook'~h User-Agent: Mutt' 'unset pgp_create_traditional' i've tried putting: send-hook . 'set pgp_create_traditional' both before and after these hooks, but that doesn't seem to be working. Regardless of the order in which the hooks are defined, a send-hook will always be executed after any message-hooks. There's not really a way to change this. But, this would be a situation where my parent_match patch could help. It would allow you to convert the message-hooks into send-hooks, and you could then get them to execute in the correct order. http://pug.schrab.com/aaron/mutt/ -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Been there, done that, didnt like it threw it out -- Alan Cox
Re: Color mails which are a reply to a mail from me?
[ I've moved quoted text around, so that it's in the correct place. ] At 20:39 +0800 12 Jan 2002, Charles Jie [EMAIL PROTECTED] wrote: On Sat, Jan 05, 2002 at 06:25:05PM -0600, Aaron Schrab wrote: color index red default ~b ^^ Would you please tell me what's the default pattern if you don't specify one as in your example? (I can not identify from the manual.) There isn't a default pattern. I'd meant to put a place holder there, but forgot to do so. As it is that pattern is broken. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ A debugged program is one for which you have not yet found the conditions that make it fail. -- Jerry Ogdin
Re: Patch trouble
At 09:00 +0100 11 Jan 2002, Nick Wilson [EMAIL PROTECTED] wrote: can anyone make sense of the output I'm getting when trying to use the %_patch? can't find file to patch at input line 4 Perhaps you should have used the -p or --strip option? The above line is patch itself telling you what the problem is. You need to use an appropriate -p option. This option tells it how many levels of directory names to strip from the front of file names in patch files. By default it will strip all directories, and just look for the named file in the current directory. The text leading up to this was: -- |diff -durp mutt-1.3.22.1/doc/manual.sgml mutt-1.3.22.1.oe.%_.1/doc/manual.sgml |--- mutt-1.3.22.1/doc/manual.sgmlWed Sep 5 02:52:17 2001 |+++ mutt-1.3.22.1.oe.%_.1/doc/manual.sgmlWed Sep 5 03:01:26 2001 Here with no -p option, patch would try to change the file named manual.sgml in the current directory. With -p1 it would strip off only the top level directory, and so look for a file named doc/manual.sgml to change; this is likely what you want. If you used -p0, patch would look for the file to change using either of the complete names mentioned above, including the mutt-* part. As a general rule of thumb, you should always run patch from inside the top level directory of the source tree for the program you're patching. If the patch file contains file names that mention what looks like the distribution directory (in this case stuff like mutt-version or possibly just mutt by itself), you should use -p1. Otherwise you probably want to use -p0 (although in these cases you can often get away without using a -p option at all). -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Let's say the docs present a simplified view of reality...:-) --Larry Wall
Re: individual index_formats
At 17:04 -0600 10 Jan 2002, I wrote: http://schrab.com/aaron/mutt/patch-1.3.24.ats.date_optional.1 Unfortunately, that URL won't work for anybody but me. The correct one is: http://pug.schrab.com/aaron/mutt/patch-1.3.24.ats.date_optional.1 -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The only disadvantage I see is that it would force everyone to get Perl. Horrors. :-)--Larry Wall
Re: individual index_formats
At 10:34 +0100 10 Jan 2002, Hanspeter Roth [EMAIL PROTECTED] wrote: Is it possible to have lines with different index_formats in the index? I would like to display a different date format for messages sent within the last 24 hours. I have a patch that does almost that: http://schrab.com/aaron/mutt/patch-1.3.24.ats.date_optional.1 That should apply to pretty much any version of mutt, since it was originally done when 0.96.6 was current. I just recently updated it to use the PATCHES file found in recent development versions. With it %?[ and %?( in index_format are treated as conditionals, if the relevant time is less than 12 hours in the past or future, the part before the next will be evaluated, otherwise the part between that and the next ? is evaluated. So, I use as my index_format: set index_format='%4C %Z %?[?%[%H:%M]%[%m/%d]? %-15.15F (%5l) %s' It would be quite simple to modify it for different periods of time. I'll also note that that index_format looks *extremely* bad with an unpatched mutt. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ It is easier to port a shell than a shell script. --Larry Wall msg22865/pgp0.pgp Description: PGP signature
Re: New vs. Deleted flags
At 03:01 -0500 07 Jan 2002, Ken Weingold [EMAIL PROTECTED] wrote: On Mon, Jan 7, 2002, Aaron Schrab wrote: It would probably be a better idea to have the macro turn off $resolve at the beginning then turn it back on before doing the actual deletion. True. How do I do this, then? I have tried to few things, but nothing seems to work correctly. Untested but based on some macros I use: macro index d enter-commandunset resolve\nclear-flagNenter-commandset resolve\ndelete-message -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ It is easier to write an incorrect program than understand a correct one. msg22429/pgp0.pgp Description: PGP signature
Re: how make From: header dependent on recipient?
At 05:50 + 07 Jan 2002, Tom Jones [EMAIL PROTECTED] wrote: The trouble is that send-hook can only look at the message that's about to be sent, not its parent. After a web trawl, it looks like the patch described in the second half of this mail http://www.ultraviolet.org/mail-archives/mutt-users.2001/2406.html may be what I'm after. I'll give it a go soon. It should be possible to do what you seem to want. But I noticed that you're still using mutt 1.2.5, if you're planning to stick with that version, the patch may not work. Then again it might, since there weren't too many changes to the relevant parts of code between that and version 1.3.23.1. If you were planning to upgrade to a recent development release, there's an updated version of that patch available from: http://schrab.com/aaron/mutt/ -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ I don't think anything makes my show look good. -- Jerry Springer msg22518/pgp0.pgp Description: PGP signature
Re: Color mails which are a reply to a mail from me?
At 20:34 -0500 05 Jan 2002, parv [EMAIL PROTECTED] wrote: in message [EMAIL PROTECTED], wrote Aaron Schrab thusly... color index red default %~P aaron, i have been using similar syntax for the same purpose since mutt v1.2.something (less than 1.2.4 for sure) created from freebsd ports, now on v1.3.25i, w/o any problems. syntax is... color index red default ~P ^- notice the missing '%' ...so how does the patch figure in? It adds support for the % modifier, which causes the rest of the match operator to match against the parent of the message (the message that it was in reply to), rather than the message itself. So while ~P matches messages that you wrote yourself, %~P matches messages that are replies to messages that you wrote. Although that would only work if your message was in the same mailbox. i didn't understand the above statement. when you say message(s) in the same mailbox, what do you mean by it? Since mutt doesn't keep information about messages not in the current mailbox, the parent of a message needs to be in the current mailbox in order to match against it. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ In general, if you think something isn't in Perl, try it out, because it usually is. :-)--Larry Wall msg22375/pgp0.pgp Description: PGP signature
Re: New vs. Deleted flags
At 02:15 -0500 07 Jan 2002, Ken Weingold [EMAIL PROTECTED] wrote: macro index d clear-flagNprevious-undeleteddelete-message delete the current entry That won't work properly on the last message in a mailbox. since I have $resolve set to yes. :) It would probably be a better idea to have the macro turn off $resolve at the beginning then turn it back on before doing the actual deletion. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ A list is only as strong as its weakest link. -- Don Knuth msg22423/pgp0.pgp Description: PGP signature
Re: New vs. Deleted flags
At 00:47 -0700 07 Jan 2002, Rob 'Feztaa' Park [EMAIL PROTECTED] wrote: Alas! Ken Weingold spake thus: macro index d clear-flagNprevious-undeleteddelete-message delete the current entry Wouldn't these set read messages to new if you try to delete a message that isn't new? ;) No, clear-flag does exactly that, it clears flags. It should be pretty easy to check this out, since by default clear-flag is bound to W in the index. Now, toggle-new... -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Beware of the Turing Tar-pit in which everything is possible but nothing of interest is easy. msg22426/pgp0.pgp Description: PGP signature
Re: Send-hook is Lazy
At 11:33 +0100 05 Jan 2002, Franco Vite [EMAIL PROTECTED] wrote: But: if I want to put the right signature when I replay (epmovi with .signature.epmovi, default From with .signature and so on [I've many accounts...]), how I can do? You can have send-hooks that match on the address that the message will appear to be from: send-hook . set signature=~/.signature send-hook '~f epmovi' 'set signature=~/.signature.epmovi' The second of those should be after any send-hooks that set the From: address. Also, if you like, you should be able to remove the setting of the signature from the two send-hooks you posted earlier since this should handle that case as well. It's not necessary, but it's a bit cleaner to have that set in only one place. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Everyone can be taught to sculpt: Michelangelo would have had to be taught how _not_ to. So it is with the great programmers.
Re: Color mails which are a reply to a mail from me?
At 23:47 +0100 05 Jan 2002, Gerhard Siegesmund [EMAIL PROTECTED] wrote: I don't know if it is at all possible, but I loved this feature with crosspoint (in the old times of fido-net). Is it possible to color (in the index) a mail which is a reply to a mail from me? So that I can see very fast if someone answered me in a list? (Hope this is not a FAQ). There are a few things that might work. - Searching the body was already mentioned in another message. color index red default ~b - You may also be able to do it based on Message-IDs mentioned in the Referecnes header, if there's a pattern that would match only Message-IDs from your messages. It looks like @gerhard.zuhause.de may work for this: color index red default ~x @gerhard.zuhause.de - The third option that I can think of involves a patch that I wrote: http://schrab.com/aaron/mutt/patch-1.3.24.ats.parent_match.1 This would allow you to do color index red default %~P Although that would only work if your message was in the same mailbox. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Real programmers don't comment their code. It was hard to write, it should be hard to understand. msg22363/pgp0.pgp Description: PGP signature
Re: Send-hook is Lazy
At 15:19 +0100 04 Jan 2002, Franco Vite [EMAIL PROTECTED] wrote: send-hook . \ my_hdr From: Franco Vite [EMAIL PROTECTED] send-hook [EMAIL PROTECTED] \ 'my_hdr From: Franco Vite [EMAIL PROTECTED]; \ set signature=~/.signature.epmovi I've a question: it work fine, but if someone post a mail to epmovi (my secondary address), when I replay work the default my_hdr. How I can to automaticaly replay with epmovi (out of an ML scenario)? First, you'll need to change that default (first) send-hook to remove any previously applied From: header. You can instead use the $from variable to set your default address: send-hook . unmy_hdr From set from=Franco Vite [EMAIL PROTECTED] Then if you tell mutt what adresses belong to you (with an appropriate regexp for $alternates) and set $reverse_name, mutt will automatically use the address to which a message was sent when you do a reply: set alternates='(franco@firenze\.linux\.it|epmovi@tin\.it)' set reverse_name -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying.
Re: unable to post to AOL
At 15:41 -0700 30 Oct 2001, Rob 'Feztaa' Park [EMAIL PROTECTED] wrote: Is that what mail would look like with it off? I guess the reason I don't have this problem has more to do with my mutt config than with my postfix config! I had my_hdr's setting the From: and Reply-To: headers, which would avoid that envelope_from problem altogether. No, it wouldn't. When $envelope_from is not set (the default), using my_hdr From: will only set the From: header. Same for the $from setting. The contents of the Reply-To: header are totally irrelevant. The address that AOL and many other places check is the envelope sender. This is often placed in the the From (note the space) line of mbox folders, or possibly a Return-Path: header. If $envelope_from is set, mutt will attempt to use whatever address is in the From: header for this as well. If $envelope_from is not set, mutt relies on your MTA to choose the envelope sender address by itself. The intended use for $envelope_from is to allow people to fully vary the address that they use, especially for posting to mailing lists that check if the envelope sender is a subscriber. Working around broken MTA configs is only a somewhat nice side benefit. But, even with this it's still a good idea to fix the MTA config, since there may be other programs on your system that send mail. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ To err is human, to forgive, beyond the scope of the Operating System.
Re: Console mail notifiers/displayers
At 23:19 -0500 25 Oct 2001, I wrote: That's pretty much how I use it as well. I've patched mutt so that the functionality of the standard versions $mark_old is split into two variables: The patch (and a couple others I've done) is available from my (currently *very* minimal) mutt page: http://pug.schrab.com/aaron/mutt/ Current version up there was originally against 1.3.8, but it should apply cleanly up to 1.3.23. There's a minor issue applying against the current CVS version, but it's pretty easy to fix. I'll probably put a new version up sometime over the weekend. Got it put up there just before my deadline. :) Of course, I haven't done extensive testing of it in a while; I just While I was at it, I also did some testing. Everything I tried still worked properly. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ If you want to travel around the world and be invited to speak at a lot of different places, just write a Unix operating system. -- Linus Torvalds
Re: Console mail notifiers/displayers
At 18:28 -0500 25 Oct 2001, David Champion [EMAIL PROTECTED] wrote: Except when it's synonymous with oh, heck, I don't want to deal with this now. That's when I want something to be old instead of new or read, and to stay old between instances of mutt -- but for unread messages to stay unread, without becoming old. That's pretty much how I use it as well. I've patched mutt so that the functionality of the standard versions $mark_old is split into two variables: - $mark_old, controls if new messages are automatically marked as old when you leave a folder. Also, this is now a quad-option (this part was actually done by somebody else, though I'd have to look to remember who). - $see_old, determines whether or not messages that are marked as old should actually be displayed as such. It's even done in such a way that changing the value of $see_old will take effect immediately, not just when messages are being parsed. The patch (and a couple others I've done) is available from my (currently *very* minimal) mutt page: http://pug.schrab.com/aaron/mutt/ Current version up there was originally against 1.3.8, but it should apply cleanly up to 1.3.23. There's a minor issue applying against the current CVS version, but it's pretty easy to fix. I'll probably put a new version up sometime over the weekend. Of course, I haven't done extensive testing of it in a while; I just know that it works for me with set mark_old=no see_old=yes -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ What kind of head of security would I be if I let people like me know things that I'm not supposed to know?-- Garibaldi
Re: message status (was Re: a timeout before N is gone)
At 23:05 -0400 30 Sep 2001, Derek D. Martin [EMAIL PROTECTED] wrote: On Sun, Sep 30, 2001 at 09:41:33PM -0400, David T-G wrote: I think that Brendan answered my question on this long ago, but it's my understanding that the IMAP server decides whether to mark the message 'O'ld or not and that mutt has nothing to do with it and can't fix it That doesn't seem to be the case -- I unset mark_old and it does indeed not mark the messages old. As I understand it (I've never used mutt with IMAP, but I have worked with the code for $mark_old), this isn't exactly true. The messages will still be marked as old, but when $mark_old is unset mutt will totally ignore that and consider old messages as new. If you set $mark_old before entering an IMAP folder any messages that had previously been seen will still show up as old. Note the variable must be set before entering the folder, since with the standard mutt code the flag is ignored as messages are parsed. I submitted a patch to change this (along with splitting the two meanings of $mark_old) awhile ago, but it hasn't been accepted. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ What kind of head of security would I be if I let people like me know things that I'm not supposed to know?-- Garibaldi
Re: send-hook based on what address the message I'm replying to was sent to?
At 00:07 -0700 27 Sep 2001, Taner Halicioglu [EMAIL PROTECTED] wrote: e.g., my pager alias... I don't want to respond back with my pager alias when I reply, but I _DO_ want it to show up with a '+' in my inbox (hence, $alternates catches it)... You can't exempt addresses. But, you can override it using send-hooks, including ones based on the address chosen by $reverse_name: send-hook ~A 'unmy_hdr From' send-hook ~f pager 'my_hdr From: some.other@address' -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development. -- [EMAIL PROTECTED]
Re: send-hook based on what address the message I'm replying to was sent to?
At 18:06 -0700 26 Sep 2001, Taner Halicioglu [EMAIL PROTECTED] wrote: I have a few email addresses that forward to this email address, and I'd like to be consistent and set my From: header based on what a message was sent TO... No need to use send-hooks. Just set up your $alternates variable to match your addresses and set $reverse_name. You'll also need to remove any my_hdr From: commands you don't want to override this. The $from variable can be used to set your default address. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The number of arguments is unimportant unless some of them are correct. -- Ralph Hartley
Re: Procmail/sed/New Mail flag problem solved, FYI (somewhat long)
At 14:09 -0400 22 Sep 2001, John P. Verel [EMAIL PROTECTED] wrote: :0 fw: * ^TO_kde-linux | sed -e '/Subject:/s/\[kde-linux\] //g' KDE-linux While this stripped off the string just fine, I was getting funny results. Specifically, my mbox N flag was getting falsely set. Examination of the procmail log showed why: What this log suggested to me was that using the f (consider the pipe a filter) and w (wait for the filter to finish and check its exit code) were not doing what I intended. Rather than simply allowing time for the sed edit to operate, procmail was sending the mail to the correct box, but was continuing to process succeeding recipes, ultimately setting the flag on mbox. I fixed this by removing the flags and the lock (:). New recipe looks like this :0 * ^TO_kde-linux | sed -e '/Subject:/s/\[kde-linux\] //g' KDE-linux Just removing the f flag would have fixed it. You should definitely keep the lock. I'd advise keeping the w flag as well, since it will allow procmail to attempt to deliver the message in some other way if the sed command fails for some reason. Personally, I prefer to let procmail do the writing to my mailboxes. It's likely to do a better job of recovering from errors than some random program acting as a filter. You could do this like: :0fw * ^TO_kde-linux | sed -e '/Subject:/s/\[kde-linux\] //g' # Only if the above succeeded :0a: KDE-linux In this case you want the f flag on the first recipe, but a lock is unnecessary (it's not dealing with any files). -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.
Re: can't seem to get folder-hook to work
At 16:35 +0200 27 Aug 2001, Anand Buddhdev [EMAIL PROTECTED] wrote: send-hook . my_hdr From: [EMAIL PROTECTED] folder-hook . 'set sort=date-received record==sent ; my_hdr From: [EMAIL PROTECTED]' folder-hook hostmaster 'unmy_hdr from ; my_hdr From: [EMAIL PROTECTED] ; set record==hostmaster.sent' When I read my hostmaster mailbox, the Fcc: is correctly set to =hostmaster.sent, but the From: header remains as From: [EMAIL PROTECTED], instead of [EMAIL PROTECTED]. And I can't understand why this is happening. Am I doing something wrong? The folder-hook is changing the From: header. When you send a message your default send-hook changes it back. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ He's not dead, he's electroencephalographically challenged.
Re: mutt porting to Max OS-X ?
At 19:03 -0700 16 Aug 2001, Chris Wong [EMAIL PROTECTED] wrote: I compile mutt on Mac OS X myself and there is also a fink package for it. The only problem is sendmail doesn't work out of the box, so I am trying to figure out how set it up on Mac OS X, if anyone of you know how to do that, please shoot me an email. The main problem with the normal sendmail config on there is that sendmail doesn't like some of the permissions. This can be fixed by adding with the following line in /etc/mail/sendmail.cf: O DontBlameSendmail=GroupWritableDirPathSafe That will at least allow it to send some mail. I haven't yet had a need for it to send any messages other than ones that various cron jobs send to me. More config work may be required for more general use. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Besides, including std_ice_cubes.h is a fatal error on machines that don't have it yet. Bad language design, there... :-)--Larry Wall
Re: mutt porting to Max OS-X ?
At 12:42 +0530 17 Aug 2001, Suresh Ramasubramanian [EMAIL PROTECTED] wrote: So it's true that / is world writeable in OSX? Ouch. As has already been pointed out it's only group writeable. I don't think there's a sendmail config option to make it ignore world-writeable directories. And as long as the group contains only trusted people, I don't see this as much of a problem. A chmod or two (and avoiding the use of HFS - which might break compatiblity with older Mac OSen) might be a great idea before compiling any *nix stuff - Older versions of Mac OS only support HFS, so they won't work with UFS at all. And from what I hear some programs even have trouble running in OS X on UFS. As for the chmod part, I also hear that various system updates will reset the permissions on / . -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ In wartime, truth is so precious she should always be attended by a bodyguard of lies.-- Winston Churchill
Re: [dallas@hq.newdream.net: Re: [ndn-adm] ** procedure for swapping peons **]
At 16:20 -0700 09 Jul 2001, Will Yardley [EMAIL PROTECTED] wrote: ok so i am trying to be as descriptive as possible, but let me know if there's other pertinent information needed. i'm getting a segfault (and my terminal gets all wonky so that i have to 'reset') when replying to a message with the following headers. is it a problem with apple mail's mime version or something? i can view the message ok. I suspect this is because the message being replied to had no Message-ID. This problem has been fixed in cvs for a while now, and I'm pretty sure the fix even got into 1.3.19. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson
Re: Changing the Mime type of the outgoing message by default?
At 23:04 -0400 10 May 2001, adam morley [EMAIL PROTECTED] wrote: On Fri, May 11, 2001 at 12:43:28AM +0530, Suresh Ramasubramanian wrote: format=flowed requires a lot more implementation than just adding a content-type header, iirc. I wouldn't really say a lot more (at least when not dealing with quoted text), but definitely more. well, if i write my messages so they are wrapped like this as you will You mean not wrapped. see in one second, then it can be classified as a flowed message. a I suppose it *could* be classified as such, but I don't see much point in doing so. The whole point of format=flowed is so that paragraphs will wrap in programs that support it, but still be readable with programs that don't do wrapping. It also doesn't follow part of RFC 2646: ] When generating Format=Flowed text, lines SHOULD be shorter than 80 ] characters. As suggested values, any paragraph longer than 79 Your nested quoting was also done incorrectly. According to section 4.5 of RFC 2646 there should be no space between the '' marks at the start of quoted lines. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ ... very sad life. Probably have very sad death but at least there is symmetry. -- Zathras
Re: Priveledge Problem with mutt
At 14:26 -0400 13 Apr 2001, Lawrence Fish [EMAIL PROTECTED] wrote: I am getting the following error when I execute mutt in command mode I don't want to run with priveleges! Mutt was installed setuid and/or setgid. It doesn't need to be run with any extra privileges, so it shouldn't be installed in that way. Having it installed that way may lead to security problems, so it will refuse to do anything. To fix the problem run the following command as root: chmod ug-s `which mutt` -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The only disadvantage I see is that it would force everyone to get Perl. Horrors. :-)--Larry Wall
Re: Feature Request - don't encrypt when sending to mailing list
At 16:00 +0200 08 Apr 2001, Christian Biesinger [EMAIL PROTECTED] wrote: It would be nice if there was an option for mutt to not encrypt mails for mailing lists, even though I've set crypt_autoencrypt to yes (I've installed the S/MIME patch). I know that I could use send-hook for this, but then I'd have to add every mailing list to send-hook as well as to lists/subscribe. You're right, you can use send-hook for this, but you're wrong about needing to specify each mailing list: send-hook ~A 'set crypt_autoencrypt' send-hook ~l 'unset crypt_autoencrypt' The ~l pattern will match if the message is going to a known list. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ If you consistently take an antagonistic approach, however, people are going to start thinking you're from New York. :-) --Larry Wall to Dan Bernstein
Re: Colors aren't quite working
At 21:06 +0100 05 Apr 2001, Ailbhe Leamy [EMAIL PROTECTED] wrote: On (05/04/01 15:26), Wade A. Mosely wrote: color header green black ^X-.*: color header white black ^X-Mailer: color header green black ^X- color header white black ^X-Mailer: Works for me. I'm using the development version, but that shouldn't matter. Sadly, this doesn't work. Nor does reversing the order. Is there a way to construct a muttrc-friendly regexp to match "^X-(.*!'Mailer'):" or something? If for some reason the above doesn't work for you you could use a regexp like: x-([^m]|m[^a]|ma[^i]|mai[^l]|mail[^e]|maile[^r]|mailer[^:]+): Ugly but it should work. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Do not simplify the design of a program if a way can be found to make it complex and wonderful.
Re: GPG BAD Signature
At 08:03 -0500 26 Mar 2001, Adam Sherman [EMAIL PROTECTED] wrote: I *am* using courier, and am quite aware of the author's, uh, personality. (-: But since it didn't work on the fcc, I would assume something else is culprit? Well, then it appears that you have a problem in addition to courier. But from your earlier message it does look like courier is causing additional corruption, making diagnosis harder. You may want to try attaching a gzipped copy (to prevent courier from messing with it) of a signed message, that may help to give a better idea of what's going wrong. I'm using 1.3.15, should I still apply this patch? Yes, this patch hasn't yet been integrated. I suspect it was decided that courier is too broken to accomodate. Also, how come incoming pgp/signed do not get munged? No idea. I have no experience with courier (and I intend to keep it that way), the patch was written based on a suggestion from the author of courier the last time this type of problem came up. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The program isn't debugged until the last user is dead. PGP signature
Re: GPG BAD Signature
At 15:48 -0500 25 Mar 2001, Adam Sherman [EMAIL PROTECTED] wrote:
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
Mutt doesn't include text like the above.
--=_693-985553325-1-3
That isn't a mutt-generated boundary.
For some reason, when I sign a message without encrypting it, it
results in a BAD signature. It workds fine when the signature is
combined with the encryption, only causes a problem when the message
is detach-signed.
Have you tried checking the signature on a Fcc'd copy of a message?
I suspect that you're using the Courier MTA. The boundary quoted above
looks like one I've seen generated by that. It's also known to be
broken in dealing with signed MIME messages. The author has been told
this, but refuses to fix the problem claiming that the relevant
standards are at fault.
If you are indeed using Courier, the attached patch to mutt may work
around the problem. But, I'd recommend switching to an MTA that doesn't
try to mess around with MIME, or if it does is written by someone that
actually understands MIME.
If you're using some other MTA you should contact the author(s) and ask
them why it's rewriting your messages.
--
Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/
[It is] best to confuse only one issue at a time. -- KR
--- sendlib.c.dist Tue Dec 5 12:31:21 2000
+++ sendlib.c Tue Dec 5 14:32:25 2000
@@ -433,7 +433,10 @@
fputc ('\n', f);
- if (a-encoding != ENC7BIT)
+ /* Courier MTA will rewrite messages that don't contain an explicit
+ * Content-Transfer-Encoding, breaking PGP/MIME signatures. */
+ if (a-encoding != ENC7BIT
+ || (a-type == TYPEMULTIPART mutt_strcmp(a-subtype, "signed") == 0) )
fprintf(f, "Content-Transfer-Encoding: %s\n", ENCODING (a-encoding));
/* Do NOT add the terminator here!!! */
Re: change-folder macro
Please wrap your text at less than 80 characters per line. At 09:53 +0100 23 Mar 2001, Kirill Miazine [EMAIL PROTECTED] wrote: There's one type of macro I can't get working: Pressing Ctrl-q should bring me to the qmail folder (=qmail) and Ctrl-m should bring me to the mutt folder (=mutt). In most cases you can't bind things to those characters. Ctrl-M is a line-feed and Ctrl-q is often used as the terminal start character. In both cases the keys are caught by the terminal driver and are never seen by mutt (at least not in that form). -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ "But what we need to know is, do people want nasally-insertable computers?"
Re: hostname problems
Please wrap your text at 80 characters per line. At 02:22 -0500 20 Mar 2001, Matt Kolon [EMAIL PROTECTED] wrote: Any ideas why I keep getting this: ---| | Received: (from mkolon@localhost) --|| -mutt by anxiety.kolon.org (8.11.0/8.11.0) id f2K7DQ425255 | -sendmail for [EMAIL PROTECTED]; Tue, 20 Mar 2001 02:13:26 -0500 | -recipient when I've set .muttrc with hostname="anxiety.kolon.org"? Sendmail is doing that, not mutt. There's no way for mutt to control what appears there. The only way to alter that would be to alter the format for Received: headers in your sendmail.cf file. But, it's also not much of a problem. That isn't the envelope sender (that doesn't appear in sendmail-generated Received: headers), sendmail's just recording where it got the message. As with everything in Received: headers, this value should never be used for anything other than tracing where a message came from. The only reason that this might be a problem is if you want your login name to be kept secret. If you are actually having problems with the envelope sender being used, setting $envelope_from may help. The docs (and advice on the many threads on this topic) seem contradictory WRT the use of the hostname variable, sometimes saying that it should be used to fix the above, sometimes saying that it's the default domain for unqualified sent mail. Which is it? Is it both (after setting use_domain)? It's used for several things: - If $use_domain is set, it's added to any addresses (either sender or recipient) that don't already have domains attached. This is the only one that's really important. - Message IDs - File names for messages in maildir-format mailboxes. - Names for various temporary files. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying.
Re: compiling Mutt on Mac OS X
At 16:09 -0800 22 Feb 2001, Eugene Lee [EMAIL PROTECTED] wrote: I'm trying to compile Mutt 1.2.5i on Mac OS X and I'm getting a bunch of warnings in the compilation: I'm not so worried about the overlapping function names, but I'm a bit I didn't see any of those in the messages you included. concerned with messasges like "ANSI C does not support `long long'". Those were all in system include files, so there's nothing the mutt developers can do about them. But it's not really anything to worry about. GCC supports "long long" even though it's not part of the ANSI C standard. The warning is there only as a reminder that it isn't portable. Portability isn't really a concern for system includes, where any language extensions used basically become required features for compilers on that system. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Vir: Ahh, he has become one with his inner self. Garibaldi: He's passed out. Vir: That too.
Re: How to do a regexp
At 19:38 -0600 17 Feb 2001, Gary [EMAIL PROTECTED] wrote: On Sat, Feb 17, 2001 at 10:56:03AM -0600, Gary wrote: :O: * (^(To|Cc):*@about.com*) about.com can think of a few more ways too. The above has worked for me well over the years. I can't see how that could possibly work. It doesn't allow anything other than colons (:) between the header name and the at-sign (@). The asterisk (*) at the end is also wrong since you want to match exactly one "m" there, not zero or more. Of course, Bruce's real problem was having ABOUT.COM in caps to begin with. as you know, UNIX/Linux is case sensitive. Check Just because Unix filesystems are case sensitive doesn't mean that everything else is. In particular, regex conditions in procmail are not case sensitive unless the "D" flag is used on the recipe. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ A debugged program is one for which you have not yet found the conditions that make it fail. -- Jerry Ogdin
Re: sort of OT MacOS X
At 10:34 -0500 15 Feb 2001, Ken Weingold [EMAIL PROTECTED] wrote: at NT. Anyway, has anyone here tried it and built mutt on it? I am wondering how some of the software I use a lot will build and run under it. Yes, I've built mutt under OS X public beta. It's been awhile since I did it, so I may be forgetting some things. I needed to build ncurses to do it, but version 5.1 built pretty easily. After that I seem to remember mutt 1.2.5 building without problems. I haven't used it much, but it seems to work fine. The only problem I've had with it is that the termcap file included with the system is quite minimal and doesn't seem to have any type of color xterm included, so I end up running mutt with 'TERM=xterm-color mutt' (my ncurses build uses terminfo, which does have xterm-color). This could easily be fixed by replacing the termcap file, I just haven't gotten around to it yet. The main problem I've had with using unix software under OS X is that I wasn't able to build vim. But it's been awhile, so things may have improved since I last tried. Other than the vim problem, I've been pretty happy with OS X. It includes many things that I've always had to install myself on other unix systems (especially Solaris). Things that I was happily surprised to see included are zsh (even though bash doesn't seem to be included, not that I really care about bash), openssh, perl 5.6, less, wget, rsync, ncftp, fetchmail, procmail, tcpdump. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup
Re: Send-hook not setting from properly
At 21:04 -0500 13 Feb 2001, Daniel J Peng [EMAIL PROTECTED] wrote: send-hook . 'set from="[EMAIL PROTECTED]"; set realname="Daniel J Peng"' send-hook '~C @gecko.serc\.rmit\.edu\.au' 'set from="[EMAIL PROTECTED]" ; set realname="Razl"' Is this a bug? Or am I just missing something about send-hooks? At the time that send-hooks are evaluated, Mutt has already generated the From: header that it plans to use. If you want to select a From: header from send-hooks you need to use 'my_hdr From:'. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson
Re: Send-hook not setting from properly
At 23:52 -0500 14 Feb 2001, Daniel J Peng [EMAIL PROTECTED] wrote: On Wed, Feb 14, 2001 at 06:01:37AM -0600, Aaron Schrab wrote: At the time that send-hooks are evaluated, Mutt has already generated the From: header that it plans to use. Is this by design? This seems like extraordinarily counterintuitive behavior. Yes it's by design. Doing it this way allows send-hooks to be based on the effects of $reverse_name which needs to be able to ovverride the value of $from. The description in the manual even says: ** When set, this variable contains a default from address. It ** can be overridden using my_hdr (including from send-hooks) and ** ``$$reverse_name''. This timing is its only reason it exists (in 1.0 my_hdr was the only way to change the From: header). Remember that it's documented as being the *default* from address, it's not really meant to be changed all the time. Also, why should Mutt not set 'realname' and 'from' at the same time? I don't know. Possibly because having the real name portion available to send-hooks isn't as usefull as having the address portion available. And, at least if $reverse_realname variable is not set the realname portion of the From: header needs to be done after $reverse_name is applied anyway, so it might as well be after the send-hooks as well. If you want to select a From: header from send-hooks you need to use 'my_hdr From:'. Will envelope_from set the envelope if I do this? Yes. The manual is accurate in saying that it uses the address from the From: header (rather than saying that it uses the $from variable). -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ /earth is 98% full ... please delete anyone you can.
Re: Selecting headers to delete on pop3 server
At 10:15 +0100 07 Feb 2001, Marco Fioretti [EMAIL PROTECTED] wrote: http://www.linuxgazette.com/issue62/okopnik.html One note: the article puts single quotes around the mutt macros, while Aaron specified double quotes. Any comment about this? The macros I suggested would take care of everything automatically (unless $wait_key is set). For this to work "\n" needs to get expanded to a line-feed; this happens inside of double quotes but not single quotes. The macros in the above article require the user to manually hit the enter key to perform the action. Because of this they don't contain "\n", so the expansion doesn't depend on the type of quotes used. Does it depend from the mutt version? It shouldn't for anything even somewhat recent. Ancient versions (quite a bit before 1.0) had somewhat different quoting rules, so might behave differently (although I don't think the differences should matter for a simple case like this). -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Real Users never use the Help key.
Re: Selecting headers to delete on pop3 server
At 13:53 +0100 02 Feb 2001, Marco Fioretti [EMAIL PROTECTED] wrote: What would REALLY do the trick is some "shell excape" which just makes mutt do the following: echo subject_and_From_header some_file macro pager X '| formail -XFrom: -XSubject: -XMessage-ID: some_file\n' macro index X '| formail -XFrom: -XSubject: -XMessage-ID: some_file\n' -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ One good reason why computers can do more work than people is that they never have to stop and answer the phone.
Re: Selecting headers to delete on pop3 server
At 15:27 -0600 02 Feb 2001, I wrote: macro pager X '| formail -XFrom: -XSubject: -XMessage-ID: some_file\n' macro index X '| formail -XFrom: -XSubject: -XMessage-ID: some_file\n' Oops, need to use double quotes not single qoutes there: macro pager X "| formail -XFrom: -XSubject: -XMessage-ID: some_file\n" macro index X "| formail -XFrom: -XSubject: -XMessage-ID: some_file\n" -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Standards are crucial. And the best thing about standards is: there are so _many_ to choose from!
Re: index_format to show attachments?
At 23:07 -0500 30 Jan 2001, mike polniak [EMAIL PROTECTED] wrote: Now i already use procmail to find attachments by looking at the header for 'Content-Type:.*multipart/mixed' which eliminates PGP and alternative attachments. That's not really a good test for whether a message has attachments. Lately, I've been seeing messages from a number of mailers that have Content-type: multipart/mixed, with only one sub-part. I woulnd't consider those as having attachments. At 12:25 -0500 31 Jan 2001, mike polniak [EMAIL PROTECTED] wrote: Mutt does support the pattern '~i ID' which matches the Message-ID: field. So since i already use procmail to find messages with attachments, i add another line to the procmail recipe, to replace the original Message-ID: | formail -i "Message-ID: attach". Ugghhh! First, "formail -i" doesn't replace the Message-ID header, it adds another one. Second, doing that will break threading of any replies to those messages; if you reply to such messages, you'll break the threading for the recipients as well as yourself. How about using the Expires: header instead? | formail -I "Expires: Thu, 1 Jan 1970 00:00:00 +" And in .muttrc: score ~E 2 # No need for folder-hook -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ "...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."-- Ted Ts'o
Re: Procmail Filtering
At 12:41 -0500 19 Jan 2001, "Douglas L . Potts" [EMAIL PROTECTED] wrote: :0 fw ^From:.*[EMAIL PROTECTED] | sed -e 's/"JOSEFINA EDWARD"/"Sophy Edwards"/g' INBOX If you redirect the output to a file, the recipe is no longer working as a filter so the f flag should be removed. You should also tell procmail to use a lockfile by putting a colon at the end of the first line. Also you need an asterisk at the beginning of the condition line. Backslash quoting the dots (other than the first one) in this line would also be a good idea. The modified recipe would then be: :0w: * ^From:.*j\.edward@codetel\.net\.do | sed -e 's/"JOSEFINA EDWARD"/"Sophy Edwards"/g' INBOX -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ However, since procmail is the ultimate supply of rope for mail hacking, here are the directions for tying a noose: -- Philip Guenther
Re: folder-hook pattern matching
At 13:16 -0800 21 Dec 2000, Eugene Lee [EMAIL PROTECTED] wrote: But there seems to be no way to match all mailboxes that begin with the letter 'b'. In other words, I can't make a folder-hook perform a match on *only* the mailbox name itself and not the absolute pathname. If there's a way to do this, I'd love to know how. There's not a way to do that but you might be able to use something like (completely untested): folder-hook (^|/)b[^/]*$ 'set ' That ensures that the "b" is immediately after either the start of the folder name (just in case that somehow gets matched against) or a slash and that there are no slashes between it and the end of the folder name (to make sure it's not some higher level directory which matches). -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Criminals today have guns. Soon they will have computers and other weapons of mass destruction. -- U.S. Attorney General Janet Reno
Re: courier-mta, mutt and PGP
At 15:49 +0100 05 Dec 2000, Anand Buddhdev [EMAIL PROTECTED] wrote:
On Tue, Dec 05, 2000 at 08:31:43AM -0500, Sam Varshavchik wrote:
Note that the second MIME section does not specify its content transfer
encoding. Neither is the default transfer encoding specified in the top
level MIME header. As I mentioned, if a MIME section that does explicitly
specify its transfer encoding, Courier will calculate one.
The default transfer encoding is never specified in the top level
header, it's specified in RFC (2045, section 6.1):
"Content-Transfer-Encoding: 7BIT" is assumed if the
Content-Transfer-Encoding header field is not present.
Please point out where it is stated that the top level encoding is
supposed to be the default for lower levels? The only mentions of a
default encoding that I can find in either RFC 2045 or 2046 is the one
quoted below and a couple in 2046 about the message/partial and
message/external-body types which also state that 7BIT is the default.
So the problem boils down to the MUA not generating full and correct MIME
headers. In this case, mutt isn't inserting all the headers that courier
expects (it assumes that the relevant information will be infered according
to RFC 1847). I suppose mutt's interpretation of the RFC is understandable.
Mutt's MIME headers *are* correct and as full as necessary. I don't see
any reason (other than broken software) for mutt to explicitly state
that a default value is to be used. So as far as can see mutt's
interpretation is not only understandable, it is correct.
of the MUA. Do you have any suggestions for alternative mail clients that
have better MIME support? Alternatively, do the mutt users have any ideas
on making mutt generate the headers as Sam suggests?
I'm not aware of mail clients with better MIME support (other than
possibly having builtin support for more types). I don't think it's
really even possible, since mutt's support is excellent.
But, I suppose you could use the attached patch to work around courier's
bad behaviour, it will cause mutt to always generate a
Content-Transfer-Encoding header for multipart/signed messages. The
same shouldn't be necessary for multipart/encrypted, since the relevant
headers are encrypted and therefore safe from courier. This patch is
against the CVS version, but I expect it will work for pretty much any
version.
--
Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/
Life is like sendmail: It's complicated and hard to understand,
but it sure beats the alternative. -- Paul Tomblin
--- sendlib.c.dist Tue Dec 5 12:31:21 2000
+++ sendlib.c Tue Dec 5 14:32:25 2000
@@ -433,7 +433,10 @@
fputc ('\n', f);
- if (a-encoding != ENC7BIT)
+ /* Courier MTA will rewrite messages that don't contain an explicit
+ * Content-Transfer-Encoding, breaking PGP/MIME signatures. */
+ if (a-encoding != ENC7BIT
+ || (a-type == TYPEMULTIPART mutt_strcmp(a-subtype, "signed") == 0) )
fprintf(f, "Content-Transfer-Encoding: %s\n", ENCODING (a-encoding));
/* Do NOT add the terminator here!!! */
Re: what is the change folder command offering?
At 21:18 + 10 Nov 2000, Conor Daly [EMAIL PROTECTED] wrote: What I'd like to see is some way to mark a folder as containing unread messages after I've read some (but not all) of the messages therein. Mutt will list folders that use the maildir format as containing new mail as long as there are messages that are marked as new. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ As I look across the web, what I find is this vast wasteland that makes television almost attractive. -- Clifford Stoll
Re: multiple mutts
At 09:23 +0930 12 Oct 2000, Brian Salter-Duke [EMAIL PROTECTED] wrote: On Wed, Oct 11, 2000 at 04:38:31PM -0700, Bruce J.A. Nourish wrote: if ps -U $LOGNAME | grep realmutt /dev/null Be careful about using grep to search the output of ps. For example $ ps ax | grep lemming 16004 tty1 S 0:00 grep lemming Y'see? Grep makes a match on its own process. It works OK on AIX 3.2.5 ps. If you add the -f flag it finds the grep line, but it does'nt without it. OK, so maybe my script does'nt work on all systems, but it is worth playing with to see if some set of ps flags works as required. Or you could just make a minor modification to the grep pattern: ps -U $LOGNAME | grep 'r[e]almutt' /dev/null That way grep won't be able to match itself. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Besides, including std_ice_cubes.h is a fatal error on machines that don't have it yet. Bad language design, there... :-)--Larry Wall
Re: Aborted unmodified message.
At 22:57 +0300 27 Sep 2000, Mikko Hänninen [EMAIL PROTECTED] wrote: For Sun, I don't know what the system call trace program is called -- truss maybe, or was that some other OS? It may not have one (installed). truss is correct. I'd probably use: truss -o /tmp/mutt.truss -f -t exec mutt -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup
Re: Images in the body of an e-mail.
At 12:40 -0400 24 Aug 2000, David T-G [EMAIL PROTECTED] wrote: Although you would probably be heavily berated for doing so on this list, you could probably manage it by creating an HTML page containing your mail text and your image and then attaching both of those to your email. But you won't be able to reference any attached images from IMG tags. To do that, you'd need to be able to add a Content-Id: field to the MIME header of the image so that it could be accessed with a cid: URL. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Killing bad guys is such fun, too bad we only captured one, are there any more out there? -- Blues Traveler, "Psycho Joe" PGP signature
Re: Configuring Mutt with Sendmail and PPP.
At 11:29 -0500 24 Aug 2000, Larry Rosenman [EMAIL PROTECTED] wrote: sendmail can be configured in the sendmail.cf to use mode=queueonly. It can also be done on the command line by including the -odq option. But d deferred; the same as q except that database lookups (notably DNS and NIS lookups) are avoided would probably be more appropriate here. It can be set on the command line using -odd . -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.
Re: mutt ignores reply-to if I am the sender.
At 23:01 + 09 Aug 2000, Marc MERLIN [EMAIL PROTECTED] wrote: 1) Can this be disabled? set reply_self -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying.
Re: PGP6 The Bat
At 12:12 +0200 08 Aug 2000, Caster [EMAIL PROTECTED] wrote: On pon 07 sie 2000 17:33:40 GMT Aaron Schrab wrote: But the rule that prevents this from happening with multipart messages is necessary, because the modification that is done by that rule will prevent mutt (or any MUA) from dealing with multipart messages. So, it's a tradeoff: Yes, you're absolutely right. However there must be a solution. Tell me how the attachment/MIME mechanizm work. I mean I know generally but maybe there is a RFC or something describing the thing? Right now I am analyzying Mutt's Content-Type output. I think there is need for a script (maybe Perl) that will reformat mails which give the trouble. One more thing: do lines like -BEGIN PGP SIGNED MESSAGE- or -BEGIN PGP SIGNATURE- need to be removed? I mean GPG will recognize and skip them? No, those lines shouldn't be removed. Really, all that needs to be done is to rewrite the Content-Type: line of the relevant part to something like that inserted by the procmail rules. It probably wouldn't be all that difficult to do this with a perl script using the MIME:: modules. One additional complication is that in this case the signed part also specifies a character set. Mutt won't currently honor a charset parameter for application/pgp parts, so some characters may appear incorrectly. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ When we aren't plundering and wreaking havoc, we speak out on the importance of safe boating. -- Spider Pirate Captain (The Drywall and Oswald Show #2) PGP signature
Re: PGP6 The Bat
At 23:16 +0200 07 Aug 2000, Caster [EMAIL PROTECTED] wrote: Maybe this will interest you. I think the recipe in the PGP-Notes is wrong. Let's say someone sends me a message with an enclusore. He is also using PGP and signs the message. There is a Content-Type: multipart/. header in his mail. Because of it the recipe doesn't match the mail. I think that "* !^Content-Type: multipart/" should be scratched. I suspect that that's what's happening in this case, since the example message (which had Content-Type: text/plain) got modified by my procmail rules and mutt successfully checked the signature. But the rule that prevents this from happening with multipart messages is necessary, because the modification that is done by that rule will prevent mutt (or any MUA) from dealing with multipart messages. So, it's a tradeoff: - Do you want automatic signature checking, but need to go through some fairly complex steps to get at attachments. - Or do you want to be able to actually use attachments right from in mutt, with manual signature checking being fairly easy. Myself, I'll stick with manually checking signatures when necessary. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ When we write programs that "learn", it turns out we do and they don't. PGP signature
Re: Dynamically Generated .muttrc Content
At 19:20 -0400 02 Aug 2000, Evan Vetere [EMAIL PROTECTED] wrote: I'm trying to source a directory full o' files into my .muttrc. Typical methods such as 'source ~/.mutt/*' (where .mutt is the directory) don't work, so I tried doing source "cat ~/.mutt/* |" -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying. PGP signature
Re: weird sent-hook
At 13:45 -0500 25 Jul 2000, Ronny Haryanto [EMAIL PROTECTED] wrote: On a slightly different but related subject, why can't "Reply-To" be used instead of "Mail-Followup-To"? Most mailers have already supported "Reply-To", so why not use that? Because that wouldn't allow the person responding to (easily) choose between sending the reply to the entire list or to just the author of the original message. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ As I look across the web, what I find is this vast wasteland that makes television almost attractive. -- Clifford Stoll
Re: multiple users
At 15:40 -0400 19 Jul 2000, Michael Soulier [EMAIL PROTECTED] wrote: Hey guys. I noticed that mutt creates .lock files while reading from mailboxes, as it should. At work here, we have some project accounts where multiple users are managing mail. I'm wondering about mutt's capabilities in this area, with respect to multiple users accessing the same mailboxes from the same account. I don't see anything in particular mentioned on this in the manual, so if someone could summarize it's multi-user features, that'd be great. Mutt doesn't have any features specifically to allow multiple people to use a mailbox. As you noted, it does lock the mailbox (through .lock files and/or kernel locks); this is to prevent mutt and the MDA (message delivery agent) from conflicting with each other, not to allow multiple people to use a mailbox. But, it really depends upon what type of features you need. Mutt will allow multiple instances to access the same mailbox at once, and for the most part it will do a pretty good job of merging the changes made by each. It won't do anything to prevent multiple people from replying to the same message or otherwise duplicating work. At my employer, we use mutt for responding to messages to our helpdesk. We often have several people doing this simultaneously, but only one person is using each mailbox at any one time (this is enforced by a wrapper script which also specifies a custom muttrc file). Instead, we have people send different types of issues to different addresses and thus different mailboxes. For some of the busier mailboxes, one person goes through the main mailbox and splits it into several other boxes (it's safe to save a message to a mailbox that's currently open in another mutt). -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ [It is] best to confuse only one issue at a time. -- KR
Re: Customizing one send-hook for all mailing lists
At 16:02 +0200 19 Jun 2000, Dirk Ruediger [EMAIL PROTECTED] wrote: Is it possible to process the entries of "subscribe" or "lists" to use it for send-hook, e.g.: Read section 4.2 of the manual. Especially the part about the ~l pattern. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ The "data" for most coffee URIs contain no caffeine. -- RFC 2324
Re: [OT-ish] HTML being filtered?
At 11:12 -0500 30 May 2000, Ronny Haryanto [EMAIL PROTECTED] wrote: an RFC (about multipart or MIME, I can't remember exactly) suggests that the last text/plain part be shown if all of the parts are of the same type. Please correct me if I'm wrong. Actually, mailers are supposed to prefer the last alternative that they can handle, regardless of type (RFC 2046, section 5.1.4). This way, the sending MUA can specify which version is the best representation of the content, and (at least in the case of things like plaintext/html messages) people with non-MIME mailers don't have to wade through screenfuls of garbage to get to the plaintext. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ To err is human, to forgive, beyond the scope of the Operating System.
Re: receive-hook?
At 08:07 -0400 30 May 2000, David T-G [EMAIL PROTECTED] wrote: % Unfortunately, there's no way to execute send-hooks dependent on the % message you are replying to. This is something that has been bothering me for a while... If that's the case, then why does send-hook . set pgp_autosign send-hook (skip|topgunch|guckes)unset pgp_autosign work as expected -- that is, not only new mails but replies to skip are not signed, but everything else is? Because, even when you're replying, you're sending a message to skip. send-hooks don't care if you're writing a new message or replying. The thing is, that when working with a reply, send-hook conditions can't be based on properties of the original message, only on properties of the message that you're writing. For instance, if you wanted to use some weird setting of $attribution whenever replying to a certain person, currently the only way to do it would be to check if that person is receiving the message, but this won't work correctly when doing a group-reply. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ As I look across the web, what I find is this vast wasteland that makes television almost attractive. -- Clifford Stoll PGP signature
Re: octet-filter
At 05:30 -0500 28 Apr 2000, Jason Helfman [EMAIL PROTECTED] wrote:
Is their a way to autoview rpm files so they are't shown in a huge flush
of ascii characters with the mutt.octet.filter?
See attached patch.
--
Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/
A successful [software] tool is one that was used to do something
undreamed of by its author. -- S. C. Johnson
--- mutt.octet.filter.orig Fri Apr 28 18:41:06 2000
+++ mutt.octet.filter Fri Apr 28 18:43:31 2000
@@ -142,6 +142,11 @@
echo $(basename "$1"): unprintable data
}
+ShowRPM()
+{
+rpm -qip "$1"
+}
+
DisplayFileType()
{
echo "[-- $(basename $0) file type: \"$1\" --]"
@@ -217,6 +222,7 @@
*.doc ) ShowFileType "$1"; ShowMSWord "$1";;
*.DOC ) ShowFileType "$1"; ShowMSWord "$1";;
*.o ) ShowFileType "$1"; ShowObject "$1";;
+*.rpm ) ShowFileType "$1"; ShowRPM"$1";;
* ) ShowMISC "$1";;
esac
fi
Re: help, set from=xxx
At 00:39 -0400 05 Apr 2000, David T-G [EMAIL PROTECTED] wrote: % send-hook '(~C mutt)' "set signature="uptime|" ;my_hdr From: Neelakanth [EMAIL PROTECTED] " It's just a nit, but you might want to change your sig to set signature='uptime|' so that it's parsed at hook-time instead of at muttrc-read time. To That's not necessary, since having a pipe at the end of the value isn't special to the parser. The pipe only affects what happens when mutt tries to read the signature from the file (or program) indicated by $signature. Whichever type of quotes you use, that will happen for each new message. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ When you're dealing with like crazy aggressors like Libya or Iran or Microsoft, you are talking about people who could do anything. -- Bill Maher PGP signature
Re: Attach-message + attachments
At 18:25 +0300 05 Apr 2000, Mikko Hänninen [EMAIL PROTECTED] wrote: In the compose menu, there's a function called "get-attachment" (bound to G) but it didn't seem to do anything for me, and I can't tell what it is supposed to do based on the description. It copies the selected attachment to a temporary file (which is marked to be deleted after sending), so that the attachment may be edited before sending without affecting the original. When the selected attachment is already a temporary file (the main body, for example) it indeed does nothing. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Feeling amorous, she looked under the sheets and cried, "Oh, no, it's Microsoft!"
Re: [Announce] Mutt-1.1.10 is out (RELEASE CANDIDATE)
At 11:05 +0200 30 Mar 2000, Thomas Roessler [EMAIL PROTECTED] wrote: On 2000-03-30 09:14:09 +0100, Chris Green wrote: There a couple of compiler warnings:- gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../intl -I../intl -Wall -pedantic -g -O2 -c imap.c imap.c: In function `imap_check_mailbox': imap.c:1157: warning: `t' might be used uninitialized in this function This is an over-eager gcc. The variable is not used uninitialized. Still, it would probably be a good idea to prevent the warning. Spurious warnings can mask ones that are real problems. fac that the install tries to set mutt_dotlock's permissions even though I have done a local directory install. umh... I wouldn't really consider this a problem in the installation mechanism... Since in cases like this, the resulting install could easily be unsafe, it could be argued that installing at all is an error. There should probably be more noticeable errors at the least, maybe even require the person doing the install run something like "make unsafe_install". -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ Everyone can be taught to sculpt: Michelangelo would have had to be taught how _not_ to. So it is with the great programmers.
Re: Question about $from and send-hooks
At 17:22 +0200 24 Mar 2000, Mikko Hänninen [EMAIL PROTECTED] wrote: So, should setting $from (and $realname) inside a send-hook actually change the from address or not for the current email? If it doesn't, then it can't be used as a full replacement for "my_hdr From:" (and No, it shouldn't. $from isn't meant to be a full replacement for 'my_hdr From:', it's meant to let people set the default. then we again get the $reverse_name problem). No, we don't. The $reverse_name problem was that it wouldn't override a default set by my_hdr. The order for this stuff is: - Apply $from - Do $reverse_name - Do send-hooks (including 'my_hdr From:') If applying $from were to be moved after the send-hooks, then $from would have exactly the same problems as 'my_hdr From:'. Unless applying $reverse name were moved so it was again after that, but then the address it sets couldn't be matched against in send-hooks, and there would be no way to override it. So, if you want to set the From: address in a send-hook, you should still use 'my_hdr From:'. That this overrides $reverse_name is a feature, not a bug. For instance, I've occasionally used things like: send-hook . unmy_hdr From: send-hook '~f aarons@illiam' my_hdr From: Aaron Schrab [EMAIL PROTECTED] Because although I want the address [EMAIL PROTECTED] to be recognized as mine, I never want to use it for sending mail. -- Aaron Schrab [EMAIL PROTECTED] http://www.execpc.com/~aarons/ "If that makes any sense to you, you have a big problem." -- C. Durance, Computer Science 234
