91–100 of 217 posts
The new fad is "loop". And any loop should have a trigger. Rather having countless integrations, let all the triggers to got email, and those triggers trigger loops. I feel AI can kick off from personal/shared inboxes to deliver meaningful outcomes
Earlier quoted context omitted.
> I'm all for email being more secure, to the point that organizations (banks, governments, insurance companies) stop creating walled-email alternatives This will literally never happen. Email doesn't support the features that those messaging platforms need to have, such as recalling messages. The security layers are also only on the sender part, not on the receiver part, which banks care a lot more about.
I know this is only tangentially related, but recalling messages is horrible. I hate that so many services will allow people to send me a message, give me a notification with a preview, but then the message gets edited or deleted. If you drop a letter in a physical mailbox, or slide a paper underneath the door, you cannot get it back either. This whole philosophy of 'we allow destruction of messages in a shared chat'…
Earlier quoted context omitted.
> To have secure email I think html /css should be dropped from email support I don’t think that helps at all. We already know how to consume that securely, we do it billions of times a day in web browsers. > the inbox should work on an invite only basis. Basically you should pre-authorize the senders just like you add someone as friend on a social network. Yes. A fundamental problem with email is that the only thing…
> A “friend request” mechanism is one way of achieving this. But then you’re left dealing with spam “friend requests”, which is still something I have to take action on, filter out, or ignore — same as spam email.
Earlier quoted context omitted.
To have secure email I think html /css should be dropped from email support and the inbox should work on an invite only basis. Basically you should pre-authorize the senders just like you add someone as friend on a social network.
Email supports text. It's your client that's the problem. I'm happy in my text only Emacs heaven. I'm also happy with my custom 5 year old bert based spam detector which hasn't failed me once (unlike whatever gmail at work does). This post was sent from Emacs.
Fastmail’s spam filter is not very good.
What's the point of this article? The most I got was "email is here to stay," followed by some discussion of an MCP server for their proprietary mail platform. I particularly don't understand the constant fanfare around discussions of SPF/DKIM/DMARC. They're widely understood, published RFCs that have been around for at least 10-15 years, some of them longer. They're not obscure folk wisdom passed down through genera…
Earlier quoted context omitted.
To have secure email I think html /css should be dropped from email support and the inbox should work on an invite only basis. Basically you should pre-authorize the senders just like you add someone as friend on a social network.
Email supports text. It's your client that's the problem. I'm happy in my text only Emacs heaven. I'm also happy with my custom 5 year old bert based spam detector which hasn't failed me once (unlike whatever gmail at work does). This post was sent from Emacs.
Yes it does. However, I have sent messages to more than a few people who tell me that my message is completely empty. I have my client set to send text-only, no HTML, and apparently the system on the other side drops the HTML version altogether. Something on the other end only processes the HTML part. No HTML, no message.
(I believe these are Outlook/MS based systems, but I don't know for sure. It's certainly not ALL Outlook/MS systems that do this.)
For these people I have to set my client to send HTML. It's all well and good to blame them, but I can't make them do something. They may not even be in a position to do anything. And I don't have an option to tell them "too bad, so sad".
The email situation is really quite bad if you don't conform to the Big Three. I've run my own email infrastructure for a very long time, and it's quite irritating that when we get something good (like DMARC, SPF, etc) it gets forced by the Big Three because along with that we also get things like Google toying with the requirement that you have to have AAAA MX records too.
Earlier quoted context omitted.
I didn't know what JMAP was but upon looking it up, I agree
JMAP's been Fastmail's future of email since circa 2016 iirc; it seems unlikely Google will ever get on board (NIH?) so it's doomed to remain not completely standard and fairly niche/popular but struggling for (technical) support.
My favorite feature of JMAP is that it gives you a single, consistent API endpoint that works for native clients, webmail and programmatic clients (like, backup scripts and things like that). JMAP means you don't have to invent your own REST API for webmail. Unfortunately, gmail, yahoo mail and all the rest predate JMAP. So it doesn't really help them in the same way.
It'd be lovely to get thunderbird working with JMAP!
The easiest and best filter is to screen emails. Only emails that were screened in once go to your inbox. It's that easy. HEY.com introduced it, and I can't see email without it; that's why I integrated it into my TUI email client, neomd [1]. Since then, when I get an email from Amazon that lands in my "To Screen" box, I am automatically alerted and know it is potentially spam, because I have approved Amazon and legi…
This is basically where I (and I imagine many others) have landed with the telephone. Anyone not in my contacts goes to voice mail. Made my phone usable again.
Earlier quoted context omitted.
The gp isn't talking about spam using "secure message" as bait to open unwanted email. Instead, legitimate companies like banks, healthcare, etc tell users to click on a url link to their "Secure Message Center" to read or submit some critical information. It's often the only way to get the info the users need. E.g. if I open a payment dispute with the bank, the workflow they use is the Secure Message area. I can't j…
> The gp isn't talking about spam using "secure message" as bait to open unwanted email. No, this includes all messages from my doctor/healthcare. It's not mass spam. Theoretically I could want to know what's in the message, but not enough to visit a website I've been logged out of again, perform multi-factor authentication, navigate to the message center and find the message and then back it up manually.
As it happens, I already knew this because the previous bill 6 months ago also included this information, but the message itself was unique and important. Certainly, there would have been financial consequences if I didn't act on that information.
I would have preferred to receive the contents by actual message rather than having to log in to read it, but that's not an option they offer. It's certainly not safe to assume it can all just be ignored.
What's the point of this article? The most I got was "email is here to stay," followed by some discussion of an MCP server for their proprietary mail platform. I particularly don't understand the constant fanfare around discussions of SPF/DKIM/DMARC. They're widely understood, published RFCs that have been around for at least 10-15 years, some of them longer. They're not obscure folk wisdom passed down through genera…
- BIMI (I hadn't heard of that before) which seems like a very minor thing to be calling "the future of email"
- AI might be easier to trick that humans
On that second point, here's the exact text:
> A person reading a suspicious email might notice that the sender’s domain has an extra character, or that something about the request feels off. An AI assistant scanning your inbox for items that need action may not slow down to check those things.
That seems wrong (AI should be better at this than the average human), but let's assume that assertion is correct. It then says "authentication is the safeguard that should stop it before it ever reaches your mailbox". Except then, a few paragraphs down, it says "A scammer with a convincing look-alike domain and a properly configured DMARC record will still pass sender authentication checks." Ok, so authentication isn't a solution to the stated problem at all (it does solve a different problem). And unless I'm missing something, no solution is proposed. No statement is made about what the future actually looks like.
Like you said, what is the point of this article?