#Tag
What's your take on #betterbird? I just found out about it and it looks like it has more fixes than Thunderbird, but I never strayed away from the latter.. 🐦
What's your take on #betterbird? I just found out about it and it looks like it has more fixes than Thunderbird, but I never strayed away from the latter.. 🐦
There have been various proposals for imposing a cost on sending email, to reduce the temptation to spam;
https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
I think imposing monetary cost is the wrong approach. But what about a system where verifying your email with a newsletter or mailing list issues their server a unique stamp? Which it can use as proof that you want email from them delivered.
Just thinking out loud here. Anyone have any ideas about implementing this?
Note for locals on this mass mail sending as-a-service ...
I've been saying for years that NZ Post is crazy not to get into commercial email hosting. After all, every public service and business expects an email address now. The NZ Post email inbox could be the digital PO Box.
Anyway, this mass mail sending business *definitely* seems like something they could be making money out of.
Coming back to the original topic, can we emulate the decentralisation of ATProto Relays in the field of mass email sending? So self/community-hosted Ghost instances don't need to pay protection money to get emails delivered to subscribers who've opted in to receiving them.
I'm thinking of an automated system where Bob clicks the link in a subscription verification email, and that sends a token to the email host approving mail from the address that will send newsletters.
(7/7)
There have been various proposals for imposing a cost on sending email, to reduce the temptation to spam;
https://en.wikipedia.org/wiki/Cost-based_anti-spam_systems
I think imposing monetary cost is the wrong approach. But what about a system where verifying your email with a newsletter or mailing list issues their server a unique stamp? Which it can use as proof that you want email from them delivered.
Just thinking out loud here. Anyone have any ideas about implementing this?
I still wish Ryan had stuck to his guns and kept BridgyFeb opt-out. So I could just interact with BS folks from my Mastodon account. Instead of having to set up an ATProto PDS to do it without the added friction of the opt-in dance.
But as with the decentralisation of ATProto Relays, the solution is probably having more bridge instances. Ideally one for every fediverse service whose community wants full social web interop. The MHOA can't brigade them all.
(6/?)
Coming back to the original topic, can we emulate the decentralisation of ATProto Relays in the field of mass email sending? So self/community-hosted Ghost instances don't need to pay protection money to get emails delivered to subscribers who've opted in to receiving them.
I'm thinking of an automated system where Bob clicks the link in a subscription verification email, and that sends a token to the email host approving mail from the address that will send newsletters.
(7/7)
I'm very disappointed to discover that a self-hosted Ghost can't actually send out newsletters by email.
It provides all the front-end for accepting subscribers and promising them new posts by email, and it's all turned on by default. But to send those emails, you need a paid account with a proprietary mail missile called MailGun.
EDIT: Not really Team Ghost's fault, see below.
(1/?)
This is the third and last in my series on #UX and #LLMs. It was the hardest to write as I (rather foolishly) take a stand on where we should go. My basic point is that the current AI bubble is going to pop. So what should replace it? I make the case that smaller, more energy-efficient, and more ethically trained models should be used for "boring" tasks. Our job is to solve problems, not look cool.
Laurel, which ran on the Xerox Alto at PARC, was the first email GUI client and had most of the features we still use today. And yes, the successor of Laurel was called Hardy.
This is the Laurel manual:
https://bitsavers.org/pdf/xerox/parc/techReports/CSL-81-6_Laurel_Manual_198105.pdf
Evaluating EU based email services, and everyone seems to flaws. @span startmail has no calendar, @span soverin has no ability to try it without fully committing your domain, @span mailbox_org gives an error when I try and register, and has no support contact for non customers, @span posteo.de doesn’t allow you to use your own domain, and of course @span Tutanota is locked in e2ee service meaning I am forced to use their app (same with Proton).
I sort of thought this would be easier.
#email
It's been a while, but our email newsletter is finally back online, and we are raring to keep you informed with more issues going forward!
You can read the first new issue on our web archive here, and get subscribed because there will be more to come very soon: https://www.privacyguides.org/newsletters/2025/09/10/were-back-and-so-is-chat-control/#/portal/signup
I can’t believe how easy it is to switch to @Tutanota and its excellent apps. I’ve been frustrated by how most alternatives to Apple Mail and Apple Calendar fall short. But Tuta Mail and Calendar work so well — including with my own domains. ⭐️⭐️⭐️⭐️⭐️ #email #calendar#ios #macos #apple#EUAlternatives
I can’t believe how easy it is to switch to @Tutanota and its excellent apps. I’ve been frustrated by how most alternatives to Apple Mail and Apple Calendar fall short. But Tuta Mail and Calendar work so well — including with my own domains. ⭐️⭐️⭐️⭐️⭐️ #email #calendar#ios #macos #apple#EUAlternatives
Vous allez à la Fête de l'Humanité ?
Cela tombe bien, nous aussi 👍
Venez nous rencontrer sur notre stand !
It's been a while, but our email newsletter is finally back online, and we are raring to keep you informed with more issues going forward!
You can read the first new issue on our web archive here, and get subscribed because there will be more to come very soon: https://www.privacyguides.org/newsletters/2025/09/10/were-back-and-so-is-chat-control/#/portal/signup
What do you use to automate #email management that is not notmuch?
What do you use to automate #email management that is not notmuch?
Hinweis:
Wer K9 Mail verwendet:
Die Version 12 ist kaputt. Bei mehr als einem eMail-Konto stürzt die App ab. Ist mit 12.1 gefixt, aber in F-Droid ist noch die buggy Version abgelegt (Stand 07.09, 12:00 Uhr).
Die korrigierte bitte dann von Github als apk verwenden:
Hinweis:
Wer K9 Mail verwendet:
Die Version 12 ist kaputt. Bei mehr als einem eMail-Konto stürzt die App ab. Ist mit 12.1 gefixt, aber in F-Droid ist noch die buggy Version abgelegt (Stand 07.09, 12:00 Uhr).
Die korrigierte bitte dann von Github als apk verwenden:
I find dealing with MIME parts (e.g., when troubleshooting email rendering) incredibly annoying. There's solid CLI tooling (e.g., ripmime) but it still involves a fair bit of poking to get the stuff you want.
Ended up vibe-coding (gasp) a quick solution for myself that uses fzf and ripmime together to make it easy to inspect mail parts. Sharing in case it's useful for anyone else - let me know if so, and I'll clean it up a bit and give it a repo.
https://gist.github.com/eloquence/08c293e890f26fca350feec5125d8c54
A space for Bonfire maintainers and contributors to communicate
