Re: reading color quoted replies
On Feb 08, Marc Vaillant [EMAIL PROTECTED] wrote: On Mon, Feb 05, 2007 at 05:53:39PM -0600, Jeremy Blosser wrote: Anyway, to the original question: the elinks and links family of text browsers can render HTML colors as ascii. If you use those as your HTML viewers you can get the colors and follow the quoting. Thanks very much. Hoping that it can sensibly dump HTML colors as ascii as well? I'll look into it. Kyle mentioned the newer versions have an option for this, and I looked far enough to see the git version has the option, but I haven't actually tried it yet. pgpZhePkesbew.pgp Description: PGP signature
Re: reading color quoted replies
On Feb 01, William Yardley [EMAIL PROTECTED] wrote: I have a vendor who occasionally sends me replies quoted this way. What's ironic is that he normally top-posts, and I suspect he's doing it this way because *I* normally quote inline in response to him. I'm sure this happens here; they are pretty happy to top quote back and forth until I give a detailed properly-quoted response to their thread, after which they will reply with this color-coded style. This is either peer pressure (doubtful) or they see the value in proper quoting and are trying to do it with what they have (possible). I could at that point either smack their nose for using HTML (a bad idea when it's my boss' boss' boss doing it) or I can take some minimal comfort that at least they're getting the spirit of proper quoting. And take some more comfort that I'm following Postel's Law. Anyway, to the original question: the elinks and links family of text browsers can render HTML colors as ascii. If you use those as your HTML viewers you can get the colors and follow the quoting. pgpxI5PT2n8EZ.pgp Description: PGP signature
Re: [OT] Correct way to quote?
On Sep 20, kevin lyda [[EMAIL PROTECTED]] wrote: On Fri, Sep 20, 2002 at 01:12:20AM +0200, Markus Garschall wrote: My question doesn't concern mutt directly, but the topic of mail as a whole. no it doesn't... Since I'm using Netscape beside Mutt as Mailer, I wanted to know whether the old way to quote things in an E-Mail is the only correct one. ...your question is about religion. There is at least one objective complaint against changing the quote character: it wreaks havoc with messages that contain bits of script or code. isn't even immune to this, but the fewer there are to deal with, the better. msg31068/pgp0.pgp Description: PGP signature
[PATCH] display-subject
The attached patch copies the functionality of the display-address function
to display the message subject, by default bound to S. This is useful if
your term isn't infinitely wide and/or you have a crowded $index_format.
I've been using a version of this since 1.3.2x without any problems; it's
pretty much just a copy of the display-address stuff so it should be pretty
innocuous.
diff -dupr mutt-cvs.orig/PATCHES mutt-cvs/PATCHES
--- mutt-cvs.orig/PATCHES Wed Sep 11 23:05:23 2002
+++ mutt-cvs/PATCHESWed Sep 11 23:26:04 2002
-0,0 +1
+patch-1.5.jjb.display_subject.1
diff -dupr mutt-cvs.orig/OPS mutt-cvs/OPS
--- mutt-cvs.orig/OPS Wed Sep 11 23:05:23 2002
+++ mutt-cvs/OPSWed Sep 11 23:26:04 2002
-53,6 +53,7 OP_DELETE_MAILBOX delete the current ma
OP_DELETE_SUBTHREAD delete all messages in subthread
OP_DELETE_THREAD delete all messages in thread
OP_DISPLAY_ADDRESS display full address of sender
+OP_DISPLAY_SUBJECT display full subject of message
OP_DISPLAY_HEADERS display message and toggle header weeding
OP_DISPLAY_MESSAGE display a message
OP_EDIT_MESSAGE edit the raw message
diff -dupr mutt-cvs.orig/PATCHES mutt-cvs/PATCHES
--- mutt-cvs.orig/PATCHES Thu Jan 24 06:10:47 2002
+++ mutt-cvs/PATCHESWed Sep 11 23:26:04 2002
-0,0 +1
+patch-1.3.25.jjb.display_subject.1
diff -dupr mutt-cvs.orig/commands.c mutt-cvs/commands.c
--- mutt-cvs.orig/commands.cSat Apr 20 12:30:38 2002
+++ mutt-cvs/commands.c Wed Sep 11 23:26:04 2002
-619,6 +619,11 void mutt_display_address (ENVELOPE *env
mutt_message (%s: %s, pfx, buf);
}
+void mutt_display_subject (ENVELOPE *env)
+{
+ mutt_message (Subject: %s, env-subject);
+}
+
static void set_copy_flags (HEADER *hdr, int decode, int decrypt, int *cmflags, int
*chflags)
{
*cmflags = 0;
diff -dupr mutt-cvs.orig/curs_main.c mutt-cvs/curs_main.c
--- mutt-cvs.orig/curs_main.c Wed Sep 11 23:05:23 2002
+++ mutt-cvs/curs_main.cWed Sep 11 23:26:04 2002
-1687,8 +1687,15 int mutt_index_menu (void)
case OP_DISPLAY_ADDRESS:
CHECK_MSGCOUNT;
-CHECK_VISIBLE;
+ CHECK_VISIBLE;
mutt_display_address (CURHDR-env);
+ break;
+
+ case OP_DISPLAY_SUBJECT:
+
+ CHECK_MSGCOUNT;
+ CHECK_VISIBLE;
+ mutt_display_subject (CURHDR-env);
break;
case OP_ENTER_COMMAND:
diff -dupr mutt-cvs.orig/doc/manual.sgml.tail mutt-cvs/doc/manual.sgml.tail
--- mutt-cvs.orig/doc/manual.sgml.tail Fri Jun 14 08:17:22 2002
+++ mutt-cvs/doc/manual.sgml.tail Wed Sep 11 23:26:04 2002
-62,6 +62,7 delete-pattern D delete me
delete-subthread ESC d delete all messages in subthread
delete-thread ^D delete all messages in thread
display-address display full address of sender
+display-subjectS display full subject of message
display-toggle-weedh display message and toggle header weeding
display-message RET display a message
edit e edit the current message
-132,6 +133,7 delete-message d delete th
delete-subthread ESC d delete all messages in subthread
delete-thread ^D delete all messages in thread
display-address display full address of sender
+display-subjectS display full subject of message
display-toggle-weedh display message and toggle header weeding
edit e edit the current message
edit-type ^E edit the current message's Content-Type
diff -dupr mutt-cvs.orig/functions.h mutt-cvs/functions.h
--- mutt-cvs.orig/functions.h Wed Sep 11 23:05:23 2002
+++ mutt-cvs/functions.hWed Sep 11 23:26:04 2002
-128,6 +128,7 struct binding_t OpMain[] = {
{ buffy-list, OP_BUFFY_LIST, . },
{ sync-mailbox,OP_MAIN_SYNC_FOLDER,$ },
{ display-address, OP_DISPLAY_ADDRESS, },
+ { display-subject, OP_DISPLAY_SUBJECT, S },
{ pipe-message,OP_PIPE,| },
{ next-new,OP_MAIN_NEXT_NEW, \t },
{ previous-new,OP_MAIN_PREV_NEW, \033\t },
-204,6 +205,7 struct binding_t OpPager[] = {
{ show-version,OP_VERSION, V },
{ search-toggle, OP_SEARCH_TOGGLE, \\ },
{ display-address, OP_DISPLAY_ADDRESS, },
+ { display-subject, OP_DISPLAY_SUBJECT, S },
{ next-new,OP_MAIN_NEXT_NEW, \t },
{ pipe-message,OP_PIPE,| },
{ help,OP_HELP,? },
diff -dupr mutt-cvs.orig/pager.c mutt-cvs/pager.c
--- mutt-cvs.orig/pager.c Wed Sep 11 23:05:24 2002
+++ mutt-cvs/pager.cWed Sep 11 23:26:04 2002
-2203,6 +2203,14 mutt_pager (const char *banner, const ch
mutt_display_address (extra-hdr-env);
Re: spam harvesting
On Sep 01, Peter T. Abplanalp [[EMAIL PROTECTED]] wrote: On Sat, Aug 31, 2002 at 04:31:54PM -0700, Will Yardley wrote: Yes, but it's much less likely to happen... a spammer would have to go to a lot of effort (comparatively) to sign up for a list like this... and spamming a list of largely technical people would be dumb anyway. i disagree. it would be trivial to set this up. i could set up a system in less than half an hour that would harvest the email addresses of posters. anyone who thinks that spammers aren't smart enough to do this is deluding themselves. even if the spammers weren't smart enough, they could pay someone who was to do it. You are correct in theory, but wrong in practice. The simple fact is that they aren't mining lists (yet), and avoiding posting your address online does prevent them from finding you as easily. Simple evidence: the web sites I admin that require my address to be posted on them get almost nothing but spam to those addresses, and have for years. The ones I admin that I only post a link to my website on (which in turn doesn't have an email link but pretty much says anyone with a brain can figure out how to mail me based on the site host name) do not get spam. Also, I posted for years to these mutt lists using a -mutt address, and never got a single spam to that address. Within minutes of posting my first feedback to the mutt bug tracking system, I was receiving spam to this address (the BTS posts full, unobfuscated messages on the web; the bugs themselves receive enough spam to make reading the bug logs a serious pain). It is of course accurate to say that spammers aren't mining lists directly because they don't need to yet, and if everyone hid their address from web pages, they would probably start doing this. Nevertheless, it does work to hide your address now, and works quite effectively, and it's silly to claim it doesn't. As I noted before, none of these things are complete solutions, but they all contribute to the solution. i do feel for those poeple that have to manage large email systems. i can see that they have it worse than i. all i have to do is filter my own email. i do this using spam assassin and see hardly any spam in my inbox. i do, however, agree with sven and the couple others that say hiding is not the answer. you just can't hide effectively as we've pointed out. I appreciate you feeling for us, but if you want to help, please do try to see the big picture, and work to know the enemy. We can't fight them if we fight them as we would be if we were them, we can only fight them if we fight them as they are. (BTW, if anyone thinks calling them the enemy, etc. is overly melodramatic, remember that spam in recent years has moved more and more from printer toner to all manner of pr0n, beastiality, etc. spams, and many of us are stuck trying to keep our bosses and spouses and parents and kids from being assulted with that trash.) msg30605/pgp0.pgp Description: PGP signature
Re: spam harvesting
On Sep 01, Eugen Leitl [[EMAIL PROTECTED]] wrote: The problem of spam is easily solvable for technically proficient users. Depening on your philosophy, install SpamAssassin/Vipul's Razor or a tagged message delivery system, and set up a few filters on MUA's side. Once in a while check into the Spam folder, looking for misflagged messages. Checking sender and subject is sufficient for that. Problem solved. If you're feeling like it, you can offer this as a commercial service. If your venture flops (as it is to be expected), you will know that people don't consider spam a big enough problem to pay a token amount for having their email screened. Next time please bother to read the thread you're replying to. Thanks. msg30613/pgp0.pgp Description: PGP signature
Re: [OT] spam harvesting
On Sep 01, Eugen Leitl [[EMAIL PROTECTED]] wrote: On Sun, 1 Sep 2002, Ken Weingold wrote: I've been noticing that one too. I'm not familiar with Vipul's or TMDA, but Spamassassin has a rule for when the From: and To: are the same. I think from the ISP mail server admin's point of view he should wish to shift the CPU load to the end user. He has allready paid for the peer traffic, and now he could at least doesn't pay for ridiculous amounts of rackmount boxes. If you're talking about me, I'm not an ISP admin. Corporate America all the way. :-/ Our end user CPU load is our CPU load. [2] BTW, if you get a clever idea for a new spam blocking system, please don't write it in perl. Anything that a serious mail server has to run per every message damn well better be in C or better. Oh. :) I think the bottleneck is pattern matching. As such it doesn't matter, as Perl's regexp stuff is highly optimized C. Considering that we aren't using any pattern matching, no. (Vipul's is checksumming + network query, the new bayesian methods are word-granular statistical analysis. I've also seen some that use perl as a wrapper to run various scanners written in other languages, with predictable results.) The problem is instantiating perl once (or more times, if using multiple checks) per every damn message. That isn't cheap. Solutions that use a daemon could write the daemon in perl and it would be less of a problem, provided the client that has to talk to the daemon isn't also perl. msg30618/pgp0.pgp Description: PGP signature
Re: spam harvesting
On Aug 31, Aaron Goldblatt [[EMAIL PROTECTED]] wrote: an fyi so yall know it's happening, my email address used exclusively for mutt-users and mutt-dev has been harvested for spam. i believe i posted to mutt-users exactly once, and never to mutt-dev. Blame the people that are archiving this list on the web without obfuscating the addresses. msg30583/pgp0.pgp Description: PGP signature
Re: spam harvesting
On Aug 31, Sven Guckes [[EMAIL PROTECTED]] wrote: * Jeremy Blosser [EMAIL PROTECTED] [2002-08-31 18:46]: On Aug 31, Aaron Goldblatt [[EMAIL PROTECTED]] wrote: .. my email address used exclusively for mutt-users and mutt-dev has been harvested for spam. i believe i posted to mutt-users exactly once, and never to mutt-dev. Blame the people that are archiving this list on the web without obfuscating the addresses. no - blame the spammers! making information unusable for serious use just because of people misuing it is a step backwards. Hint: putting your hands over your eyes and saying you can't see me! does not, in fact, make you invisible. Put your real address online all you want. They will see you, and your mail servers will scream. msg30597/pgp0.pgp Description: PGP signature
Re: spam harvesting
On Sep 01, Cameron Simpson [[EMAIL PROTECTED]] wrote: On 13:44 31 Aug 2002, Jeremy Blosser [EMAIL PROTECTED] wrote: | On Aug 31, Aaron Goldblatt [[EMAIL PROTECTED]] wrote: | an fyi so yall know it's happening, my email address used exclusively | for mutt-users and mutt-dev has been harvested for spam. i believe i | posted to mutt-users exactly once, and never to mutt-dev. | | Blame the people that are archiving this list on the web without | obfuscating the addresses. Feh. If the addresses are mechanically munged, and decodable by humans reading the archive, then the munging can be undone by address harvesters. And since they don;t care about 100% accuracy, they only have to get it mostly right. Anything they have to do is more cost for them, and means less of them are able to do it. And they aren't known for being bright, either. (At some point, for example, they appear to have determined that addresses of the form '[EMAIL PROTECTED]' are munged forms of '[EMAIL PROTECTED]', which is completely backwards.) Personally, I have long considered hiding from spammers a waste of effort. A laudable ideal perhaps, but futile. Install spamassassin or one of the newer Bayesian filters and cease to hide. You will feel freer. No, I will feel chained to my mail servers as people take that attitude, which has the nice effect of making it so they don't see the spam in their inbox, but the mail servers still see it and have to not only deal with it as normal, but also have to deal with the added processing introduced by determining if each and every message is spam or not, and what to do with it if it is (bounce it, eat it, or add it to Vipul's database or the local bogofilter lists, etc.). The mail servers I support are currently bouncing (or eating) upwards of 20% of their incoming mail volume as spam, on a system that sees upwards of 130k messages per week. We've managed to keep our users from seeing most of their spam using a combination of Vipul's Razor and some local filters, but we admins are having to deal ever more with the effect of it, upgrading and expanding our infrastructure and switching our blocking attempts to more efficient ones as they become available. (We're probably going to have to switch from Vipul's to DCC soon, just to save a little on the network overhead. And we'll be implementing bogofilter as soon as ESR completes the daemonization of it; we can't even consider the overhead until then.) They are of course sites that see much more mail than we do, and I'm sure they have it much worse. Oh, we're also having to continually change our tactics as the spammers do the same. Within days of implementing Vipul's (initially bouncing spam mails to protect against false-positives as we tested the effects it was having) we started getting spam with the forged return addresses set to inside our network, so that when the mails bounced they bounced right into user mailboxes[1]. Note that the same exact tactic *will* work against TMDA-like systems, and will render them completely useless. You can't use TMDA if sending the reply means getting the spam, and preventing yourself from seeing your bounces is asking for trouble and a complete non-option in enterprise environments (we stopped bouncing Vipul spams and just eating them and just hoped for the best false-positive wise, but this isn't an option in a system that depends on sending replies to let legit mail through). You can guard your bounces with something like Vipul's or bogofilter, but that's more overhead. And the more of them that use this method, the less useful TMDA is to actually block spam. This does of course require the spammers to use their own systems to send mail one-to-one instead of dumping on relays, but at least some of them are apparently willing to do it. I am not suggesting that the spam-detection methods aren't useful, but neither are they a complete solution to the problem, and it's negligently naive to think they are. The same is of course true of *just* hiding your address. We need to make spam completely undeliverable by any means at our disposal as soon as possible so they have to just give it up and go get real jobs. And we'll still have to bear the processing burden of checking each and every mail[2] to make sure it stays undeliverable, forever, so the never have the option of starting again. [1] A few of these bounces came with what has to be one of the most fscking evil things ever said by a spammer: This email was sent to you via Saf-E Mail Systems.nbsp; Your email address was automatically inserted into the To and From addresses to eliminate undeliverables which waste bandwidth and cause internet congestion. Your email or webserver bIS NOT /bbeing used for the sending of this mail. [2] BTW, if you get a clever idea for a new spam blocking system, please don't write it in perl. Anything that a serious mail server has to run per every message damn well better be in C or better
Re: Emulating (gaaack) Outlook attribution
On Aug 29, Ken Weingold [[EMAIL PROTECTED]] wrote: On Thu, Aug 29, 2002, Peter T. Abplanalp wrote: you can always try but it has been my experience that these people don't want to change to anything other than M$. if your boss is still semi technical this might work; however, if he has gone totally over to the dark side of management, he is a lost cause. Wow, lucky me that my boss uses mailx or Pine (hey, consider the alternatives) and she was into the idea of us setting up something for ourselves to use the Unix MUA of our choice for work email, but we have Notes and it's a lost cause. We can't enable POP or IMAP either. And you thought Exchange was bad. Is Notes at least able to forward all incoming mail to an address? Our Exchange server doesn't have IMAP enabled either, so I've got some scripts that make it push incoming mail out to a unix box. Exchange can only forward, not redirect/bounce, so the unix box has scripts that strip off the outside fwd container on incoming. So far it works well. msg30550/pgp0.pgp Description: PGP signature
Re: Emulating (gaaack) Outlook attribution
On Aug 30, Ken Weingold [[EMAIL PROTECTED]] wrote: On Fri, Aug 30, 2002, Jeremy Blosser wrote: Is Notes at least able to forward all incoming mail to an address? Our Exchange server doesn't have IMAP enabled either, so I've got some scripts that make it push incoming mail out to a unix box. Exchange can only forward, not redirect/bounce, so the unix box has scripts that strip off the outside fwd container on incoming. So far it works well. Hmm, cool. I will talk to her and maybe set up a Linux box for our mail. We have this huge server for Notes, yet all we use from the whole thing is mail. Only other problem I guess is the address book. I wonder if I can export it to something readable by mutt. If it can be queried externally at all (LDAP, etc.) you should be able to query it directly from mutt. Though I haven't set that up here yet and just have a local address book for most of my contacts, and it works well enough it hasn't bothered me. I guess it helps most of the people here have standard-format user names. msg30556/pgp0.pgp Description: PGP signature
Re: Exchange Exchange!
On Aug 30, Sven Guckes [[EMAIL PROTECTED]] wrote: * Ken Weingold [EMAIL PROTECTED] [2002-08-30 13:19]: On Fri, Aug 30, 2002, Jeremy Blosser wrote: Is Notes at least able to forward all incoming mail to an address? Our Exchange server doesn't have IMAP enabled either, so I've got some scripts that make it push incoming mail out to a unix box. Exchange can only forward, not redirect/bounce, so the unix box has scripts that strip off the outside fwd container on incoming. So far it works well. Hmm, cool. I will talk to her and maybe set up a Linux box for our mail. We have this huge server for Notes, yet all we use from the whole thing is mail. Only other problem I guess is the address book. I wonder if I can export it to something readable by mutt. LDAP and the query_command spring to mind... but this ain't the workarounds for exchange servers list, is it? ;-) I don't remember it being the quit-your-job-if-your-boss-uses-Outlook advocacy list, either. Considering that some of us are talking about just another way to get mail to where Mutt can read it, I'm not considered about topicalness. msg30559/pgp0.pgp Description: PGP signature
Re: Emulating (gaaack) Outlook attribution
On Aug 29, Michael Herman [[EMAIL PROTECTED]] wrote: At work, I use Linux and have been using Mutt and Sylpheed. Yesterday, my boss complained about the format of my e-mails. So to make him happy, I have developed an attribution string that mimics Outlook. Yes, I have to do the same. :( folder-hook $HOME/Mail/Mail-Work/* 'set attribution=\n\n-Original Message-\nFrom: %f\nSent: %d\n%t\nSubject: %s\n\n' Heh. Good idea with the \n's; I've been using some more arcane stuff to get something not quite as good. Forgot newlines would just work. :P This works fine but I have noticed something and I'm not sure how to fix it. Instead of a or |, Outlook indents earlier sections of the mail. Mutt has a way of knowing this using quote_regexp. The problem is, when I read a reply, the latest reply (which is at the top, thank you Microsoft)is left justified but earlier replies which would be indented in Outlook have as the quote character. When I reply to these, it leaves the instead of the tab. This probably isn't mutt, since mutt doesn't rewrite mail like that. Outlook's reply style, such as it is, is configurable. Users can do the indent thing or a thing or a combination. It's likely the person sending you the mails you're noticing this in is just using that as their reply setting. msg30507/pgp0.pgp Description: PGP signature
Re: save-message to scp
On Jun 24, Rocco Rutte [[EMAIL PROTECTED]] wrote: Hi, * Sascha Huedepohl [02-06-24 12:12:38 +0200] wrote: I think it should be possible to write a little shell script which takes the mail per STDIN, then saves it to a .tmp file and scp that file to the other machine. ~/bin/dieter.sh: #!/bin/sh tee /tmp/to-be-scped scp /tmp/to-be-scped ... rm -f /tmp/to-be-scped ~/.muttrc: macro pager ,s '|~/bin/dieter.sh' (just as a starting point) You can also just cat the message directly through ssh: macro pager ,s '|ssh remote_host cat remote_file' msg29189/pgp0.pgp Description: PGP signature
Re: tricky limiting
On Apr 11, David T-G [[EMAIL PROTECTED]] wrote: ...and then Bruno Postle said... % Go to the first message and press esctesctesct etc.. until you've % tagged all the threads. Then limit to show all tagged messages: Aha! I didn't realize that tagging would go beyond limits. It's manual, but it will work. Tagging won't necessarily go beyond limits, it's *-thread commands that go beyond limits. Because of this feature you could just limit to messages with your message ids in the references header and then delete-thread on those messages. I don't like that this works, but in your case it appears to be useful. msg27083/pgp0.pgp Description: PGP signature
Re: broken link in FAQ
On Apr 08, fEd Franks [[EMAIL PROTECTED]] wrote: The FAQ found at the website URL: http://www/fefe/de/muttfaq/faq.html has a broken link... Under How can I report bugs?, the link check Sven's giantlist of known bugs gets me an HTML error: Forbidden ... I would like to know if my error during make install under Solaris 8 is a known bug or not. The canonical list of reported bugs is kept at: http://bugs.guug.de/db/pa/lmutt.html If you lose that link you can find it linked from http://www.mutt.org/ as Current Reported Bugs. msg27004/pgp0.pgp Description: PGP signature
Re: Sending mail to a recipient
On Apr 04, David T-G [[EMAIL PROTECTED]] wrote: ...and then [EMAIL PROTECTED] said... % writing to, but my emails usually start by going into the folder for the % person that I am writing to and clicking an old email from them, then % pressing r which adds in the in-reply-to line in the header. I then % manually Edit the email headers and remove the reference to the reply. If you can get rid of the References: and In-Reply-To: headers, then you're on your way, but if you leave either then mutt will very cleverly ferret out where the message belongs -- even if it no longer belongs there -- and place it for the reader. Not quite; as Cedric noted, you can just remove the IRT header with $edit_headers set and Mutt will Know What You Meant. % There must be an easier way - anyone? :) Yes, there is; use your aliases file or an external query to something like lbdb or abook or ... This is what he did, but a 3rd option is to use 'show-address' (bound to @) for a quick cut-and-paste. msg26717/pgp0.pgp Description: PGP signature
Re: French accentuated letters in 1.3.28i - stable snapshot
On Apr 03, Sven Guckes [[EMAIL PROTECTED]] wrote: * Charles Gagnon [EMAIL PROTECTED] [2002-04-03 14:30]: .. I cannot get mutt-1.3.x to process and display french accentuated letters properly since the support for iconv was introduced. [..] But I compiled libiconv-1.7 and then compiled mutt-1.3.28i and I can't get it to display those accentuated properly. I always end-up with ?, spaces or \009 codes. I added: source /usr/local/doc/mutt/samples/iconv/iconv.solaris-2.7.rc I am running on a Solaris 2.8 system but I couldn't see the solaris-2.8 file anywhere. Any ideas? today the no-iconv patch has been added - and I'll try again tomorrow when Thomas Roessler will upload the current snapshots. maybe then it'll work? i hope so. as a matter of fact i dont' the value in this iconv thing. i just seems to get in the way.. does anyone use it successfully? Er, my understanding* is that all the internal support for extended characters has been dropped in favor of letting libiconv handle it, so no, being able to build without libiconv isn't going to help him. The point of being able to build without it is for people on very old systems that don't (want|need|have) it. For anyone else it seems to have been working fine for some time now. *Very likely flawed or incomplete, since I don't need to deal with it and remain mostly blissfully ignorant on this issue. msg26595/pgp0.pgp Description: PGP signature
Re: display proces id (Re: to GNU ps or not to GNU ps)
On Apr 03, darren chamberlain [[EMAIL PROTECTED]] wrote: (I diff'ed with -caw; is there a preferred option set for mutt patches?) -dup msg26625/pgp0.pgp Description: PGP signature
Re: How do you search to: header?
On Apr 03, jennyw [[EMAIL PROTECTED]] wrote: On Wed, Apr 03, 2002 at 12:53:29PM -0500, David T-G wrote: Hmmm... That certainly sounds like the index. Does your help screen look like Yes, I found it. I was just confused about the search function ... I expected it to work like less where it'd take you to the next occurrence if you searched again. I now realize it just highlights stuff and you still need to page through the list. Doh! Weird, I never noticed before that it doesn't work that way. If you hit 'n' for next it will go to the next match (also found in less). msg26626/pgp0.pgp Description: PGP signature
Re: hiding the pgp sig completely from view?
On Mar 28, John Buttery [[EMAIL PROTECTED]] wrote: * Sven Guckes [EMAIL PROTECTED] [02/03/28 07:58]: well, I had tried to delete those lines with sed pattern /^\[-- .* --\]$/d but it did not work. however, using the following sed pattern makes them go away: /-- .* --/d I'll have to find out why the first pattern did not work... ... Actually, I've had similar trouble trying to colorize some things. ... If I replace the .* at the end with a $ (to make the match tighter), they stop working. It suggests to me that there is some kind of control character or other nonprintable hanging at the end of the line there...but I'm not sure how to determine what it might be. I think Is filter-message seeing the message after the attachment color is applied? If so, and you have an 'attachment' color, there would be some color escape sequences in there. To determine what it is, set your display-filter to some cat command that sends the output to a file. Then you can see just what filter-message sees. msg26353/pgp0.pgp Description: PGP signature
Re: hiding the pgp sig completely from view?
On Mar 28, Jeremy Blosser [[EMAIL PROTECTED]] wrote: Is filter-message seeing the message after the attachment color is applied? s/filter-message/display-filter must not mail before 9am. msg26355/pgp0.pgp Description: PGP signature
Re: Optimizations?
On Mar 27, Simon White [[EMAIL PROTECTED]] wrote: 26-Mar-02 at 11:33, Will Yardley ([EMAIL PROTECTED]) wrote : if you have shell access on your mail machine, and it's on a good connection, i'd just run mutt on the machine itself. ... Secondly, on a dialup link, it's too slow if you SSH somewhere and you have to /compose/ mail. For moving around the screen, even if you're good with vim (or whatever you set $THE_ONE_TRUE_EDITOR to) is not responsive enough. And if you have a connection that is fast enough not to notice that, you can probably download mail fast anyway. I SSH to my workstation from a fixed IP authenticated dialup connection at home and it's too slow to compose mail, although reading mail is quicker with Mutt than PINE running locally and just fetching mail from the server. This is largely due to the pager allowing faster browsing of mail. Weird. I used to do this all the time before I had DSL, and it was never a problem. And the mail server I was connecting to was a 486 w/12M of RAM. The initial connection was slow, but after that it was fine. Are you using SSH compression? It helps a lot. msg26270/pgp0.pgp Description: PGP signature
Re: Optimizations?
On Mar 27, Simon White [[EMAIL PROTECTED]] wrote: 27-Mar-02 at 08:33, Jeremy Blosser ([EMAIL PROTECTED]) wrote : On Mar 27, Simon White [[EMAIL PROTECTED]] wrote: Secondly, on a dialup link, it's too slow if you SSH somewhere and you have to /compose/ mail. For moving around the screen, even if you're good with vim (or whatever you set $THE_ONE_TRUE_EDITOR to) is not responsive enough. And if you have a connection that is fast enough not to notice that, you can probably download mail fast anyway. I SSH to my workstation from a fixed IP authenticated dialup connection at home and it's too slow to compose mail, although reading mail is quicker with Mutt than PINE running locally and just fetching mail from the server. This is largely due to the pager allowing faster browsing of mail. Weird. I used to do this all the time before I had DSL, and it was never a problem. And the mail server I was connecting to was a 486 w/12M of RAM. The initial connection was slow, but after that it was fine. Are you using SSH compression? It helps a lot. How fast do you type? I'm at ~55wpm if typing easy mail where I don't think too much. Faster than that. Not sure if I had compression set. In any case, I don't like ANY delay between keypress and letter appearing on screen, since I'm not looking at the keys as I type, and if the display is constantly catching up it throws me right off. You probably didn't have compression set. Try running ssh with the -C option. It makes a dramatic difference. msg26283/pgp0.pgp Description: PGP signature
Re: Optimizations?
On Mar 27, Simon White [[EMAIL PROTECTED]] wrote: 27-Mar-02 at 11:09, Jeremy Blosser ([EMAIL PROTECTED]) wrote : You probably didn't have compression set. Try running ssh with the -C option. It makes a dramatic difference. So, I have PuTTY for SSH, will look into the options and check that out tonight. It should still help, but probably not as much. I've not seen a windows terminal emulator that didn't run a whole lot slower than seemed necessary. msg26290/pgp0.pgp Description: PGP signature
Re: unmessage-hook?
On Mar 27, Sven Guckes [[EMAIL PROTECTED]] wrote: There is no way to remove a message-hook, is there? So once you screw up with the pattern or whatever then you have to correct your setup and restart mutt, right? unhook message-hook This removes all message-hooks currently defined, but it's the only option. msg26313/pgp0.pgp Description: PGP signature
Re: unmessage-hook? - unhook message-hook
On Mar 28, Sven Guckes [[EMAIL PROTECTED]] wrote: * Jeremy Blosser [EMAIL PROTECTED] [2002-03-27 23:05]: On Mar 27, Sven Guckes [[EMAIL PROTECTED]] wrote: There is no way to remove a message-hook, is there? So once you unhook message-hook This removes all message-hooks currently defined, but it's the only option. :-/ ... Sven [adding one more item for the pet peeves list] The un* functions are pretty clean; I doubt it would be very hard to scratch this one if it itches you. msg26322/pgp0.pgp Description: PGP signature
Re: unmessage-hook? - unhook message-hook
On Mar 28, Sven Guckes [[EMAIL PROTECTED]] wrote: * Jeremy Blosser [EMAIL PROTECTED] [2002-03-27 23:49]: Sven [adding one more item for the pet peeves list] The un* functions are pretty clean; I doubt it would be very hard to scratch this one if it itches you. so much for theory. ? well, i find it bad by design that message-hook does not have an matching unmessage-hook command. There's really no difference between 'unmessage-hook', 'unsend-hook', 'unfoo-hook', etc. vs. 'unhook message-hook', etc. It could be argued either was cleaner than the other, for different reasons. In the end it's just semantics. But if you don't like it, by all means submit a diff to extend the functionality. this should be taken care of before mutt-1.4 ships. Er, is there any conceivable change you *don't* think should be done before 1.4 ships? It's called perspective. Try it sometime. then again, obviously not many people are using it. ? msg26327/pgp0.pgp Description: PGP signature
Re: hiding the pgp sig completely from view?
On Mar 28, Sven Guckes [[EMAIL PROTECTED]] wrote: [-- Attachment #2 --] [-- Type: application/pgp-signature, Encoding: 7bit, Size: 0.2K --] [-- application/pgp-signature is unsupported (use 'v' to view this part) --] that is, mutts still shows the pgp sig (like an extra attachment). ok, this text gets its own color and all - that's not so bad. but - is there a way I can just *hide* the pgp sig *completely* from view? Mutt doesn't see that attachment as any different from any other one when it isn't verifying them, so no. You can use your new friend display-filter to gag those lines... you may get some false-positives though; your original message is a good example. Messages like that are rare though and the subject matter usually makes it obvious what they are talking about. msg26334/pgp0.pgp Description: PGP signature
Re: reverse_name question
On Mar 26, Tim Kennedy [[EMAIL PROTECTED]] wrote: Sorry if this has been asked a lot. I've been looking through the 'net, and various archives of various messages, for an answer to how I can get mutt to reply to emails using the To address, as the From address. ... set reverse_name = yes set alternates = [EMAIL PROTECTED]|[EMAIL PROTECTED] ... I still am not getting the behavior that I expect. It always sends from the defined from, [EMAIL PROTECTED]. If I unset the from, then it sends from the local account, and uses the real name from the gecos field of /etc/passwd. Your settings look fine. Whatever is going wrong here, it's not standard behaviour. Are you sure you don't have a typo or something in your actual alternates setting? Try making it just the abuse address and see if that one at least catches. msg26226/pgp0.pgp Description: PGP signature
Re: Bug Report Guide - additions?
On Mar 25, Sven Guckes [[EMAIL PROTECTED]] wrote: * Jeremy Blosser [EMAIL PROTECTED] [2002-03-20 03:23]: Second, it is wrong as far as it goes. flea(1) doesn't send anything to debian.org. SUBMIT=[EMAIL PROTECTED] DEBIAN_SUBMIT=[EMAIL PROTECTED] hmm... isn't DEBIAN_SUBMIT used at all? Oops, I forgot, flea does check to see if it thinks you are running Debian, and if so it submits a Cc to the Debian BTS. But that's only a Cc, the mutt BTS is the one at guug.de. Also, it's not that useful to suggest people send bugs to mutt-users, since most people that frequest this list aren't developers. mutt -v requests bug reports go to mutt-dev, and that's where they should go. well, considering the amount of data this generates mutt-dev isn't the place to take in such huge mails, either. mutt-dev is the place where the developers want the bugs to come so that the appropriate people see them, and if discussion needs to happen, it happens with the appropriate people around. mutt-dev. But please refrain from posting dumping your complete setup there. It's been established that it's better if they post to much info than not enough. That's why flea behaves as it does. You may not want that traffic, but that's your own choice about what kinds of lists you yourself want to monitor. Bug reports to mutt-dev are expected to be verbose. Remember that sending to the mailing list requires subscription; mails from unsubscribed addresses will go to a moderator - and I'm not whether anyone really moderates those mails... Someone moderates those mails. Usually several someones do. msg26100/pgp0.pgp Description: PGP signature
Re: Bug Report Guide - additions?
On Mar 25, Jeremy Blosser [[EMAIL PROTECTED]] wrote: On Mar 25, Sven Guckes [[EMAIL PROTECTED]] wrote: well, considering the amount of data this generates mutt-dev isn't the place to take in such huge mails, either. mutt-dev is the place where the developers want the bugs to come so that the appropriate people see them, and if discussion needs to happen, it happens with the appropriate people around. Oh, in case there was any confusion there: flea sends it the BTS, and the BTS sends copies of most everything it sees to mutt-dev. The sender can tell the BTS not to forward a given message, but that's the exception. msg26102/pgp0.pgp Description: PGP signature
Re: Defanged HTML headers [WAS: Re: [Announce] Mutt 1.3.28 (BETA) is out.]
On Mar 18, John Buttery [[EMAIL PROTECTED]] wrote: * Carl B. Constantine [EMAIL PROTECTED] [2002-03-18 08:43:58 -0800]: all I get at this page is the following: HEADDEFANGED_META HTTP-EQUIV=REFRESH CONTENT=0 URL=http://cedricduval.free.fr/mutt/;/HEAD that is displayed in NS 6.2.1 (solaris). You have a proxy server that is defanging tags for you (to protect from malicious META headers, Javascript, yadda yadda). You need to remove the DEFANGED_ so it just says ...META ... and it will redirect properly. Or you could just hit that URL it lists there directly and skip the redirection altogether. :) The version of Carl's mail that I saw did not have the defanged prefix. Are you sure your proxy isn't doing this for you in his incoming mail? msg25841/pgp0.pgp Description: PGP signature
Re: Bug Report Guide
On Mar 16, Sven Guckes [[EMAIL PROTECTED]] wrote: I have updated my text about reporting bugs and made it available as a separate page: http://www.math.fu-berlin.de/~guckes/mutt/bugrep.html Additions? Corrections? Feedback welcome! The last sentence of the top section is: The report then gets sent to debian.org and there enters the First, this is incomplete. Second, it is wrong as far as it goes. flea(1) doesn't send anything to debian.org. Also, it's not that useful to suggest people send bugs to mutt-users, since most people that frequest this list aren't developers. mutt -v requests bug reports go to mutt-dev, and that's where they should go. And while you need to be subscribed to the lists to post to them normally, other legitimate mails (especially bug reports) will make it through the moderators. It's not necessary to tell people they have to subscribe before they can even report a bug. I see bugs posted to comp.mail.mutt get forwarded to mutt-dev periodically, but I have no idea what developers actively monitor that newsgroup or how many of the reports make it to mutt-dev. In any case, people really should just use flea if they want to get a tracked resolution/not fall through the cracks. msg25750/pgp0.pgp Description: PGP signature
Re: display of flagged message in collasped thread
On Mar 17, parv [[EMAIL PROTECTED]] wrote: i am currently using v1.3.27i. is it possible to show the flag-message indicator for a collapsed thread? currently i see when threads are collasped... It can't be done now but it's been requested a few times. msg25751/pgp0.pgp Description: PGP signature
Re: Mutt 1.3.28 + ncurses 5.2 + xterm = blank screen
On Mar 18, Thomas E. Dickey [[EMAIL PROTECTED]] wrote: On Mon, 18 Mar 2002, Pavel Roskin wrote: I've compiled mutt-1.3.28i in the default configuration on RedHat Linux 7.2 (i386) with all updates. If I run it in xterm (from XFree86-4.1.0) or in rxvt-2.7.6, it shows a blank screen. I can quit by pressing Ctrl-C and Enter. The same executable runs on the Linux console just fine. ... Unsetting COLORFGBG fixes the problem. that's a bug that I fixed in September. The problem was that when I coded the $COLORFGBG logic (which btw is under-documented in rxvt - you have to read the C code to see it), it didn't occur to me that its format might change. It happens that the format depends on whether xpm is linked in - 2 or 3 fields. The background color is the last field. Indeed; Pavel, please see http://bugs.guug.de/db/10/1011.html for this bug and the resolution, and ignore the mails from Cindy. $COLORFGBG is marked as an experimental feature. I've gotten 2-3 reports of this particular problem - but only months after I stumbled on it myself. Apparently one or more of the rpm's last year turned that feature on, though it was in the code almost a year. Well, I think it was more the other bug where it would get turned on if other development features like hard-tabs were turned on. It was apparently a combination of these two. msg25752/pgp0.pgp Description: PGP signature
Re: Mutt 1.3.28 + ncurses 5.2 + xterm = blank screen
On Mar 19, Jeremy Blosser [[EMAIL PROTECTED]] wrote: Well, I think it was more the other bug where it would get turned on if other development features like hard-tabs were turned on. It was apparently a combination of these two. Sorry, I mean a combination of the colorfgbg bug, and the bug where colorfgbg was enabled when unrelated dev features were enabled. msg25753/pgp0.pgp Description: PGP signature
Re: Mail-Followup-To on mutt-users redundant?
On Mar 15, Shawn McMahon [[EMAIL PROTECTED]] wrote: This one time, at band camp, Jeremy Blosser wrote: Not for list-reply. The important thing to make this command work is letting mutt know which mails are from lists, using the 'subscribe' and 'lists' commands. Bleargh. What a pain in the ass. Most of my mailing lists identify themselves with non-standard but commonly-used headers, and you'd think it could at least intuit a mailing list and prompt, even with the ones that don't, with a few exceptions. Mutt's handling of this stuff predates most of these commonly-used headers by years. Recently several people have suggested using these newer list headers to intuit mailing list addresses, but no one who cares has produced working code yet, and the rest of us seem to be following if it ain't broke, don't fix it. msg25567/pgp0.pgp Description: PGP signature
Re: Mail-Followup-To on mutt-users redundant?
On Mar 15, Shawn McMahon [[EMAIL PROTECTED]] wrote: This one time, at band camp, Dave Pearson wrote: Perhaps I'm missing something here but I don't use list-reply to tell mutt that an email is from a mailing list, I use list-reply to tell mutt that I want to respond to the list it was from (instead of to the author of the email, or whatever). Uh huh. And we're discussing making Mutt handle that without you having to put two statements in the config file for every list you're on, just for the ones that are too hard to figure out programmatically. You only need one statement in the config file per list. 'subscribe' and 'lists' are two different but related commands. One is for lists you are subscribed to, the other is for lists you may see mail from/send mail to but are not actually subscribed to. Which of the two you use to tell mutt about a list determines how things like the MFT header are generated. (If you're subscribed, you don't want your address in MFT. If you're not subscribed, you do want your address in MFT.) Note that this distinction is another piece that would be missed if we just relied on the list headers. Also, FWIW, it isn't even one statement per list. You can put as many lists as you want on one line, and the entries themselves are patterns matched against the address, so one entry can match multiple lists if you write it that way. I maintain that a sufficient percentage of them are NOT too hard to figure out that it's worth doing. If you want to see this, you probably need to produce a patch that does it in a quality way. I haven't heard any of the developers interested in changing how it works now. msg25572/pgp0.pgp Description: PGP signature
Re: GPG revisited
On Mar 15, Derek D. Martin [[EMAIL PROTECTED]] wrote: This really isn't ideal. What I'd like to know is if there is a way to tell mutt when I hit enter to enter a message, do an Esc-P first. This way, the delay is much smaller and virtually unnoticable. Really what I'd like is for mutt to do this automatically... macro index return check-traditional-pgpdisplay-message msg25601/pgp0.pgp Description: PGP signature
Re: Non-interactive command line send
On Mar 14, Sven Guckes [[EMAIL PROTECTED]] wrote: * Simon White [EMAIL PROTECTED] [2002-03-14 10:24]: I have a script which grabs today's Garfield comic, and /should/ then send it on to my wife. This is what I have: mutt -x -s Daily\ Garfield -a ga$theimg.jpg [EMAIL PROTECTED] echo smooches | mutt -s Daily Garfield -a ga$theimg.jpg [EMAIL PROTECTED] FWIW you can also just redirect stdin from something like /dev/null if you want a completely empty body. Pretty standard *nix stuff. mutt -s foo [EMAIL PROTECTED] -a img.jpg /dev/null msg25542/pgp0.pgp Description: PGP signature
Re: Semi-OT: Mailman and MUAs
On Mar 11, Lorin Winchester [[EMAIL PROTECTED]] wrote: This is semi-off-topic, but it somewhat relates to Mutt and Mailman. I'm on another mailing list that was recently switched from Majordomo to Mailman. Many times when users try to reply privately to a poster they end up posting to the list. This causes many complaints about Mailman being a poor piece of software. I (and others on the list using Mutt) have never noticed this bug that the (l)users speak of, since Mutt handles mailing lists VERY well. The More specifically, mutt routes around munging of reply-to and other headers as much as is possible. complaints come from those using LookOut!, AOL, and other Windoze MUAs. The list administrator says that this is just Mailman's standard behavior and it can't be changed. I'm almost 100% sure that this can be easily changed. I don't know if it can be changed or not in mailman. I think all of the mailman lists I'm on do provide a reply-to header. Othat attributes that software has would make it not surprise me if you indeed can't change that. You'd probably find something if you searched the web a little. So is this a case of users not knowing how to properly configure/use their MTAs, or is it a case of the list administrator not knowing how to properly setup the list? I posted this here since this list runs Mailman and I've heard no comments here about this. There also seems to be a good number of knowledgeable people here. These lists are majordomo, not mailman. msg25291/pgp0.pgp Description: PGP signature
Re: Scoring known addresses
On Feb 28, Volker Moell [[EMAIL PROTECTED]] wrote: Is there a posibillity to score all known mail addresses (i.e. all addresses defined in aliases) in one single score statement? David Champion has a patch for this... you can find a link to it from www.mutt.org in the user patches section. msg25105/pgp0.pgp Description: PGP signature
Re: Various questions from a new user
A little more info... On Mar 04, Mike Schiraldi [[EMAIL PROTECTED]] wrote: 1: What does the * mean on the tree arrow in a thread? I've searched the manual for this repeatedly, but I must keep missing it. This might not be in there yet -- mutt's threading subsystem was recently overhauled, and i'm not sure if the old one had a *. It's been there forever. It means that mutt thinks the message is part of the thread, but isn't sure exactly where in the thread it belongs. For example, it might have a subject which matches the thread, but no specific In-Reply-To header explaining exactly where it belongs. See the manual re: strict_threads for more info. folder-hook . 'ignore X- Resent- Errors-To Envelope-To' folder-hook IN-Spambox 'unignore *' This is a wild guess, but try putting a '\' before the '-', since the first arg is a regexp. Yeah, in general you need to make sure that IN-Spambox matches the folder you want, and that you don't need something like =IN-Spambox. msg25106/pgp0.pgp Description: PGP signature
Re: Selecting messages in my threads
On Feb 21, Daniel Eisenbud [[EMAIL PROTECTED]] wrote: On Thu, Feb 21, 2002 at 02:52:57PM +, Bruno Postle [EMAIL PROTECTED] wrote: On Thu 21-Feb-2002 at 03:28:48PM +0100, Alexander Skwar wrote: Hmm, but how to do this? Sometimes, messages don't contain my message-id in the References, aren't To: or Cc: me (eg. a message far down in the thread), but mutt will still show that it belongs to a given thread. You can't with the current 'limit' command. A context-limit ability (like grep -C) would be a useful refinement to mutt though. In fact, most of the time I use 'limit' I would prefer to use a more general context-with-threads-limit than the current behaviour. I often find myself limiting to a pattern, picking a message, showing everything to see the thread, limiting again, picking a message etc.. Hmm, maybe a tag-pattern-threads and a limit-pattern-threads command? I think some pattern matching modifiers would be more general purpose: - one for 'all messages in the same thread as a message that matches this pattern' - one for 'parent message of the thread of a message that matches this pattern' - one for 'all children of a message that matches this pattern' These can all be used for tag-pattern and limit-pattern, but also for colors, etc. I guess there aren't actually any pattern match modifiers in the real source, but there are several patches to add these, and they are useful. There's even one that already does the last one above, but the other two are the ones I usually want, especially the first; it'd be nice to be able to view threads while they are collapsed and still see that a thread had a flagged message, or color it when it contains new messages (it does get the small 'n' but colors are easier to see, esp when other new messages are colored). The kind of thing mentioned in http://bugs.guug.de/db/40/408.html seems really useful to me, but I'd rather see it based on pattern matching. Sounds useful to me, and relatively easy to implement. As it is, I usually limit, and do tag-thread on each visible message, and then limit to tagged, which works but is kind of a pain. It also is odd to me it works... you can affect messages you can't actually see using tag-thread, but not otherwise? (The one that always bites me is when I enter a big mailbox with threads collapsed by default, read the stuff I want, then try to do delete-pattern~N without uncollapsing threads first.) msg24641/pgp0.pgp Description: PGP signature
Re: tagging and copying/saving
On Feb 21, Fred Dech [[EMAIL PROTECTED]] wrote: in Elm, i could tag numerous emails and then group copy or save them to a folder. when i try this in Mutt, only the currently selected email gets appended to the specified folder. am i missing something obvious? how is this normally achieved in Mutt? Lookup tag-prefix and $auto_tag in the manual. one other question. is there a way to enable wildcards in order to get a subset menu of one's entire folder list (e.g. change to =myJunk_*)? another elmism i can live without... but don't wanna! If you're doing change-folder, you should be able to do =myJunk_tabtab to see a list of matching folders (the first tab would just complete the line if there was only one match, the second tab brings up a list if the first remains ambiguous). msg24651/pgp0.pgp Description: PGP signature
Re: field parsing behavior
On Feb 20, Tim Whitehead [[EMAIL PROTECTED]] wrote: If someone sends me an email and they don't have their name before their email address, mutt thinks that the name and the email address are the same. When it should recognize that the email address is just the email address. I noticed this because I have set attribution=Le jour %d, %n (%a) a écrit...\n and the %n is the same as %a. So when I'm replying it's Le jour ~~, [EMAIL PROTECTED] ([EMAIL PROTECTED]) a écrit... Which is bad French, but that's irrelevant here. Or I could be doing it completely wrong. This is the documented behaviour: %n author's real name (or address if missing) See the Fine Manual on $index_format. msg24614/pgp0.pgp Description: PGP signature
Re: Decrypting GPG-encoded messages
On Feb 15, Dave Smith [[EMAIL PROTECTED]] wrote: Is anyone willing/able to send me a .muttrc which works with GnuPG and a recent version of mutt? # Name: forward_decrypt # Type: boolean # Default: yes # Controls the handling of encrypted messages when forwarding a message. When # set, the outer layer of encryption is stripped off. This variable is only # used if ``$mime_forward'' is set and ``$mime_forward_decode'' is unset. set forward_decrypt=yes # Name: pgp_autosign # Type: boolean # Default: no # Setting this variable will cause Mutt to always attempt to PGP/MIME sign # outgoing messages. This can be overridden by use of the pgp-menu, when # signing is not required or encryption is requested as well. set pgp_autosign=yes # Name: pgp_autoencrypt # Type: boolean # Default: no # Setting this variable will cause Mutt to always attempt to PGP/MIME encrypt # outgoing messages. This is probably only useful in connection to the # send-hook command. It can be overridden by use of the pgp-menu, when # encryption is not required or signing is requested as well. send-hook . set pgp_autoencrypt=no send-hook mark(|-.*)@(firinn|cymry).org set pgp_autoencrypt=yes #... # Name: pgp_ignore_subkeys # Type: boolean # Default: yes # Setting this variable will cause Mutt to ignore OpenPGP subkeys. Instead, the # principal key will inherit the subkeys' capabilities. Unset this if you want # to play interesting key selection games. set pgp_ignore_subkeys=yes # Name: pgp_entry_format # Type: string # Default: %4n %t%f %4l/0x%k %-4a %2c %u # This variable allows you to customize the PGP key selection menu to your # personal taste. This string is similar to ``$index_format'', but has its own # set of printf()-like sequences: # %n number # %k key id # %u user id # %a algorithm # %l key length # %f flags # %c capabilities # %t trust/validity of the key-uid association # %[s] date of the key where s is an strftime(3) expression set pgp_entry_format=%4n %t%f %4l/0x%k %-4a %2c %u # Name: pgp_good_sign # Type: regular expression # Default: # If you assign a text to this variable, then a PGP signature is only # considered verified if the output from $pgp_verify_command contains the text. # Use this variable if the exit code from the command is 0 even for bad # signatures. set pgp_good_sign=^gpg: Good signature from # Name: pgp_long_ids # Type: boolean # Default: no # If set, use 64 bit PGP key IDs. Unset uses the normal 32 bit Key IDs. set pgp_long_ids=no # Name: pgp_replyencrypt # Type: boolean # Default: yes # If set, automatically PGP encrypt replies to messages which are encrypted. set pgp_replyencrypt=yes # Name: pgp_replysign # Type: boolean # Default: no # If set, automatically PGP sign replies to messages which are signed. # Note: this does not work on messages that are encrypted and signed! set pgp_replysign=yes # Name: pgp_replysignencrypted # Type: boolean # Default: no # If set, automatically PGP sign replies to messages which are encrypted. This # makes sense in combination with ``$pgp_replyencrypt'', because it allows you # to sign all messages which are automatically encrypted. This works around # the problem noted in ``$pgp_replysign'', that mutt is not able to find out # whether an encrypted message is also signed. set pgp_replysignencrypted=yes # Name: pgp_retainable_sigs # Type: boolean # Default: no # If set, signed and encrypted messages will consist of nested multipart/signed # and multipart/encrypted body parts. # This is useful for applications like encrypted and signed mailing lists, # where the outer layer (multipart/encrypted) can be easily removed, while the # inner multipart/signed part is retained. set pgp_retainable_sigs=no # Name: pgp_show_unusable # Type: boolean # Default: yes # If set, mutt will display non-usable keys on the PGP key selection menu. # This includes keys which have been revoked, have expired, or have been marked # as ``disabled'' by the user. set pgp_show_unusable=no # Name: pgp_sign_as # Type: string # Default: # If you have more than one key pair, this option allows you to specify which # of your private keys to use. It is recommended that you use the keyid form # to specify your key (e.g., ``0x00112233''). set pgp_sign_as=0xF009764F # Name: pgp_strict_enc # Type: boolean # Default: yes # If set, Mutt will automatically encode PGP/MIME signed messages as # quoted-printable. Please note that unsetting this variable may lead to # problems with non-verifyable PGP signatures, so only change this if you know # what you are doing. set pgp_strict_enc=yes # Name: pgp_timeout # Type: number # Default: 300 # The number of seconds after which a cached passphrase will expire if not # used. set pgp_timeout=0 # Name: pgp_verify_sig # Type: quadoption # Default: yes # If ``yes'', always attempt to verify PGP/MIME signatures. If ``ask-yes'' or # ``ask-no'', ask whether or not to verify the signature. If ``no'', never # attempt
Re: forground color of the indicator
On Feb 13, Marc Bruenink [[EMAIL PROTECTED]] wrote: Is it possible to set the indicator foreground color to none? I mark new, old mails with colors and so i don't want to let the indicator change it. Currently there isn't, but Mike Schiraldi has a patch which is also in the CVS version that allows the indicator to just reverse the current colors on a message, which may be better for you than nothing. msg24479/pgp0.pgp Description: PGP signature
Re: forground color of the indicator
On Feb 13, Jeremy Blosser [[EMAIL PROTECTED]] wrote: On Feb 13, Marc Bruenink [[EMAIL PROTECTED]] wrote: Is it possible to set the indicator foreground color to none? I mark new, old mails with colors and so i don't want to let the indicator change it. Currently there isn't, but Mike Schiraldi has a patch which is also in the CVS version that allows the indicator to just reverse the current colors on a message, which may be better for you than nothing. Ok, technically you could set $arrow_cursor, but this isn't really what you want I'm guessing. msg24480/pgp0.pgp Description: PGP signature
Re: [simon@mtds.com: Re: Previous issue with ~/mbox]
On Feb 12, Simon White [[EMAIL PROTECTED]] wrote: Now I just need a tip (if anyone has a simple way of doing it) for getting rid of duplicates in mbox (there are loads of each read message) and then I can hack the synchronisation with my inbox myself, I guess. If they are real duplicates (ie same message-id) you can do 'D~=', which with the default keybindings expands to 'delete-pattern', with '~=' (duplicate messages) as the pattern. Search the manual for 'duplicate_threads' for more information and options. Note that ~= is new with 1.3.26. Your User-Agent is listed as 1.3.27, so you should be fine, but if you have a different version where you have the problem please keep this mind. msg24449/pgp0.pgp Description: PGP signature
Fwd: [Patch] 1.3.x without iconv
There have been various comments here by people attempting to move from the 1.2.x tree to the 1.3.x tree about the new iconv requirement, and the fact that the --without-libiconv option documented in INSTALL does not actually work. Lars Hecking posted the attached message patch to mutt-dev as part of an attempt to get this resolved by 1.4, but it needs testing. I'm reposting it here so it can hopefully get some more, since most of the -dev crowd already resolved this by having a good enough iconv locally. If you have problems or comments related to this patch please post them back to mutt-dev. ---BeginMessage--- See attached. Warning: this is a HACK, no matter how ingeniously executed. It allows to compile mutt-1.3.27 without iconv support, and it does just that. I cannot guarantee and haven't tested that a patched mutt performs correctly in every respect, only made it compile. These changes should go into cvs/distribution, they are independent of the rest: * charset.c, gnupgparse.c, rfc2047.c: don't #include iconv.h, charset.h already does it * init.h: conditionalise iconv-hook for HAVE_ICONV (fair enough, no?) These changes should no go into cvs/distribution, on account of being an untested hack: * charset.h: conditionalise iconv.h inclusion for HAVE_ICONV_H; add iconv_t definition, and prototypes for iconv_open(), iconv() iconv_close() if there is no system iconv(); mutt's iconv functions already have fallbacks if no system iconv is available, but we still need the prototypes/typedef to get everything compiled in the first place * configure.in: add check for iconv.h; add check for iconv_t; emit a warning rather than an error if iconv is not found * sendlib.c: let convert_file_to() always fail with -1 if iconv() is not available === * m4/iconv.m4: change --with-libiconv-prefix=DIR to --with-iconv[=DIR] and check for no; this makes configure compatible to INSTALL :) Caveat: this change makes MUTT_AM_ICONV totally incompatible with (but also better than ;) AM_ICONV. That's the main reason I don't want this in cvs or distribution, I would like to see the generic AM_ICONV changed to do something useful. === No auto* generated files included. patch-1.3.27.lh.noiconv.1.gz Description: application/gunzip ---End Message--- msg24452/pgp0.pgp Description: PGP signature
Re: setting from on compose
On Feb 12, Daniel Sully [[EMAIL PROTECTED]] wrote: Hi - I'm not finding the functionality (or it's hiding from me) of when I hit 'c' for composing a message, the ability to set a From: address right there, just like a To: and Subject: line is set. No, I don't want to just edit the headers afterwards, I want this to be a pseudo send-hook. I have a send-hook setup for when I reply to a message that comes in to a a certain address, but there doesn't seem to be an easy way to do that when I want to compose a new email *as* that from address. Right now the only ways to manually change the From: header are by using $edit_hds or using edit-from (default bound to escf) from the compose menu. There's no option to have it show up as one of the headers you're prompted for before composing. I guess that would be $askfrom if it were there, but it isn't. Any ideas, or should I start hacking on compose.c ? Hack away. msg24456/pgp0.pgp Description: PGP signature
Re: How can I underline the current index entry?
On Feb 10, Benjamin Smith [[EMAIL PROTECTED]] wrote: On Sat, Feb 09, 2002 at 04:01:49PM -0600, Jeremy Blosser wrote: It can't be done. Mono attributes are not currently available when color attributes are being used. Why is this? This is a mutt limitation isn't it, as other ncurses apps (w3m) can colour *and* underline, perhaps this should get placed on a TODO list? Yes, it's specific to the way Mutt is written. It's in the BTS somewhere already. msg24391/pgp0.pgp Description: PGP signature
Re: Could I temporarily switch smtp server?
On Feb 11, Charles Jie [[EMAIL PROTECTED]] wrote: On Sun, Feb 10, 2002 at 09:26:48PM -0500, Scott Lambert wrote: On Mon, Feb 11, 2002 at 09:52:34AM +0800, Charles Jie wrote: Due to an annoying firewall strategy on a mailing list server, I can not use my own server to send it mail. What I can do is using ISP's smtp server. Is it possible for mutt to switch smtp server (by default it uses my postfix) to my ISP's with send-hook? I didn't find a related variable. Just set relay_host=mail.yourisp.com in postfix's main.cf. Do you mean that mutt can not have and switch among multiple smtp servers like netscape does? To send mail, something local on your computer has to speak smtp to other computers. Understood this way, Netscape does not just switch among multiple smtp servers. It instead is its own smtp server, with only the ability to point to a remote relay (and maybe some smtp auth stuff, I don't know). Mutt leaves this functionality to the local program of your choice and worries about other things itself. You can use something featured like postfix, or just something like ssmtp which (like Netscape) has only the ability to point to a remote relay. msg24400/pgp0.pgp Description: PGP signature
Re: How can I underline the current index entry?
On Feb 09, Daniel Farnsworth Teichert [[EMAIL PROTECTED]] wrote: So I'd really like to be able to *underline* the current entry, or perhaps make it bold, or something like that. But I haven't been able to find a way to do this. If the mono settings could somehow work in conjunction with the color settings--but in all my experimentation this has never worked right. Could someone point me to a place to find out more about this, or give me a pointer or two, or tell me it can't be done? Thanks! It can't be done. Mono attributes are not currently available when color attributes are being used. However, Mike Schiraldi has a patch to make just the indicator bar able to do inverse even when in color mode. You can find it by searching the list archives. msg24375/pgp0.pgp Description: PGP signature
Re: Toggle to weed=yes for fwding only
On Feb 08, William Guynes [[EMAIL PROTECTED]] wrote: I tend to not want to see all headers normally (having a full screen of headers just doesn't entice me to read the message). But, I tend to need them when I report spam using forward. If you turn off $forward_decode you'll get this effect without touching $weed. I've given thought to re-binding the default forward key to... 1) set weed=yes 2) forward-message 3) set weed=no Er, you do realize this turns $weed on for forwarding, and off otherwise, which is the opposite of what you first said you wanted? From looking at all the available examples, I think I'll have to make a macro then bind the f key to it. Is there a way to perform a set command in a keybinding? If so, what's the syntax for multiples, assuming no macro? Multiple what? A keybinding is to bind a key to a defined function in a key map. Anything more complex is by definition a macro. There's nothing bad about using a macro instead of keybinding, either, so it doesn't really matter... Also, I'm not sure I can perform the toggle while in index mode, but would have a better chance in pager mode. Can the binding even do the toggle in index menu? Short answer: yes. Longer answer: Macros can call enter-command from anywhere, and 'set' is always a valid command. msg24345/pgp0.pgp Description: PGP signature
Re: Toggle to weed=yes for fwding only
On Feb 08, Will Yardley [[EMAIL PROTECTED]] wrote: Has anyone else had a desire to be able to toggle weed=yes for only certain instances of pager, reply, or forward? yes. i use: ## put headers in the edit buffer if i'm forwarding macro index f :set header\nforward-message macro index r :unset header\nreply macro pager f :set header\nforward-message macro pager r :unset header\nreply This isn't doing what you think it is. $header is only valid in a reply context. You always get headers when you forward a message, in the body if not mime forwarding and as part of the mime message if mime forwarding. $header basically gives you that header functionality when replying as well, though forwarding respects both $weed and $forward_decode, which there is no cooresponding $reply_decode, so $weed always applies to $header. Anyway, your above settings basically have no effect beyond what a universal 'unset header' would do. msg24346/pgp0.pgp Description: PGP signature
Re: Toggle to weed=yes for fwding only
On Feb 08, Will Yardley [[EMAIL PROTECTED]] wrote: Jeremy Blosser wrote: This isn't doing what you think it is. well it has the effect i want anyway, which 'unset header' doesn't. You miss the point; it shouldn't have any effect at all. And by shouldn't I mean doesn't, unless I'm completely missing something. You get headers included when you forward regardless of the setting of $header. How many you get depends on the settings of $weed, $forward_decode, and 'ignore' commands. msg24349/pgp0.pgp Description: PGP signature
Re: Scripted GPG-encrypted mails
On Feb 07, Dave Smith [[EMAIL PROTECTED]] wrote: On Thu, Feb 07, 2002 at 09:30:03AM -0600, [EMAIL PROTECTED] wrote: Well, I'm not sure how to do this on the command line, but in a script (or possibly on the command line given enough voodoo) you could gpg-encrypt the file first, use --output to generate a gpg-crypted output file, and then call mutt with -a to attach that file to a message. Is that what you had in mind? Well, that's closer (and less work at the receiving end), but it still doesn't come out like a 'proper' PGP/MIME mail. Use mutt -e or -F to invoke a specific set of configs for this task that encrypt all mail sent. You may run into confirmation dialogues for the key you're encrypting to... if so, there are patches linked from www.mutt.org that can get rid of these. mutt recipient -a file_to_attach -s subject -e configs /dev/null msg24286/pgp0.pgp Description: PGP signature
Re: Sorting in mailbox question
On Feb 06, Christian Ordig [[EMAIL PROTECTED]] wrote: On Mon, Feb 04, 2002 at 02:40:48PM -0600, Kenneth Pronovici wrote: I guess what I'm looking for is a way to sort by thread/subject/date rather than just thread/subject. It doesn't look like I can use sort and sort_aux to do this. Anyone have a suggestion for some other way to accomplish this (other than just using procmail to put these things in a different folder)? I'd be also interested in such a solution. I am using sort=threads sort_aux=score but so my mails aren't sorted by date anymore ... and new mails show up as first lines after opening the mailbox. I'd really like to see something like sort=threads/score/date or sort=thread sort_aux=scoredate or which syntax ever seems usable, but having only 2 levels of sorting seems not enough ... ;-( btw. I am still using 1.2.5.1 ... is there something like that in 1.3.x already and I haven't seen it, yet? There is not, but this seems like an appropriate thing to file a wishlist bug for, using flea(1). msg24225/pgp0.pgp Description: PGP signature
Re: Sorting in mailbox question
On Feb 06, Daniel Eisenbud [[EMAIL PROTECTED]] wrote: I've been planning to do this for a while. It seems to me that the only time that more than two levels of sorting is useful is when the first level is threads. If anyone can give me a plausible scenario where they'd want more than three, or more than two unthreaded, I'll think about my approach. But for the moment the right thing to do seems to be to break threading out into its own config variable. So you can set threads=forward threads=reverse or threads=off and then sort and sort_aux are what's used for secondary and tertiary sorting, or primary and secondary if threads=off. Make sense to people? Heh, I had the exact same thought reading this thread, so I certainly concur. The only other possibility I was thinking of was trying to accomodate the guy who wants all Debian Weekly News [date] sorted together. Date won't do it, and subject won't do it. He could munge the subject in procmail, but that's probably not desirable. Without having time to give it too much thought, the two approaches that immediately come to mind are scoring (and using scoring for anything like this always limits what else you can use it for) and some kind of sorting based on arbitrary message headers, because having procmail add those headers _would_ make sense. Both of this have problems if they're taken literally, but they also both point toward some kind of combination of sorting with pattern matching. You can get this in a limited way now if you score based on patterns and sort based on score, but again, that limits what else you can use scoring for. I guess that's also an example of where one would want more than your above listed tertiary sorting... you could want to sort on subject first, followed by date, but all able to be overridden by score. Anyway, just rambling, since I don't have a good idea of how to approach this. But maybe someone else will. msg24246/pgp0.pgp Description: PGP signature
Re: Breaking News: Lusers _want_ to quote email replies The Right Way.
On Feb 06, Rob 'Feztaa' Park [[EMAIL PROTECTED]] wrote: I just got an email from a nondescript luser asking how I put my replies after the quote, The Right Way. She uses LookOut, of course, and doesn't like the default quote style that it uses. She says that the way I do it is so cool. I'm going to turn this into another reason why she ought to be using Linux, because it makes it easier to do that. So what do you guys think now? Lusers forced into poor quoting by default settings they don't know how to change, or lusers stubbornly refusing to do anything resembling intelligent behavior? Don't know to change or even if they do, can't really. If I started quoting the right way at work, it would confuse people to no end... they wouldn't know where to find my response inside of Outlook's awful message display interface (marking replies inline with [name] tokens? WTF is that?). I had to hobble my copy of Mutt there to mimic Outlook's reply style as closely as possible with the existing variables. There's a serious when in Rome factor to consider. Or as the Apostle Paul put it... I have become all things to all men, in the hopes that I might somehow save some of them. ;) msg24255/pgp0.pgp Description: PGP signature
[OT] handling outlook cal stuff
Looking for recommendations on a way to get outlook appts and other calendar stuff into something more open, such as ical. Found outlook2ical on freshmeat, just wondering what other options are recommended, if any. TIA. msg24186/pgp0.pgp Description: PGP signature
Re: ~b pattern and encrypted messages
On Feb 04, Brian Clark [[EMAIL PROTECTED]] wrote: If I set this up in my .muttrc: color index brightblue white ~b foobar Or this: color index brightblue white ~b \foobar\ And I open a mbox where every single message is encrypted, as soon as I enter that mbox I get the prompt for my GPG passphrase. It seems like it's trying to descrypt the messages to check the body. After I enter my passphrase, each move up or down in the list is _really_ slow -- which is another hint that it may be trying to descrypt each messages first. Is that desired behavior, or is that a bug, or just a side effect of working with ~b? I'd have to say it's a feature -- it's doing what you told it to. And if you want it to not act this way, just use: color index brightblue white !~G ~b foobar which will explicitly exclude the encrypted messages. msg24204/pgp0.pgp Description: PGP signature
Re: 'N' indicator in folder list
On Feb 04, David T-G [[EMAIL PROTECTED]] wrote: So tell me a bit about Maildir... When new mail arrives, it is written to tmp/ and then atomically moved to new/, right? Does it stay in new/ until you read it and it moves to cur/? If that's the usual behavior, Yes. when you e'x'it or otherwise don't sync your changes (like changing from 'n'ew to read) do they stay in new/ instead of moving? I had thought Yes. And Mutt will move them back to new/ if you toggle the N flag to true again and sync. that all mail gets moved to cur/ as a final part of the delivery and that the MUA was not expected to find things in new/ ... No... the MTA is responsible for getting it to new/. The MUA is responsible for it after that. From the maildir(5) man page: HOW A MESSAGE IS DELIVERED ... Files in cur are just like files in new. The big differ ence is that files in cur are no longer new mail: they have been seen by the user's mail-reading program. ... HOW A MESSAGE IS READ A mail reader operates as follows. It looks through the new directory for new messages. Say there is a new message, new/unique. The reader may freely display the contents of new/unique, delete new/unique, or rename new/unique as cur/unique:info. See http://pobox.com/~djb/proto/maildir.html for the meaning of info. The reader is also expected to look through the tmp direc tory and to clean up any old files found there. A file in tmp may be safely removed if it has not been accessed in 36 hours. It is a good idea for readers to skip all filenames in new and cur starting with a dot. Other than this, readers should not attempt to parse filenames. msg24205/pgp0.pgp Description: PGP signature
Re: regex isn't working in color index ~C ... context
On Feb 03, parv [[EMAIL PROTECTED]] wrote: #color index brightwhite default ~C $alternates color index brightwhite default ~C (parv_@yahoo\.com|parv@(localhost|.*holy\.cow)) ...i get error message while starting mutt... Error in /home/parv/cf/mail/mutt.cf, line 58: parentheses not balanced quoting. try: color index brightwhite default ~C \(parv_@yahoo\.com|parv@(localhost|.*holy\.cow))\ (the pattern matching syntax allows for (|) itself, so ~C (... is ambiguous to mutt's parser) msg24161/pgp0.pgp Description: PGP signature
Re: regex isn't working in color index ~C ... context
On Feb 03, Cedric Duval [[EMAIL PROTECTED]] wrote: Jeremy Blosser wrote: On Feb 03, parv [[EMAIL PROTECTED]] wrote: #color index brightwhite default ~C $alternates ^^ Am I missing something? I believe the main goal of the original poster is to achieve something like this... Oops. Didn't read closely enough. I then would rather suggest to have a look at the ~p and ~P patterns. Yep. msg24164/pgp0.pgp Description: PGP signature
Re: Sorceforge bouncing mail: Create Postmaster Account ??
On Feb 02, John P Verel [[EMAIL PROTECTED]] wrote: I have the impression that this is unsolvable. In any case, if I attempt to post to [EMAIL PROTECTED], I get this message: This has nothing to do with mutt. Create (or get your admins to create) a postmaster address for this domain, as is indeed required by RFC 822. msg24136/pgp0.pgp Description: PGP signature
Re: Exporting a message?
On Jan 31, Michael Elkins [[EMAIL PROTECTED]] wrote: Philip Mak wrote: I don't suppose there's a command like pipe-message, except that it filters headers (the header filtering code is already available in the pager, after all)? Or would I have to write an external header filtering program and then do something like: macro index E pipe-message perl filter_header.pl which isn't exactly the optimal solution, since an external program does not have ready access to my configuration file my_hdr settings, but would work I suppose. Yes, there is a pipe-message. If you set $pipe_decode, it will weed out the headers and the message you get will look just like it does in the pager, which should be suitable for printing. ...and there is also the corresponding $print_decode for use with $print_cmd. msg24072/pgp0.pgp Description: PGP signature
Re: s/mime questions
On Feb 01, Volker Moell [[EMAIL PROTECTED]] wrote: Mike Schiraldi wrote: [...] Just a question: Is it really necessary to attach at each message the smime.p7s file (your signature or so)? It has always about the 10th size of your underlying posting, so it increases the size of your posting way much. What is it for at all? Why is this (I think) signature so large? Mike and I were discussing this in private mail earlier this week... I'm sure he'll have his own things to add, but after talking with him this is my take on it: The sigs are that big because they all include his public key. S/MIME does not use keyservers like OpenPGP does. It also does not have a web of trust concept, instead relying on central CAs. They consider this an advantage, since it means you can always verify a message regardless of your current network connection status, etc... all that you need to verify the message is containted in the message itself and your local list of trusted CA certs. This means that people that don't understand how public key encryption works can still use it without really having to know anything at all. There are of course a few disadvantages to these methods... first, the bandwidth issue you raise (I believe it's worth it to sign all my mails, but I have to question if it's still worth it when the sig is 3k instead of 0.2k; or rather, question if that extra bulk is giving me anything I want over what the 0.2k gives me). There are also a plethora of issues regarding the use of a CA at all vs. manually verifying your keys/using a tighter web of trust, but those are well beyond the scope of this list, probably. I think this kind of opportunistic encryption has its place in at least affecting some useful social engineering, but I don't like how all or none it is currently. To me the ideal solution to the bandwidth issue would be a system that allowed you to send the whole key with the sig to certain people, and let people request it from key servers in other cases (mailing lists). Unfortunately nothing around really does this in the ideal way (you can do it with OpenPGP implementations, but OpenPGP still has a lot of usability issues that won't make it quite reach the opportunistic encryption bar). msg24081/pgp0.pgp Description: PGP signature
Re: s/mime questions
On Feb 01, Mike Schiraldi [[EMAIL PROTECTED]] wrote: To me the ideal solution to the bandwidth issue would be a system that allowed you to send the whole key with the sig to certain people, and let people request it from key servers in other cases (mailing lists). I could attach just a signature and leave out the certs when sending to certain mailing lists (using a hook to change smime_sign_command to toggle OpenSSL's --nocerts switch). However, this only decreases the smime.p7s size (after base64 decoding) from ~1700 bytes to ~650 bytes. I'm don't think there's any way to get an S/MIME signature that's anywhere near as small as a PGP signature. I know it's bad netiquette to waste other people's bandwidth, but i also think unsecure email needs to be deprecated as soon as possible. Suggestions? Well it would obviously be good if they could get the sig size down to something smaller, either through a more efficient algorithm or compressing it -- most people are in much better shape for CPU than they are for bandwidth, especially when you factor in per-minute costs for the latter. Also, they'd theoretically only need to decompress the sig if they actually wanted to verify it, and could otherwise ignore it. But I'm guessing it's too late to fix this in the specification itself, especially in things like the Outlook implementation. Maybe Mutt's implementation could support optionally compressing the signatures? It would only work among mailers that knew how to use it, but many people that know enough to care about this are going to be using a decent mailer. You could install gpg and use it when cooresponding with lists and people that can do better than just opportunistic encryption. Having Mutt support both should make switching between the two rather easy. msg24091/pgp0.pgp Description: PGP signature
Re: s/mime questions
On Feb 01, Mike Schiraldi [[EMAIL PROTECTED]] wrote: It would only work among mailers that knew how to use it, but many people that know enough to care about this are going to be using a decent mailer. Part of the problem with PGP is that only people that know enough to care use it. My goal is to be able to communicate securely and privately with everyone -- even Outlook and Netscape users. My only point was that the people that care about the bandwidth issues and that you are likely going to be communicating with are for the most part going to be people that are using a decent mailer. These people would both benefit from this kind of compression and be able to take advantage of it. The people you are likely to coorespond with that wouldn't be able to take advantage of it would also likely not need to, either because they didn't know enough to care or because they would be [American] end users who wouldn't have the same kind of per-minute costs or poor quality connections. Thus you could continue to communicate with all people the way you want, without imposing unneccessary expectations on any of them. The people you actually coorespond with may well make the above generalizations completely bogus, but I think they would hold true in most situations. Even on the mutt list, there are people who use Outlook or Netscape. On most mailing lists, they form the majority. If a large number of people can't securely communicate with me, i haven't achieved the goal. So even if we wrote such an extension, i wouldn't use it. It's worth noting again that the issue only applies to signatures, not to messages that are actually encrypted, since encryption generally implies compression as well. If people are able to encrypt their mail they've achieved a gain in relation to their bandwidth issues, and a 3k sig vs. a .2k sig is pretty much irrelevant. However, due to overwhelming demand and the unusual demographics of the mutt lists, i've added the following to my .muttrc so that messages i post here will be signed instead with PGP: folder-hook . 'set smime_is_default=yes' folder-hook =mutt 'set smime_is_default=no' Heh... even easier than I thought. Thanks. msg24097/pgp0.pgp Description: PGP signature
Re: s/mime questions
On Feb 01, Will Yardley [[EMAIL PROTECTED]] wrote: yeah i think the issue is not so much of technical sophistication (although that's an issue too) as of the fact that most people Don't Care. 99% of the people i correspond with simply don't care, so i generally don't bother to encrypt or sign my communications with them. This is the issue of why-to-sign-mails-anyway, and it comes up often enough to ignore it here... for the purposes of the issue at hand (S/MIME compared to OpenPGP, especially their respective sig sizes), let's just assume that the mails in question *are* going to be signed. /me fears yet another thread that never ends. also, there are pgp front ends and plugins for most browsers/ email clients; obviously this isn't as good as built in support, but from what i've seen it's not rocket science. The web of trust is close enough to rocket science for most people that we are never going to see encryption become a social norm through relying only on public acceptance of what that market offers now. S/MIME apparently makes it easy enough for average people that they can get benefits on basic, CA based encryption. That's not the ideal situation but it gets us closer to it than not. however the fact is - using any sort of encryption requires some amount of technical sophistication, as you have to understand some of the more subtle issues at work (both technical issues, and issues of trust). encryption used by someone without at least a basic understanding is worse (IMHO) than none at all. Neither of these are necessarily true. HTTPS is a good example. Most ebay and amazon users have no idea of any of the technical issues involved with using SSL, but because they use it anyway, their communication is more secure than it would be without it. And because they use it, it is easily available to those of us that do understand it. And because it is a social norm and Big Companies even rely on it, when the US Congress recently suggested that they were going to break it all to stamp out terrorism, it was the big corporate guns that told them the idea was ridiculous. If they'd only attacked PGP and email encryption in it's current state, we wouldn't have gotten anything like that kind of support. There is certainly a point where misunderstanding or failing to understand what's going on will put you at more risk than not using any encryption at all, but that point is not reached by casual use of things like HTTPS or S/MIME. i don't think the difficulty of PGP is totally a bad thing - PGP is designed in such a way that you HAVE to come to a basic understanding of some of these issues in order to use it. The difficulty of PGP is what's kept it from being publically accepted as a normal thing to do, and that in turn has made it so those that DO use it are limited to a few tech-savvy subsets and real revolutionaries, both of which are easily identifiable with simple traffic analysis. People need to consider encryption completely normal, so that everyone uses it as a matter of course. This will drive the industry forward and take basic threats of government intervention completely off the table as options. Those who don't understand it could still get some benefit from it, and those of us that do understand it would get quite a lot of peripheral benefit from having all traffic encrypted, even if a lot of it were encrypted poorly. People need to accept encryption the way they accept envelopes on snail mail. They never would have globally accepted these if you couldn't use one unless you knew how to make your own adhesive, ink, and stamps. I saw Phil Zimmerman speak a few months ago at ALS in Oakland, and he understands this more than anyone. He expressed a good bit of dismay at how clique-ish PGP usage is, and how much it has missed the mark of being a way to give encryption to the masses and make it normal. He endured all manner of government harassment to defend people's right to use this stuff, and yet years later, hardly anyone is taking advantage of it. It was really interesting hearing him speak. It's too bad he had to stop due to people in the audience arguing that there was no value at all in people using PGP unless they all used it completely securely (the main antagonist noted that he keeps his private keys on a CD and never has that near his computer unless it's completely disconnected from the network), which prompted a bunch more people to complain that there was too much talking and not enough key signing going on. msg24103/pgp0.pgp Description: PGP signature
Re: s/mime questions
On Feb 01, Mike Schiraldi [[EMAIL PROTECTED]] wrote: [2] I guess this is where we disagree - you seem to think that there is little overlap between the set of people who care about email security and the set of people who good mailers .. i think there is a lot. No, I think that the overlap of set of people that care a lot about message size and set of people that don't use good mailers is small. I didn't mean you'd use this extension all the time, just that you'd use it on lists like mutt-users that were frequented by international(care about message size) and technical(have good mailers) people. ie., you'd use it like you're now using $smime_is_default, which is probably a better solution anyway. Sorry, didn't mean for that one to turn into anything worth miscommunicating about... Thomas' point about the compressability of signatures wins, regardless. msg24105/pgp0.pgp Description: PGP signature
Re: s/mime questions
On Feb 02, Stephan Seitz [[EMAIL PROTECTED]] wrote: On Fri, Feb 01, 2002 at 03:36:13PM -0600, Jeremy Blosser wrote Neither of these are necessarily true. HTTPS is a good example. Most ebay and amazon users have no idea of any of the technical issues involved with using SSL, but because they use it anyway, their communication is more secure than it would be without it. And Sorry, I don't think, that's correct. If you only see your lock that indicates a ssl connection, doesn't mean that it uses the right key. If you don't check the key owner you don't know if the connection is secure. And if you don't check it you don't need this kind of security. Is it better/safer overall to: a) live in a world where no one has locks on their doors, except for the very few people that know how to build their own lock from scratch and check it every morning for any scratches to indicate someone tried to break in, and the robbers just skip those and go rob all the other houses with no locks or b) live in a world where everyone has locks on their doors, most of which are very easy to pick, but the robbers have to take their chances with any given lock -- and since the locks are the normal thing, and lots of time is spent on them, even the crappy locks are better than they would be in (a) The benefits of mass use of encryption are not just the obvious ones. Reality is more complicated and interdependant than that. msg24110/pgp0.pgp Description: PGP signature
Re: is it possible to have color reversed indicator?
On Jan 31, parv [[EMAIL PROTECTED]] wrote: i am using mutt 1.3.27i, and i tried... color indicator reverse ...which, of course, doesn't work as desired. what i want/wish is to have indicator in reverse colors in the index. mono reverse is, well, not colored. possible? Not currently. You can only use color commands with colors, and mono commands with other attributes. msg24017/pgp0.pgp Description: PGP signature
Re: Pity that mutt doesn't read news - what's the best match?
On Feb 01, Charles Jie [[EMAIL PROTECTED]] wrote: I have been a netscape user. Now I'm satisfied with mutt and will not go back to netscape except one thing - reading news groups. Could any Mutter suggest a good news reader of mutt style? (Highly customizable) SLRN. Much of Mutt's user interface was based on SLRN originally. http://slrn.sourceforge.net/ Also, there are various patches to make Mutt do NNTP, if that's your thing. See http://www.mutt.org/links.html#patch. Most people seem to use Vsevolod Volkov's. msg24022/pgp0.pgp Description: PGP signature
Re: how best to forward attachments
On Jan 31, Mark Johnson [[EMAIL PROTECTED]] wrote: Generally, I want to forward all attachments along with any message I am forwarding. What's the best way to configure mutt to achieve this? see the manual entry for mime_forward. msg24044/pgp0.pgp Description: PGP signature
Re: fetchmail to MTA to procmail (WAS Re: folders ?)
On Feb 01, Prahlad Vaidyanathan [[EMAIL PROTECTED]] wrote: On Wed, 30 Jan 2002 Knute spewed into the ether: [-- snip --] fetchmail - MTA - procmail - folder(s) or am I missing something ? What I meant was that when you hit G for the default getmail function that mutt has, it doesn't run it thru procmail, it just gets it. And my question is, Why does it *not* run it through procmail ? Does this mean that fetchmail is writing to the spool folder ? AFAIK, You're missing the point. fetchmail is not involved when you use Mutt's built in POP fetch-mail function, even though the names are similar. That function just brings the mail directly into the folders, it bypasses the system's normal MTA/MDA system entirely. This is, of course, one of the main reasons to not use Mutt's limited POP support, and to use an external program such as fetchmail instead. fetchmail does not do that. Hence, I am guessing, fetchmail hands the mail over to your MTA, and your MTA doesn't pass the mail on to procmail. msg24060/pgp0.pgp Description: PGP signature
Re: 2 Q's about printing...
On Jan 30, Nick Wilson [[EMAIL PROTECTED]] wrote: Currently I have to print msg's via the pipe command. I have 2 questions regarding this: 1. How can I print only the headers I see on the screen as opposed to all of them when I '| lpr'? Well using pipe, set pipe_decode. 2. Why do I /have/ to pipe to lpr? It doesn't work if I just print. Verify that your value for print_cmd is correct (it should probably be the same as whatever you are piping to). Related to question 1, you'll probably want to set print_decode as well. msg23991/pgp0.pgp Description: PGP signature
Re: 2 Q's about printing...
On Jan 30, Nick Wilson [[EMAIL PROTECTED]] wrote: * and then Igor Pruchanskiy blurted I am using muttprint. It is superior. I have used a2ps and enscript before, but i ended up with muttprint and i love it. Even though my boss makes fun of a cute little penguin :) Hmmm much thanks everyone. I'll try the var stuff this evening but where do I get muttprint and is it a GUI thing? It's linked off www.mutt.org's links page. msg23995/pgp0.pgp Description: PGP signature
Re: Mails received as attachment?
On Jan 29, Nick Wilson [[EMAIL PROTECTED]] wrote: from inside the untarred mutt dir: $ patch --dry-run -i ../dales_patch-xxx [snip] can't find file to patch at input line 147 Perhaps you should have used the -p or --strip option? [snip] and that's where I'm stuck, I've tried -p0 and -p1 instead of -i but ^^ Not instead of. You need both. patch -p1 -i ../dales_patch-xxx msg23950/pgp0.pgp Description: PGP signature
Re: rewriting message stautus
On Jan 29, [EMAIL PROTECTED] [[EMAIL PROTECTED]] wrote: On Mon, Jan 28, 2002 at 08:38:45PM -0600, Jeremy Blosser wrote: Yeah, you can do some great stuff with that. My own settings do the following: Sounds great, maybe you could send part of your muttrc responsible for such colors? Heh, here. There are some comments at the top about the verbosity of the way it's done. Also, if you pay attention to the colors specified you'll notice the bright ones aren't in the same format as the others... this is because I changed the behaviour on mine to use inverse for bold background so that I can get some more colors than I could otherwise. ### Index coloring. These are all much more specific than they need to be ### since only the last matching will have an affect, but hopefully that will ### get fixed at some point. Being able to have attributes cascade would ### also make this all easier in general. # regular new messages color index black white ~N !~T !~F !~p !~P # regular tagged messages color index default white ~T !~F !~p !~P # regular flagged messages color index default red ~F !~p !~P # messages to me color index yellow default ~p !~N !~T !~F !~P color index default yellow ~p ~N !~T !~F !~P color index yellow white ~p ~T !~F !~P color index yellow red ~p ~F !~P # messages from me color index green default ~P !~N !~T !~F color index default green ~P ~N !~T !~F color index green white ~P ~T !~F color index green red ~P ~F # messages which mention my name in the body color index yellow default ~b \[Bb]losser[ @]\ !~N !~T !~F !~p !~P color index default yellow ~b \[Bb]losser[ @]\ ~N !~T !~F !~p !~P color index yellow white ~b \[Bb]losser[ @]\ ~T !~F !~p !~P color index yellow red ~b \[Bb]losser[ @]\ ~F !~p !~P # messages which are in reference to my mails color index magenta default ~x shade.firinn.org !~N !~T !~F !~p !~P color index default magenta ~x shade.firinn.org ~N !~T !~F !~p !~P color index magenta white ~x shade.firinn.org ~T !~F !~p !~P color index magenta red ~x shade.firinn.org ~F !~p !~P # messages to root, etc. color index blue default ~C \(root|postmaster|abuse|mailer-daemon)@\ !~N !~P !~p color index default blue ~C \(root|postmaster|abuse|mailer-daemon)@\ ~N !~P !~p # messages from known aliases (requires dgc.isalias) color index cyan default @~f . !~N !~T !~F !~P color index default cyan @~f . ~N !~T !~F !~P color index cyan white @~f . ~T !~F !~P color index cyan red @~f . ~F !~P # messages from my wife color index brightblue default ~f mywifesemail !~N !~T !~F color index brightblue brightwhite ~f mywifesemail ~N !~T !~F color index brightblue white ~f mywifesemail ~T !~F color index brightblue red ~f mywifesemail ~F # bigass messages color index red default !~N ~z 10240- # deleted messages color index brightblack default ~D msg23952/pgp0.pgp Description: PGP signature
Re: Mails received as attachment?
On Jan 29, Nick Wilson [[EMAIL PROTECTED]] wrote: Hmmm... Thanks Jeremy, that's getting results, unfortunately it's failing on each hunk? What output? msg23953/pgp0.pgp Description: PGP signature
Re: Mails received as attachment?
On Jan 29, Nick Wilson [[EMAIL PROTECTED]] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * and then Jeremy Blosser blurted On Jan 29, Nick Wilson [[EMAIL PROTECTED]] wrote: Hmmm... Thanks Jeremy, that's getting results, unfortunately it's failing on each hunk? What output? Here ya go .. Well actually those are almost all succeeding. All the 'patching...' with no other comments means those succeeded. The 'offset' lines mean that patch was able to find the lines it was looking for near the ones specified by the patch, but that something had changed since the patch was made. The 'failed' lines means something had changed enough to make the lines patch was looking for not the same as when the patch was made, therefore it gives up. Basically, you have a version of Mutt different from the one this patch was made against. Since it's all failing in just translation stuff, and that stuff probably doesn't matter to you, you can go ahead and just build with what succeeded and not worry about it. If the failures bother you, you can get past this by editing the patch and removing the lines that affect the po/* files. patching file PATCHES patching file init.h patching file muttlib.c patching file pgp.c patching file protos.h patching file send.c patching file doc/muttrc.man Hunk #1 succeeded at 2415 (offset 11 lines). patching file po/ca.po patching file po/cs.po patching file po/da.po patching file po/de.po patching file po/el.po patching file po/eo.po Hunk #1 succeeded at 3168 (offset -1 lines). patching file po/es.po patching file po/et.po patching file po/fr.po patching file po/gl.po patching file po/hu.po patching file po/id.po patching file po/it.po Hunk #1 FAILED at 2. 1 out of 2 hunks FAILED -- saving rejects to file po/it.po.rej patching file po/ja.po patching file po/ko.po patching file po/lt.po patching file po/nl.po Hunk #1 FAILED at 1. 1 out of 2 hunks FAILED -- saving rejects to file po/nl.po.rej patching file po/pl.po patching file po/pt_BR.po patching file po/ru.po patching file po/sk.po patching file po/sv.po Hunk #1 FAILED at 1. 1 out of 2 hunks FAILED -- saving rejects to file po/sv.po.rej patching file po/tr.po patching file po/uk.po patching file po/zh_CN.po patching file po/zh_TW.po msg23958/pgp0.pgp Description: PGP signature
Re: Mails received as attachment?
On Jan 29, Dale Woolridge [[EMAIL PROTECTED]] wrote: http://www.woolridge.org/mutt/patches/patch-1.3.26.dw.pgp-traditional.2 It will apply cleanly to 1.3.26, but I don't know about 1.5.0. If the patch applies cleanly to 1.5, please let me know. Nope. Note that Thomas has been working on a variant of this idea in the current CVS already, so there's not much chance this patch would apply. % patch -p1 ../patch-1.3.26.dw.pgp-traditional.2 patching file PATCHES patching file init.h Hunk #1 succeeded at 1349 (offset 49 lines). patching file muttlib.c Hunk #1 succeeded at 108 (offset 4 lines). Hunk #3 succeeded at 197 (offset 4 lines). patching file pgp.c Hunk #1 FAILED at 1646. Hunk #2 FAILED at 1698. 2 out of 2 hunks FAILED -- saving rejects to file pgp.c.rej patching file protos.h Hunk #1 succeeded at 258 (offset 1 line). patching file send.c Hunk #1 succeeded at 1422 (offset -17 lines). Hunk #2 FAILED at 1541. 1 out of 2 hunks FAILED -- saving rejects to file send.c.rej can't find file to patch at input line 147 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -- |--- mutt-1.3.26/doc/muttrc.man Fri Jan 18 12:29:26 2002 |+++ mutt-1.3.26/doc/muttrc.man Sun Jan 20 09:03:14 2002 -- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored patching file po/ca.po patching file po/cs.po patching file po/da.po Hunk #1 succeeded at 3164 (offset -1 lines). patching file po/de.po patching file po/el.po Hunk #1 succeeded at 3843 (offset -22 lines). patching file po/eo.po Hunk #1 succeeded at 3168 (offset -1 lines). patching file po/es.po patching file po/et.po patching file po/fr.po patching file po/gl.po patching file po/hu.po patching file po/id.po Hunk #1 succeeded at 3179 (offset 1 line). patching file po/it.po patching file po/ja.po Hunk #1 succeeded at 3145 (offset -1 lines). patching file po/ko.po patching file po/lt.po patching file po/nl.po patching file po/pl.po Hunk #1 succeeded at 2949 (offset -232 lines). patching file po/pt_BR.po patching file po/ru.po patching file po/sk.po patching file po/sv.po patching file po/tr.po patching file po/uk.po Hunk #1 succeeded at 3137 (offset -20 lines). patching file po/zh_CN.po patching file po/zh_TW.po % ls doc/muttrc.man* doc/muttrc.man.head doc/muttrc.man.tail msg23965/pgp0.pgp Description: PGP signature
Re: rewriting message stautus
On Jan 29, Michael Montagne [[EMAIL PROTECTED]] wrote: folder-hook lists 'color index brightmagenta default ~x mithrandir.codesorcery.net !~P' Can you explain how this works? It matches if the References: header (specified by the ~x pattern) contains the pattern mithrandir.codesorcery.net, and the message is not from me (the !~P pattern... I believe in this case me is Justin Miller). See section 4.2 in TFM. I think I can use it to Flag entire threads if they have any Flagged messages in them. But I'm a bit new and I don't understand the syntax. No, unfortunately there are no patterns that allow you to match messages other than one at a time. There is a patch out there that allows you to match children of a given match, but not quite what you're looking for. msg23966/pgp0.pgp Description: PGP signature
Re: mutt-1.5.0, was Re: \223 and \224
On Jan 28, Russell Hoover [[EMAIL PROTECTED]] wrote: User-Agent: Mutt/1.5.0i Could this mean that a 1.5.0 release is around the corner? I'm asking because, if it is, I'd like to tell my admin to hold off upgrading from 1.3.25 to 1.3.27, if 1.5.0 will be available in a week or two . . . 1.5.x is the new development branch, cut in the CVS by Thomas last week. It will be the new home for development from now on, post 1.4. It's already had a fair amount of large-ish patches thrown at it, so it's headed for a good start as a development branch which probably soon won't be very wise to use for daily tasks, until it has shaken down a bit more. :) What is just around the corner is the 1.4 release. It's due any day now, and is the very stable result of the current 1.3.x development tree (the code will be identical to 1.3.27, plus any fixes important enough to be necessary before it becomes 1.4). msg23910/pgp0.pgp Description: PGP signature
Re: forwarding and headers
On Jan 28, Brian Clark [[EMAIL PROTECTED]] wrote: When I'm forwarding a message, is there any way to turn off the inclusion of the complete headers? I've been weeding them myself for far too long. You will get the same headers in the forwarded version that you see when viewing the message, IFF you have $forward_decode set. BTW, this is probably the best behaviour, but it's contrary to what the manual currently indicates: Forwarding can be done by including the original message in the new message's body (surrounded by indicating lines) or including it as a MIME attachment, depending on the value of the ``$mime_forward'' variable. Decoding of attachments, like in the pager, can be controlled by the ``$forward_decode'' and ``$mime_forward_decode'' variables, respectively. The desired forwarding format may depend on the content, therefore $mime_forward is a quadoption which, for example, can be set to ``ask-no''. The inclusion of headers is controlled by the current setting of the ``$weed'' variable, unless ``mime_forward'' is set. Thoughts? I've seen `set forward_weed' in a few .muttrc, and I'm guessing this is yet another patch? :-) When I include it, I get a parse error when loading mutt. $forward_weed was an old option that controlled this. It went away in 1.2: - The various weeding options are gone. You have one global option, $weed, now which can be influenced using configuration commands, or using the display-toggle-weed function (this used to be display-headers!). This option is applied when forwarding, replying, or printing messages. Essentially, this means that you have some WYSIWIG-like behaviour with respect to message header weeding. msg23917/pgp0.pgp Description: PGP signature
Re: rewriting message stautus
On Jan 28, Nicholas A. Martini [[EMAIL PROTECTED]] wrote: does anyone know how to make mutt show messages from yoursef (or another address) show up as read, or not new, or something? it would be handy for high-volume lists. depends... if you mean to do it at any given time, use: T (tag-pattern) some pattern (see the manual...mails from yourself would be ~P) enter ; (tag-prefix) W (clear-flag) N If you want this always true for these mails, Mutt won't do it. You'd want to use procmail or something to change the status flags as the messages arrive. msg23930/pgp0.pgp Description: PGP signature
Re: rewriting message stautus
On Jan 28, Justin R. Miller [[EMAIL PROTECTED]] wrote: Thus spake Nicholas A. Martini ([EMAIL PROTECTED]): does anyone know how to make mutt show messages from yoursef (or another address) show up as read, or not new, or something? it would be handy for high-volume lists. Well, as for something, I use these settings: folder-hook . 'color index brightblue default ~P' folder-hook sent 'uncolor index brightblue default ~P' folder-hook . 'uncolor index brightmagenta default ~x mithrandir.codesorcery.net !~P' folder-hook lists 'color index brightmagenta default ~x mithrandir.codesorcery.net !~P' folder-hook lists 'color index green default ~p' Which has the effect of showing mail from me as brightblue (except in my sent folder, which is unnecessary), threads that I've been a part of as brightmagenta, and mail sent directly to me but that ends up in a list folder as green so as to distinguish it further from list mail (aside from the to_chars markings). Yeah, you can do some great stuff with that. My own settings do the following: foreground colors: - mails to me are foreground yellow (even in my non-list boxes...helps make spam easy to visually identify) - mails from me are foreground green - mails in a thread I've participated in are foreground magenta - mails to me from a known alias are foreground cyan (I use this and my alias list to basically flag interesting people) - mails from certain particular people get their own color background colors: - normal mails are background default - new mails invert the regular colors (so new mails to me are background yellow, foreground default) - tagged mails are background white - flagged mails are background red a few special cases that override other colors: - messages bigger than 10k are red on default - deleted mails are brightblack on default My wife looks at my mail desktop and thinks I'm nuts, but it saves a heckuva lot of unnecessary scanning. msg23932/pgp0.pgp Description: PGP signature
Re: rewriting message stautus
On Jan 28, David T-G [[EMAIL PROTECTED]] wrote: ...and then Justin R. Miller said... % folder-hook . push 'T~N~P\n;N\n\ct.\n' You'd want to clear the new flag instead of toggle it, or when he entered the folder a second time all of his old new messages would be new and then his new new messages would be old, and then next time... Meanwhile, this is the sort of thing that's good with Nicolas's tag_conditional patch. I had the same thought initially, but since he's got the ~N in his pattern for tagging, it won't actually have that problem. msg23938/pgp0.pgp Description: PGP signature
Re: rewriting message stautus
On Jan 29, parv [[EMAIL PROTECTED]] wrote: when you want something done, you have to do it yourself. enough w/ all the fudging! given all the guesses flying around, i fed up and tried on my own. so here it is... Er, what fudging? What you have is pretty much identical to what was suggested. Oh well. # next three lines should be one; # wrapped for email macro index Escz \ 'tag-pattern ~Pentertag-prefixclear-flagNuntag-pattern ~Penter' \ mark messages read sent by me # # after defining key binding, make it execute for every folder # folder-hook . 'push \ez' ...i tried to put the whole macro in to the folder hook; but i kept getting unknown command w/... folder-hook . 'tag-pattern' Yes, because folder-hooks can only take commands. tag-pattern is a function. push is a command. You need 'push tag-pattern...' ...and too many arguments w/ ... folder-hook . 'push T~P' This is probably because you have multiple matching folder-hooks w/push or something, and you don't have an enter in there, so they all end up in the same keyboard buffer and manage to create an illegal command. msg23941/pgp0.pgp Description: PGP signature
Re: rewriting message stautus
On Jan 29, parv [[EMAIL PROTECTED]] wrote: in message [EMAIL PROTECTED], wrote Justin R. Miller thusly... folder-hook . push 'T~N~P\n;N\n\ct.\n' i tried the above which works (1.3.25i), or at least worked once. can anybody enlighten me why the variation below does not? folder-hook . push 'T~N~P\n;\efN\cT~P\n' bad quoting... use folder-hook . 'push T~N~P\n;\efN\cT~P\n' msg23944/pgp0.pgp Description: PGP signature
Re: html email
On Jan 26, Michael Maibaum [[EMAIL PROTECTED]] wrote: My favorite was the last bi-monthly report from our (win NT dominated...) IT dept...It was a 4Mb word document for about a page and a half, plus some high res pics, plus all the revisions in the word document. It was sent to every email address in the institution (thousands) and nearly brought the exchange server to it's knees...our dept survived as our mail is on a sparcstation, though it nearly filled it's disk, our IT guy, stripped out about 10k of text and sent that to us all A month or two ago, we started getting pages from our router guys asking if we knew why our Linux/qmail/etc. boxes were completely saturating our external pipe and almost taking the router down. By the time the guy that was on call got back to work, they had shut down outgoing SMTP at the firewall to at least block whatever it was, since 4 of our remote offices' Exchange servers had gone down under the load. Turns out somebody was trying to send a mail with a 3MB word doc to everyone in the company and their brother. Of course qmail happily complied, killing 4 other mail servers and almost the router in the process. We'd just recently gotten them to switch to Linux + qmail on the corporate border SMTP, and one of the managers actually suggested it was a flaw of qmail that it didn't crash at this point, to act as a break point. :) Of course we now have real limiting in place to make sure someone can't do it again. msg23839/pgp0.pgp Description: PGP signature
Re: html email
On Jan 25, David Ellement [[EMAIL PROTECTED]] wrote: I also see this fairly often. Of course, because these folks care about how their message looks, they also include stationery, background or border images. So I'll get a multipart/alternative message with one or two image attachments, where the text part is about 300 byte, the html part about 3k bytes, and the images about 30-100k bytes each. Yeah... and the stationery and fonts they use with it often require superhuman eyes to handle the contrast, etc. And replies to it often pick it up because of how people have their configurations. My personal favorite is when they send single images announcing some event/etc. as a _PowerPoint_ file. msg23840/pgp0.pgp Description: PGP signature
Re: html email
On Jan 26, Rob 'Feztaa' Park [[EMAIL PROTECTED]] wrote: Alas! Jeremy Blosser spake thus: one of the managers actually suggested it was a flaw of qmail that it didn't crash at this point, to act as a break point. :) Linux: Too stable for it's own good! That's a new one on me ;) Yeah... there's a little more to that... we'd just switched from a Novell Groupwise system to using Exchange for the group mail stuff with qmail on the border handling the real incoming/outgoing mail (talk about your bad news/good news situations). This was pretty much the first Friday after we switched. When he heard the story, one of the old Groupwise admins commented that the Groupwise system used to go down every Friday at about the same time, and they never quite knew why... they just bounced the server and it was fine again. So the theory (among managers anyway) became that this was some kind of regular mail that had been going on all along, but had never been a problem before because Groupwise just crashed and it died there. It seems to me there would still be a queue with those messages waiting to go out again that would keep causing problems til they fixed it, but I don't know Groupwise. msg23844/pgp0.pgp Description: PGP signature
Re: html email
On Jan 26, Knute [[EMAIL PROTECTED]] wrote: Isn't that what logs are for? You know, to help diagnose issues such as that. Yeah. Our group maintains/checks our logs. The others... It's actually been hard for management to adjust to the idea that we can tell them what happened when they ask, and aren't guessing about it. msg23851/pgp0.pgp Description: PGP signature
