Earlier quoted context omitted.
Just to make it clear, is this true if you use your own domain, or just if you use any of Fastmail's domains?
Seems to be just Fastmail domains but there might be some setup involved for custom domains. See their docs https://www.fastmail.com/help/technical/senderauthentication...
JMAP: Like IMAP but Not Really
101–110 of 235 posts
Re: JMAP: Like IMAP but Not Really
#102Earlier quoted context omitted.
fastmail lets you write complete scripts for filtering using the Sieve programming language. https://www.fastmail.com/help/technical/sieve.html
Holy cow, I will have to look into this. Thanks a ton!!
be sure to write your filters before receiving anything. Especially important if you're importing your email for the first time... and insanely annoying if you want to debug such an advanced filter.
as always with fastmail: It has great features... but always with a massive caveat.
Re: JMAP: Like IMAP but Not Really
#103>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind R…
At this point I guess any API that runs on top of HTTP is REST? Strange world.
Re: JMAP: Like IMAP but Not Really
#104Earlier quoted context omitted.
So you know that “we” don’t reinvent umbrellas, because “you” buy the same all the time?
I don't imagine who would waste their money in re-invented umbrellas, maybe it is an hipster thing.
Re: JMAP: Like IMAP but Not Really
#105> JMAP is not designed around a persistent network socket, so it’s perfect for webmail clients that connect, do stuff, then disconnect (which is exactly NOT how IMAP is supposed to be used) WTF? So, webmail was limited by the fact that it was running in a browser and thus had to use HTTP, which has semantics that don't really fit the needs of an email access protocol. Now, we do have stuff like websockets that would…
Most mail clients are running on mobile (judging by number of devices). Long-running connections on mobile are a bad idea because of network reliability and battery concerns.
And could you also explain how constantly making new connections makes things work more reliably over unreliable links? Like, does that allow you to transfer data when the network link is down? Does the fact that inside the TLS/TCP connection data is transferred via HTTP instead of IMAP somehow make the TCP connection work better over lossy links?
It would seem to me like the exact opposite should be the case, if it has any effect at all?
Re: JMAP: Like IMAP but Not Really
#106The main failure in mail standards is a lack of explicit utf8 clean support lhs@rhs -if this got fixed (it's often called universal acceptance) a lot of things about mail as an ecology would improve. I have view on the spam thing. The whole "your idea will not work because" meme is hugely destructive of innovation in email. It sucks energy and mindshare. It's classic old timer put down. What would (imnsho opinion) ha…
If paying to send email is your suggested solution, I can see why you don't like the meme in question. But the suggestion is rife with problems. How exactly are you going to get everyone to start paying for email, which is free today? If it's a parallel system, how are you going to get people to switch? Who are they going to pay?
The obvious downside is that since the system is fundamentally just cryptography it doesn't discriminate between spam and legitimate bulk mail (password resets, newsletters, mailing lists, etc.)
Re: JMAP: Like IMAP but Not Really
#107Earlier quoted context omitted.
So you know that “we” don’t reinvent umbrellas, because “you” buy the same all the time?
I don't imagine who would waste their money in re-invented umbrellas, maybe it is an hipster thing.
People buy cheap umbrellas, they suck, the people imagine better umbrellas that cost more: goto START.
A 9yo of my acquaintance is really inventive; he often says "what if we had something that would ...", yes, if you'd invented and developed that 50 years ago you'd have been a multi-millionaire.
A lot of inventions arise naturally out of a creative mind being confronted with the problem.
Re: JMAP: Like IMAP but Not Really
#108FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface. I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years. Seeing this new protocol is exciting, because JMAP i…
I've been a happy Fastmail customer too, until I was made aware that you can impersonate other Fastmail customers by just spoofing the email address. Their servers just happily accept it. SPF and DKIM all pass with flying colours, and the only way you'd know it's happened is if you have DMARC on and happen to notice a pass in the report you don't remember sending. Well, that is if the recipient doesn't reply to the s…
Re: JMAP: Like IMAP but Not Really
#109Earlier quoted context omitted.
Holy cow, I will have to look into this. Thanks a ton!!
filters cannot be applied retroactively, however. be sure to write your filters before receiving anything. Especially important if you're importing your email for the first time... and insanely annoying if you want to debug such an advanced filter. as always with fastmail: It has great features... but always with a massive caveat.
Re: JMAP: Like IMAP but Not Really
#110Earlier quoted context omitted.
I've been a happy Fastmail customer too, until I was made aware that you can impersonate other Fastmail customers by just spoofing the email address. Their servers just happily accept it. SPF and DKIM all pass with flying colours, and the only way you'd know it's happened is if you have DMARC on and happen to notice a pass in the report you don't remember sending. Well, that is if the recipient doesn't reply to the s…
SPF/DKIM are designed to prevent spam and not to prevent spoofing of From. There is a difference. SPF has nothing to do with the From header. And the DKIM signature does not have to match the sender’s domain, the signature can be that of any domain. This means that for practical purposes, anybody can send spoofed emails. That an email is signed with DKIM, that doesn’t mean much and it is meant to build a web of trust…
The average layperson will not get that. I'm fairly sure if my mother received an email that wasn't delivered to a their spam folder saying "Hey, remember that old copy of my birth certificate you have floating around? Could you send that. Also, CC my good friend bad_user@fastmail.com" that she would call me first - if I was reachable. Also is totally ignorant of digital signatures and most likely unable to verify any present anyway.
As much as I dislike Google and try to avoid their products and services at all cost, at least I have confidence this wouldn't happen with them. Not that I would go back, but it's still concerning.