Re: compose with mutt on a remote server
Kai Grossjohann [EMAIL PROTECTED] wrote: | On Fri, Aug 31, 2007 at 08:30:12PM +0200, mess-mate wrote: | | Well..no. | I've a remote machine were i keep all the email's for all the users | (virtual). | From my desktop i connect with courier-imap to the remote server and | access my mailboxes with mutt. This works very well for reading but | when i compose or reply to a message my own send-hooks, signature | etc.. (~/.mutt) of my desktop no longer works. | | OK. Since mutt runs on your desktop, it will read the ~/.mutt file(s) | from your desktop machine. Copy them over. Do not change anything and where do i copy them over ? | | And since mutt runs on your desktop, it uses the mailer there. By | default, mutt invokes sendmail, so you need to configure that to send | mail properly. Alternatively, you could install msmtp and tell mutt to | use it, and tell msmtp how to send mail. (Using msmtp is what I do.) | Or you could use the smtp client feature of mutt and configure the | correct smtp server in mutt. (I've never done this.) | | Kai | More exactly: i've my ~/mutt on my desktop The messages are kept on a server like this: server.mydomain.com /home/vmail/mydomain.com/mess-mate/ and here are my folders I login as [EMAIL PROTECTED] and acess without any problem my folders and can send messages. But at that time my ~/.mutt is no more considered, so no more send-hooks and wharever. I've copied my ~/.mutt to server.mydomain.com/home/vmail/mydomain.com/mess-mate, but it didn't change anything with my own rigts an tryed also with the vmail rights. Best regards mess-mate
Re: Subject üî
Thus spake Kyle Wheeler [09/07/07 @ 08.01.34 -0500]: Latin1 it is, until further bizarre things pop up. Plus, xterm under X11 does it right under Latin1, while it is screwy under UTF-8. (uxterm and other things, like the -u8 option and friends, resulted in messed-up colors, including no colors in vim -- a deal-breaker). Hmm... For what it's worth, I use uxterm on my Mac all the time without problems. The messed-up colors sound like a $TERM problem. When you launch uxterm, what's it set to? Mine's xterm-16color. I've tried setting it to xterm-16color, 256color, and just color, all with no dice. The messed-up colors have a precedent. When I installed OSX 10.4 with Apple's X11, the colors were messed up: what should be a nice, royal blue is borderline light-turquoise, etc. These colors are perfect under OSX 10.3. So I built xterm myself, with 256 support, and put it into /usr/local/bin. This custom xterm has all the correct colors, even when I don't tell it to use all 256 colors. But 'uxterm' calls the custom xterm, and suddenly the bad colors reappear. It won't pass any colors at all to vim, to top it all off. -G
Re: Triple wrap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday, September 10 at 12:30 PM, quoth Meenal Pant: Does Mutt support Triple wrap ( sign,encrypt,sign)with smime or gpg ? If no, then what would be a way to achieve this? Mutt doesn't support this behavior. The way to get what you want would probably to do all your encrypting manually, by piping the message to gpg (you could codify it all in a macro, to avoid lots of retyping). While I recognize the importance of this to avoid surreptitious forwarding, do you know of any email programs that *do* support triple-wrapped (or whatever you want to call it) email? Most of the folks I email to that can read encrypted mail either use a similar PGP plugin that only supports SignEncrypt or use pine, which has the same limitation. ~Kyle P.S. For anyone curious why the OP wants this, read: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html - -- Morality, like art, means drawing a line someplace. -- Oscar Wilde -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFG5Z6eBkIOoMqOI14RAtt1AKDdyXj/ACVSCI+2K62eDu6XqLtrSwCgqUtw /vlEZ8lQ9WHMUQcvPmQI4YM= =vl2P -END PGP SIGNATURE-
Re: Triple wrap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday, September 10 at 12:30 PM, quoth Meenal Pant: Does Mutt support Triple wrap ( sign,encrypt,sign)with smime or gpg ? If no, then what would be a way to achieve this? I would point out that, as Don Davis suggests: Overall, it's clear that the simplest repair is to add the recipient's name, then Sign Encrypt(§ 5.1, bullets 1 and 3). The other solutions all require an extra hash of the message or of the encrypting key, so as to block Anderson's plaintext-replacement attack. Which mutt absolutely supports. ;) ~Kyle - -- Nothing makes a woman more beautiful than the belief she is beautiful. -- Sophia Loren -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFG5Z+HBkIOoMqOI14RAlLcAJwKqT+ZwbbGdy2R+ILlxtBYYQh3PwCfQQg5 Y1rIwxCjhw8lxrtFjmGn+FE= =8P6s -END PGP SIGNATURE-
Re: Subject üî
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday, September 10 at 03:42 PM, quoth [EMAIL PROTECTED]: I've tried setting it to xterm-16color, 256color, and just color, all with no dice. The messed-up colors have a precedent. When I installed OSX 10.4 with Apple's X11, the colors were messed up: what should be a nice, royal blue is borderline light-turquoise, etc. Ahhh, so THAT's what you mean by messed up. I *think* this is actually a result of a change, not to xterm, but to it's default configuration. The easiest way to change it back to the way you like it is to set things explicitly in your ~/.Xdefaults file, like so: xterm*color4: blue2 Or like this, to be even more explicit: xterm*color4: #A8 The hex is ordered: red green blue (obviously) When you change it, of course, you have to run: xrdb -load ~/.Xdefaults If that doesn't fix it for you, then your xterm really is messed up. Once you've done that, then xterm will use that color for color4 NO MATTER WHAT! uxterm, xterm, hand-compiled xterms, they should all have exactly the same color for color4, because you've explicitly set it. I even know how to do the same thing for Apple's Terminal.app: http://culater.net/software/TerminalColors/TerminalColors.php Personally, I rather like the color it is now---I find it much easier to read than before. ~Kyle - -- This is my simple religion. There is no need for temples; no need for complicated philosophy. Our own brain, our own heart is our temple; the philosophy is kindness. -- Dalai Lama -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFG5aV9BkIOoMqOI14RAi/4AKDKVmI6xe/JkiWfIHoVCpaQe1/c3ACg73pH UHT4PaMjzazhTHjlP6BPK0E= =p37K -END PGP SIGNATURE-
Re: Subject üî
Thus spake Kyle Wheeler [09/10/07 @ 15.13.49 -0500]: On Monday, September 10 at 03:42 PM, quoth [EMAIL PROTECTED]: I've tried setting it to xterm-16color, 256color, and just color, all with no dice. The messed-up colors have a precedent. When I installed OSX 10.4 with Apple's X11, the colors were messed up: what should be a nice, royal blue is borderline light-turquoise, etc. Ahhh, so THAT's what you mean by messed up. I *think* this is actually a result of a change, not to xterm, but to it's default configuration. The easiest way to change it back to the way you like it is to set things explicitly in your ~/.Xdefaults file, like so: xterm*color4: blue2 Or like this, to be even more explicit: xterm*color4: #A8 The hex is ordered: red green blue (obviously) When you change it, of course, you have to run: xrdb -load ~/.Xdefaults If that doesn't fix it for you, then your xterm really is messed up. Once you've done that, then xterm will use that color for color4 NO MATTER WHAT! uxterm, xterm, hand-compiled xterms, they should all have exactly the same color for color4, because you've explicitly set it. Thanks for the link and info. I may play around with it, but I'm hesitant, because xterm's colors are just fine *unless* I either (1) call uxterm, or (2) call the factory xterm from Apple as opposed to the one I built myself. If I tweak color defs in order to get uxterm to look correct, I don't want to mess them up for regular xterm. -G
Re: Subject üî
On 10.09.2007 (17:38), [EMAIL PROTECTED] wrote: Thanks for the link and info. I may play around with it, but I'm hesitant, because xterm's colors are just fine *unless* I either (1) call uxterm, or (2) call the factory xterm from Apple as opposed to the one I built myself. If I tweak color defs in order to get uxterm to look correct, I don't want to mess them up for regular xterm. You can specify settings specifically for uxterm: UXterm*termName: xterm-color , eg. -- Try to remove the color-problem by restarting your computer several times. -- Microsoft-Internet Explorer README.TXT
Re: Subject üî
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday, September 10 at 05:38 PM, quoth [EMAIL PROTECTED]: Thanks for the link and info. I may play around with it, but I'm hesitant, because xterm's colors are just fine *unless* I either (1) call uxterm, or (2) call the factory xterm from Apple as opposed to the one I built myself. If I tweak color defs in order to get uxterm to look correct, I don't want to mess them up for regular xterm. Don't worry, they won't. I include specific color settings as a standard part of my Xdefaults precisely because the defaults sometimes vary. All it does is force specific color numbers to be associated with the specific rgb values that you prefer. And of course, you can try them out, and if you don't like the results, change it back to how it is now without a second thought. :) ~Kyle - -- No nation is permitted to live in ignorance with impunity. -- Thomas Jefferson -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFG5dJiBkIOoMqOI14RArurAJ0RyTz3ib+spxYENBld62aYIybH/QCfUeVl zZeSV5eEF+2Is78NcfNHqYA= =R4Bx -END PGP SIGNATURE-
Re: Subject üî
Thus spake Kyle Wheeler [09/10/07 @ 18.25.23 -0500]: And of course, you can try them out, and if you don't like the results, change it back to how it is now without a second thought. :) I don't know what it is now, since I do not have an ~/.Xdefaults file. (not in my home dir anyway). Can I revert it just by deleting this file, if I create it? -G
Re: Subject üî
Thus spake Kyle Wheeler [09/10/07 @ 18.25.23 -0500]: And of course, you can try them out, and if you don't like the results, change it back to how it is now without a second thought. :) As a matter of fact, I don't seem to have .Xdefaults *anywhere* on my machine. There is something called .Xauthority in my home dir, but it is a blank file. -G
Re: Subject üî
On 2007-09-10, [EMAIL PROTECTED] wrote: Thus spake Kyle Wheeler [09/10/07 @ 18.25.23 -0500]: And of course, you can try them out, and if you don't like the results, change it back to how it is now without a second thought. :) I don't know what it is now, since I do not have an ~/.Xdefaults file. (not in my home dir anyway). Can I revert it just by deleting this file, if I create it? You usually have to do something with the X server or the window manager for the ~/.Xdefaults file to take effect or to remove its effects after removing the file. The surest way is to log out and log back in. The window manager I used to use had a root menu item that would reset the X resource database, but I haven't been able to find the equivalent on KDE. If you're careful and you know what you're doing, you can use xrdb to manage the X resource database. On 2007-09-10, [EMAIL PROTECTED] wrote: Thus spake Kyle Wheeler [09/10/07 @ 18.25.23 -0500]: And of course, you can try them out, and if you don't like the results, change it back to how it is now without a second thought. :) As a matter of fact, I don't seem to have .Xdefaults *anywhere* on my machine. There is something called .Xauthority in my home dir, but it is a blank file. I've lost track of what kind of system you're on, but you can usually find the system default settings for your X resources--those parameters you set in your ~/.Xdefaults file--in the /usr/lib/X11/app-defaults/ directory. You might also take a look at the xrdb(1) man page. HTH, Gary
Re: Subject üî
On 10.09.2007 (19:38), [EMAIL PROTECTED] wrote: Thus spake Kyle Wheeler [09/10/07 @ 18.25.23 -0500]: And of course, you can try them out, and if you don't like the results, change it back to how it is now without a second thought. :) As a matter of fact, I don't seem to have .Xdefaults *anywhere* on my machine. There is something called .Xauthority in my home dir, but it is a blank file. You can create it; once it's there, X will (on most systems) find it during startup. Settings there will not take effect immediately. You will first have to merge the new values into the settings database with the command xrdb -merge ~/.Xdefaults Then the changes should be reflected in any NEW shell you open. If you're not satisfied, go back and change and merge again. Note, however, that if you want to remove the new value completely, you can't just delete it from the .Xdefaults file, since the xrdb command just reads what is there, not what is not. There are ways to remove settings - see man xrdb. The easiest way is to restart X. Eyolf -- Acting is not very hard. The most important things are to be able to laugh and cry. If I have to cry, I think of my sex life. And if I have to laugh, well, I think of my sex life. -- Glenda Jackson
Xdefaults (was: Subject ü î)
* [EMAIL PROTECTED] on Monday, September 10, 2007 at 19:38:21 -0400 Thus spake Kyle Wheeler [09/10/07 @ 18.25.23 -0500]: And of course, you can try them out, and if you don't like the results, change it back to how it is now without a second thought. :) As a matter of fact, I don't seem to have .Xdefaults *anywhere* on my machine. If you use Apple's X11 have a look at /usr/X11R6/lib/X11/app-defaults/*, especially at /usr/X11R6/lib/X11/app-defaults/XTerm. ... and, of course: $ man xterm ;) c -- Python Mutt utilities http://www.blacktrash.org/hg/muttils/
