How I recovered a lost email from my email client’s memory
ctrl.blog
ctrl.blog
and
> I might have been able to partially recover the message from the Draft folder if I’d retained my cool and acted immediately. It had been overwritten by an empty message instead. I must look into versioning my email draft folder at a later time.
This person has a much greater tolerance for shitty software than I do. I'm certainly not a perfectionist and appreciate that almost all software has bugs, but come on! Arbitrarily deleting draft emails twice a month for two years? Requiring convoluted versioned draft folders to work around this glaring issue? Why are they punishing themselves like this?! They must find something really awesome about Evolution to deal with this level of annoying.
Its no wonder that it will never be the year of the Linux Desktop.
Newscommers to the email client market have all been proprietary subscription-based middleware instead of actual email clients. The market has been standing mostly still for the last 10 years.
The three good options are KMail, Thunderbird, and Evolution. Everything else is CLI or lacks features like DAV.
KMail and Evolution both bring in the entire KDE/Gnome PIM suite with daemons and other programs, making them not great unless you are using Gnome or KDE - as another HN commenter said about Java web applications, you wanted a banana and instead got the entire jungle and an angry gorilla. But they do integrate very well. Thunderbird is standalone.
I tried Evolution for a week, about a month ago, and have used KMail and Thunderbird a lot.
KMail is fully-featured, with native support for CalDAV/CardDAV and 'send later.' But it's incredibly complex and easy to misconfigure. When upgrading to a new computer recently, I tried doing an export => import to transfer data, but it apparently permanently borked the KMail installation on the new computer. Tried uninstalling/reinstalling and deleting all KDEPIM-related files in ~, and it still would not work... Even on my old computer I still kept Thunderbird installed along with KMail sometimes didn't work properly.
Thunderbird is very straightforward to use and is quite stable. I use the TbSync add-on (Thunderbird has an official add-on repository like Chrome/Firefox). You'll also need the 'Provider for CalDAV & CardDAV', which adds that functionality to TbSync but is distributed as a separate add on.
Set up cal/carddav account, then go to calendar, right click the toolbar => Customize, and drag the 'Synchronize' button onto the toolbar so you can force a synchronization if needed (in addition to the timer-based background sync).
There's also a 'send later' add-on available. Aside from that, I only have a few minor issues with Thunderbird:
To switch between HTML and plain-text emails, you need to shift-click the 'compose new email' button. Can't switch in the middle of composing; you'll need to make a new email and copy-paste over. Changing the default from HTML to plain text requires going into about:config. And you can't enable/disable text wrapping on the fly for plain text emails; it's an about:config pref.
With Gmail accounts, it incorrectly lists the inbox/sent/etc. folders in a subfolder of the account (functions properly, but ugly). You have to right click the account, go to Settings => Server Settings => Advanced and set the IMAP Server Directory to '[Gmail]'.
Finally, TB has its own Spam filtering mechanism. You can't fully disable it. Even if you go to account settings and disable junk filtering for that account, it still shows a button to mark as junk and overrides the J key for that. Annoying if you are used to vim controls and press J often. Also J has the homing nub on the keycap so I like pressing it a lot...
KMail has all of this stuff built in / fixed, but is just way too complex and brittle.
Actually, after seeing your article's screenshot of Evolution with KDE titlebars, and a person replying suggesting that Evolution is good for this purpose, I'm trying it out on KDE. Never thought that would happen! I don't use signatures so hopefully this bug doesn't affect me... I did have to separately install the gnome-keyring package to get it to remember the IMAP/SMTP password but aside from that it appears to work fine.
> Thunderbird is the least worst option (in our opinions :).
I use TB when I use macOS. TB does weird thing to plain-text email formatting, though. E.g. it sometimes refuses to let me delete lines that contain "> ", and it sometimes freaks out when I try to insert al line break in a section of quoted text. (I reply inline, like a civilized emailer.)
> I tried Evolution for a week, about a month ago, and have used KMail and Thunderbird a lot.
I’ve used all three for years. KMail would be my preferred option if it was way more stable and less buggy. It has great features and I feel at home in it. But it works way less reliably than Evolution.
The version of KMail shipping on Flathub doesn’t even start. —and that’s when it’s running in a sandboxed environment that’s identical on everyone’s systems!
> There's also a 'send later' add-on available.
I know. https://www.ctrl.blog/entry/kmail-cve-2017-9604-openpgp.html On a related note, I couldn’t login to my IMAP account with KMail maybe ten years ago. My password back then contained an apostrophe. KMail didn’t encode it properly and would crash every time it tried to submit the password to the server. The bug also made it impossible to overwrite the saved password with a new one from the UI.
> Actually, after seeing your article's screenshot of Evolution with KDE titlebars.
The screenshot is manipulated, see disclaimer at the bottom of the article. It’s indeed running under Plasma, though.
Thunderbird feels wrong for some reason, and webmail doesn't let me have ten accounts in one place... I love being about to readily move an entire email folder to a different imap amount entirely with drag and drop.
I think it mostly just reminds me the most of Eudora so I just like it for being familiar.
(I've never encountered this bug, I guess I just don't have changing my signature in the workflow.)
I haven't personally used it, I just know that it shares a lineage (?) with the elementaryOS project, and they seem to be making great stuff.
Nope, there's at least three of us :)
It's by far my favorite client. Not only is the UI nice (for some reason I can't stand Thunderbirds UI), but it works well with integrations and multiple accounts.
I don't want to trawl through 'have you tried turning it off and on again' on Apple support forums, I want to find the text-based config solution in the Arch wiki, a man page, or unix.SE.
(Yes that order, not `man` first, typically. 'Sue me'. Other than for executables I don't find it that 'discoverable' for what's available or might be relevant. I only recently discovered `man [7] hier` - but how was I supposed to know the page is called 'hier' (for hierarchy of course, but even that)? I got it from a unix.SE answer.)
Really I guess I miss outlook for windows. There I’ve said it. Judge me if you will. Its search feature is broken, but everything else worked well.
He new that he could avoid it by not changing the signature afterwards.
The bug probably exists, and maybe with the magic set of configuration options, I could make it trigger too. But bugs can be finicky like that -- developers certainly don't like them, and it'll probably vanish pretty fast if they are able to reproduce it.
In the end I’ve always fallen back to Thunderbird as the least bad option.
also, emacs can be used as an email client
I haven't used it in anger though, I tend to stick to email in the browser these days.
Thunderbird is and will be for some time the only realistic least bad option. Once they replaced xul, perhaps updating its visuals will get easier.
The same approach works for recovering any secret information that people used on a computer that an attacker can access. Of course there are plenty of possibilities. But it’s eye opening to see them in action.
[1] https://www.cru-inc.com/products/wiebetech/hotplug_field_kit...
There may be still some exploits, especially when you consider that Linux kernel is not designed with security as its first priority, and over the last 20 years a lot of black magic has been developed to insert bad things into the kernel, but at least doing the countermeasures I mentioned will make it difficult. Hence, it's impossible to do any low-level changing or debugging on the system without rebooting it - which will immediately revert the system back to a "at rest" state, and triggers full-disk encryption. Other people may choose to do the opposite, it's a tradeoff between uptime and security.
Unfortunately, any attempt to introduce such a lockdown will be accused of being an evil technology that enables DRM. However, ultimately, the question is not whether a computer is locked down, but who is in control of the computer and it's locked down to protect whom.
[0] Don't confuse "memory scrambling" and "memory encryption". The vast majority of PCs today already use memory scrambling - the memory controller will "scramble" the data in RAM to a seemingly-random pattern using a Linear Feedback Shift Register, but it's done for electrical considerations - if there are too many 1s or 0s in a row, excessive current spike (di/dt) is produced, and it reduces signal integrity and creating excessive electromagnetic interference - LFSR-based scrambling is not for cryptography purposes and trivial to decode. On the other hand, memory encryption is a true solution that provides cryptographic protection to the RAM, and many hardware vendors have roadmap to implement it. Currently, it seems that there are two types, the first type is a "full memory encryption" - protecting RAM from physical access, the second type is "per-application memory encryption", which allows an application to request a segment of encrypted memory with an unique key - protect sensitive data of one application from accidental access by other programs. Both are helpful.
> no ptrace() to arbitrary process
Traditionally, ptrace() restriction is a grsec feature. But in mainline kernels, the same feature is available in the Yama module, see [0]. Use Yama with "kernel.yama.ptrace_scope = 3" will permanently disable ptrace() for all users, including root, and it cannot be enabled again. Then, you should also compile your own kernel, so you can disable /dev/kmem (CONFIG_DEVKMEM), /dev/mem (CONFIG_DEVMEM) and /proc/kcore (CONFIG_PROC_KCORE) in the Linux kernel. Also, I forgot to mention kexec(), which allows the attacker to execute another kernel without rebooting, so CONFIG_KEXEC should be disabled as well. And the list goes on and on, I think it's necessary to download an old grsec kernel, and using the configuration section of grsec as a checklist (and try disabling them using mainline technique if possible) if your security is serious business.
If you do these things, it will block the technique described in the original article.
[0] https://www.kernel.org/doc/Documentation/security/Yama.txt
These are called file carving tools and two better known ones are foremost and it's successor scalpel [1].
I did a thesis on file carving some 10 years ago, and scalpels ideas where very good back then. Photorec[1], however, has been the gold standard for a long time on (open source) file carving. It can handle text based formats way better (scalpel is severely limited in this aspect due to the "header/footer" paradigm), and is a wonder with stream based formats (that can have boundaries on the bit level).
And it's not because they authors weren't good[2], I think what mainly happened is that they didn't have the time to keep maintaining the software they created (I know that has happened to me more than once).
There are also some commercial file carving tools, though most are aimed at having better integration with forensics software (like Encase, FTK, Oxygen, etc) or automate parts of the process, like document analysis. Still, if you just want to compare them by their ability to recover files, I'm pretty sure Photorec makes it to the top.
[0] https://github.com/sleuthkit/scalpel
[1] https://www.cgsecurity.org/wiki/TestDisk_Download (PhotoRec is part of TestDisk)
[2] They're some of the best in the field of digital forensics
To add to your list of options there is also YARA when used with appropriate rules. I don't know how it stacks up against specialized tools though.
And it can also handle fragmentation (though I haven't tested the later versions to see how strong that is).
yes, but probably not a good idea?
https://www.pcworld.com/article/227948/Firefox.html
From Tom's Hardware:
"Lazarus: Form Recovery is a free downloadable Add-On for the Firefox web browser that automatically saves everything you type into forms of web pages you visit.
With Lazarus: Form Recovery, you will never lose what you write after a crash the browser or other technical problems. In the case when a problem, simply right click and select "recover form" to retrieve data previously typed."
However, that was for web forms, not an email client or other applications.
https://addons.mozilla.org/en-US/firefox/addon/form-history-...
May try out InScribe
Modern web email clients have this since a long time and Gmail never crashed internally for me ;)
Can't argue that there must be easier ways to handle email.
Some google services seem to be crashing the tab in my Firefox (but me only, since this bug has been there for many months now and I reported the crash with URL a bunch of times), I remember street view for sure but recently there was another, don't remember the name. (I don't use google services that frequently aside from pulling youtube content.)
Anyway, point is, browsers aren't infallible either and google is known to make their software work only in google-branded browsers. I'm not sure that a really stupid bug in $someSoftware is a good argument for why we should move everything into the browser, or a Google product in particular (why not bring up roundcube or runbox or something?).