Re: Privacy considerations when using mutt
Something I've not seen in this thread: surely the header cache, if used, will leak information onto your hard drive? -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench. - Gene Spafford
Re: Privacy considerations when using mutt
* Kyle Wheeler wrote: > It'll ask for my gpg password, decode it, etc. I can even then use > gpg-agent to store my passphrase and allow me to quit and restart > mutt multiple times without retyping the passphrase. With regard to gpg/gpg-agent and hibernating check this: http://lists.gnupg.org/pipermail/gnupg-users/2010-March/038327.html -- left blank, right bald pgpEfPOjlcLKo.pgp Description: PGP signature
Question on Attachment sent by Mutt
Hello, I meet with a problem sending emails with attachements by mutt. simplly like this: # code uuencode file_name file_name > att.email cat mail_message >> att.email mutt -s "Subject" recei...@somewhere.net < att.email with this script, I can send email with attachment very easy. and gmail users have no problem reading these. BUT, with some mail providers or clients can not read the attachments correctly. what they can see is only code like @#$!...@$!#!@#...@# Please somebody know what should I do to fix this problem? Thank you very much! -- Zhang Qi
Re: Question on Attachment sent by Mutt
On 11.05.10,15:50, Qi Zhang wrote: > Hello, > > I meet with a problem sending emails with attachements by mutt. > simplly like this: > > # code > uuencode file_name file_name > att.email > > cat mail_message >> att.email > > mutt -s "Subject" recei...@somewhere.net < att.email > > > with this script, I can send email with attachment very easy. and > gmail users have no problem reading these. > BUT, with some mail providers or clients can not read the attachments > correctly. > what they can see is only code like @#$!...@$!#!@#...@# > > Please somebody know what should I do to fix this problem? > Can you check with another file ending, like att.txt instead of att.email? Jostein
Re: Question on Attachment sent by Mutt
On Tue, May 11, 2010 at 12:15:33PM +0200, Jostein Berntsen wrote: On 11.05.10,15:50, Qi Zhang wrote: # code uuencode file_name file_name > att.email cat mail_message >> att.email mutt -s "Subject" recei...@somewhere.net < att.email with this script, I can send email with attachment very easy. and gmail users have no problem reading these. BUT, with some mail providers or clients can not read the attachments correctly. what they can see is only code like @#$!...@$!#!@#...@# Please somebody know what should I do to fix this problem? Can you check with another file ending, like att.txt instead of att.email? Since he's using shell redirects, that shouldn't matter: mutt can't use the extension to set the file type since it has no chance to see the extension. My question is why do it that way at all? The command "mutt -s 'Subject' -i mail_message -a file1 file2 ... -- recei...@example.com" should accomplish the same goal, but with less chance of errors. Ed signature.txt Description: Digital signature
Re: Privacy considerations when using mutt
Interesting responses! Thanks Kyle's idea of doing GPG on-the-fly decryption is interesting. But my question was, exactly what files do you need to decrypt? Obviously there are the config files, and the header cache, and the body cache if you have it turned on. Does mutt write information to any other files? Mutt would need to be configured so that all files that it writes to are located in a GPG-encrypted directory, including even any temporary files that mutt deletes when it quits. Yes, I can see that disk encryption may be the way to go for a laptop. But the world of full disk encryption still looks quite complicated to me right now. TrueCrypt may be the way to go. The new version of Ubuntu gives you the option to encrypt your homedir when you install it. I haven't looked into how this works, and whether temp directories and swap space etc. are also encrypted. I like the idea of keeping your data off your laptop in the first place. If you have a remote server (either in your home or controlled by someone else) then you can ssh into it from any machine and run mutt. If you always do your email this way your laptop should more or less be clean, ignoring the possibility of people attacking your RAM and that sort of thing. (lets call that _too_ paranoid for now). I think if you used a remote server and additionally used GPG on-the-fly decryption for all files that mutt writes on the server that might be pretty safe. It could also be pretty convenient, having access to the same mutt setup from any machine, and you could even download the emails to the server and run mutt over a local maildir instead of IMAP, as long as you encrypt the maildir as well.
Re: Privacy considerations when using mutt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tuesday, May 11 at 09:21 PM, quoth chombee: > Does mutt write information to any other files? Mutt would need to > be configured so that all files that it writes to are located in a > GPG-encrypted directory, including even any temporary files that > mutt deletes when it quits. So you're worried about the safety of deleted files? Disk encryption may not guarantee that the message is never stored in memory (and thus potentially swapped to disk) un-encrypted, so you definitely need encrypted swap space. You can control where mutt puts its temp files (with $TMPDIR, according to the man page), so you can ensure that those are placed somewhere "safe". ~Kyle - -- Once again the conservative sandwich-heavy portfolio pays off for the hungry investor! -- Zoidberg -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iQIcBAEBCAAGBQJL6fdnAAoJECuveozR/AWehDQP/3ituKhkpG4+rJ+2/KoOuvNn 8nvHAxr6s5/+49fmAXzHd8gOW3W9K+lJt6ARcRsNhqmgg7iMlpgEXQNTphG1O3GY +HaKnBHIaNXpSeNEvEpwpFgYbdcq1IfJJ09BLpXH8EFBvn1yKLgpg5xYANrn7wn1 h/mcjfM4l/xTLN5sWh13BJ8hcejtpGRENQinfJ/rDmpYQ5/vX3+Kn7iLgKUJtUZX lhdAFV12/66CHxkkNkchzpQbRNyCW0COlhcHVzwVHjM/tJ/g63R13PPlEF+kYfch 4TEYR4WaWOCxmmyVdUE8qKfz1JtQH6LmTgmLl7o7Zwx/GmPLZCBhUsgXKey/gR8e se0yu/i9AD/8VgtH1y1gfzVLjy7a6vU0fGERMGcKj/Vv4S34ONHi/GTh2vX+IFhM sH8bM1SfQYAU41CJR+vaQ8pZOJBa2+uh1VSx476HYwPgWqGyHVxjObooGbp3uzW2 ELY4NP6awdjZUtmCwkgy4Ym0mjQPkIs6015z3QvTPFvgwXtXhqfZ1nl47bXwhrUW oP6g2zVGYV/UUSBryJopx8UMBV2mRZvAh/xtjVH8oggv13mD3YdGZ9zFQQ4Kx8JQ GnFe8we8a4Sx1vIZyo4uOzCocYwrjYk1L/rDlUXEXJ7I4WucIzLobduiNttjI9DT sY3hc/Jhw5HP1j+nfAQN =JTpQ -END PGP SIGNATURE-
Re: Privacy considerations when using mutt
On Tue, May 11, 2010 at 07:33:43PM -0500, Kyle Wheeler wrote: > So you're worried about the safety of deleted files? Disk encryption > may not guarantee that the message is never stored in memory (and thus > potentially swapped to disk) un-encrypted, so you definitely need > encrypted swap space. Actually now that you've pointed that out I'm not bothered about deleted files. It's obvious that only full disk encryption will take care of them. So for now I'm just interested in keeping all files that mutt leaves behind encrypted. > You can control where mutt puts its temp files (with $TMPDIR, > according to the man page), so you can ensure that those are placed > somewhere "safe". Thanks for that. I wonder if config files, header and body caches, and tmpdir covers it then? I guess this might be something that would need to be asked on the dev list.
Re: Question on Attachment sent by Mutt
Yes, because the attachments are generated by scripts then put into different folders. Each receiver has different amount of attachments. redirect mail attachments to a single file is more easy than use "-a file1 file2" I plan to use mail -s "Subject" recei...@example.com < att.email (This attachment is readable in hotmail, but mutt don't) but have some problem by setting the mail header. only thing I wanna to do is change the from address to another mailbox. Zhang Qi On Tue, May 11, 2010 at 10:53 PM, Ed Blackman wrote: > On Tue, May 11, 2010 at 12:15:33PM +0200, Jostein Berntsen wrote: >> >> On 11.05.10,15:50, Qi Zhang wrote: >>> >>> # code >>> uuencode file_name file_name > att.email >>> >>> cat mail_message >> att.email >>> >>> mutt -s "Subject" recei...@somewhere.net < att.email >>> >>> with this script, I can send email with attachment very easy. and >>> gmail users have no problem reading these. >>> BUT, with some mail providers or clients can not read the attachments >>> correctly. >>> what they can see is only code like @#$!...@$!#!@#...@# >>> >>> Please somebody know what should I do to fix this problem? >> >> Can you check with another file ending, like att.txt instead of att.email? > > Since he's using shell redirects, that shouldn't matter: mutt can't use the > extension to set the file type since it has no chance to see the extension. > > My question is why do it that way at all? The command "mutt -s 'Subject' > -i mail_message -a file1 file2 ... -- recei...@example.com" > should accomplish the same goal, but with less chance of errors. > > Ed > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFL6W9n3nrUNJhVPs4RAps5AKCCcNdlHm76PcsVrOug6sK25MNCnwCfbkzY > GGtMx7MqVVIMItlk8JjT3WU= > =2Orf > -END PGP SIGNATURE- > >
Re: Question on Attachment sent by Mutt
Does your version of mutt support the "-a" option which will generate proper mime-compliant header? Срд, 12 Май 2010, Qi Zhang писал(а): > Yes, because the attachments are generated by scripts then put into > different folders. > Each receiver has different amount of attachments. > redirect mail attachments to a single file is more easy than use "-a > file1 file2" > I plan to use mail -s "Subject" recei...@example.com < att.email (This > attachment is > readable in hotmail, but mutt don't) > but have some problem by setting the mail header. only thing I wanna > to do is change > the from address to another mailbox. > > > Zhang Qi > > > On Tue, May 11, 2010 at 10:53 PM, Ed Blackman wrote: > [---=| TOFU protection by t-prot: 39 lines snipped |=---] -- regards, GPG key 1024D/4434BAB3 2008-08-24 gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
Re: Question on Attachment sent by Mutt
My Mutt version is 1.4.2, buildin with Centos 5.4 If I use -a option, everything goes well. But I should write more bash scripts on how many attaments for each receiver, with the file name and email address. Zhang Qi 2010/5/12 bill lam : > Does your version of mutt support the "-a" option which will generate > proper mime-compliant header? > > Срд, 12 Май 2010, Qi Zhang писал(а): >> Yes, because the attachments are generated by scripts then put into >> different folders. >> Each receiver has different amount of attachments. >> redirect mail attachments to a single file is more easy than use "-a >> file1 file2" >> I plan to use mail -s "Subject" recei...@example.com < att.email (This >> attachment is >> readable in hotmail, but mutt don't) >> but have some problem by setting the mail header. only thing I wanna >> to do is change >> the from address to another mailbox. >> >> >> Zhang Qi >> >> >> On Tue, May 11, 2010 at 10:53 PM, Ed Blackman wrote: >> [---=| TOFU protection by t-prot: 39 lines snipped |=---] > > -- > regards, > > GPG key 1024D/4434BAB3 2008-08-24 > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >
Re: Question on Attachment sent by Mutt
On Wed, May 12, 2010 at 11:50:20AM +0800, Qi Zhang wrote: > Yes, because the attachments are generated by scripts then put into > different folders. > Each receiver has different amount of attachments. If I understand correctly, this is trivial to do with mutt in a script, unless your attachment filenames can contain shell special characters or whitespace. The shell deals badly with that, unfortunately. Otherwise, if your attachment directory is in $dir, then something like this should do what you need: cd $dir attachments=`echo *` # DO NOT quote $attachments, so each is treated as a separate arg mutt -s "$subject" -i "$message_file" -a $attachments -- "$recipient" -- 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. pgp5xGzdK7u3l.pgp Description: PGP signature
