Re: How to prevent recoding of attachments?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, October 9 at 02:27 PM, quoth Jörg Sommer: when sending LaTeX files or translations of program strings mutt recodes them and breaks them. How can I prevent mutt sends the attachment with a different encoding as the local? In the LaTeX file I define the encoding of the file as option of the package inputenc. If I say utf8 there, mutt can't tell the recipient of the mail the file is encoded in latin1 or something else. The easiest way is to compress them first. The fundamental problem is that text attachments get labeled with a character set, and mutt has to make sure that this label is correct. Your solution for po files solves this problem by tricking mutt into believing that it's not actually a text file. Mutt *can* attempt to guess what character set text file attachments are in, using the $attach_charset setting. Here's the snippet from the manual: attach_charset Type: string Default: This variable is a colon-separated list of character encoding schemes for text file attachments. If unset, the value of $charset will be used instead. For example, the following configuration would work for Japanese text handling: set attach_charset=iso-2022-jp:euc-jp:shift_jis:utf-8 Note: for Japanese users, iso-2022-* must be put at the head of the value as show above if included. If you don't want mutt guessing, or if mutt proves to be pretty bad at guessing, the easiest workaround is to simply gzip your files before sending them - then mutt won't touch their insides. ~Kyle - -- Last comes the beverage of the Orient shore, Mocha, far off, the fragrant berries bore. Taste the dark fluid with a dainty lip, Digestion waits on pleasure as you sip. -- Pope Leo XII -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjuNz4ACgkQBkIOoMqOI15hrwCgy8hskcOT2mZ/JM6SrZZl6grA nVsAoIwIHhFeBU/SK2LfnGPqNAuZZxAp =o20X -END PGP SIGNATURE-
mutt's .mutt folders when saving attachments?
Hi, I didn't get a reply when I asked before, still keen to find out how to avoid mutt creating/leaving an empty .muttxx fo9lder in the directory in which an attachment is saved. I assume there's some option to autodelete these folders? -- Tim
Re: mutt's .mutt folders when saving attachments?
=- Tim Chown wrote on Tue 23.Sep'08 at 10:31:27 +0100 -= I didn't get a reply when I asked before, still keen to find out how to avoid mutt creating/leaving an empty .muttxx fo9lder in the directory in which an attachment is saved. I assume there's some option to autodelete these folders? Yes, rmdir ~/.mutt* Scan mutt-dev archive for this topic to understand origin, problems and workarounds. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: mutt's .mutt folders when saving attachments?
On Tue, Sep 23, 2008 at 04:08:35PM +0200, Rado S wrote: =- Tim Chown wrote on Tue 23.Sep'08 at 10:31:27 +0100 -= I didn't get a reply when I asked before, still keen to find out how to avoid mutt creating/leaving an empty .muttxx fo9lder in the directory in which an attachment is saved. I assume there's some option to autodelete these folders? Yes, rmdir ~/.mutt* Scan mutt-dev archive for this topic to understand origin, problems and workarounds. Hmm, well the Yahoo view of mtt devs mails doesn't throw up anything obvious. I think 'folder', 'attachment', 'save' are too generic a term to find a specific thread. Just very sad my mutt poops everywhere. Must be possible to train him. After recent discussions I'm almost afraid to ask... :/ -- Tim
Re: mutt's .mutt folders when saving attachments?
=- Tim Chown wrote on Tue 23.Sep'08 at 15:57:47 +0100 -= Scan mutt-dev archive for this topic to understand origin, problems and workarounds. Hmm, well the Yahoo view of mtt devs mails doesn't throw up anything obvious. I think 'folder', 'attachment', 'save' are too generic a term to find a specific thread. For me it was related to NFS, and it was about tmpdir/tmpfile generation. Lookout for posts by me, I suggested a patch to revert the newly introduced behaviour. After recent discussions I'm almost afraid to ask... :/ *grins* No worries, just keep improving. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: mutt's .mutt folders when saving attachments?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, September 23 at 10:31 AM, quoth Tim Chown: I didn't get a reply when I asked before, still keen to find out how to avoid mutt creating/leaving an empty .muttxx fo9lder in the directory in which an attachment is saved. I assume there's some option to autodelete these folders? There is no option to auto-delete those folders, they are deleted whenever possible. The reason they stick around is when there's a filesystem problem, and mutt doesn't think the directory is empty. Let me guess: you're using either vfat or something like sshfs? It boils down to the fact that some filesystems do not support operations that are necessary for safe operation, and give inconsistent or unreliable error codes when you try. This is yet another reason why using these sorts of filesystems for anything important in a unix system is a really bad idea. For more information, check this: http://marc.info/?l=mutt-devm=116775858411732w=2 ~Kyle - -- The most important thing a father can do for his children is to love their mother. -- Fr. Theodore Hesburgh -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjZCjkACgkQBkIOoMqOI14MJQCgt7luJa5zEutjpEgHiUm8pb4f cgQAninVcBcmCz0RfIqfvdlocIUNmdIc =dfWr -END PGP SIGNATURE-
Re: mutt's .mutt folders when saving attachments?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, September 23 at 05:10 PM, quoth Rado S: For me it was related to NFS, and it was about tmpdir/tmpfile generation. Lookout for posts by me, I suggested a patch to revert the newly introduced behaviour. http://marc.info/?l=mutt-devm=117588920724808w=2 Here's the relevant patch... which is supposed to fix the problem. http://dev.mutt.org/trac/changeset/c0e6d2617984/ ~Kyle - -- If an elderly respected expert in a given field tells you that something can be done he is almost certainly right. If an elderly respected expert in a given field tells you that something is impossible, he is almost certainly wrong. -- Robert A. Heinlein -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkjZCyEACgkQBkIOoMqOI16RmwCgi4i0nH5EaN9XTnYlscBdqL+n SFgAoKY401/z6wAsI6Rlxnxg7q3NuuSq =1Qkj -END PGP SIGNATURE-
Re: mutt's .mutt folders when saving attachments?
On Tue, Sep 23, 2008 at 10:28:33AM -0500, Kyle Wheeler wrote: http://dev.mutt.org/trac/changeset/c0e6d2617984/ ~Kyle - -- If an elderly respected expert in a given field tells you that something can be done he is almost certainly right. If an elderly respected expert in a given field tells you that something is impossible, he is almost certainly wrong. -- Robert A. Heinlein And if an elderly respected expert in a given field tells you RTFM, don't whine about it. RTFM advice is not (usually) an insult or an attempt to be nasty. Its usually valid and ALWAYS a good idea. Yes its the wrong thread, but the above sig was too timely to pass up! :-) In Summary: Never be afraid to ask and don't take RTFM personally. JK
Re: mutt's .mutt folders when saving attachments?
On Tue, Sep 23, 2008 at 11:54:19AM -0400, Jeff Kinz wrote: And if an elderly respected expert in a given field tells you RTFM, don't whine about it. RTFM advice is not (usually) an insult or an attempt to be nasty. Its usually valid and ALWAYS a good idea. On the other hand, some people who offer RTFM as advice are neither elderly nor respected. And some just do it way too often, period. I second David's well-said thoughts about the subject, especially in the context of Mutt. No matter how much I love it, Mutt's configuration is intricate and complicated in the extreme; reading its manual is a bit like reading a text on computer architecture. It contains lots of good information which is usually right (but not always), but that is both a blessing and a curse: IT CONTAINS LOTS OF INFORMATION. :) It's also, IMO, not very well organized from the perspective of I want to solve this particular problem with my e-mail, how do I do it? Finding what you need in the manual can be quite difficult, unless you know exactly what you're looking for, and even then... If you have time to sit down and read the 240+ some-odd* pages of Mutt's manual, and you're very serious about managing your e-mail, then you should do that. But in the end, even if they do need more power than what Pine or Outlook offer, most people just want to read their mail. - * as approximated by paging at 66 lines and counting pages until I got bored with counting at about 50% -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpK4NJsMquOo.pgp Description: PGP signature
Re: mutt's .mutt folders when saving attachments?
Quoting Derek Martin ([EMAIL PROTECTED]): No matter how much I love it, Mutt's configuration is intricate and complicated in the extreme; You haven't tried configuring Sendmail, have you? ;-) *SCNR* -Sndr. -- | Did you hear about the cat that ate a ball of wool? -- It got mittens. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D signature.asc Description: Digital signature
Re: mutt's .mutt folders when saving attachments?
* Sander Smeenk [EMAIL PROTECTED] [2008-09-23 19:35]: Quoting Derek Martin ([EMAIL PROTECTED]): No matter how much I love it, Mutt's configuration is intricate and complicated in the extreme; You haven't tried configuring Sendmail, have you? ;-) For a change you could have a look at fvwm ;-) pgpcgvIFZD1jp.pgp Description: PGP signature
Re: mutt's .mutt folders when saving attachments?
On Tue, Sep 23, 2008 at 07:33:31PM +0200, Sander Smeenk wrote: Quoting Derek Martin ([EMAIL PROTECTED]): No matter how much I love it, Mutt's configuration is intricate and complicated in the extreme; You haven't tried configuring Sendmail, have you? ;-) As a matter of fact, being a professional system administrator, I have... on many occasions. I think Sendmail is much easier. :) [...unless you need to do something really unusual.] -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpcmvCiLknzm.pgp Description: PGP signature
Re: mutt attachments html and cron
Hello Michael, Wednesday, July 2, 2008, 5:26:58 PM, you wrote: MK On 2 Jul 2008 17:19 +0300, by [EMAIL PROTECTED] (Paul -Spawn- Rysevets): ah.. btw.. when run by cron i've managet to get error-out: -- Error in /home/webmaster/.muttrc, line 2: header_cache: unknown variable source: errors in /home/webmaster/.muttrc Error in command line: content_type: unknown variable -- MK Do you by any chance have two different versions of Mutt installed? MK Try adding a cron job to be executed soon that runs which mutt - is MK the path the same one as when you run it from the command line? many thanks... this worked.. there were two different versions of mutt... one from console is 1.15 the one from cron is 1.14 ... so those content_type's were not working adding full path to new mutt fixed the problem. MK Usually when manually executed programs behave differently from when MK they are run through cron, the problem is that the environments MK differ. -- Best regards, Paul 'Spawn' Rysevets [EMAIL PROTECTED] SpAwN_gUy.aka.WAREZMasta [EMAIL PROTECTED] ICQ:968978 SKYPE-ID: spawn_guy
mutt attachments html and cron
Hello Mutt-users, i'm a bit new to linux world, but my current task needs to be finished though... okay.. here is the deal: i need to send html - e-mail from commandline with bunch of attachments.. every day .. i've wrote bash-script already.. and when run from console (like direct-execute) everything goes fine.. just as planned.. mutt -s System summary report for $THEDATE \ -e 'my_hdr From: scrapped eMail--' \ -e 'set content_type=text/html' \ -a $TMPDIR/d6intprod1_cpu.png \ [EMAIL PROTECTED] /home/master/stat/getsend_rrdstat_template.html this way.. mutt sets content type of std-in'ed .html to text/html... and all the mailers read it properly and display right html-page with attached pictures... i.e. fine, as i wanted it.. but... here comes the troubles... when i set this script to run by cron... - everything works except -- -e 'set content_type=text/html' \ -- even the change of From: is working fine... but not the content type :( ... please help.. i'm stuck with only this... ah.. btw.. when run by cron i've managet to get error-out: -- Error in /home/webmaster/.muttrc, line 2: header_cache: unknown variable source: errors in /home/webmaster/.muttrc Error in command line: content_type: unknown variable -- -- Best regards, Paul 'Spawn' Rysevets [EMAIL PROTECTED] SpAwN_gUy.aka.WAREZMasta [EMAIL PROTECTED] ICQ:968978 SKYPE-ID: spawn_guy
Re: mutt attachments html and cron
On 2 Jul 2008 17:19 +0300, by [EMAIL PROTECTED] (Paul -Spawn- Rysevets): ah.. btw.. when run by cron i've managet to get error-out: -- Error in /home/webmaster/.muttrc, line 2: header_cache: unknown variable source: errors in /home/webmaster/.muttrc Error in command line: content_type: unknown variable -- Do you by any chance have two different versions of Mutt installed? Try adding a cron job to be executed soon that runs which mutt - is the path the same one as when you run it from the command line? Usually when manually executed programs behave differently from when they are run through cron, the problem is that the environments differ. -- Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se * . No bird soars too high if he soars with his own wings . * * ENCRYPTED email preferred -- OpenPGP key ID: 0x 758F8749 BDE9ADA6 * * ASCII Ribbon Campaign: Against HTML mail, proprietary attachments * signature.asc Description: Digital signature
Re: mutt attachments html and cron
On Wed, Jul 02, 2008 at 05:19:39PM +0300, Paul -Spawn- Rysevets wrote: Hello Mutt-users, i'm a bit new to linux world, but my current task needs to be finished though... okay.. here is the deal: i need to send html - e-mail from commandline with bunch of attachments.. every day .. i've wrote bash-script already.. and when run from console (like direct-execute) everything goes fine.. just as planned.. mutt -s System summary report for $THEDATE \ -e 'my_hdr From: scrapped eMail--' \ -e 'set content_type=text/html' \ -a $TMPDIR/d6intprod1_cpu.png \ [EMAIL PROTECTED] /home/master/stat/getsend_rrdstat_template.html this way.. mutt sets content type of std-in'ed .html to text/html... and all the mailers read it properly and display right html-page with attached pictures... i.e. fine, as i wanted it.. but... here comes the troubles... when i set this script to run by cron... - everything works except -- -e 'set content_type=text/html' \ -- even the change of From: is working fine... but not the content type :( ... please help.. i'm stuck with only this... ah.. btw.. when run by cron i've managet to get error-out: -- Error in /home/webmaster/.muttrc, line 2: header_cache: unknown variable source: errors in /home/webmaster/.muttrc Error in command line: content_type: unknown variable -- So on the one hand you've got a bash script that you've run as your user, and on the other hand you have the same bash script as called from cron, perhaps by a different user? Does your script actually declare #!/bin/bash at the top? Cron may not use bash by default on your system. Run from the CLI as the same user that'll be doing it in cron and see if it fails that way. Make sure your run from CLI matches what's happening in cron exactly. Cheers, -- Cristóbal Palmer ibiblio.org systems administrator
Re: information about not saved attachments
=- Peter Münster wrote on Sun 29.Jun'08 at 23:29:37 +0200 -=
How could I get information about not saved attachments in the fcc-copy?
{...}
Is this already possible with mutt?
If no, then please consider this a feature request.
Hook yourself to the proper ticket and raise the relevance
with this. ;)
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
Re: Hi all, is there anyone knows how to send bigger attachments
On Mon, Jun 02, 2008 at 12:41:50PM -0500, David Champion wrote: It could be on your system, or it could be on the one that your system relays to when it sends the message on to the recipient. Where you find the configuration depends on what MTA you're using. If you're using sendmail, it's probably in /etc/mail/sendmail.cf and/or /etc/mail/sendmail.mc. If you're using postfix, it's probably in one of the files in /etc/postfix -- perhaps main.cf. Check your MTA's docuementation for whatever distribution of Linux you're using. Just had a look in my local sendmail config (which is relaying to an exchange server) and I have no size limit. Found an option in my sendmail.cf which are commented out: # maximum message size #O MaxMessageSize=0 But, as you can see, they are not active. I think this should be a common way. I would not like to run to every computer and configure a local limit if I can do so at a central point. /me -- bastard operator from hell regards, Marcus
Re: Hi all, is there anyone knows how to send bigger attachments
On 3 Jun 2008 10:03 +0200, by [EMAIL PROTECTED] (Marcus Franke): #O MaxMessageSize=0 But, as you can see, they are not active. I think this should be a common way. I would not like to run to every computer and configure a local limit if I can do so at a central point. The maximum size of a message that can be sent is the minimum size limit of the MTAs the message passes through. So your local sendmail may have no limit, but your smarthost or the remote MTA might, and in that case the remote server (which presumably is not under your control) is the one imposing the size limit. There is also the possibility of your connection having problems with prolonged uplink transfers. The easy way to test that is to simply upload a file of the same size as the message when encoded, to the server in question (be sure to disable any compression that may be in use), and see if that works. -- Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se * . No bird soars too high if he soars with his own wings . * * ENCRYPTED email preferred -- OpenPGP key ID: 0x 758F8749 BDE9ADA6 * * ASCII Ribbon Campaign: Against HTML mail, proprietary attachments * signature.asc Description: Digital signature
Re: Hi all, is there anyone knows how to send bigger attachments
Thanks, and thanks very much for all of your tips. But the problem is still not solved :( I am really a Linux newbie, however, i do have the access to the system but I cannot find the configuration file . I use whereis sendmail to find the MTA and it seems to be a file named exim4. But that's just a file, I did not find anywhere to review the configuration. I tried man exim4 but got a lot of complicated parameters ... So do I need to locate a configuration file or just use a parameter to tell/modify the limitations of my MTA ? On Tue, Jun 3, 2008 at 6:35 PM, Michael Kjorling [EMAIL PROTECTED] wrote: On 3 Jun 2008 10:03 +0200, by [EMAIL PROTECTED] (Marcus Franke): #O MaxMessageSize=0 But, as you can see, they are not active. I think this should be a common way. I would not like to run to every computer and configure a local limit if I can do so at a central point. The maximum size of a message that can be sent is the minimum size limit of the MTAs the message passes through. So your local sendmail may have no limit, but your smarthost or the remote MTA might, and in that case the remote server (which presumably is not under your control) is the one imposing the size limit. There is also the possibility of your connection having problems with prolonged uplink transfers. The easy way to test that is to simply upload a file of the same size as the message when encoded, to the server in question (be sure to disable any compression that may be in use), and see if that works. -- Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se * . No bird soars too high if he soars with his own wings . * * ENCRYPTED email preferred -- OpenPGP key ID: 0x 758F8749 BDE9ADA6 * * ASCII Ribbon Campaign: Against HTML mail, proprietary attachments * -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIRR57dY+HSb3praYRAjw9AKCReTA/+F+0szIhi+mrs1+FevAU7QCbB3bf 2YUvPqST2GIEiDl8UZN4BTI= =8fB0 -END PGP SIGNATURE- -- Blog in Chinese http://www.awflasher.com/blog/ Blog in English http://www.ifgogo.com/
Re: Hi all, is there anyone knows how to send bigger attachments
On Tue, Jun 03, 2008 at 06:55:31PM +0800, Awflasher(GuoQirui) wrote: I use whereis sendmail to find the MTA and it seems to be a file named exim4. But that's just a file, I did not find anywhere to review the configuration. ok, sendmail is just the interface. Its been the first mail server software so its binaries defined the standard interface. You could have a look in /etc/mail/ or maybe /etc/exim[4] if there are your config files. But, what we were trying to tell you, its very likely that your local machine has no size limitation for mails and its one of the other servers en route to your destinations mailbox. Have you looked at the header lines? Which server wrote the notification, that your mail was too huge? I tried man exim4 but got a lot of complicated parameters ... So do I need to locate a configuration file or just use a parameter to tell/modify the limitations of my MTA ? Exim4 on Debian uses /etc/exim4/exim4.conf. Have a look if you find the files. regards, Marcus
Re: Hi all, is there anyone knows how to send bigger attachments (a 6M sized file) with mutt?
Can not be... Am 2008-06-01 16:58:36, schrieb Awflasher(GuoQirui): Mutt is really great but I cannot get anything when sending a 6M file. It's ok for sending small files but when i'm trying to send a big file, it stopped working. Hope to get some tips, thanks very much!! END OF REPLIED MESSAGE Today morning I have send an attachment of 26 MByte (Debian Package) per mutt over then net... It take some time because Up-Stream is only 128 kBit (50 MBit Down-Stream) per Satelite but it works. Thanks, Greetings and nice Day Michelle Konzack Systemadministrator 24V Electronic Engineer Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 +49/177/935194750, rue de Soultz MSN LinuxMichi +33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Hi all, is there anyone knows how to send bigger attachments
On Sun, Jun 01, 2008 at 09:27:35PM +0200, Michelle Konzack wrote: Can not be... Size of mails is a system restriction enforced by your mail server. Your mail client just sends data to the mail server and somewhere in the line it may be restricted. Your server may be configured for 50MB files, Microsoft Exchange servers accept per default just 10MB. And thats about the raw message size, so if you have some 9MB file that gets uuencoded up to 11M, you crossed the line and the mail will be rejected. Marcus
Re: Hi all, is there anyone knows how to send bigger attachments
Thanks. But I am using a Linux system, and the file is just about 6M. I am just curious that where can I find the so-called system restriction ? Would u please give me some further tips ? Thanks very much in advance! On Mon, Jun 2, 2008 at 8:46 PM, Marcus Franke [EMAIL PROTECTED] wrote: On Sun, Jun 01, 2008 at 09:27:35PM +0200, Michelle Konzack wrote: Can not be... Size of mails is a system restriction enforced by your mail server. Your mail client just sends data to the mail server and somewhere in the line it may be restricted. Your server may be configured for 50MB files, Microsoft Exchange servers accept per default just 10MB. And thats about the raw message size, so if you have some 9MB file that gets uuencoded up to 11M, you crossed the line and the mail will be rejected. Marcus -- Blog in Chinese http://www.awflasher.com/blog/ Blog in English http://www.ifgogo.com/
Re: Hi all, is there anyone knows how to send bigger attachments
Thanks. But I am using a Linux system, and the file is just about 6M. I am just curious that where can I find the so-called system restriction ? It could be on your system, or it could be on the one that your system relays to when it sends the message on to the recipient. Where you find the configuration depends on what MTA you're using. If you're using sendmail, it's probably in /etc/mail/sendmail.cf and/or /etc/mail/sendmail.mc. If you're using postfix, it's probably in one of the files in /etc/postfix -- perhaps main.cf. Check your MTA's docuementation for whatever distribution of Linux you're using. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Hi all, is there anyone knows how to send bigger attachments (a 6M sized file) with mutt?
Mutt is really great but I cannot get anything when sending a 6M file. It's ok for sending small files but when i'm trying to send a big file, it stopped working. Hope to get some tips, thanks very much!!
Re: Hi all, is there anyone knows how to send bigger attachments
On 1 Jun 2008 16:58 +0800, by [EMAIL PROTECTED] (Awflasher(GuoQirui)): Mutt is really great but I cannot get anything when sending a 6M file. It's ok for sending small files but when i'm trying to send a big file, it stopped working. Hope to get some tips, thanks very much!! Please explain how exactly mutt stops working when you try to send a large file. I have sent files well into the two-digit megabyte range in e-mail using mutt with no problems (assuming the mail servers involved allow such large e-mails). -- Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se * . No bird soars too high if he soars with his own wings . * * ENCRYPTED email preferred -- OpenPGP key ID: 0x 758F8749 BDE9ADA6 * * ASCII Ribbon Campaign: Against HTML mail, proprietary attachments * signature.asc Description: Digital signature
Re: Hi all, is there anyone knows how to send bigger attachments
=- Awflasher(GuoQirui) wrote on Sun 1.Jun'08 at 16:58:36 +0800 -= Mutt is really great but I cannot get anything when sending a 6M file. That's not a mutt problem, check your sendmail config and your ISP limitations. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: Hi all, is there anyone knows how to send bigger attachments
em ... I just sent the mail (with mutt) and nothing received in my mail Is there any log file I could seek ? Thanks very much for your reply! On Sun, Jun 1, 2008 at 7:28 PM, Michael Kjorling [EMAIL PROTECTED] wrote: On 1 Jun 2008 16:58 +0800, by [EMAIL PROTECTED] (Awflasher(GuoQirui)): Mutt is really great but I cannot get anything when sending a 6M file. It's ok for sending small files but when i'm trying to send a big file, it stopped working. Hope to get some tips, thanks very much!! Please explain how exactly mutt stops working when you try to send a large file. I have sent files well into the two-digit megabyte range in e-mail using mutt with no problems (assuming the mail servers involved allow such large e-mails). -- Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se * . No bird soars too high if he soars with his own wings . * * ENCRYPTED email preferred -- OpenPGP key ID: 0x 758F8749 BDE9ADA6 * * ASCII Ribbon Campaign: Against HTML mail, proprietary attachments * -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQof3dY+HSb3praYRAsldAKCcpa/ZKxQJ1dna0Z401AYDpvWOHQCfWtmo uJsdICFUEn3RZbOjjonqmro= =WHu/ -END PGP SIGNATURE- -- Blog in Chinese http://www.awflasher.com/blog/ Blog in English http://www.ifgogo.com/
forcing mutt to use base64 encoding for all attachments
mutt experts - Is it possible to force 'mutt' to use base64 encoding for all attachments, irrespective of their real types / file extensions? if yes, then what do I need to mention in .muttrc file for this to happen? Please note that, I need this functionality when 'mutt' is invoked from command line. (I already know how to do this when 'mutt' is used as mail client) Thanks, Shiv.
deleting attachments
Hi,
I was wondering if there is an easy way to delete attachments from
postponed messages. For email which you receive the procedure is
clear ('v' and afterwards 'd'). In the postponed message menu
the d-key is reserved for descriptions. Perhaps somebody has a quick
solution or a macro defined.
Many thanks. Best, Michael
Re: deleting attachments
* Michael M. Tung [EMAIL PROTECTED] [03-04-08 07:39]:
I was wondering if there is an easy way to delete attachments from
postponed messages. For email which you receive the procedure is
clear ('v' and afterwards 'd'). In the postponed message menu
the d-key is reserved for descriptions.
try shiftd
--
Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711
http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2
Registered Linux User #207535@ http://counter.li.org
Re: DOS text file attachments.
Am 2008-02-07 00:14:02, schrieb Kyle Wheeler: What if the file had been left as-is, and the line endings had been recognized as not needing conversion? The receiver would receive a correctly encoded text/plain attachment, and when saving that attachment to disk, his MUA would convert the line endings to whatever the native scheme happened to be. There would be no extra lines, BUT the file's status as a DOS text file would vanish the instant the DOS was dropped from the label---there's no such thing as dostext/plain, after all. What I have already seen was: text/ms-dos Thanks, Greetings and nice Day Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: DOS text file attachments.
I think the point that the people on the Postfix mailing list were trying to make is that the MUA (in this case mutt) should not be sending something to the MTA that is marked as text/plain, but has CRLF line endings since text/plain on Unix has just LF line endings. Me, I don't know what should do what with what for this type of file. If it is converted by the MUA to have just LF line endings then the Windows PC I'm sending it to will still see it as a DOS text file since the MTA has to convert it to CRLF for the smtp protocol. Then again if the MTA noticed that the lines already had CRLF on the end and didn't convert it then that would work too. Also if the libmagic stuff noticed that a file was DOS text and reported it as application/octet-stream then I guess that would work too. Maybe I just tell mutt to use a shell script as the MTA and I get that to convert all text to LF line endings then pass it on to the real MTA. Would that work ? I assume all data from mutt to the MTA will be text ? i.e. already be base64 encoded if needs be ? Thanks everyone or your help. Scott. On Tue, Feb 05, 2008 at 12:08:07PM -0600, Kyle Wheeler wrote: On Tuesday, February 5 at 04:35 PM, quoth Michael Kjorling: On 5 Feb 2008 10:00 -0600, by [EMAIL PROTECTED] (Kyle Wheeler): The best way to send a DOS file, if it needs to *stay* a DOS file, is to compress it (e.g. to zip it) and send the compressed form. When it is decompressed, it will return to its original DOS form. This will obviously work. I was wondering though, if sent as an application/octet-stream MIME part, shouldn't the file be encoded by mutt in such a way that it can get reconstructed accurately on the receiver side? Yes, I know that calling plain text a/o-s is a borderline case, but sometimes compressing might not really be an option. (Say, if the recipient might want to read the attachment on a cell phone or PDA, which may not even be able to uncompress formats taken for granted on PCs.) Perhaps, though there are two considerations to that: first, encoding as a/o-s is a common spammer trick that most people do not employ (so it may get your message tagged as spam), and second, there's no guarantee that a cell phone or PDA can decode base64 either. Lastly, why would someone send a DOS text file to a cell phone (that's incapable of doing simple things like decompress zip files) in the first place? ~Kyle -- What progress we are making. In the Middle Ages they would have burned me. Now they are content with burning my books. -- Sigmund Freud
Re: DOS text file attachments.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, February 7 at 12:01 AM, quoth [EMAIL PROTECTED]: I think the point that the people on the Postfix mailing list were trying to make is that the MUA (in this case mutt) should not be sending something to the MTA that is marked as text/plain, but has CRLF line endings since text/plain on Unix has just LF line endings. Mmmm, I would put it slightly differently, because it depends on who should be responsible for MIME encoding: the MTA or the MUA. Each platform has it's own line-ending standard for plain old text files. On the other hand, text/plain has a very specific line-ending meaning in the context of MIME encoding. As specified in RFC 2046, section 4.1.1: The canonical form of any MIME text subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME text MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden. It seems clear, then, that in sending a MIME-encoded object, labeled text/plain, with the wrong line endings, someone is at fault. The line endings CANNOT be preserved if the file is to be sent encoded as a MIME text/* object. But, and here's the trick: it *WAS* correctly formatted. It's just that ordinarily, things are *NOT* correctly formatted. The MTA world has gotten so used to converting line endings on behalf of the user that the MUA world now rarely considers line-endings to be a problem they need to address (unless the MUA will be speaking SMTP directly). So who is wrong? Is mutt wrong for being inconsistent: handing incorrectly encoded text to the MTA most of the time but correctly encoded text some of the time? Or is the MTA wrong for being lazy and assuming that the MUA *always* sends incorrectly encoded text? In the end, I don't think it matters. What if the file had been left as-is, and the line endings had been recognized as not needing conversion? The receiver would receive a correctly encoded text/plain attachment, and when saving that attachment to disk, his MUA would convert the line endings to whatever the native scheme happened to be. There would be no extra lines, BUT the file's status as a DOS text file would vanish the instant the DOS was dropped from the label---there's no such thing as dostext/plain, after all. In the end, I think it all comes down to expectations. Mutt deals in text files, and expects that all files labeled as text files will be native text files (for the obvious reason that this is almost always a correct assumption). Text is a special-case MIME category: it is a category that indicates that line-ending preservation is unimportant and may be converted to whatever is most convenient. This is relatively easy to work around with proper labeling: the goal is simply to avoid labeling the file as something whose line-endings can change as necessary (in other words: *any* non-text label will work). For example, one could add a line to the mime.types file like this: application/dostxt dostxt Then all files ending in .dostxt will be safely base64 encoded before being sent. The file's line endings would be preserved, and all the recipient would have to do is decode the base64 encoding and rename the file back to ending in .txt. Unfortunately, there is no way to tell mutt that the .txt ending is ambiguous and files ending in .txt need to be handled two different ways depending on whether they're *native* text or weirdly-encoded text. Maybe I just tell mutt to use a shell script as the MTA and I get that to convert all text to LF line endings then pass it on to the real MTA. Would that work ? That would assure that the DOS file was correctly encoded as a text/plain attachment, yes. However, it would also make it impossible to identify as a DOS-text file on the recipient's end. It would appear as a DOS-text file on a Windows system, and as a Unix-text file on a Unix system, and as a Mac-text file on a Mac. So it depends on what problem you're trying to solve: if you're trying to send a DOS-file, intact, through email, this is a bad idea. If you're trying to send a recipient-dependent text file, no matter what format it's saved in on your own system, then this would work perfectly. At that point, though, I'd question why on earth you were dealing in DOS files on your Unix box. :) I assume all data from mutt to the MTA will be text ? i.e. already be base64 encoded if needs be ? Yes. Does that help? ~Kyle - -- If I were you, I'd run! - -- Mesh-Head If you were me, you'd be good-looking. - -- the Six-String Samurai -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHqqGqBkIOoMqOI14RAmcvAKCVXhBQgCRduyQdGLuToFBqmJxMIACfZc+q SgQrTqfWZB7RUzZJsDbTY50= =5W9G -END PGP SIGNATURE-
DOS text file attachments.
Hello I am having a problem sending a DOS text file as an attachment. I am running mutt version 1.5.11 on Linux, my MTA is Postfix. When I attach a DOS text file the mime type is text/plain and the encoding is 7bit. When the person at the other end (I get the same results sending it to myself) opens the attachment all lines are double spaced, i.e. each line has an extra CRLF on the end (when received on Linux it has 2 LFs on the end of each line rather than one). I have done some digging and it seems that postfix (the MTA) converts the LF at the end of each line into a CRLF so each line of the attachment ends up with CRCRLF, then something on the server adds the LF in the middle. I suspected that this was a postfix problem and so emailed the postfix list, discuss can be found here : http://groups.google.com/group/list.postfix.users/browse_thread/thread/4b881735fc266c39 which shows most of it. The summary of this is that since I am running on Linux text/plain MUST have unix line endings rather than DOS and so Mutt should convert the CRLF to LF before sending the file to the MTA. I was wondering what the mutt users thought about this.and if they could help me with my problem. Thanks Scott.
Re: DOS text file attachments.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday, February 5 at 03:27 PM, quoth [EMAIL PROTECTED]: The summary of this is that since I am running on Linux text/plain MUST have unix line endings rather than DOS and so Mutt should convert the CRLF to LF before sending the file to the MTA. I was wondering what the mutt users thought about this.and if they could help me with my problem. Mutt shouldn't go converting what you tell it to feed the MTA (mutt trusts the user not to tell it to do something silly). Unfortunately, email is NOT a reliable file transfer mechanism, especially if you're looking to preserve something like line endings. The best way to send a DOS file, if it needs to *stay* a DOS file, is to compress it (e.g. to zip it) and send the compressed form. When it is decompressed, it will return to its original DOS form. ~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! iD8DBQFHqIguBkIOoMqOI14RAmirAKC5MsZVhnvrAF9rh7BWoubJ2wqKAQCfQZZ4 G3Gvdi1D3ss0fzQb5na1Y7I= =OXbH -END PGP SIGNATURE-
Re: DOS text file attachments.
On 5 Feb 2008 10:00 -0600, by [EMAIL PROTECTED] (Kyle Wheeler): The best way to send a DOS file, if it needs to *stay* a DOS file, is to compress it (e.g. to zip it) and send the compressed form. When it is decompressed, it will return to its original DOS form. This will obviously work. I was wondering though, if sent as an application/octet-stream MIME part, shouldn't the file be encoded by mutt in such a way that it can get reconstructed accurately on the receiver side? Yes, I know that calling plain text a/o-s is a borderline case, but sometimes compressing might not really be an option. (Say, if the recipient might want to read the attachment on a cell phone or PDA, which may not even be able to uncompress formats taken for granted on PCs.) -- Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se * . No bird soars too high if he soars with his own wings . * * ENCRYPTED email preferred -- OpenPGP key ID: 0x(758F8749)BDE9ADA6 * * ASCII Ribbon Campaign: Against HTML mail, proprietary attachments * pgpiF7W5ardNe.pgp Description: PGP signature
Saving multiple attachments
Hi you again, Sometimes I receive msgs with lots of files attached. It's sort of boring to tag them one by one in order to save them. So I found the link below: http://wiki.mutt.org/?action=browsediff=1id=MuttFaq/Attachment I did exactly as text said, but the thing is that once I get the msg File is a directory, save under it? [(y)es, (n)o, (a)ll] nothing happens no matter which key I press... Am I doing something wrong or is it a bug? Thank you for your attention. -- Atenciosamente, Leonardo Caldas ICQ: 801133| Black holes are where god divided by zero. GTalk: leonardo.caldas | Skype: leonardo.caldas | Yahoo: leonardocaldas | Celular: 71-8821-9755 | signature.asc Description: Digital signature
Re: Finding All Attachments
* Bill on Wednesday, January 16, 2008 at 20:28:33 -0800 How would one go about finding all the emails which have attachments? With more recent versions of Mutt (than you are using) you can do limit (bound to l by default) ~X 1- Is there a way to list them in a unix 'ls' like listing, which would show the size and type of each attachment? Not exactly, but you can configure what ~X does. But for more precise info, you probably need an external script that analyzes your mailbox. Depending on your needs mairix http://www.rc0.org.uk/mairix might be worth looking into. c -- Python Mutt utilities http://www.blacktrash.org/hg/muttils/
Finding All Attachments
How would one go about finding all the emails which have attachments? Is there a way to list them in a unix 'ls' like listing, which would show the size and type of each attachment? Thanks, Bill
bug saving attachments
Hello, I received a file from a friend starting with '-': --=_NextPart_000_1cd4_6abd_704a Content-Type: application/vnd.ms-powerpoint; name=-Casamento.pps; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=-Casamento.pps; While saving the attachment, mutt prompted for the filename and presented the default of -Casamento.pps, that I accepted: Save to file: -Casamento.pps However, it didn't save to that file, but to a file with the '-' replaced to the last folder I was in: ~/Maildir/fooCasamento.pps mutt version: Mutt 1.5.14 (2007-03-31) Copyright (C) 1996-2007 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.6.23.12lcfs1 (i686) ncurses: ncurses 5.6.20070812 (compiled with 5.6) libidn: 0.6.14 (compiled with 0.6.14) Compile options: -DOMAIN -DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK -USE_INODESORT +USE_POP +USE_IMAP +USE_SMTP +USE_GSS +USE_SSL_OPENSSL -USE_SSL_GNUTLS +USE_SASL +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE ISPELL=/usr/bin/ispell SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/home/luciano/opt/i386/mutt/share/mutt SYSCONFDIR=/home/luciano/opt/i386/mutt/etc EXECSHELL=/bin/sh -MIXMASTER To contact the developers, please mail to [EMAIL PROTECTED]. To report a bug, please visit http://bugs.mutt.org/. Source: changeset: 5343:3cf8bc21bc3d branch: HEAD tag: tip user:Johan Svedberg [EMAIL PROTECTED] date:Wed Jan 02 11:47:33 2008 -0800 summary: Updated Swedish translation changeset: 5342:68a9c3e74f9a branch: HEAD user:Rocco Rutte [EMAIL PROTECTED] date:Tue Dec 11 15:22:44 2007 +0100 summary: Manual: Update caching docs (hcache naming, maintenance) changeset: 5341:d6e0b6f1f8ff branch: HEAD user:Rocco Rutte [EMAIL PROTECTED] date:Tue Dec 11 14:58:31 2007 +0100 summary: POP: Name hcache the way IMAP does. ... -- lfr 0/0 pgpiOoEV0jaM4.pgp Description: PGP signature
Re: bug saving attachments
Hi, * Luciano Rocha wrote: I received a file from a friend starting with '-': --=_NextPart_000_1cd4_6abd_704a Content-Type: application/vnd.ms-powerpoint; name=-Casamento.pps; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=-Casamento.pps; While saving the attachment, mutt prompted for the filename and presented the default of -Casamento.pps, that I accepted: Save to file: -Casamento.pps However, it didn't save to that file, but to a file with the '-' replaced to the last folder I was in: ~/Maildir/fooCasamento.pps Umm, that's not a bug but rather a feature. Mutt expands certain shortcuts in paths, including '!' ($spoolfile), '^' (current), '=' ($folder)... and '-' for the last folder opened. So it's rather undocumented, also see ticket #1719 (http://dev.mutt.org/trac/ticket/1719). Saving to \-Casamento.pps should work. Rocco
Re: bug saving attachments
On Jan 15, 2008 2:18 PM, Rocco Rutte [EMAIL PROTECTED] wrote: Hi, * Luciano Rocha wrote: I received a file from a friend starting with '-': --=_NextPart_000_1cd4_6abd_704a Content-Type: application/vnd.ms-powerpoint; name=-Casamento.pps; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=-Casamento.pps; While saving the attachment, mutt prompted for the filename and presented the default of -Casamento.pps, that I accepted: Save to file: -Casamento.pps However, it didn't save to that file, but to a file with the '-' replaced to the last folder I was in: ~/Maildir/fooCasamento.pps Umm, that's not a bug but rather a feature. Mutt expands certain shortcuts in paths, including '!' ($spoolfile), '^' (current), '=' ($folder)... and '-' for the last folder opened. So it's rather undocumented, also see ticket #1719 (http://dev.mutt.org/trac/ticket/1719). Saving to \-Casamento.pps should work. Shouldn't mutt prompt for \-Casamento.pps instead of -Casamento.pps ? -- Francis
Re: bug saving attachments
On Tue, Jan 15, 2008 at 02:18:33PM +0100, Rocco Rutte wrote: Hi, * Luciano Rocha wrote: I received a file from a friend starting with '-': --=_NextPart_000_1cd4_6abd_704a Content-Type: application/vnd.ms-powerpoint; name=-Casamento.pps; Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=-Casamento.pps; While saving the attachment, mutt prompted for the filename and presented the default of -Casamento.pps, that I accepted: Save to file: -Casamento.pps However, it didn't save to that file, but to a file with the '-' replaced to the last folder I was in: ~/Maildir/fooCasamento.pps Umm, that's not a bug but rather a feature. Mutt expands certain shortcuts in paths, including '!' ($spoolfile), '^' (current), '=' ($folder)... and '-' for the last folder opened. So it's rather undocumented, also see ticket #1719 (http://dev.mutt.org/trac/ticket/1719). Saving to \-Casamento.pps should work. Yeah, but as Francis mentioned, mutt should escape all magic chars from the attachment name. -- lfr 0/0 pgpztVPtN2a4y.pgp Description: PGP signature
Re: bug saving attachments
Hi, * Luciano Rocha wrote: On Tue, Jan 15, 2008 at 02:18:33PM +0100, Rocco Rutte wrote: So it's rather undocumented, also see ticket #1719 (http://dev.mutt.org/trac/ticket/1719). Saving to \-Casamento.pps should work. Yeah, but as Francis mentioned, mutt should escape all magic chars from the attachment name. Oh, escaping doesn't work as mutt treats the \ literally. So you need to prepend './' (like in deleting a file named '-f' in the current dir). That's what mutt should be abled to do more or less easily. Rocco
forwarding attachments
is there a .muttrc setting that will cause attachments to be forwarded? thx.
Re: forwarding attachments
Hi Ray! On Tue, 15 Jan 2008, Ray Stell wrote: is there a .muttrc setting that will cause attachments to be forwarded? thx. Look for the mime_forward setting. regards, Christian -- Congratulations! You are the one-millionth user to log into our system. If there's anything special we can do for you, anything at all, don't hesitate to ask!
Re: bug saving attachments
On 15 Jan 2008 16:23 +0100, by [EMAIL PROTECTED] (Rocco Rutte): Oh, escaping doesn't work as mutt treats the \ literally. So you need to prepend './' (like in deleting a file named '-f' in the current dir). That's what mutt should be abled to do more or less easily. If nothing else, it can be done through a macro. I do something very similar using a folder-hook to save attachments in a specific directory by default when in a particular mailbox. This should replicate the default behavior but prepend ./ to the file name when saving: macro attach s save-entrybol./eol But I agree, this is something that should be done automatically when the attachment file name begins with a character that has a special meaning in mutt-speak. -- Michael Kjörling .. [EMAIL PROTECTED] .. http://michael.kjorling.se * . No bird soars too high if he soars with his own wings . * * ENCRYPTED email preferred -- OpenPGP key ID: 0x(758F8749)BDE9ADA6 * * ASCII Ribbon Campaign: Against HTML mail, proprietary attachments * pgp4CJNAgJOMg.pgp Description: PGP signature
Colors vanish when I open email from attachments menu..
Hi, When I open the email from attachment menu, the colors of message, quoted text, doesn't show up. How to get this work? Please suggest.. -- Dilip
Re: Colors vanish when I open email from attachments menu..
=- Dilip M wrote on Tue 8.Jan'08 at 18:10:31 +0530 -= When I open the email from attachment menu, the colors of message, quoted text, doesn't show up. How to get this work? Please suggest.. Go back to normal pager mode with quit. Attachment mode is not meant for this flashy stuff. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
howto prevent loading of attachments in index-view (imap)
Hi, I use Debian Etch and connect via IMAP to a cyrus-server. In one directory / mailbox I have some really big e-mails (30 MB). I know that e-mail is no file-transfer-medium, but others don't ;-) Each time I open this mailbox this big messages is downloaded to my client, although I didn't open it. (still index-view). The index-view is sometimes rather slow (because of loading all big messages) and I use only a 400-800MHz PC (laptop). How can I stop mutt loading the mails (or only attachments) in index-view? Best regards, Paul -- signature.asc Description: Digital signature
Re: howto prevent loading of attachments in index-view (imap)
=- Paul Puschmann wrote on Fri 4.Jan'08 at 11:26:24 +0100 -= I know that e-mail is no file-transfer-medium, but others don't ;-) Each time I open this mailbox this big messages is downloaded to my client, although I didn't open it. (still index-view). See wiki faq + muttguide/ useimap. You probably have some user-defined ~h or ~b checks/ hooks for index view. -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
execute command on all attachments
How do I from within mutt apply a command (like scp) to all the attachment in the current message? -- - Eric Smith
Re: execute command on all attachments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday, November 8 at 10:02 AM, quoth Eric smith: How do I from within mutt apply a command (like scp) to all the attachment in the current message? Well... you can tag them all and pipe them to something, but that's about it. ~Kyle - -- Reality is that which, when you stop believing in it, doesn't go away. -- Philip K. Dick -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHMxqIBkIOoMqOI14RAirLAKDSkxBd58t0HOwMLCL5yCKm5IVAWgCguMFh zq9JzU8VtvUUbneopIlLCWw= =txYn -END PGP SIGNATURE-
how to cut attachments from mails...
Hi users how can I remove all attachments from a mail? The idea is, if someone send me a big mail with pictures, I save the images with 'save' and after, I want to archive the mail-text, whithout the (big) attachments. The simplest way is a macro in mutt to remove all attachments on the selected mail. Does anyone have a good and simple idea to do this? Thanks for any replies. raphi
Re: how to cut attachments from mails...
how can I remove all attachments from a mail? The idea is, if someone Delete them from the attachments menu. Normally this means pressing 'v' while viewing the message in index or pager, scrolling to the attachment you don't want, and pressing 'd'. When the folder is synced, the attachments will be gone. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago Polka music needs to prevail. John Ziobrowski, Polka America Corporation
Re: Problem printing doc-attachments
On Sep 18, Gary Johnson [EMAIL PROTECTED] wrote: I upgraded to Red Hat Enterprise Linux WS release 4 some months ago and had a similar problem. I fixed it by changing that line to this: application/msword; mutt_rem_bgrun openoffice.org-2.1 -view %s I need the mutt_rem_bgrun command because I run mutt on a Solaris machine and run viewers for MS attachments remotely on the Linux box. In your case, this might work: application/msword; ooffice -view %s I don't know if that will help, but it's something to try. Thanks for the response. I tried that openoffice startup paramater but it had no effect on this problem. Any suggestions still welcome. I put the same question to the Ubuntu and Openoffice forums, if a solution comes up I'll report here. Holger
Re: Problem printing doc-attachments
On 2007-09-18, Holger Lillqvist [EMAIL PROTECTED] wrote: Hi, I'm not certain this is the right forum to ask this question.. anyway. I recently switched Linux distribution (from Debian Sarge to Ubuntu Feisty) and since that I've the following problem printing mutt attachments using openoffice (mostly doc-attachments): my system is unable to use a running instance of openoffice to open the attachment. So going into the attachment menu and hitting enter at the appropriate line, the attachment is loaded into openoffice _only_ if there is no openoffice already running. Otherwise I get the oo error message /tmp/[file_name] does not exist. Any suggestions how to fix this problem? The relevant line in my .mutt.mailcap is: application/msword; ooffice %s I upgraded to Red Hat Enterprise Linux WS release 4 some months ago and had a similar problem. I fixed it by changing that line to this: application/msword; mutt_rem_bgrun openoffice.org-2.1 -view %s I need the mutt_rem_bgrun command because I run mutt on a Solaris machine and run viewers for MS attachments remotely on the Linux box. In your case, this might work: application/msword; ooffice -view %s I don't know if that will help, but it's something to try. Regards, Gary
Re: Problem printing doc-attachments
0n Tue, Sep 18, 2007 at 12:43:42AM -0700, Gary Johnson wrote: I need the mutt_rem_bgrun command because I run mutt on a Solaris machine and run viewers for MS attachments remotely on the Linux box. In your case, this might work: Where does one find details on mutt_rem_bgrun ? -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.
Re: Problem printing doc-attachments
On 2007-09-18, Wilkinson, Alex [EMAIL PROTECTED] wrote:
0n Tue, Sep 18, 2007 at 12:43:42AM -0700, Gary Johnson wrote:
I need the mutt_rem_bgrun command because I run mutt on a Solaris
machine and run viewers for MS attachments remotely on the Linux
box. In your case, this might work:
Where does one find details on mutt_rem_bgrun ?
I normally publish such scripts on my web page,
http://www.spocom.com/users/gjohnson/mutt, but this one seemed of
little general interest, so I didn't.
My desktop runs Linux, but I use Solaris machines for most of my
work. My home directory is accessible from all of them.
I read my mail on Solaris, but Linux has more tools for viewing MS
attachments, so I use this script to save the attachment file to a
temporary directory under $HOME and then run the viewer on Linux.
I leveraged most of the script from another I wrote, and which is on
my web page, mutt_bgrun. That runs a viewer on the local machine
but in the background so that the user can continue to use mutt.
The script is small enough that I'll just attach it.
The name of the Linux machine is hard-coded, so you'll have to
change that if you want to use it yourself.
Regards,
Gary
#!/bin/sh
# @(#) mutt_rem_bgrun $Revision: 1.1 $
# mutt_rem_bgrun - run an attachment viewer on a remote machine in the
background
# Copyright (C) 1999-2007 Gary A. Johnson
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
# SYNOPSIS
# mutt_rem_bgrun viewer [viewer options] file
#
# DESCRIPTION
#
# EXAMPLE
# To use gnumeric to view Excel attachments from mutt, add the
# following line to mutt's mailcap file.
#
# application/vnd.ms-excel; mutt_rem_bgrun gnumeric %s
#
# AUTHOR
# Gary A. Johnson
# [EMAIL PROTECTED]
prog=${0##*/}
# Check the arguments first.
if [ $# -lt 2 ]
then
echo usage: $prog viewer [viewer options] file 2
exit 1
fi
# Separate the arguments. Assume the first is the viewer, the last is
# the file, and all in between are options to the viewer.
viewer=$1
shift
while [ $# -gt 1 ]
do
options=$options $1
shift
done
file=$1
# Create a temporary directory for our copy of the temporary file.
#
# This is more secure than creating a temporary file in an existing
# directory.
tmpdir=$HOME/tmp/mutt/$LOGNAME$$
umask 077
mkdir $tmpdir || exit 1
tmpfile=$tmpdir/${file##*/}
# Copy mutt's temporary file to our temporary directory so that we can
# let mutt overwrite and delete it when we exit.
cp $file $tmpfile
# Run the viewer in the background and delete the temporary files when done.
(
remsh whiffle -n DISPLAY=$DISPLAY $viewer $options $tmpfile
rm -f $tmpfile
rmdir $tmpdir
) $HOME/tmp/$prog.errors 21
Re: how not to auto-load attachments?
Am 2007-08-24 13:26:29, schrieb Louis-David Mitterrand: Hi, When using imap with mutt-1.5.16 is there a way to not automatically load attachements when viewing the message body? No, since the attachments ARE the message body. Ideally when on a low-bandwidth connection I'd like to have access to the message text and select which attachments to download. I do not know a Imap-Server which allow this... Maybe Exchange? - Oops! Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSN LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: how not to auto-load attachments?
On Sat, Aug 25, 2007 at 02:00:14AM +0200, Michelle Konzack wrote: Am 2007-08-24 13:26:29, schrieb Louis-David Mitterrand: Hi, When using imap with mutt-1.5.16 is there a way to not automatically load attachements when viewing the message body? No, since the attachments ARE the message body. This seems to be an oversimplification. Actually, the message body consists of multiple parts, and IMAP provides mechanisms to selectively download some of the parts. (It also provides mechanisms to get a list of parts.) Kai
Re: how not to auto-load attachments?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday, August 27 at 11:18 PM, quoth Kai Grossjohann: On Sat, Aug 25, 2007 at 02:00:14AM +0200, Michelle Konzack wrote: Am 2007-08-24 13:26:29, schrieb Louis-David Mitterrand: Hi, When using imap with mutt-1.5.16 is there a way to not automatically load attachements when viewing the message body? No, since the attachments ARE the message body. This seems to be an oversimplification. Actually, the message body consists of multiple parts, and IMAP provides mechanisms to selectively download some of the parts. (It also provides mechanisms to get a list of parts.) Indeed. And, to my knowledge, EVERY IMAP server supports downloading specific MIME-encoded body parts. Read the RFC (3501), particularly where it talks about the FETCH command: BODY[section]partial The text of a particular body section. The section specification is a set of zero or more part specifiers delimited by periods. A part specifier is either a part number or one of the following: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT. An empty section specification refers to the entire message, including the header. Every message has at least one part number. Non-[MIME-IMB] messages, and non-multipart [MIME-IMB] messages with no encapsulated message, only have a part 1. Multipart messages are assigned consecutive part numbers, as they occur in the message. If a particular part is of type message or multipart, its parts MUST be indicated by a period followed by the part number within that nested multipart part. It goes into some depth about how one might go about requesting first the MIME structure of a message, and then asking for just specific pieces (e.g. you can ask for only the TEXT/PLAIN body sections). You can even request substrings of each component of the messages. I think Michelle must have confused IMAP for POP3 or something. ~Kyle - -- Asking whether machines can think is like asking whether submarines can swim. -- Unknown -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFG00JXBkIOoMqOI14RAhfRAJ4p5WTEnayx8ME+dfsg0CU1hAYIbQCgk53U uttwpLOmVKoQzDVnD0TwWgY= =7UYd -END PGP SIGNATURE-
Re: how not to auto-load attachments?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2007-08-24 13:26:29, schrieb Louis-David Mitterrand: When using imap with mutt-1.5.16 is there a way to not automatically load attachements when viewing the message body? Unfortunately, no, there isn't. Mutt's imap support is somewhat primitive, and mutt's underlying design doesn't currently make room for messages that are only partially available (to mutt, messages are either completely there, or entirely missing). It's certainly conceivable that mutt *could* develop this ability in the future (file a bug report and pester the developer!), it doesn't have the ability at the moment. ~Kyle - -- Next in importance to freedom and justice is popular education, without which neither freedom nor justice can be permanently maintained. -- James A. Garfield -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFG00NJBkIOoMqOI14RAkw/AJ4+VsFCUyhZTTh/6iFSbqc5/JrexgCgp1/b O57fXkGHkRC8Yyakh5jIMPs= =IuSa -END PGP SIGNATURE-
how not to auto-load attachments?
Hi, When using imap with mutt-1.5.16 is there a way to not automatically load attachements when viewing the message body? Ideally when on a low-bandwidth connection I'd like to have access to the message text and select which attachments to download. I tried running mutt with auto_view turned off but it didn't change its behaviour. Thanks,
attachments menu: macros
I often get PDF attachments that are mis-labeled. I use ^E in the attachments menu and replace the mime type, and all is well. I would like to add a macro to the attachments menu to do that for me in a more automatic way. But I can't; mutt doesn't accept :macro attachments I am using Mutt 1.4.2.1i. Raphael
Re: attachments menu: macros
On Mon, Apr 23, 2007 at 11:25:27AM -0400, Raphael Finkel wrote: But I can't; mutt doesn't accept :macro attachments The menu is named 'attach'. me
large attachments
hello, does anybody know if its possible to cancel the download of large email attachments or not download the data for the attachment at all unless it needs to be downloaded to be saved. It would be really useful to read the content of an email without having to wait for the attachment to download. Cheers, Matty. pgp5qg1Gfb3oj.pgp Description: PGP signature
show names of attachments in index
Is there a patch for this, that will show n number of attachments, each in a line below the main index line. Thanks Eric
Re: show names of attachments in index
On Mon, Mar 19, 2007 at 09:24:24PM +0100, Eric Smith wrote: Is there a patch for this, that will show n number of attachments, each in a line below the main index line. you can press 'v' on the index view... -- Javier Rojas GPG Key ID: 0xA1C57061 pgp6lvrm9UexX.pgp Description: PGP signature
Re: forwarding messages with attachments
* Derek Martin [2007.03.14 19:30]: I consider this to be utterly and completely broken, and I'm considering reporting it as a bug, but I'm waiting to see what other people think. From my limited understanding, when a message is mime-encoded, the *whole body* is a set of attachments, including what you refer to as the body, which is the part you composed before sending the message. So when you set mime_forward=yes, it's *consistent* to put the body of the original message as an attachment. I agree it's annoying, because we, as users, distinguish between the body and the attachments. But, and again if I'm wrong somebody correct me, mime doesn't make that distinction. So the behavior you (and I) want is actually a special case where you want the *first* attachment to be quoted but not the others, regardless of their mime type. Note that the behavior is perfectly ok when the attachments are not of type text/*. I guess what we need is a bit of control into the heuristics mutt uses to determine whether or not to quote the message when forwarding/replying. Note also that mutt is not *always* consistent. For example when in the attach menu, if there are multiple text attachments and I press e to edit the message, I get only the part I composed. Not the text attachments. I agree with Gary this is not a bug, but would be a nice feature. -- JR
Re: forwarding messages with attachments
On Thu, Mar 15, 2007 at 12:51:55PM -0400, Jean-Rene David wrote: * Derek Martin [2007.03.14 19:30]: I consider this to be utterly and completely broken, and I'm considering reporting it as a bug, but I'm waiting to see what other people think. From my limited understanding, when a message is mime-encoded, the *whole body* is a set of attachments, including what you refer to as the body, which is the part you composed before sending the message. It's not the encoding that I care about... it's the behavior of Mutt as I'm responding to the mail. When READING a mime-encoded message, mutt essentially treats the first plain text attachment as the message body, and does the right thing. However, when FORWARDING such a message, it does not treat this same attachment as a message body that you can respond to. How it gets encoded after I'm done with it is really irrelevant to me. The second issue is that it actually does include the HEADERS of the message in the editable body, along with the usual ---forwarded message--- blah blah... but it does not include the actual message body. I think that's definitely a bug, on both counts. If you're not going to give me the original body, what possible reason would I have for wanting the headers in the body? Including them goes against every reasonable standard for how to quote e-mail messages... If you're not sure what I mean, send yourself a message with attachments, and put something in the body. Then set mime_forward, and forward the message to yourself, and look at the message you get. I can't see any use case for the results being desirable. it's just plain yucky. CCing mutt-dev, since it seems this discussion needs to go there instead of here. Please REMOVE mutt-users if you reply. Thanks -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgpxHQFpfP6HO.pgp Description: PGP signature
forwarding messages with attachments
Please read carefully before you reply. I already know about mime_forward, forward_decode, mime_forward_decode, and mime_forward_rest... I've played with these vars quite a bit, and no combination of these appears to do what I want them to do. [Though, FWIW, the manual documentation on some of these could stand to be a lot clearer... i.e. what the hell does Controls the decoding of complex MIME messages into text/plain when forwarding a message actually mean, exactly?] Anyway... The problem is this: Often, I have mail which consists of a body, and several text attachments. The attachments very often are scripts or source code of some sort, attached with a type of text/plain. What I want to do is to be able to forward (or reply to) these messages to someone else, with the original body included in-line in my body, so I can comment on it. However, I *DO NOT* want the attachments included in-line, because this makes them very difficult to save separately (remember, they're individual programs -- albeit in plain text format). Is there a way to make Mutt deal with this properly? I can't imagine that the audience of Mutt (largely sysadmins and programmers and such) hasn't run into this problem before... The normal way I handle this is to save the original body to a text file, mime_forward the message components *excluding* the body, and then while composing my own body, read the original body into my editor, manually marking it up to distinguish it from what I've written. This is a solution, but it's a pretty sucky one. It was workable when I did this a lot less often, but in my new role, I find it happening a lot. It's giving me major headaches. I believe, based on perusing the manual, that mutt does not provide a way to do this. But I'm hoping that I've just missed something... and perhaps also that me mentioning it will encourage some ambitious young soul to fix it if it's not there. :) I'm getting too old to spend time hacking on my mailer... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgp37w3qkWc4e.pgp Description: PGP signature
Re: forwarding messages with attachments
On Wed, Mar 14, 2007 at 06:55:48PM -0400, Derek Martin wrote: Is there a way to make Mutt deal with this properly? I can't imagine that the audience of Mutt (largely sysadmins and programmers and such) hasn't run into this problem before... The normal way I handle this is to save the original body to a text file, mime_forward the message components *excluding* the body, and then while composing my own body, read the original body into my editor, manually marking it up to distinguish it from what I've written. Definitely interested in hearing the discussion on this one as well.. in the past I've relied on 'b' to bounce the message on to someone when I needed to preserve the attachments as-is, but this obviously doesn't allow you to (easily) edit the contents of the message first. At least not in a way compareable to how other mailers do it. Ray
Re: forwarding messages with attachments
On Wed, Mar 14, 2007 at 04:03:00PM -0700, Ray Van Dolson wrote: On Wed, Mar 14, 2007 at 06:55:48PM -0400, Derek Martin wrote: Is there a way to make Mutt deal with this properly? I can't imagine that the audience of Mutt (largely sysadmins and programmers and such) hasn't run into this problem before... The normal way I handle this is to save the original body to a text file, mime_forward the message components *excluding* the body, and then while composing my own body, read the original body into my editor, manually marking it up to distinguish it from what I've written. Definitely interested in hearing the discussion on this one as well.. in the past I've relied on 'b' to bounce the message on to someone when I needed to preserve the attachments as-is, but this obviously doesn't allow you to (easily) edit the contents of the message first. At least not in a way compareable to how other mailers do it. If bouncing is enough for you, then probably it will be enough for you to add this to your muttrc (or make a macro to do it when you need it, or something): set mime_forward But again, this does not (AFAICT) allow you to easily edit the original body. In fact, it's really annoying in another way: it includes the *headers* from the original message in-line in the body, but not the original body itself... But then the entire message is included (with headers) in the first attachment. I consider this to be utterly and completely broken, and I'm considering reporting it as a bug, but I'm waiting to see what other people think. It's shocking to me that people have not previously complained loudly enough about this to get it changed; but that just leads me to think that some people actually *like* this behavior, which boggles my mind. It might even bottle my mind. ;-) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgpgBhPYfP8w4.pgp Description: PGP signature
Re: forwarding messages with attachments
On 2007-03-14, Derek Martin [EMAIL PROTECTED] wrote: On Wed, Mar 14, 2007 at 04:03:00PM -0700, Ray Van Dolson wrote: On Wed, Mar 14, 2007 at 06:55:48PM -0400, Derek Martin wrote: Is there a way to make Mutt deal with this properly? I can't imagine that the audience of Mutt (largely sysadmins and programmers and such) hasn't run into this problem before... The normal way I handle this is to save the original body to a text file, mime_forward the message components *excluding* the body, and then while composing my own body, read the original body into my editor, manually marking it up to distinguish it from what I've written. Definitely interested in hearing the discussion on this one as well.. in the past I've relied on 'b' to bounce the message on to someone when I needed to preserve the attachments as-is, but this obviously doesn't allow you to (easily) edit the contents of the message first. At least not in a way compareable to how other mailers do it. If bouncing is enough for you, then probably it will be enough for you to add this to your muttrc (or make a macro to do it when you need it, or something): set mime_forward But again, this does not (AFAICT) allow you to easily edit the original body. In fact, it's really annoying in another way: it includes the *headers* from the original message in-line in the body, but not the original body itself... But then the entire message is included (with headers) in the first attachment. I consider this to be utterly and completely broken, and I'm considering reporting it as a bug, but I'm waiting to see what other people think. It's shocking to me that people have not previously complained loudly enough about this to get it changed; but that just leads me to think that some people actually *like* this behavior, which boggles my mind. It might even bottle my mind. ;-) I think it works to: 1. go to the attachment menu; 2. tag all the message parts; 3. type ;f (without quotes) to forward everything; 4. answer yes to Forward as attachments? ([no]/yes):; 5. save away the stuff that appears in your editor; 6. exit editor; 7. delete first attachment; 8. edit what was the second attachment; 9. insert stuff saved away previously. Never mind. Yuck! I've thought about fixing this on several occasions, but the gap between thinking about fixing it and actually fixing it has always been too great. One of my excuses has been that I thought I should first understand what all the mime forward settings do, and their behavior depends on the content-type and the associated mailcap rules, so the set of all combinations of settings and rules was discouragingly large. Also, I have a solution for forwarding messages with non-text attachments and I don't forward text attachments often enough to become irritated enough with the current behavior to find the time to fix it. As far as complaining about it goes: I figured that everyone else who works on the mutt code is just as busy as I am and if I couldn't find the time to do it, I couldn't expect anyone else to. I don't think it's really a bug, either, but a missing feature. Regards, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Mobile Broadband Division http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA
Re: mutt, gpg, inline, attachments
On Wed, Jan 31, 2007 at 10:58:10AM -0500, Kyle Wheeler wrote: On Wednesday, January 31 at 04:18 PM, quoth Stefan M??rkl: I know that officially this isn't possible, but can I make mutt sign and encrypt messages with attachments inline somehow? One of my contacts uses broken software so he can't handle PGP/MIME messages. However, it IS possible to encrypt/sign just the text-part of a message that includes attachments, you just have to be aware that an encrypted message with an attachment CANNOT encrypt the attachment. Alternately, you can use shar or something to make several files into one, gpg-encrypt it, and then insert that into the body. That's the poor man's attachment, and it seemed to work for Usenet for a few decades. Of course the recipient has to pipe it through sh to extract all the files, but... you have to use something to serialize/deserialize, since his mailer can't handle multipart MIME and if you don't want to send seperate emails. Or you could use tar and uuencode/uudecode, etc. Many ways, but obviously none as easy as installing a MIME compatible email client. A tyrant must put on the appearance of uncommon devotion to religion. Subjects are less apprehensive of illegal treatment from a ruler whom they consider God-fearing and pious. On the other hand, they do less easily move against him, believing that he has the gods on his side. That sounds like something Macchiavelli wrote in The Prince: ``Therefore, a prince doesn't need to have all the qualities mentioned earlier, but it is necessary that he appear to have them. I'll even add to this: having good qualities and always practicing them is harmful, while appearing to practice them is useful. It's good to appear to be pious, faithful, humane, honest, and religious, and it's good to be all those things; but as long as one keeps in mind that when the need arises you can and will change into the opposite. It needs to be understood that a prince, and especially a prince recently installed, cannot observe all those qualities which make men good, and it is often necessary in order to preserve the state to act contrary to faity, contrary to mercy, contrary to humaneness, and contrary to religion. And therefore he needs a spririt disposed to follow wherever the winds of fortune and the variability of affairs leads him. As I said above, it's necessary that he not depart from right but that he follow evil.'' ``When you are doing business with a religious son of a %*#!*, get it in writing. His word don't mean %#!@ with the good lord telling him how to $#@ you on a deal'' -- William Burroughs -- The driving force behind innovation is sublimation. -- URL:http://www.subspacefield.org/~travis/ For a good time on my UBE blacklist, email [EMAIL PROTECTED] pgpx4hXTsUYKT.pgp Description: PGP signature
mutt, gpg, inline, attachments
Hi, I know that officially this isn't possible, but can I make mutt sign and encrypt messages with attachments inline somehow? One of my contacts uses broken software so he can't handle PGP/MIME messages. Stefan -- Dipl.-Ing. Stefan Märkl | [EMAIL PROTECTED] Institute of Microelectronic Systems | http://www.ims.uni-hannover.de Phone: +49-(0)-511-762-19657 | Fax: +49-(0)-511-762-19694 pgplo8SKF0Plb.pgp Description: PGP signature
Re: mutt, gpg, inline, attachments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * On Wed, Jan 31, 2007 Stefan Märkl ([EMAIL PROTECTED]) muttered: I know that officially this isn't possible, but can I make mutt sign and encrypt messages with attachments inline somehow? One of my contacts uses broken software so he can't handle PGP/MIME messages. Yes, see $pgp_autoinline, $pgp_replyinline. Also adjustable in the pgp menu. (like I did for this message) HTH, Michael - -- I did this 'cause Linux gives me a woody. It doesn't generate revenue. (Dave '-ddt-` Taylor, announcing DOOM for Linux) PGP-Key-ID: 0xDC1A44DD Jabber: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFwLmDAWr0j9waRN0RAgH7AJwNsZovk5UiIvpLHz9AOz57eZILYgCg5mHV d74z87keML8niMHlSCMxgbM= =93cc -END PGP SIGNATURE-
Re: mutt, gpg, inline, attachments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, January 31 at 04:18 PM, quoth Stefan Märkl: I know that officially this isn't possible, but can I make mutt sign and encrypt messages with attachments inline somehow? One of my contacts uses broken software so he can't handle PGP/MIME messages. Make mutt sign them? Not without seriously patching it yourself. Here's why: Mutt signs the ENTIRE email, not just the message. That's one of the reasons PGP/MIME was invented: to allow entire MIME blocks, including attachments, to be signed and/or encrypted. However, it IS possible to encrypt/sign just the text-part of a message that includes attachments, you just have to be aware that an encrypted message with an attachment CANNOT encrypt the attachment. The way you'd encrypt just the text part is to, for example in your text editor, pipe that message to gpg with the appropriate flags. You can also do that from within mutt, after a fashion, by using the pipe-entry command. You can macro this to make it more convenient, but... you'll need to be careful not to make the macro too easily broken (e.g. it shouldn't rely on your current cursor position in the attachment list). ~Kyle - -- A tyrant must put on the appearance of uncommon devotion to religion. Subjects are less apprehensive of illegal treatment from a ruler whom they consider God-fearing and pious. On the other hand, they do less easily move against him, believing that he has the gods on his side. -- Aristotle -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFFwLySBkIOoMqOI14RAr2UAJ91+aqmAKyG0qm1NR4HWxiubGI12wCfcuuq o4Kl3yOZJ27obyRy41d3cMI= =g8Sw -END PGP SIGNATURE-
Re: mutt, gpg, inline, attachments
* On Wed, Jan 31, 2007 Kyle Wheeler ([EMAIL PROTECTED]) muttered: On Wednesday, January 31 at 04:45 PM, quoth Michael Tatge: * On Wed, Jan 31, 2007 Stefan Märkl ([EMAIL PROTECTED]) muttered: I know that officially this isn't possible, but can I make mutt sign and encrypt messages with attachments inline somehow? Yes, see $pgp_autoinline, $pgp_replyinline. Also adjustable in the pgp menu. (like I did for this message) That doesn't work for messages with attachments, as he is requesting. Oh, I oversaw that, Sorry. Not possible in this case. Michael -- Computers are like air conditioners. Both stop working, if you open windows. -- Adam Heath PGP-Key-ID: 0xDC1A44DD Jabber: [EMAIL PROTECTED]
Re: Viewing attachments with detached process while remianing in attachments menu
Hello Eric, Why not use metamail in a macro and pipe the whole message to it by detaching the whole process? If I open a pdf attachment, my viewer xpdf is always detached and i can continue reading my messages while xpdf stay open. Greetings Michelle Konzack Systemadministrator Tamay Dogan Network Debian GNU/Linux Consultant -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ # Debian GNU/Linux Consultant # Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: Problem displaying text/html mime attachments (solved)
Stefano Sabatini wrote: # textual session if [ -z display ]; then This will never be true. You meant to say the following there. if [ -z $DISPLAY ]; then Bob
Re: Problem displaying text/html mime attachments (solved)
On date Saturday 2007-01-20 12:20:36 -0700, Bob Proulx muttered: Stefano Sabatini wrote: # textual session if [ -z display ]; then This will never be true. You meant to say the following there. if [ -z $DISPLAY ]; then Yes, you're right, thanks! -- Stefano
Re: Problem displaying text/html mime attachments
On ons 17 jan 15:34, Stefano Sabatini wrote: Any suggestions? I've had the same problem with firefox. I've solved it by hitting enter twice. Then the first tab will be blank and the second one will have the html message. Give it a try. :-) -- Johannes Martinsson [EMAIL PROTECTED] 0736 - 345 661
Re: Viewing attachments with detached process while remianing in attachments menu
On Wed, Jan 17, 2007 at 04:12:27PM -0800, Gary Johnson wrote: image/*; mutt_bgrun xv %s; test=test $TERM != screen RunningX Is RunningX much like: test -n $DISPLAY When your sh -c exec display %s /dev/null 21 Instead of asynchronously forking off a process, you could also use a program that displays the image and immediately exits, avoiding a race condition with respect to mutt doing something to the original file after the handler exits. Various image viewing programs offer this (and don't necessarily imply that you lose the ability to do things with a GUI; they may fork off a child to handle such things, and have the parent exit when the child signals it is ready). command returns to mutt, mutt immediately overwrites the temporary file with nulls, then removes (unlinks) the file. Hmm, that's an unfriendly way to do it. I would open the file, unlink it, then overwrite it (presumably this is for privacy), then close the file descriptor. That way, if there are multiple links to the file, you don't overwrite them, leading to an elegant way of solving the race conditions mentioned in this thread; simply create an additional hard link and then invoke your handler on that. -- ``Unthinking respect for authority is the greatest enemy of truth.'' -- Albert Einstein -- URL:http://www.subspacefield.org/~travis/ pgpnrRv5jDbkn.pgp Description: PGP signature
Problem displaying text/html mime attachments
Hi all mutters. I'm facing this problem (don't remember when it started to issue). When I try to view a text/html attachment I get from my browser a similiar message: File /home/sds/tmp/muttIVsHqg not found. Check the location of the file and try again. I checked for the named file and I effectively couldn't find it. I have no auto_view commands in my muttrc and have this line in my ~/.mailcap: text/html; /usr/bin/epiphany --new-tab %s Any suggestions? Thanks in advance -- Stefano Sabatini Linux user number 337176 (see http://counter.li.org)
Re: Problem displaying text/html mime attachments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday, January 17 at 03:34 PM, quoth Stefano Sabatini: When I try to view a text/html attachment I get from my browser a similiar message: File /home/sds/tmp/muttIVsHqg not found. Check the location of the file and try again. I checked for the named file and I effectively couldn't find it. I have no auto_view commands in my muttrc and have this line in my ~/.mailcap: text/html; /usr/bin/epiphany --new-tab %s Mutt deletes the temporary file whenever the helper program exits, so that temporary files don't build up and lay around. If epiphany is just sending the URL to the master program and exiting, then that's what's going on. The solution is to do something like make a script to copy the temporary file elsewhere, or to make the helper program not exit right away, or to make mutt think there will be something to view (e.g. add copiousoutput to your mailcap file). ~Kyle - -- I have great faith in fools; my friends call it self-confidence. -- Edgar Allen Poe -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFFrjjlBkIOoMqOI14RAjBAAKDaTEvS2X8CT7ULv0lSbH6yzsh3YgCgwTCG DkV5XBrmy5uvUtDsX2lXfgI= =w+Ht -END PGP SIGNATURE-
Re: Problem displaying text/html mime attachments (solved)
On date Wednesday 2007-01-17 09:55:33 -0500, Kyle Wheeler muttered: On Wednesday, January 17 at 03:34 PM, quoth Stefano Sabatini: When I try to view a text/html attachment I get from my browser a similiar message: File /home/sds/tmp/muttIVsHqg not found. Check the location of the file and try again. I checked for the named file and I effectively couldn't find it. I have no auto_view commands in my muttrc and have this line in my ~/.mailcap: text/html; /usr/bin/epiphany --new-tab %s Mutt deletes the temporary file whenever the helper program exits, so that temporary files don't build up and lay around. If epiphany is just sending the URL to the master program and exiting, then that's what's going on. The solution is to do something like make a script to copy the temporary file elsewhere, or to make the helper program not exit right away, or to make mutt think there will be something to view (e.g. add copiousoutput to your mailcap file). So thanks Kyle you're right. I've tried both the copiousoutput solution (mutt will wait for the user to press a key while displaying an empty pager until the user will press the exit key, mutt will delete the temporary file and the browser won't be able to display it anymore), and this (somehow circonvoluted, but more closed to what I want since I don't want to change the usual mailcap behaviour) scripting solution. Now I have in my mailcap: text/html; ~/bin/web-browse %s and in ~/bin/web-browse: #! /bin/bash file=$1 # textual session if [ -z display ]; then links $file exit $? fi # graphical session # if this script is run by mutt (the parent process is mutt) if ps -u $USER -o pid,command | grep -q $PPID *mutt; then tmp_file=~/tmp/mutt-$$-$(date +%s) mv $file $tmp_file file=$tmp_file fi if ps -u $USER -o command | grep -q sawfish; then sawfish-client -q -e (select-workspace web-workspace-num) epiphany --new-tab $file else epiphany --new-tab $file fi In this way the script will mv the HTML file in a temporary file with a unique name and exit, while epiphany will continue to see the file (mutt will try to delete the original file which doesn't exist anymore, but it seems without complaining). The temporary file will be then automatically cleaned by a periodic cron script. Cheers -- Stefano Sabatini Linux user number 337176 (see http://counter.li.org)
Viewing attachments with detached process while remianing in attachments menu
Like in other mail clients I just want to press on the selected attachment and view it and then go down to the next and view it. So I may open any number of the attachments at one time. To detach I am using a mailcap recipe of: image/jpg; sh -c exec display %s /dev/null 21 When I concatenate in .muttrc or on the mutt colon command line as followS: view-attach exit The viewing does not work properly, (xview no-op and display gives an X windows fiule listing option). When I just go view-attach the viewing works fine but I get plonked into the Pager and have to exit from there. How do i fix this? Is it too much to ask that this works out of the box? Ot am I missing some things? Even nicer would be an open-all-attachment macro. Thanks Eric
Re: Viewing attachments with detached process while remianing in attachments menu
On 2007-01-18, Eric Smith [EMAIL PROTECTED] wrote: Like in other mail clients I just want to press on the selected attachment and view it and then go down to the next and view it. So I may open any number of the attachments at one time. That's how I have my mutt configured and it works very well. To detach I am using a mailcap recipe of: image/jpg; sh -c exec display %s /dev/null 21 I'm not sure how much difference it makes to our results, but I use this: image/*; mutt_bgrun xv %s; test=test $TERM != screen RunningX The test tries to keep me from trying to run xv in the wrong environment. We can ignore it here. The mutt_bgrun script copies the temporary file %s to another location, runs xv on that file in the background, and returns to mutt. It also removes the copy of the temporary file when xv exits. When I concatenate in .muttrc or on the mutt colon command line as followS: view-attach exit I assume that you mean that from the attach menu, you execute :exec view-attach exit The viewing does not work properly, (xview no-op and display gives an X windows fiule listing option). It works fine for me. When your sh -c exec display %s /dev/null 21 command returns to mutt, mutt immediately overwrites the temporary file with nulls, then removes (unlinks) the file. There is a race condition between the opening and reading of the file by your viewer and the writing and removing of the file my mutt. In the cases where your viewer fails, it probably loses the race. When I just go view-attach the viewing works fine but I get plonked into the Pager and have to exit from there. I assume just go view-attach means you execute :exec view-attach That should put you back in the attach menu, not in the pager. I don't know how you would get from the attach menu to the pager without an exit command. Did I miss a step? I also don't know why the viewer would work in this case but not in the previous case. As I recall from mutt's code, it doesn't do anything between the return of the system() call the executes the viewer and the overwriting and removing of the temporary file. How do i fix this? Is it too much to ask that this works out of the box? Ot am I missing some things? It should work fine, except for the race-condition problem. You can solve that to a degree by adding a sleep command to your viewer command, e.g., sh -c exec display %s /dev/null 21 sleep 2 That should give your viewer a chance to run before mutt proceeds. Of course you then have to wait 2 seconds, or whatever sleep time you choose, to regain control of mutt. Also, 2 seconds may not be long enough for some viewers. A better choice is the mutt_bgrun script or the equivalent. You can find out more about it here: http://www.spocom.com/users/gjohnson/mutt/#background Even nicer would be an open-all-attachment macro. That would be nice, but there doesn't seem to be a way to do that. For one thing, I don't see a way to tag attachments according to patterns the way you can tag messages from the index menu. For another, after manually tagging attachments in the attachment menu, the tag prefix (;) seems to have no effect when followed by an Enter. This may be a bug. I'm running mutt-1.5.12. HTH, Gary -- Gary Johnson | Agilent Technologies [EMAIL PROTECTED] | Wireless Division http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA
Re: Forward des attachments
Merci pour l'info ! La commande set auto_tag=yes m'était inconnue, mais elle me correspond parfaitement ! Je te remercie. From: Mickaël LEDUCQ [EMAIL PROTECTED] Date: 210303 Salut, Je suis nouveau mais je pense que la chose à faire est de : * tu tag tes messages avec t * puis tu appuyes sur ; pour dire que la commande suivante conserne les messages avec un tag ( tu peut te passer de cette commande si tu met set auto_tag=yes dans ton fichier de config ) * et apres tu tape f pour forwarder En resumé des commandes : t pour tagger ;f pour forwarder l'ensemble des attachements tagger Voila. Le vendredi 21 mars 2003 à 16:25, Ploum écrivait : Bonjour, Comment est-il possible avec mutt de forwarder plusieurs attachments d'un mail. En les taggant avec t dans la liste des attach puis en appuyant sur f, seul l'attachment en dessous du curseur est réellement sélectionné. Merci, Ploum -- Mickaël LEDUCQ GnuPG KeyID : 0xAD483D96 Registered Linux User #308711 @ http://counter.li.org Pour obtenir la clé publique, envoyer un mail vide avec comme object : GET 0xAD483D96
uuencode / mutt / attachments
When I use uuencode (uuencode somefile somefile2 | mail address) it comes across as an attachment in outlook but not in mutt. When I send an attachment from mutt to mutt (or outlook to mutt) it comes in as an attachment that doesn't require uudecode. I know that I can save the encoded version from mutt as a file and then use uudecode but the app I have doesn't know which is which before making the query. My question is this - can I use uuencode to send an attachment that mutt will see as an attachment without requiring the uudecode.
Re: uuencode / mutt / attachments
Hi, * John Haviland ([EMAIL PROTECTED]) wrote: When I use uuencode (uuencode somefile somefile2 | mail address) it comes across as an attachment in outlook but not in mutt. This is because Outlook means to know it better and interprets the begin file as an atachment. Realy it is no attachment. It is simply an encodet file, for mutt nothing else then normal text. So mutt does not display it as an attachment. When I send an attachment from mutt to mutt (or outlook to mutt) it comes in as an attachment that doesn't require uudecode. This is because it is a correct mime-attachment. With all the headers and so. My question is this - can I use uuencode to send an attachment that mutt will see as an attachment without requiring the uudecode. AFAIK no. You should use mutt -a file to send attachments from commandline. HTH HAND sascha sorry for my english ;) -- Fuer einen neuen Monitor bitte hier ==[X]== einen Nagel einschlagen. msg31891/pgp0.pgp Description: PGP signature
Re: uuencode / mutt / attachments
* John Haviland [EMAIL PROTECTED] [2002-10-19 00:46 (CEST)] My question is this - can I use uuencode to send an attachment that mutt will see as an attachment without requiring the uudecode. Is there any special reason tu use the 'outdated' uudecode? Why not using the base64, which seems to be supported by every mailer/MUA that supports MIME (by the way, MIME is how things are 'attached', uuencode was widely used before MIME, to insert files into the messages (not attached to them). -- Rafael C. Gawenda 2:346/7.549@fidonet Registered LiNUX user #93375 Computers are useless. They can only give you answers (Pablo Picasso) msg31892/pgp0.pgp Description: PGP signature
Re: saving several attachments in a specified directory
* jochen issing [EMAIL PROTECTED] [09-10-2002 13:56]: I recently received a message with a huge number of pictures attached. Now I want to store all these (or tagged ones) pics in a specified folder. Can anybody tell me how to do this? Perhaps a sample? Currently, mutt asks per file where and under what name this file has to be saved. IM(H)O these are not prompts you want to skip. I am just able to store the files in my home dir (default...) Change dir to the destination folder and fire mutt from there... -- René Clerc - ([EMAIL PROTECTED]) A Smith and Wesson beats four aces. -Canada Bill Jones msg31673/pgp0.pgp Description: PGP signature
Re: saving several attachments in a specified directory
jochen issing ([EMAIL PROTECTED]) muttered: I recently received a message with a huge number of pictures attached. Now I want to store all these (or tagged ones) pics in a specified folder. Can anybody tell me how to do this? Perhaps a sample? This has become an FAQ. Check the archives. HTH, Michael -- Oh, I've seen copies [of Linux Journal] around the terminal room at The Labs. (By Dennis Ritchie) PGP-Key: http://www-stud.ims.uni-stuttgart.de/~tatgeml/public.key
Re: saving several attachments in a specified directory - macro adds /path
* jochen issing [EMAIL PROTECTED] [2002-10-09 11:55]:
I recently received a message with a huge number of pictures attached.
Now I want to store all these (or tagged ones) pics in a specified
folder. Can anybody tell me how to do this? Perhaps a sample?
I am just able to store the files in my home dir (default...)
oh, my, this *is* a faq by now...
and the answer is: use a macro!
macro attach S save-messagebol/path
this makes the cursor jump to
the beginning-of-line (bol)
at the prompt for the filename,
thus adding the /path before
the filename (if there is one).
when you to to the attachments menu with
view-attachments ('v') then you can
tag-entry ('t') all the parts you want
to save and then use the tag-prefix (';')
command before you use save-entry ('s');
mutt will prompt you before saving each
entry (attachment/file/part), and the macro
will add the selected path automatically.
drawback:the /path is *fixed* in the macro.
workaround: maybe use $DIR_ATTACH in the macro..
wish:add an option to set the favourite
directory for saving attachments in.
(fefe - can you please add this to the faq?)
Sven [who will add this macro to the setup page]
--
Sven Guckes [EMAIL PROTECTED] http://www.guckes.net/mutt/the MUTT PAGES:
Binaries| Bugs| DOWNLOAD| History| Intro| Installation| Links| MailList| NEWS|
Patches| Philosophy| Pictures| Quotes| SETUP| Sites| Usenet| Users| Utilities|
Windows| Wishlist -- Comparison to Elm|.. Not for everyone!| Pet Peeves| Sigs.
Re: saving several attachments in a specified directory - macro adds /path
[ no cc to fefe ]
Hi,
* Sven Guckes [02-10-09 14:24:56 +0200] wrote:
[...]
wish:add an option to set the favourite
directory for saving attachments in.
Because mutt sucks in this particular sence I made a patch
which is kind of ``works for me''. It's attached.
How it works: It prepends the value of $attach_dir _before_
prompting so that one can change it from case to case.
bye, Rocco [ not cc'ing to mutt-dev ]
--- globals.h.orig Sun Aug 4 13:03:23 2002
+++ globals.h Sun Aug 4 13:03:42 2002
-34,6 +34,7
WHERE char *AliasFmt;
WHERE char *AttachSep;
WHERE char *Attribution;
+WHERE char *AttachDir;
WHERE char *AttachFormat;
WHERE char *Charset;
WHERE char *ComposeFormat;
--- init.h.orig Sun Aug 4 13:03:57 2002
+++ init.h Sun Aug 4 13:05:27 2002
-193,6 +193,11
** If set, Mutt will prompt you for carbon-copy (Cc) recipients before
** editing the body of an outgoing message.
*/
+ { attach_dir, DT_PATH, R_NONE, UL AttachDir, UL ~},
+ /*
+ ** .pp
+ ** Default location where attached files should be saved to.
+ */
{ attach_format, DT_STR, R_NONE, UL AttachFormat, UL %u%D%I %t%4n %T%.40d%
[%.7m/%.10M, %.6e%?C?, %C?, %s] },
/*
** .pp
--- recvattach.c.orig Wed Sep 26 12:33:09 2001
+++ recvattach.cSun Aug 4 13:07:50 2002
-379,7 +379,16
int append = 0;
if (body-filename)
-strfcpy (buf, body-filename, sizeof (buf));
+ {
+if (AttachDir)
+{
+ snprintf (buf, sizeof (buf), %s/, AttachDir);
+ strncat (buf, body-filename, _POSIX_PATH_MAX -
+ strlen (body-filename) - strlen (AttachDir)
+ - 1);
+}
+else strfcpy (buf, body-filename, sizeof (buf));
+ }
else if(body-hdr
body-encoding != ENCBASE64
body-encoding != ENCQUOTEDPRINTABLE
