It's the end of 2019 and there still is no decent, usable, #PGP-enabled e-mail client that I could roll-out to regular, non tech-savvy users without feeling bad.
10 years ago that would have been #KMail. But KMail shot itself in the foot, knee, and hip with Akonadi.
#Thunderbird is... Thunderbird.
#Mailpile doesn't do writes to IMAP, so you either use *only* it, or not use it at all.
#Kube just crashed on me because I tried to reply to a signed e-mail.
Anybody any other suggestions?
@rysiek I can't help feel defeatist about email security given that it seems like a more viable option to store local maildir as an encrypted loopback file and then create a local MTA proxy that just buffers up outbound and inbound mail until you unlock your gpg-agent and then uses it to attempt to transparently encrypt and decrypt and use whatever MUA on unencrypted local maildir :/
@grimmware you're *almost* describing kuvert. That's how our infrastructure send signed and often encrypted e-mails from our services:
https://www.snafu.priv.at/mystuff/kuvert/
Fun fact, the "mustencrypt" option was added after we explicitly asked for it. 👍
I should really blog about how we use kuvert to encrypt outgoing automatic mail from our infrastructure; and how we use Schleuder3, offlineimap, and opensmtpd to have encrypted e-mail groups.
Before I do this, here's some stuff I dockerized for this:
https://github.com/occrp/kuvert
https://0xacab.org/schleuder/schleuder/
https://git.occrp.org/libre/schlocker-compose
https://git.occrp.org/libre/docker-opensmtpd
https://github.com/occrp/docker-offlineimap
@rysiek I used offlineimap for quite some time but found that it could sometimes get wedged due to intermittent connectivity so I switched to mbsync.
My use case was being able to do maildir-based email over a cell connection though... I wrote a daemon in golang to handle it all (testing for connectivity, fetching mail, flushing my msmtp mail queue) because apparently I like overcomplicating my life for the sake of the 3 minutes a year where I want to read my mail on my laptop on the tube.
@rysiek holy fucking shit the amount of my life that I've dedicated to my mail setup it makes no sense.
@kensanata @grimmware @rysiek no doubt a big portion of that is connected to the spam fight, & the collateral damage from incompetent admins using #spamhaus w/reckless disregard.
@grimmware @rysiek @kensanata I took the hard-ass approach b/c I felt that by complying with corporate greed and control I then become a supporter of it. Refusing to be part of the problem means running my own MX & refusing to correspond w/ @gmail and @outlook users. I've become a heavy fax user as a result. Fax is much more reliable than email.
@resist1984 @grimmware @kensanata
"Fax is much more reliable than email."
...words seldom uttered. But I get your point.
@rysiek
Just noticed your original post. A good option for lowtech users used to be #Hushmail since non-HM users could do all the key management. Now that HM has a cost that I usually can't impose on others, I often pimp #ElectronMail (& thus #Protonmail). It's worse than HM but it's a sad state of affairs these days. Anything else becomes too challenging for normies.
Hushmail? I’ll just leave this here: https://en.m.wikipedia.org/wiki/Hushmail#Compromises_to_email_privacy
ProtonMail has a nice approach to PGP where they actually follow OpenPGP standards (e.g. beta.protonmail.com uses WKD to fetch keys). Unfortunately the same doesn’t apply to SMTP/IMAP and the pricing structure is not really friendly to people with custom domains.
@wiktor @rysiek the steriod bust is well known, & what most ppl fail to realize is that #Protonmail has the same vulnerability. PM will cooperate with demands from relevant courts. Also, Swiss law has changed in the past couple yrs such that LEAs can compel subpoenas.
@wiktor @rysiek #Hushmail has foolishly given up the one advantage it had over #Protonmail: that non-users could interact with the keyring so dumb users need not bother. Both HM & PM impose key management burdens on low-tech users now.
@resist1984 @wiktor whoa, good background info there! Much appreciated.
@rysiek
Why Fax is more reliable than #Email
@rysiek
That presenter needs to read the article I linked.
He claims fax has zero reliability due to "dog can eat the fax" (in a despirate grasp for straws) & "paper out".
I'm not convinced that running out of paper leads to a "success" ack & also lost data when paper is refilled. If it's true then it has merit but still nothing like the astronomical list of email reliability problems.
@grimmware @kensanata
@rysiek
Regarding the vulnerability: it's a legit find and I applaud CCC for their work. But I think they overstate the popularity of T.30. And certainly color faxes are rare. JPG buffer overflow is a classic problem; interesting that they are still finding instances of that.
Of course the simple fix is to have the RX fax be standalone, not a LAN-attached MFD. For TX, it can be LAN-attached w/out inbound calls, or it can be a fax card.
@rysiek
The presenter's recommendation "stop using fax" is haphazard, as it neglects to account for how over-zealous anti-spam techniques have destroyed email. Convincing admins to understand & avoid collateral damage or to use PGP is a non-starter. Thick skulls.
I use fax as a protest statement. The crudeness of fax serves to spotlight that recipients aren't doing email right. And fax /just works/.
@rysiek
In any case, I appreciate the link. It's indeed useful info.
@resist1984 @rysiek @grimmware @kensanata Have you actually used a fax over an analog phone line? If not, you can emulate: print a paper document; scan it at 150DPI; add random noise; print what you scanned
@kravietz @kensanata @grimmware @rysiek I have faxed over PSTN as well as over SIP in serial w/PSTN. You seem to be talking about quality not reliability. I use this cmd to obtain a WYSIWYG fax doc: gs -q -dNOPAUSE -dBATCH -sDEVICE=tiffg3 -r204x196 -sPAPERSIZE="$paperform" -dFIXEDMEDIA -sOutputFile="$tiffg3_filename" "$src_pdf"
@rysiek @grimmware @kensanata @kravietz (where "$paperform" is either "a4" or "letter")
@resist1984 @kensanata @grimmware @rysiek well, it's not much of use if it reliably transfers unreadable bitmap isn't it?
@kravietz @rysiek @grimmware @kensanata have you tested that command? Your content is generated electronically. Rendering a vector PDF as a 200dpi fax is very readable. That can be fax-transmitted as-is; no need for scanning.
@kensanata @grimmware @rysiek @kravietz your concern for the "analog" line is a red herring, because the signal is digitally modulated with error correction over that analog line, so the receiving fax station gets an exact copy.
@kravietz @rysiek @grimmware @kensanata Have a look for yourself. I suggest writing a letter in #latex or libre office, exporting it as PDF, and running the #ghostscript command I posted.
@resist1984 @kensanata @grimmware @rysiek That's why I asked if you actually used a fax machine. In practice the quality of printed document was often total crap due to noise introduced by poor scanner on sender side, poor printer on recipient side (usually a thermal printer). Fax bandwidth was also rather small and on poor line it was taking ages to send a single page.
@resist1984 @kensanata @grimmware @rysiek I personally hated fax because what you got was a smudgy printout or a PDF (if you used computer fax) that was an embedded *bitmap* which you obviously couldn't copy & paste text from.
Some professions - especially lawyers - loved to print that crap and then fax it again, which further reduced quality.
@kravietz @rysiek @grimmware @kensanata copy-paste is both possible & non-essential. If a recipient wants to copy & paste, OCR makes that possible. I OCR most docs I receive as bitmaps as a standard practice.
@resist1984 @kensanata @grimmware @rysiek
If you're concerned about email privacy today a much more suitable solution would to produce a *text* PDF (as opposed to bitmap) and send over Magic Wormhole or any other P2P communication protocol abundance of which we have out there.
@kravietz @rysiek @grimmware @kensanata anything you do in email is subject to the tens of reliability pitfalls mentioned in this article https://oasis.code-cat.com/posts/1833714. Magic Wormhole does nothing for most of those issues. Indeed there are many superior options to email/fax/pstn, but you only have those options if the other party uses them to begin with.
@kensanata @grimmware @rysiek @kravietz To be clear, the thesis is not "fax is better than everything". The thesis is "fax is more reliable than email".
@kravietz @rysiek @grimmware @kensanata on rare occasions, the recipient I need to contact is using an email service that does not DNSBL residential IPs & where the service is not gmail, hotmail, outlook, yahoo, or other such PRISM junk. In those cases I send an encrypted PDF - assuming I can find a different channel to xmit the password.
@kensanata @grimmware @rysiek @kravietz to send a msgs back and fourth over a long term calls for both sides to install something special or unconventional (e.g. magic wormhole, Wire, etc). But you still have to make initial contact to negotiate that - to ask them to install something. Fax is more reliable than email for that initial contact.
@resist1984 @kensanata @grimmware @rysiek Well, you can chat over raw TCP using netcat - I routinely transfer large backups this way :) wormhole just simplifies that if NAT is involved.
@resist1984 @kensanata @grimmware @rysiek ...if you know his or her phone number.
@resist1984 @rysiek @grimmware @kensanata Absolutely, it's not trivial to run an email server. That applies to any federated service I'm afraid.
You need to cope with spam and other abuse (phishing, malware) and after 20 years Matrix or Mastodon will be most likely just as complex as email.
Fax is really simple architecture, you just need to know other party's number. Same as in P2P.
@resist1984 @rysiek @kensanata Legit, I spend a lot of time compartmentalizing to mitigate how much my data can play into a given data economy that I don't benefit from but I think you're on the money with just using a different mode of communication. SMTP is like, the old-school federated service but I just don't think we can retroactively plumb in security, privacy and confidentiality. It seems like too big a task.
Not that I have any particularly good alternative suggestions mind...