Re: winmail.dat
Christoph P.U. Kukulies writes: Hi. I'm running Mutt 1.5.20 (2009-06-14) under Ubuntu and was wondering why mutt couldn't cope with some mail I got, containing an attachment, named winmail.dat (MS Outlook). Ask the sender to configure their mail tool for plain text or html rather than rich text.
Re: winmail.dat
Wouldn't it be more appropriate to ask why Thunderbird can process said email from that users' settings (outlook) and mutt cannot, rather than asking the sender to change something in his settings? The sender's settings are pre-MIME. MIME is a set of Internet mail standards that has been around in some form for nearly 20 years or so. Look up mailcap settings for application/ms-tnef, but in my personal opinion, this sort of thing should be discouraged.
Re: Revisiting: application/pgp-signature is unsupported
I am facing the same problem now, but may have a bit more information. Original message has a multipart/signed structure with a qp text and a signature part, all of which is wrapped into a multipart/mixed structure, presumably done by the list server for the purpose of adding a (text, 7-bit) footer. Exchange flattens the struture into a multipart/ mixed with a qp text part, a application/pgp-signature part in base64, and another base64 text part. I presume mutt needs multipart/signed.
Revisiting: application/pgp-signature is unsupported
There was a thread on this mailing list back in March, http://marc.info/?l=mutt-usersm=130016436305546w=2 List: mutt-users Subject:application/pgp-signature is unsupported From: Joseph xxx () gmail ! com Date: 2011-03-15 4:44:57 which doesn't seem to have had a resolution. I am facing the same problem now, but may have a bit more information. The copy of mutt I'm using is fully supporting signed/encrypted emails. Point in case, the earlier, signed message to this list Date: Wed, 22 Jun 2011 04:10:36 -0400 From: Athanasius m...@miggy.org To: Joseph syscon...@gmail.com, mutt-users@mutt.org mutt-users@mutt.org Subject: Re: EXITCODE==255 presents no problems whatsoever. But there are some messages mutt fails to interpret correctly. I think this all started when $work moved to Exchange. Exchange seems to have the nice and friendly habit of rewriting all sorts of things on delivery, although in this case I have no proof without the original message (MIME info and attachments are scrubbed from the corresponding mailing list archive). The messages that fail have the following MIME structure: I 1 no description [text/plain, quoted, windows-1251, 1.6K] A 2 This is a digitally signed message part.[applica/pgp-signat, base64, 0 A 3 ATT1.c [text/plain, base64, us-ascii, 0.2K] Part two is the signature, encoded in base64, and part three is a mailing list footer, also in base64. Also note that the header Content-Type: is multipart/mixed rather than multipart/signed.
Re: [Announce] mutt-1.4 is out.
Thomas Roessler writes: Mutt-1.4 has been released. You can download it from the following location: ftp://ftp.mutt.org/pub/mutt/. - Mutt now uses the iconv interface for character set conversions. This means that you need either a very modern libc, or Bruno Haible's libiconv, which is available from http://www.gnu.org/software/libiconv/. Here is my patch for configuring mutt without iconv, which unfortunately didn't make it into 1.4. It features o --disable-iconv configure option o correction of INSTALL instructions The patch does not include auto* generated files. To use it, you will have to have GNU autoconf and GNU automake installed. I am not subscribed to mutt-users. If you have any problems with this patch, search the mutt-dev list archives, and post to mutt-dev (in this order). diff -ur mutt-1.4.orig/INSTALL mutt-1.4/INSTALL --- mutt-1.4.orig/INSTALL 2002-04-20 22:40:52.0 +0100 +++ mutt-1.4/INSTALL2002-05-29 14:01:17.509294748 +0100 -237,7 +237,7 /usr/local/etc. -If you really want to, you can configure Mutt --without-iconv, but +If you really want to, you can configure Mutt --disable-iconv, but there will then be no character set conversion. diff -ur mutt-1.4.orig/PATCHES mutt-1.4/PATCHES --- mutt-1.4.orig/PATCHES 2002-04-02 19:48:57.0 +0100 +++ mutt-1.4/PATCHES2002-05-29 14:11:36.235171096 +0100 -0,0 +1 +patch-1.4.lh.noiconv.1 diff -ur mutt-1.4.orig/charset.h mutt-1.4/charset.h --- mutt-1.4.orig/charset.h 2002-04-20 08:25:49.0 +0100 +++ mutt-1.4/charset.h 2002-05-29 14:01:17.509294748 +0100 -28,8 +28,9 #endif #ifndef HAVE_ICONV +#define ICONV_CONST /**/ iconv_t iconv_open (const char *, const char *); -size_t iconv (iconv_t, const char **, size_t *, char **, size_t *); +size_t iconv (iconv_t, ICONV_CONST char **, size_t *, char **, size_t *); int iconv_close (iconv_t); #endif diff -ur mutt-1.4.orig/configure.in mutt-1.4/configure.in --- mutt-1.4.orig/configure.in 2002-05-29 10:29:26.0 +0100 +++ mutt-1.4/configure.in 2002-05-29 14:01:17.519297335 +0100 -665,7 +665,19 dnl -- iconv/gettext -- +AC_ARG_ENABLE(iconv, [ --disable-iconv Disable iconv support], +[ if test x$enableval = xno ; then +am_cv_func_iconv=no +fi +]) + MUTT_AM_GNU_GETTEXT + +if test $am_cv_func_iconv != yes +then + AC_MSG_WARN([Configuring without iconv support. See INSTALL for details]) +else + AC_CHECK_HEADERS(iconv.h, [AC_MSG_CHECKING(whether iconv.h defines iconv_t) AC_EGREP_HEADER([typedef.*iconv_t],iconv.h, -674,12 +686,6 [Define if iconv.h defines iconv_t.])], AC_MSG_RESULT(no))]) -if test $am_cv_func_iconv != yes -then -# AC_MSG_ERROR([Unable to find an iconv function. See INSTALL for help]) - AC_MSG_WARN([Unable to find an iconv function. See INSTALL for help]) -else - dnl (1) Some implementations of iconv won't convert from UTF-8 to UTF-8. dnl (2) In glibc-2.1.2 and earlier there is a bug that messes up ob and dnl obl when args 2 and 3 are 0 (fixed in glibc-2.1.3). diff -ur mutt-1.4.orig/m4/iconv.m4 mutt-1.4/m4/iconv.m4 --- mutt-1.4.orig/m4/iconv.m4 2002-04-20 22:40:52.0 +0100 +++ mutt-1.4/m4/iconv.m42002-05-29 14:01:23.299261521 +0100 -7,19 +7,14 dnl Some systems have iconv in libc, some have it in libiconv (OSF/1 and dnl those with the standalone portable GNU libiconv installed). - AC_ARG_WITH([iconv], -[ --with-iconv[=DIR] search for libiconv in DIR/include and DIR/lib], [ -if test $withval != no ; then + AC_ARG_WITH([libiconv-prefix], +[ --with-libiconv-prefix=DIR search for libiconv in DIR/include and DIR/lib], [ for dir in `echo $withval | tr : ' '`; do if test -d $dir/include; then CPPFLAGS=$CPPFLAGS -I$dir/include; fi if test -d $dir/lib; then LDFLAGS=$LDFLAGS -L$dir/lib; fi done -else - use_iconv=no -fi - ],use_iconv=yes) + ]) - if test $use_iconv = yes ; then AC_CACHE_CHECK(for iconv, am_cv_func_iconv, [ am_cv_func_iconv=no, consider installing GNU libiconv am_cv_lib_iconv=no -71,6 +66,4 LIBICONV=-liconv fi AC_SUBST(LIBICONV) - - fi # use_iconv ]) msg28368/pgp0.pgp Description: PGP signature
Re: signed emails, why ?
Alexander Skwar writes: So sprach »Steve Kennedy« am 2002-01-07 um 12:52:25 + : Why does everyone send signed emails to the list, is it always necessary ? No, it's not. Personal mails and important mails should be signed and/or encrypted. However mailinglist mails should not be encrypted, because those mails are not important, and thus the overhead for signing (both processing time and bandwidth/hd-space wise) is just wasted. Exactly. I have been on this list since 1997, and I'm unsubscribing because - too many mails on the list are signed, which slows down processing immensly - there's just too much noise
Re: Mutt sucks less than the rest
- clearsigned and/or ascii-armored messages Whether you guys like it or not, most of the rest of the world uses clearsigning and ascii-armored plaintext messages. Mutt falls down here. You apparently refuse to support this, which makes no sense since the majority of the PGP-using world uses this form of message. [...] Not true. 6.3.121. pgp_create_traditional Type: quadoption Default: no This option controls whether Mutt generates old-style PGP encrypted or signed messages under certain circumstances. Note that PGP/MIME will be used automatically for messages which have a character set different from us-ascii, or which consist of more than a single MIME part. Also note that using the old-style PGP message format is strongly deprecated. (I don't remember when this was introduced, though.) Secondly, mutt also supports checking of traditionally signed email (i.e. without conversion). EscP check-traditional-pgp check for classic pgp
Re: How to place a request of receipt for an outgoing mail?
Frankly it is a diabolical practise, causes uneccessary and pointless mail. If a mail is so important that you *must* be certain it has been read then phone the person up. Since the mechanism is inherently unreliable anyway, what is the point of using it ? Exactly. Every now and then, I have to remove undeliverable notification receipts from the mail queue. Undeliverable, because the original mails apparently underwent some internal-external address rewriting, but the address in the DSN header was not rewritten.
Re: --without-iconv doesn't work?
without iconv. Also note that for some reason the iconv macro is defined twice in config.h: perhaps one of them is hardwired. So make The reason is that the definition in acconfig.h is superfluous. At a glance, it seems that about 20 definitions in acconfig.h are superfluous. (See Making `configure' Scripts in the autoconf manual for how config.h gets generated).
Re: --without-iconv doesn't work?
Claus Assmann writes: System: OpenBSD 2.8 ./configure --without-iconv doesn't work: The documentation in INSTALL is wrong. There is no --without-iconv configure option, and configure does the right thing by bombing out. I think this can be fixed, though :)
Re: Problems installing MUTT
Ivan Castillo Escobar writes: Hi, I'm trying to install and configure MUTT 1.3.24 in Tru64UNIX 4.0F. I have the tar file, I did extract all files, but when I try to run (# configure ) command the system returns the following message: # ./configure configure: error: can not find sources in . or .. Somebody knows how to correct this problem??? No idea, but there is absolutely NO reason nor requirement to run configure as root!
Re: Another command line question
Barney Wells writes: I am using mutt .93.1 on SCO UNIX 5.0.5. A few weeks ago I asked about attaching files; mutt -x -s testing -a test.file username /dev/null This works great. Now I want to send text that is not in a file. It is fields out of my database. I would like this to appear in the body of the e-mail message. Here is an example: mutt -x -s testing this is what I want to say username /dev/null As you know this syntax does not work. /command/to/extract/your/message/from/the/database | mutt -s testing username -x is not needed because mutt is not used interactively if used like above.
Re: SMTP in Mutt
OK, thats not what I mean. If you want me to set the variable like above. Its done before I write the first email. I want to use my ISP provider SMTP server, so I need the variable for it. I have done the search at Mutt manual, but they never say anything about SMTP server, they do have ESMTP which is out of my question. mutt does not have any builtin SMTP code. You use your local MTA, which needs to be configured correctly (and that's a lot easier with postfix than, say, sendmail). And for the EDITOR wrap, I will find a way, thanks for telling me.
Re: Script to rebuild quotes
Signing list email is a complete useless exercise and wastes my time if your key is not on any key servers (and yes, I tried several, just in case). [-- PGP output follows (current time: Fri 30 Nov 2001 12:14:19 PM GMT) --] gpg: Signature made Fri Nov 30 08:04:08 2001 GMT using DSA key ID 2125BB86 gpg: requesting key 2125BB86 from search.keyserver.net ... gpg: no valid OpenPGP data found. gpg: Total number processed: 0 gpg: Can't check signature: public key not found [-- End of PGP output --] -- Chicken Little only has to be right once.
Re: 1.3.24 fails to compile on SunOS
Steve Kennedy writes: SunOS 4.1.4 gcc 2.95.2 make[2]: Entering directory `/home2/ns/steve/mutt/mutt-1.3.24/imap' gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../intl -I/usr/local/include -I../intl -Wall -pedantic -O2 -c auth.c In file included from ../protos.h:20, from ../mutt.h:809, from auth.c:23: ../mbyte.h:18: parse error before `wc' ../mbyte.h:19: parse error before `wc' ../mbyte.h:20: parse error before `wc' ../mbyte.h:21: parse error before `towupper' ../mbyte.h:21: parse error before `wc' ../mbyte.h:21: warning: type defaults to `int' in declaration of `towupper' ../mbyte.h:21: ANSI C forbids data definition with no type or storage class ../mbyte.h:22: parse error before `towlower' ../mbyte.h:22: parse error before `wc' ../mbyte.h:22: warning: type defaults to `int' in declaration of `towlower' ../mbyte.h:22: ANSI C forbids data definition with no type or storage class gmake[2]: *** [auth.o] Error 1 gmake[2]: Leaving directory `/home2/ns/steve/mutt/mutt-1.3.24/imap' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home2/ns/steve/mutt/mutt-1.3.24' gmake: *** [all-recursive-am] Error 2 http://marc.theaimsgroup.com/?l=mutt-devm=100288683121313w=2 http://marc.theaimsgroup.com/?l=mutt-devm=100288714522738w=2 Sorry :-)
Re: mutt configure --with-sasl
Volker Jahns writes: I would like to configure mutt compile to include imap support w/ sasl authentication: configure --enable-pop --enable-imap --with-sasl terminates w/ error message: snip checking for sasl_client_init in -lsasl... no configure: error: could not find libsasl What does config.log say?
Re: Cancelling an action?
Ctrl-G. Cancels any action in mutt. It's a beautiful thing. :) Yeah, and Emacs raises its HUGE head ;-)
Re: Mailing list and starting a new message
Sean LeBlanc writes: I see the lists and subscribe commands, and I added them to my .muttrc. They *seem* to work, I haven't figured out how to get the list info that shows up via lists, but anyway... I was wondering how one might set up mutt so that you hit some particular key while in the index of the list, and have it start a new message. Hitting L starts a new message, but in response to the message I'm currently positioned on. Is there a way to do this? No idea, but the workaround I usually use is to edit the message with headers (E instead of e) and remove the In-Reply-To: header.
Re: List processing in Mutt
Bruno Postle writes: On Sat 03-Nov-2001 at 11:06:16AM -0500, Rich Lafferty wrote: (In case you haven't already gone D'oh!:) Am I the only person who got a huge windows virus tagged onto the end of that email? I never saw it because it was rejected on my mail gateway. Yes, Rich's message was infected with the SirCam virus. The pgp sig was attachment 3, the virus was attachment 4. You can inspect the complete message at http://marc.theaimsgroup.com/?l=mutt-usersm=100480801725434w=2 This is quite interesting. Attachment 4 is a complete message to the list moderator (Steve K), so I'm wondering where and how exactly it got attached. It doesn't look like the virus came from Rich (which would have surprised me massively ;-)
Re: [THKS] Different From: addresses
Thanks for the great tip. The second method works wonderful. Now I can post to lists with my arms at rest. Could you tell me what the '~l' and '~C' are good for? For exactly the purposes mentioned in the manual. You should take some time to read it. http://www.mutt.org/doc/manual/manual-4.html 4.2 Patterns
Re: How to un-attach?
Justin R. Miller writes: Thus spake John P. Verel ([EMAIL PROTECTED]): I sometimes accidentally attach the wrong file to a message. I can't figure out how to to un-attach it. Can anyone help on this? Try highlighting the attachment in the compose menu and hitting 'D' (however, not 'd', which changes the description of the attachment.) And it's even documented ;) Press ? in the send menu. D detach-filedelete the current entry
Re: Maildir config?
Johansson Jan writes: Why don't you let mutt create it? Yet you need some place to store your Maildir-Folders in. I have over 2gigs of mail in ~/Maildir ;) Thank god that you're not a user in my network ;-)
Re: Postfix question
both of these boxes are on the same cable network. I will attach a copy of my main.cf file and maybe someone can give me Don't! a pointer (I have tried reading the manual..) There is a postfix-users mailing list. There is a FAQ at www.postfix.org. If you need to send configuration data, post only the output of postconf -n. This prints all non-default settings, and is usually enough to diagnose problems. Along with log file evidence, that is :)
Re: deleting messages with same message id's?
:0 Whc: msgid.lock | formail -D 16384 msgid.cache :0 a: duplicates You can change 'duplicates' to '/dev/null' if you trust the recipe works. No, you shouldn't. Unfortunately, the procmailex man page doesn't mention that procmail may fail for reasons other than ... their own scripting capabilities. If you change duplicates to /dev/null in the recipe above and procmail dies right after this recipe, for whatever reasons, you face irrevocable mail loss.
Re: the 'You have got new mail' message
or if this does not work : is there a bash command to look if i have got new mail. so that i can put this command in the .bashrc file What's so hard about doing a man bash?
Re: mutt exchange
Another good reason to include SMTP capabilities into mutt. They don't belong there. Check the archives, this has been discussed to death already.
Re: mutt-1.3.2i corrupt?
Rino Mardo writes: hi. i'm using debian 2.2r0 and have downloaded mutt-1.3.2i from ftp.mutt.org. 1.3.2i is an OLD development version from way way back. The current development version is 1.3.22.1i.
Re: mutt-1.3.2i corrupt?
Rino Mardo writes: hi. i'm using debian 2.2r0 and have downloaded mutt-1.3.2i from ftp.mutt.org. i have gnupg-1.0.5 installed which is currently being used by mutt-1.2.5i without any problems. mutt-1.3.2i produces errors when doing make install and it's searching for the file README.UPGRADE at the top-level directory where i'm compiling mutt. i got around this by copying my current README.UPGRADE file from my /usr/local/doc/mutt directory. I presume this is a typo, and you really mean 1.3.22i. The solution is to use1.3.22.1i. when installed, mutt-1.3.2i would not recognize my settings in ~/.mutt/gpg.rc although mutt-1.2.5i does. the problem setting is set pgp_sign_micalg=sha1. You need to upgrade your gpg.rc with the one from the mutt distribution you are using. lastly, the diff file diff-1.3.2i-1.3.2.1i.gz produces a lot of reject files everywhere. but this one i can live without. it's the first two problems that bothers me. Minus the typos, are you really trying to upgrade from 1.3.22 to 1.3.22.1? Or are you using 1.3.2 and diff-1.3.22-2.3.22.1? Hard to tell, and the latter would definitely fail like hell.
Re: fcc
Will Yardley writes: i just compiled mutt 1.2.5 in my home directory on a shell account on a machine for which i don't have root access (later versions aren't happy compiling for some reason, but 1.2.5 worked ok). a couple questions; i installed libiconv 1.7 in my home dir and pointed --with-libiconv to my lib directory (tried pointing it to my home dir too). later versions of mutt say 'iconv is not good enough - try getting libiconv instead. mutt 1.2.x doesn't use iconv.
Re: fcc
so my problem with 1.2.5 is the save-hook thing (which may have a very simple answer for all i know), but i would like to be able to compile 1.3.x just for cheap thrills. Well, if you don't show us how exactly 1.3.22.1i fails to compile, we're unable to help ...
Re: iconv etc
configure:6558: checking for iconv configure:6576: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include -I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c 15 /tmp/cca149331.o: In function `main': /home/will/mutt-1.3.22.1/configure:6570: undefined reference to `libiconv_open' /home/will/mutt-1.3.22.1/configure:6571: undefined reference to `libiconv' /home/will/mutt-1.3.22.1/configure:6572: undefined reference to `libiconv_close' Ok. You probably need to run configure as $ LDFLAGS=-R/home/will/lib ./configure ... (or LDFLAGS=-rpath /home/will/lib ..., I don't know which syntax your ld uses.) configure:6644: gcc -c -Wall -pedantic -g -O2 -I/home/will//include -I/home/will/include conftest.c 15 configure:6634: conflicting types for `libiconv' /home/will//include/iconv.h:82: previous declaration of `libiconv' Very strange. I have no explanation for this. configure:7326: checking whether this iconv is good enough configure:7354: gcc -o conftest -Wall -pedantic -g -O2 -I/home/will//include -I/home/will/include -L/home/will//lib -L/home/will/lib conftest.c -liconv 15 configure: failed program was: Possibly also fixed with that LDFLAGS trick. Mutt 1.3.22.1i did build fine for me with libiconv-1.7 on NetBSD.
Re: [applica/mac-binhex, 7bit, 911K]
the only way i can view it is if i read this email in Netscape. I've looked into the linux mac utils, but they don't seem to work for me. can anyone tell me how in mutt i can save this attatchment in a format that i can view with the gimp or any linux/unix image viewer. Just save the file and run xbin over it. If you want perl, you can write a short script using the uulib module.
Re: recompile for updated ncurses?
Ken Weingold writes: I built mutt with ncurses 5.0, and just updated ncurses to 5.2. Any reason to recompile mutt? I'm following the ncurses snapshots and don't usually recompile mutt, but in your case, I'd recommend it if you are using shared libs for ncurses. If you check out the top of the NEWS file in ncurses, you'll find that a tremendous amount of stuff has changed since 5.0. The ncurses update won't affect mutt if the libs are compiled in statically.
Re: procmail
Then the usual reason why .forward is ignored is unsafe permissions on your homedir or your .forward / .procmailrc (should not be group-writeable). Unless you have one group per user, and procmail was configured accordingly. As appears to be the case with at least one major Linux distro. But why would anyone use Linux anyway ...
Re: SMTP AUTH-capable MTA
My issue is not with sendmail, per se, but with a new set of policies that have been implemented locally. Redirecting all mail from the Unix host to a Windows NT machine to be virus and content screened is a decision I disagree with. And seeing as that screening server has already had three significant downtimes in the past month I'd like to bypass it altogether. Maybe your Unix people were asleep when that policy was decided? There are several commercial and semi-commercial (you always need to buy at least a virus scanner) solutions for virus scanning on Unix machines. This is better than running a virus scanner on a system that itself is prone to infections (think orthogonal). There were also a couple of bugtraq postings in the past few months about vulnerabilites in NT/2000 versions of some commercial screening software. If that system already had downtime, you have a good case for pushing into the other direction now. Sorry for the OT ;)
Re: Procmail
:0 Whc: .msgid.lock | formail -D 16384 .msgid.cache :0 a: /dev/null Overkill. :0 Wh: $HOME/.msgid.lock | formail -D 16384 $HOME/.msgid.cache is sufficient (why make a copy if you drop it to /dev/null anyway?) Overkill, yes, but still wrong. Please read also the next section in the procmailex man page, the one starting with Beware if you have delivery problems in recipes below this
Re: Prpblems Installing Mutt-1.3.20 from tar.gz ~ libiconv-1.7
tabanna writes: After doing ./configure I am getting the message that iconv is not good enough ~ try using libiconv instead ~ have already Installed libiconv-1.7 If libiconv-1.7 is, indeed, the correct version, then, What, please, do I need to do ? Try ./configure --help and check whether there's anything relevant.
Re: Installing Mutt 1.3.19
I did`nt find anything in my config.log, but then again, I`m fairly ignorant on these kind of things. I was wondering if someone could check it out. Attached is the config.log, sorry if it bothers anybody, this is the first and last time I attached an unrequested file. It was created by configure, which was generated by GNU Autoconf 2.50. Invocation command line was Uninstall autoconf 2.50 and install autoconf-2.13. (Or install autoconf 2.13 in a location in your path that has precedence over the location of 2.50). Unpack a fresh copy of the mutt archive and run the included prepare script. You can specify the same cmd line options you would use with configure.
Re: Installing Mutt 1.3.19
Thanks a lot, as you can see it worked: [nelsong:~]$ mutt -v Mutt 1.3.19i (2001-06-07) System: Linux 2.4.5 [using ncurses 5.2] Is that problem with autoconf 2.50 in general or just the one that`s shipping with slackware? autoconf 2.5x is not fully backwards compatible. I have not yet had the time to find out what exactly goes wrong, and whether it is possible to rewrite configure.in to work with both versions.
Re: feature request
Erwin Kaiser writes: Mutt is great! Two features I'd like to propose: 1. The screen should be cleared at termination. This is a feature of the terminal emulator you are running. This is the reason why I replaced the xterm terminfo entry on my Solaris box with the X11R6 xterm definition from ncurses ;)
Re: Evaluation of shell commands in .muttrc
The header stays the same for the entire mutt session. I thought to myself that perhaps the my_hdr was only being evaluated once, so I tried the following instead: Insert send-hook . 'unmy_hdr X-BOFH-Excuse:' before the one below. See section 4.4 Using Hooks in TFM. send-hook . my_hdr X-BOFH-Excuse: `fortune -n 80 -s bofh-excuses | tail -1`
Re: compiling Mutt with ncurses
Eugene Lee writes:
When I built ncurses-5.2, I set the installation prefix to /usr/local.
The libraries are in /usr/local/lib, which I expect. But the header
files are grouped into a /usr/local/include/ncurses directory. The
configure script for mutt-1.2.5i can't figure this out --- or maybe I
can't figure out how to set --with-curses=DIR. Is there a nice way to
this work? Or is it time to hack the configure script? Any suggestions
are welcome!
Unless TED has a better suggestion :-)
--- configure.in.orig Wed Jun 13 06:30:17 2001
+++ configure.inMon Jun 18 16:53:06 2001
@@ -173,7 +173,11 @@
fi
if test x$mutt_cv_curses != x/usr; then
LDFLAGS=-L${mutt_cv_curses}/lib $LDFLAGS
-CPPFLAGS=$CPPFLAGS -I${mutt_cv_curses}/include
+if test -d $mutt_cv_curses/include/ncurses; then
+CPPFLAGS=$CPPFLAGS
+-I${mutt_cv_curses}/include/ncurses
+else
+CPPFLAGS=$CPPFLAGS -I${mutt_cv_curses}/include
+fi
fi])
for cf_ncurses in ncurses ncursesw unknown
Re: compiling Mutt with ncurses
The script should recognize this (I haven't looked recently, but thought that mutt's configure script used chunks of script that I'd written to encompass this). CF_CURSES_LIBS is not used in 1.2.5, and the parts we borrowed don't cover header file location. Hhm, just by looking at it now I cannot figure out whether CF_NCURSES_CPPFLAGS or CF_ADD_INCDIR does the right thing in the situation described ...
Another pop3 question
I've been playing around with cucipop, but I can't seem to make it work with mutt. Running cucipop in debug mode, all seems to fine: after specifying USER and PASS, I can LIST and STAT, the mailbox, RETR messages etc. But mutt (1.3.19) only ever tells me that APOP authentication failed, Fetching list of messages ..., and then quits. I compiled cucipop with and w/o APOP, ran it with and w/o -A, no luck. So, who's the culprit here?
Re: ..and the mouse?
Is there any chance with Mutt to use the mouse? What for? One of the reasons I like mutt for is that I can keep my hands on the keyboard at all times.
Re: ..and the mouse?
Is there any chance with Mutt to use the mouse? What for? One of the reasons I like mutt for is that I can keep my hands on the keyboard at all times. Copy and Paste, especially if you use an xterm. I don't think this qualifies as using the mouse with mutt ;-)
Re: index format
Doug Kearns writes: Hello all, Is there some way to to set the index format so that it strips certain characters from the subject( %s ) ? eg. I'd like to strip the leading [...] from the subject [ruby-talk:15734] java based interpreter and regexes There is no way to do it in mutt, as the format strings available for index_format don't allow access to substrings. But you can do this in procmail: :0 fhw * ^Subject:[]*\[[^]]*\][]\/.* | formail -I Subject: $MATCH The empty bracket pairs contain a space and a tab each.
Re: X-Face header
Ralf Hildebrandt writes: Ok, I found out how to generate an X-Face suitable image using compface, but how can I insert the header from within mutt? my_hdr X-Face: the four line string but a) The string spans multiple (4) lines b) makes mutt crash (segfault) Well, Ralf, I'm sure you know the routine: version info, backtrace etc. :-) I _think_ that # characters in the X-Face string need to be escaped \#. If this is what makes mutt crash, the config file parser needs to be sanitised. Not sure about other characters.
Re: request for SMTP integration (was Re: Mail using non-local SMTP server.)
Mutt doesnt ask for it - and postfix / exim / qmail dont implement DSN at all Postfix now supports DNS: Major changes with snapshot-2924 DSN formatted bounced/delayed mail notifications, finally. The human-readable text still exists, so that users will not have to be unnecessarily confused by all the ugliness of RFC 1894. Postfix does _not_ support DSN. The ChangeLog above is about DNS-like formatting of notification messages! To support DSN, an internal protocol and interface redesign is necessary. This is not going to happen anytime soon.
Re: Multiple [*.log] file attachements from script
[Note: moved to mutt-users only!] I am using mutt to send e-mail messages to the development group following a product build/compile. Now I am writing some scripts for a new product which is made out of multiple modules each of which will be built individually. I may find myself in a situation where I do not know how many *.log files I end up with after the build. If I do try to send a message and try attach and inexistent file -:) , mutt will not send it, of course. My question is: Is there a way that I can tell mutt to attach whatever *.log files happen to exist in the current directory, from within a script, knowing that there may me one or more such files? Let the script build the mutt command line. attach= for i in *.log ; do test -s $i attach= -a $i ; done ... mutt -s $subject $attach rcpt /dev/null
Re: Saving messages w/o the headers
is there a slick way to save 'read' messages to a folder w/o all those space-wasting headers? Or am I forced to run the folder file through a 'filter' script? TIA... In many cases, I find the headers more useful than the contents ...
Re: alias list expansion
JT Williams writes: Hi, How can I request that mutt does *not* expand an alias list? Suppose I have alias foo-workers worker1, worker2, ... and I send a message to `foo-workers'; I do *not* want the To: field to be expanded into the names of everyone on that list. Leave To: empty and use Bcc:, or set up a proper mailing list.
Re: Help...I forgot...
Scott Davis writes: Please forgive my short memory. I know when you compose a message in mutt, and you are at the final screen preparing to send, you can change the From: line with CTRL something or ALT something. I just forgot. Thanks in advance, Close, but no cigar ;-) Pressing ? in the send menu gives you, among other things, Escf edit-from edit the from field
Re: lag
Igor Pruchanskiy writes: I am having some serious lag sending mail to this list. Is that normal ? Takes about 20 min to show up on the list This certainly cannot be called serious!
Re: How handle HTML emails?
Dr. Christian Seberino writes: How do people read HTML emails? If I'm in a good mood, I ask the poster to switch it off. Otherwise /dev/null.
Re: debian-user save hook
I do it like this in my muttrc, is there a better way, maybe one that works for all subscribed lists with a single command? subscribe mutt-users@ fcc-save-hook '~C mutt-users' =mutt-users subscribe sawfish@ fcc-save-hook '~C sawfish'=sawfish In addition to the subscribe command, I use save-hook ~l =%O send-hook ~l 'push f^Uenter'
Re: printf format
For example: the index format uses %-15.15L And I found out that these 15.15 is working like the C printf. So I tried to find some info which explains what C printf is. The only thing I found was some complicated mathematics about this being a format of telling how a printer is going to bring that to paper when digging somewhere in the groff pages. But this may not be related. Have you tried man printf(3)? ;-) [...] - A negative field width flag `-' indicates the converted value is to be left adjusted on the field boundary. Except for n conver- sions, the converted value is padded on the right with blanks, rather than on the left with blanks or zeros. A `-' overrides a `0' if both are given. [...] o An optional decimal digit string specifying a minimum field width. If the converted value has fewer characters than the field width, it will be padded with spaces on the left (or right, if the left-adjust- ment flag has been given) to fill out the field width. o An optional precision, in the form of a period `.' followed by an op- tional digit string. If the digit string is omitted, the precision is taken as zero. This gives the minimum number of digits to appear for d, i, o, u, x, and X conversions, the number of digits to appear after the decimal-point for e, E, and f conversions, the maximum num- ber of significant digits for g and G conversions, or the maximum number of characters to be printed from a string for s conversions.
Re: Orphaned tmp files?
Jim Lambert writes: I've noticed that mutt occasionally forgets to clean up tmp files. It seems to be an intermittent problem and I was wondering if other users had seen it. -Jim mutt -v Mutt 1.2.5i (2000-07-28) Copyright (C) 1996-2000 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: SunOS 5.8 [using slang 10202] ^ For a long time, I have been harboring a suspicion that there is a bug in Solaris 2.[678]'s unlink(2) if used in /tmp. I see quite a few temp files left over in /tmp, some by homebrewn programs, some by system commands (man(1) seems the worst offender). It doesn't always happen, maybe there is some kind of (not so rare) race condition.
Re: Pb with this mailing list
Andre Berger writes: Whenever I post to this list, I get an undeliverable mail-receipt, saying [EMAIL PROTECTED] Too many "Received" headers - suspected mail loop This has begun about a week (or two) ago. How to deal with the situation? More than likely a mail loop. You need to examine the Received: headers and find out where the loop occurs, and then notify the postmaster of the offending site. If this is not possible, said .ac.za address should be taken off the list. [Btw, signing emails to this list is virtually useless to anyone if the public key is not available from the keyservers. gpg: Signature made Sun Apr 15 11:30:15 2001 IST using DSA key ID 07182FBC gpg: requesting key 07182FBC from horowitz.surfnet.nl ... gpg: no valid OpenPGP data found. gpg: Total number processed: 0 gpg: Can't check signature: public key not found ]
Re: How to display a mail in raw format
I was wondering how one can display any mail in it's pure, raw format within Mutt. So as to get the same result than if I would load the mbox file into an editor and look at a particular message. e edit edit the raw message if you can exit your editor without saving anything back to disk ;-)
Re: [OT - Procmail] Filter UU/XXencode and HTML?
This time, I'm wondering how to convert XX/UU-encoded stuff (which, after what I've noted, can be difficult in MUTT when some broken mailer was there before) into proper MIME attachments. Also, I wonder how in the world shall I make procmail take a (optionally MIME-encoded) message with HTML and turn it into plain text, so I can read the thing? I would just bounce it straight, or delete it. Lusers who send html email should not be encouraged. My personal opinion only, of course. I heard something called emil would do this, but the docs aren't really what I'd call helpful... Hhm. I've played around a bit with emil, but couldn't figure out anything useful. Maybe metamail, or reformime (from the maildrop package), or a combination of those and emil might work. Check out the procmail archive at http://www.xray.mpe.mpg.de/mailing-lists/procmail/ Html conversion was discussed only recently (March) IIRC. For the other question, it could be worth posting to the procmail users list directly. See http://www.procmail.org/.
Re: vim procmail recipe
How about: :0 Whc: msgid.lock | formail -D 8192 msgid.cache :0 a: dupes.lock $HOME/Mail/duplicates This is the super safe version; if you're confident w/ this, you can drop the second recipe and the c flag from the first. It's not a matter of confidence. This _is_ the safe version. Read procmailrc(5), and if the above recipe (or some variation of it) is not there, upgrade to a newer version of procmail.
Re: procmail mailing list strategy (was Re: vim procmail recipe)
Here is how I deal with mailing lists in my .procmailrc: # eliminate duplicate messages :0Wh: msgid.lock | formail -D 16384 archive/msgid.cache This is *bad*. If procmail fails somewhere after dupes checking and the message is requeued, the next delivery attempt will detect that message as duplicate and silently nuke it. Recommended reading: the c_o_m_p_l_e_t_e_ entry for duplicate filtering in the procmailex man page!
[Fwd: mutt+gpg=screen_corruption]
I'm fwd'ing this for someone who is not reading the list. Any ideas? The problem is that every time he hits a signed message (during the same mutt session), the status line at the bottom gets corrupted more and more. It happens under xterms, gnome-terms, and the linux console. All relevant system info is included below (RedHat/slang). The gpg config file used is from Gero Treuner's gpg-2comp, which I'm using, too. | if you could, that would be nice. i have two more examples beyond those | in my ilug post: | | the ilug post screenshots - just showing corruption. | http://suberic.net/~kevin/mutt/2001_04_02_220431_shot.jpg | http://suberic.net/~kevin/mutt/2001_04_02_220609_shot.jpg | | your message corrupted: | http://suberic.net/~kevin/mutt/2001_04_03_143531_shot.jpeg | after ^L: | http://suberic.net/~kevin/mutt/2001_04_03_143710_shot.jpeg | | note the bits of previous screens in the corrupted display - not just | at the bottom. it's the standard mutt from redhat's 6.2 update: | mutt-1.2.5i-8.6 mutt -v yields: | |Mutt 1.2.5i (2000-07-28) |Copyright (C) 1996-2000 Michael R. Elkins and others. |Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. |Mutt is free software, and you are welcome to redistribute it |under certain conditions; type `mutt -vv' for details. | |System: Linux 2.2.17-14 [using slang 10202] |Compile options: |-DOMAIN |-DEBUG |-HOMESPOOL -USE_SETGID -USE_DOTLOCK +USE_FCNTL -USE_FLOCK |+USE_IMAP +USE_GSS +USE_SSL +USE_POP +HAVE_REGCOMP -USE_GNU_REGEX |+HAVE_COLOR +HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS +ENABLE_NLS |SENDMAIL="/usr/sbin/sendmail" |MAILPATH="/var/spool/mail" |SHAREDIR="/etc" |SYSCONFDIR="/etc" |-ISPELL |To contact the developers, please mail to [EMAIL PROTECTED]. |To report a bug, please use the muttbug utility. | | gpg is also a standard redhat packaged binary: gnupg-1.0.4-8.6.x, and | slang is what's on the redhat 6.2 cd: slang-1.2.2-5. i've also switchd | from tcsh to zsh so i have a pretty bog standard environment.
Re: [Fwd: mutt+gpg=screen_corruption]
Argh, I hate following up myself ... Lars Hecking writes: I'm fwd'ing this for someone who is not reading the list. Any ideas? The problem is that every time he hits a signed message (during the same mutt session), the status line at the bottom gets corrupted more and more. It happens under xterms, gnome-terms, and the linux console. All relevant system info is included below (RedHat/slang). The gpg config file used is from Gero Treuner's gpg-2comp, which I'm using, too. Well, not quite, and that was making a difference! My setting of set pgp_getkeys_command in gpg.rc is empty, while his was set pgp_getkeys_command="gpg --recv-keys %r" The "screen corruption" was due to the output of this command. Workaround: set pgp_getkeys_command="gpg --recv-keys %r /dev/null 21" Is that something mutt should take care of automatically (unexpected output of some commands, that is)?
Re: [Fwd: mutt+gpg=screen_corruption] - output redirection
Is that something mutt should take care of automatically (unexpected output of some commands, that is)? How does a program catch "unexpected things"? Besides, if it expected anything they would not be unexpected, now, would they? ;-) I kind of expected a reply like this ;-)
Re: [MAILER-DAEMON@localhost.localdomain: Returned mail: see transcript for details]
MAIL From:[EMAIL PROTECTED] 553 sorry, your sender is not liked (#5.7.1) 501 5.6.0 [EMAIL PROTECTED] Data format error If kde.org is blocking mail.com, what can we (or mutt) do? That's understandable. One of our users, long gone, seems to have set up a fwding account at mail.com. This account is still receiving tons of spam (which gets all bounced, of course), and my numerous requests to mail.com to remove this account have not been honoured, even though I included spam samples. And most of their dialups/dsl boxes etc. are so open you could drive an aircraft carrier through ...
Re: [MAILER-DAEMON@localhost.localdomain: Returned mail: see transcript for details]
Suresh Ramasubramanian writes: Lars Hecking proclaimed on mutt-users that: And most of their dialups/dsl boxes etc. are so open you could drive an aircraft carrier through ... Lars - you got mail.com confused with someone else. They don't do dialup / dsl - they are a freemail service (free webmail + forwarding, paid pop3 / smtp) Ooops, sorry - wrt dialups, I meant home.com. Apologies for any pre-caffeine statements :)
Re: Procmail user+ext@bla.com addresses
I think he was looking for a somewhat more general solution:) Maybe: :0: * ^TO_user+\/.*@her\.com `echo $MATCH | sed "s/@.*//"` Untested, of course. (You might have to escape the "+" in the second line, cannot remember the procmail regex syntax right now, too late:) Yes, you have to. Ralf and I exchanged some more email and finally settled on :0 * ^Delivered-To: copymail\+\/[^@]* /copymail/Maildir/$MATCH/ as he cannot use the From: header. No locking is required for maildir delivery.
Re: Procmail user+ext@bla.com addresses
Ralf Hildebrandt writes: I can use a (folder)-hook to set my From: header and envelope from to [EMAIL PROTECTED] But how can I motivate procmail to filter my mail into /home/user/Maildir/muttusers if a mail to [EMAIL PROTECTED] comes back in? What about :0: * ^TO_user+muttusers@her\.com /home/user/Maildir/muttusers/ ?
Re: your mail
Well, passing the message to a very simple one line script seems to work. I made a ~/.mutt/mailout (mode +x to make it executable): #!/bin/sh cat | procmail ~/.procoutrc # End of ~/.mutt/mailout [Splutter] Useless Use of cat.
Re: Mutt, procmail, and sendmail
[Splutter] Useless Use of cat. Thanks, Lars, for that marvelously helpful comment. I didn't find any better solution on my own, though. There is none. The problem, as you stated correctly, is that mutt passes sender and recipient addresses to $sendmail on the command line, but procmail expects only rcfiles and/or environment assignments as arguments. Using 'set sendmail="procmail ~/.procoutrc"' didn't seem to work because of the recipients being included on the command line by Mutt. Is there a better way to get the message passed to procmail from Mutt? send-hooks would seem a logical alternative, but I have no idea why the restrictions you quoted exist in the first place. How exactly to you change the recipient headers? Are you trying to work around a different kind of config problem (eg. masquerading)?
Re: Sending mail with attachment from a shell script
Cristian Gheorghe writes: Hello, I am trying to use mutt in order to be able to send e-mail notifications in regards to the nightly source code builds that I am doing. Something to the extent of "Build Failed", see attached file. I can see how to attach a file, specify the address, subject, etc. It's just that if I want to do this from the command line without going inside the interface I can not. mutt -y [EMAIL PROTECTED] -s "Build Failed" -a ./build.log -y is for interactive use. mutt -s "Build Failed" -a ./build.log [EMAIL PROTECTED] /dev/null
Re: outlook 2000 attachments
Encapsulation Format." The product I QA for can read these, but there isn't any publicly available code that I'm aware of to decompose TNEF files. There are plenty. Off my head, I can think of Convert-TNEF on CPAN, and a standalone conversion program called tnef on http://world.std.com/~damned/software.html.
Re: outlook 2000 attachments
There are plenty. Off my head, I can think of Convert-TNEF on CPAN, and a standalone conversion program called tnef on http://world.std.com/~damned/software.html. Amavis uses (or rather, requires) this damned program afaict. I find it extremely funny that you should mention amavis to me ;-)
Re: Minor build problem with 1.3.16i
I have just built mutt 1.3.16i and had a (minor) problem. This is mutt-users. mutt-1.3.16.i is a development version, and feedback about this version should go to mutt-dev. The solution to your problem is in the mutt-dev archives. In fact, it was even posted here less than a week ago. The ./configure produced one error:- sed: can't read ./doc/instdoc.sh.in: No such file or directory
Re: hostname
I sent two msgs to two members of Mutt-Users' List (directly to their email address) and both msgs were bounced back because of the ff. errors: So that was you ... How can I fix the problem? Before I set ~/.procmailrc everything seems fine. Could the error be cause by ~/.procmailrc? No way. Unless you filter *outbound* mail through procmail.
Re: sending attachments
Mullen A.J. writes: To elaborate on my earlier question about including attachments, the following is what I'm sending out. This is the raw text of the mail. When Mutt receives this, it's able to parse it without a problem and treat the attachments and text appropriately. When other mailers (so far tried with emacs and hotmail, among others) they fail. You are running mutt-1.3.8, right? Then you should post to mutt-dev, not mutt-users. 1.3.8 is ultimately outdated. I'd recommend to upgrade to the latest devel version 1.3.16 (or use 1.2.5, the latest stable release). The problem you observe was fixed in mutt-1.3.9. 1.3.8's handling of character set conversion (iconv) was broken. I had a very similar problem with 1.3.8 on Solaris.
Re: mutt 1.3.16i build problem
Marcelo Martinelli writes: i have been trying to build mutt 1.3.16 on my machine (RH 7.0) and when i run ./configure i get the following error message: sed: can't read ./doc/instdoc.sh.in: no such file or directory can anyone help. http://groups.yahoo.com/group/mutt-dev/message/10239
Re: how to overried mime types?
Michael S. Tsirkin writes: Hello! I get lots of mail from Outlook which all have attachments of the type "application/octet-stream". I would like in this case to use file extension to select the viewer for the attachment. This is precisely what Dave Pearson's mutt.octet.filter does. http://www.hagbard.demon.co.uk/mutt.html
Re: A newbie question regarding sending mail and the time it takes
Per Dalum Jensen writes: Hi all! I've just downloaded and installed mutt on a Solaris system and have a question. When I send a mail, it takes allmost forever for Mutt to complete the action and return the control to me. Is that normal or is there something I can do to change this behaviour? I can't seem to find anything in the FAQs or man pages. How long exactly is "forever"? Sounds like a possible DNS problem to me (sendmail does a lookup on the recipient addresses). Do you generally have problems with, say, telnet, ftp, netrape, other mail clients? If I succeede in getting Mutt to work, I can ditch the Outlook client, that my company uses and I will then be very happy :-) That's a worthy cause, indeed ;-)
Re: autoconf and mutt-1.3.14
Well, now I understand the directory structure of the mutt site a little better, so in the future I won't get lost again. But is there any documentation that would direct people to the "devel" directory instead of "snapshots"? The intended target audience for devel hangs out on mutt-dev ...
Re: autoconf and mutt-1.3.14
Michael Tatge writes: Lloyd Zusman muttered: I have recently downloaded the current unstable mutt release, version 1.3.14. It doesn't come with a `configure' script Mine does: Maybe he downloaded the cvs version? It does indeed not have a configure script, and one needs to run the included prepare script to generate all auto* files. If the generated configure script is broken, someone may have messed with autoconf on that box.
Re: autoconf and mutt-1.3.14
Now I realize that this tarball probably contains the same data as what I would have gotten if I went directly to CVS, and therefore, I now see that the `prepare' script applies to this tarball, as well. Correct. The tarball you downloaded is a daily (or nightly :) snapshot of the cvs. All release archives mutt-1.x.yi.tar.gz include the necessary files.
Re: mutt-1.25.i message id errors
Steve Kennedy writes: I dont know whether it's mutt or the mta, however someone on the lists here was using mutt and generating a header of the form Message-ID: whatever.whatever@ Which was being rejected by lots of MTA's (and thus causing bounces). Is this mutt ? I guess mutt doesn't know the hostname it's running on, or you have set hostname="" in .muttrc.
Re: mutt-1.25.i message id errors
Not me, a list-user ... I just get the crap bounces ... Oops, sorry, I misread your message. You are refering to [EMAIL PROTECTED]? Still, what I posted applies. The problem can be remedied by setting hostname explicitly in .muttrc. Besides, bouncing emails with malformed bad message-id's is a daft idea.
Re: mutt and Maildir support
Ralf Hildebrandt writes: Basically just a very basic question: You'll get a very basic answer, too :) mutt can use Maildir type folders. But how can I tell procmail to sort my Mail into Maildir type folders instead of Mbox type folders? man procmailrc. And you definitely want procmail 3.15 or newer.
Re: mutt and Maildir support
Might be. But Procmail-3.15.1 can do this without a patch. Isn't it great if an author accepts patches to his program... The procmail author hasn't been involved with the software in years!
Re: Sender
Ilya writes: Can I stop mutt from putting sender header? I have two domains setup on my system. alchemistry.net and krel.org. The bsd's main host is alchemistry.net. But my email is usually from @krel.org. I noticed that in headers there is User-Agent: Mutt/1.2.5i Sender: Ilya Krel [EMAIL PROTECTED] though Reply-To: and From: is [EMAIL PROTECTED] $ cd src/cvs/mutt/ $ grep Sender: * $ mutt doesn't generate a Sender: header. It's most likely your MTA.
Re: mutt postfix
[Please don't sign list email, or upload your key to one of the public keyservers. Thank you.] geoffrey writes: [..] The problem is that I cannot get mutt to hand off mail to postfix for delivery. When I attempt to send email, mutt stops with the message: "Error sending message, child exited 127 (Exec error.)." How do I correct this? I compiled both mutt and postfix myself, and they live on a box that I built from sources. Thus I have no rpm installed as of yet. When I looked over the mutt Makefile I noticed the line: SENDMAIL = no How should this be amended to indicate that I use postfix as my mta? I know that postfix is working properly since I am able to send email by hand. Thanks for any, and all, help. Where is postfix installed? In particular, where does the sendmail compatibility wrapper live? mutt's configure should have found it in any standard location (/usr/lib, /usr/sbin etc.).
Re: Question regarding clearsigning emails automatically
[EMAIL PROTECTED] writes: Hi, I would first like to thank Graham, Brian, and Andrew for their responses to my question regarding clearsigning my emails. As you can see, this message is clearsigned. Please trim your lines to 72-76 chars per line. Thank you. IMHO signing list email is a useless and wasteful exercise, especially if the sender hasn't submitted his/her keys to the public keyservers. In this situation, those who have configured their encrytion software to automatically import keys from these servers are penalised.
Re: gnupg vs pgp?
This is getting kind of off-topic for this list ... Is the German government just as much a police state as the US? I'm not sure, but I suspect that -- in spite of their Orwellian ban on teaching the history of Germany in the 1930s and 1940s and other evidence -- they are not. I am German, and I have absolutely no idea what you are refering to by your statement. What ban? What "evidence"? On the other topic: it seems that all Western countries are moving towards police state, in the disguises of "safety", "security" "fight against crime and child porn" etc. While many republican constitutions are based on ideas that were developed (or put in writing) by philosophers a couple of hundred years ago (separation of powers, protect the individual from the State), a shift of paradigm seems to have taken place. Now it's the State who protects its subjects, even at the cost of civil liberties. Witness the ongoing discussions, legislative attempts and actual legislation (eg. RIP) about monitoring all kinds of electronic communications, or the introduction of a new mobile phone generation with with builtin GPS. The general public is complacent, the media don't pick up. Industry is only opposing these things if their means of making money are affected (i.e. rarely). And all the piecemeal changes over the years taken together have way outclassed Orwell already. The US govt seems to be a driving force in these efforts, even on the international stage. Sorry for the outburst ...
Re: compressed mailbox mutt
Please trim your long lines next time. But when I try to access this oldlih.gz I am getting the message for a split second decompressing oldlih.gz and than the mutt bar displays the message no mailbox. What's wrong ? It's called *compressed* folders patch - not "tar'ed and compressed" folders patch.
Re: gnupg vs pgp?
Ralf Hildebrandt writes: On Thu, Dec 14, 2000 at 07:44:57PM +0100, Thorsten Haude wrote: Yup. We're the good guys Well, I wouldn't go this far. We're considerably better than the most :) Sure. "Am deutschen Wesen soll die Welt genesen." Heard that before. Didn't like it.
Re: [1.2.5] resend-message
Vincent Lefevre writes: The resend-message function isn't documented in the manual. I submitted a patch for this back in August. It went straight into cvs (and 1.3.x). Moreover, it doesn't set the Bcc and Fcc fields (unlike the other send functions).
Re: From: depending on To:
I want my mutt to use different "From: " field values depending on the "To: " field. I managed to get it almost to work with the send-hook, but the problem is that the "From: " field changed with "my_hdr" directive doesn't get changed back to the default after sending the mail. Add another send-hook *before* the other one that resets this particual my_hdr: send-hook . 'unmy_hdr From:' send-hook '~t [EMAIL PROTECTED]' my_hdr From: ... I think I'll write up something for the manual ...
Re: gnupg vs pgp?
Myrddin writes: Just like the subject says. I see on the mutt homepage that gnupg is recommended over pgp. Are there reasons for this beyond the whole 'use gnu whenever possible because of their licensing'? Or are there real, functional reasons behind choosing gnupg over pgp? Much better compliance with the OpenPGP (RFC2440) standard? Check out http://www.gnupg.org/.
Re: Summary: courier-mta BROKEN.
Ok. I've attached the message here. It has a Content-Type charset specified. It also specifies a Content-Transfer-Encoding header. Both were inserted by mutt. What courier did was not to change the headers, but to re-order them, and that caused the signature to become invalid. So, the question is, why did courier change the order of the headers when they were perfectly valid? Simple: it mustn't. sendmail had the same bug, and they fixed it in 8.9.3.
Re: Fix References of Received Mails
#-- macro index ,T "\ pipe-messageformail -x Message-ID /tmp/mutt-msgIDenter\ enter-commandset editor=\ 'cat %s |\ formail -i \"References:\ \`cat /tmp/mutt-msgID;\ cat %s | formail -x References\`\"\ Some luser mailers use both References: and In-Reply-To:. Fixing just one of them has no effect in such a case.
Re: change color settings depend on tty in use
when I use Mutt on a direct console I like color settings. When I dial in
from work the color settings don't work very well even though I DO set
the terminal type correctly.
Is there a way I can have mutt apply different color settings depending
on terminal type, or may be depending on which tty I'm on , or some other
way to handle this issue?
I am using:
~/.muttrc:
# Color settings
source ${HOME}/.mutt/`echo $TERM`
Then, there are two files with different settings in .mutt, colors and mono.
$TERM is just a link to the approproiate file:
$ ls -l ~/.mutt
-rw-r--r-- 1 lhecking users1064 Aug 16 1999 colors
lrwxrwxrwx 1 lhecking users 6 May 8 22:15 dtterm - colors
lrwxrwxrwx 1 lhecking users 6 May 8 22:15 emacs - colors
lrwxrwxrwx 1 lhecking users 6 May 8 22:15 linux - colors
-rw-r--r-- 1 lhecking users 22 Sep 11 1997 mono
lrwxrwxrwx 1 lhecking users 4 May 8 22:15 screen - mono
lrwxrwxrwx 1 lhecking users 4 May 8 22:15 sun - mono
lrwxrwxrwx 1 lhecking users 4 May 8 22:15 sun-cmd - mono
lrwxrwxrwx 1 lhecking users 4 May 8 22:15 vt100 - mono
lrwxrwxrwx 1 lhecking users 4 May 8 22:15 vt220 - mono
lrwxrwxrwx 1 lhecking users 6 May 8 22:15 xterm - colors
lrwxrwxrwx 1 lhecking users 6 May 8 22:15 xterm-color - colors
