big mail problem
Hi I've got a big mail problem - as in moby of mobies unto the unttermost moby - yesterday I downloaded my mail as per usual, and as required by my agreement with TelstraClear. There was one email - no. 159 - that was clearly over 5MB, that took most of an hour to download. When I came to look for it, intending of course to send its author a thick ear, I couldn't find it anywhere in kmail. You'd think that an over-5MB file would be easy to find. Except it has disappeared. Firstly, is there a handy grep script that can search through MBOXes? Secondly, this smells like an attack vector. Download an invisible file through a visible email that deletes itself Does kmail have the kind of vulnerability that would allow the installation of a privilege-excalating binary? Thirdly, I was going directly in downloading my email, because of the major problems I have had with Telecom's lines being unreliable, thus making it difficult to sanitise my email by looking through the webmail interface. I regard Telecom's gratuitous line unreliability as the teleco equivalent of a gratuitous buffer overflow, and naturally, would like to see Telecom pay the consequences. Any help would be greatly appreciated. Thanks Wesley Parish -- Clinersterton beademung, with all of love - RIP James Blish - George Kelischek - To impress those high-tech computer types, tell them what an Ocarina really is: an animal-activated-solid-state-multi-frequency-sound-synthesizer. - Mau e ki, he aha te mea nui? You ask, what is the most important thing? Maku e ki, he tangata, he tangata, he tangata. I reply, it is people, it is people, it is people.
Re: big mail problem
On 28 May 2010 20:27, Wesley Parish wes.par...@paradise.net.nz wrote: Hi I've got a big mail problem - as in moby of mobies unto the unttermost moby - yesterday I downloaded my mail as per usual, and as required by my agreement with TelstraClear. There was one email - no. 159 - that was clearly over 5MB, that took most of an hour to download. When I came to look for it, intending of course to send its author a thick ear, I couldn't find it anywhere in kmail. You'd think that an over-5MB file would be easy to find. Except it has disappeared Is it still on the mail server? Firstly, is there a handy grep script that can search through MBOXes? You could search for a file larger than 5 megs in your email archive using the find command. find KMail's data directory -type f -a -size +5M -ls I'm sorry I have forgotten where the email is stored. I suspect somewhere in the ~/.kde tree. Secondly, this smells like an attack vector. Download an invisible file through a visible email that deletes itself Does kmail have the kind of vulnerability that would allow the installation of a privilege-excalating binary? Goodness only knows, but I suspect not. Kmail is a pretty well put together program. Thirdly, I was going directly in downloading my email, because of the major problems I have had with Telecom's lines being unreliable, thus making it difficult to sanitise my email by looking through the webmail interface. I regard Telecom's gratuitous line unreliability as the teleco equivalent of a gratuitous buffer overflow, and naturally, would like to see Telecom pay the consequences. Any help would be greatly appreciated. Thanks np -- Sincerely etc. Christopher Sawtell
Re: big mail problem
On Fri, May 28, 2010 at 8:27 PM, Wesley Parish wes.par...@paradise.net.nz wrote: Any help would be greatly appreciated. You might be more inclined to get help if you restricted your .sig to 3 lines or so, In the meantime I suggest you look at your mail server's logs and see if you can find out what happened.
Re: big mail problem
On Fri 28 May 2010 20:27:08 NZST +1200, Wesley Parish wrote: agreement with TelstraClear. There was one email - no. 159 - that was clearly over 5MB, that took most of an hour to download. When I came to look for it, intending of course to send its author a thick ear, I couldn't find it anywhere in kmail. Never mind. kmail is not the most reliable when it comes to indexing mail, but then I use it with mbox, which it is clearly not supporting well, e.g. it's unable to work our reliably when an mbox file has changed and therefore needs to be re-indexed, let alone locking the file when it modifies it. You failed to say what your mailstore is. Local disk? IMAP? By default, kmail stores everything under ~/.kde (it's easy to find), and like every other semi-modern MUA, i.e. one with a GUI, treats your mail as its private property to be guarded jealously from your tinkering. Firstly, is there a handy grep script that can search through MBOXes? Yes. At the shell prompt, type g r e p, followed by something smart, like a substring of the subject line. There's a faster way for you: use grepmail. There's an even faster way for you: use mutt -f. It's a workhorse as reliable as any you can get, and it never EVER fails. By comparison, you can kick all the good-looking stuff half way to inter-galactic space. Choose between easy to use and works well. Sad, but true. Secondly, this smells like an attack vector. Download an invisible file through a visible email that deletes itself Does kmail have the kind of vulnerability that would allow the installation of a privilege-excalating binary? Nobody knows, but historically it hasn't featured on the walls of shame, or not much that I remember anyway. Thirdly, I was going directly in downloading my email, because of the major problems I have had with Telecom's lines being unreliable, thus making it difficult to sanitise my email by looking through the webmail interface. [Telecom bla bla deleted] It's called fetchmail. Coupled with procmail and someone with a computer-clue it pretty rocks. Works better with a permanent connection though. I have a script which wraps fetchmail, and runs when *I* say it (not fetchmail wants to), and which carefully logs fetchmail's activity. Happy to give out copies BUT it's not in releasable state, i.e. needs local adaptation work (mainly editing constants). Volker -- Volker Kuhlmann http://volker.dnsalias.net/ Please do not CC list postings to me.
